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. >