That's actually also what I'm seeing most of the time and what I'd expect to improve with the newer RocksDB version. Hence, I'd also favour the upgrade even if there is a slight catch with respect to performance - we should, however, continue to investigate this together with the RocksDB community.
Nico On Wednesday, 4 August 2021 14:26:32 CEST David Anderson wrote: > I am hearing quite often from users who are struggling to manage memory > usage, and these are all users using RocksDB. While I don't know for > certain that RocksDB is the cause in every case, from my perspective, > getting the better memory stability of version 6.20 in place is critical. > > Regards, > David > > On Wed, Aug 4, 2021 at 8:08 AM Stephan Ewen <se...@apache.org> wrote: > > Hi all! > > > > *!!! If you are a big user of the Embedded RocksDB State Backend and have > > performance sensitive workloads, please read this !!!* > > > > I want to quickly raise some awareness for a RocksDB version upgrade we > > plan to do, and some possible impact on application performance. > > > > *We plan to upgrade RocksDB to version 6.20.* That version of RocksDB > > unfortunately introduces some non-trivial performance regression. In our > > Nexmark Benchmark, at least one query is up to 13% slower. > > With some fixes, this can be improved, but even then there is an overall > > *regression up to 6% in some queries*. (See attached table for results > > from relevant Nexmark Benchmark queries). > > > > We would do this update nonetheless, because we need to get new features > > and bugfixes from RocksDB in. > > > > Please respond to this mail thread if you have major concerns about this. > > > > > > *### Fallback Plan* > > > > Optionally, we could fall back to Plan B, which is to upgrade RocksDB only > > to version 5.18.4. > > Which has no performance regression (after applying a custom patch). > > > > While this spares us the performance degradation of RocksDB 6.20.x, this > > > > has multiple disadvantages: > > - Does not include the better memory stability (strict cache control) > > - Misses out on some new features which some users asked about > > - Does not have the latest RocksDB bugfixes > > > > The latest point is especially bad in my opinion. While we can cherry-pick > > some bugfixes back (and have done this in the past), users typically run > > into an issue first and need to trace it back to RocksDB, then one of the > > committers can find the relevant patch from RocksDB master and backport > > it. > > That isn't the greatest user experience. > > > > Because of those disadvantages, we would prefer to do the upgrade to the > > newer RocksDB version despite the unfortunate performance regression. > > > > Best, > > Stephan -- Dr. Nico Kruber | Solutions Architect Follow us @VervericaData Ververica -- Join Flink Forward - The Apache Flink Conference Stream Processing | Event Driven | Real Time -- Ververica GmbH | Invalidenstrasse 115, 10115 Berlin, Germany -- Ververica GmbH Registered at Amtsgericht Charlottenburg: HRB 158244 B Managing Directors: Yip Park Tung Jason, Jinwei (Kevin) Zhang, Karl Anton Wehner
