Hao, Could you help to open a JIRA under HDDS-11508 < https://issues.apache.org/jira/browse/HDDS-11508> for this block delete request size exceeds the SCM raft log max message size issue than you found?
Thanks, Sammi On Mon, 28 Oct 2024 at 23:36, Ethan Rose <er...@apache.org> wrote: > Thanks for sharing Sammi. For deletion issues, see HDDS-11506 > <https://issues.apache.org/jira/browse/HDDS-11506> and its subtasks. > > - Proposed a key deleting service optimization, instead of iterating from > > first key of the table, save last key of last iterator as the start key > of > > next iterator, to skip the tombstones of already deleted record. > > > > Are there any benchmarks for how much improvement this has? In general I > feel it is better to keep the Ozone code simple and use RocksDB through its > interface instead of coupling our code to its internal details. Changes > like this can add permanent complexity to the Ozone code and may become > irrelevant as RocksDB upgrades improve performance. If there is > significant improvement it might be worth exploring though. > > - Found one issue that the block delete request exceeds the SCM raft log > > max message size when there are big MPU files involved. Should control > the > > block delete request size under the SCM raft log max message size. > > > This looks like it fits under HDDS-11508 > <https://issues.apache.org/jira/browse/HDDS-11508> > > Ethan > > On Sun, Oct 27, 2024 at 11:50 PM Sammi Chen <sammic...@apache.org> wrote: > > > Attenders: Hao, Weiming, Conway, Jianghua, Sammi > > > > Sammi：The new OM HA prototype shows times of improvement of OM > throughput. > > Weiming/Weiming/Jianghua: > > - Follower reader feature is used in production environment with a bit of > > customization. > > - Tencent Kona JDK 17 is used with G1 GC to replace the Open JDK 17 on > OM, > > which welly solve the OM GC problem triggered by threadLocal usage. > > GuoHao: > > - Found EC pipeline creation lock contention which causes P99 latency > > higher than expected, when there is intensive block allocation requests. > > Will investigate a) EC pipeline pre-allocation pool, and b) code refactor > > to reduce the lock scope, two solutions next. > > - Proposed a key deleting service optimization, instead of iterating from > > first key of the table, save last key of last iterator as the start key > of > > next iterator, to skip the tombstones of already deleted record. > > - Found one issue that the block delete request exceeds the SCM raft log > > max message size when there are big MPU files involved. Should control > the > > block delete request size under the SCM raft log max message size. > > >
