Details
-
Bug
-
Status: Resolved
-
Blocker
-
Resolution: Fixed
-
1.3.0
-
None
Description
After HDDS-6456 updated RocksDB version from 6.25.3 to 7.0.4, we started to experience OOM at Ozone Manager very quickly.
In our test environment, the OM memory stayed at around 3GB. But after that, OM memory quickly increase to over 100GB and crashed within 2 hours.
After some investigation and discussion with the RocksDB developers (https://github.com/facebook/rocksdb/issues/9962) we were able to isolate the issue to this particular breaking change: https://github.com/facebook/rocksdb/commit/99d86252b
Prior to the change, RocksDB 6 automatically reclaims native memory when the corresponding Java object is garbage collected. After the change (RocksDB 7), applications must proactively close the objects unused.
The biggest offenders are the RocksIterator. But there are many others. I'll file jira to clean up their usage. Unfortunately, SonarCloud doesn't seem to detect these unclosed objects.
Attachments
Attachments
Issue Links
1.
|
Close Rocks objects properly in OzoneManager | Resolved | Wei-Chiu Chuang | |
2.
|
Close Rocks objects properly in DataNode | Resolved | Duong | |
3.
|
Close Rocks objects properly in StorageContainerManager | Resolved | Attila Doroszlai | |
4.
|
Close Rocks objects properly in tools and Recon | Resolved | Duong | |
5.
|
Close Rocks objects properly in TrashOzoneFilesystem | Resolved | Attila Doroszlai | |
6.
|
Tracker to detect RocksObject leaks | Resolved | Duong | |
7.
|
Avoid leaking RocksObject from DBProfile | Resolved | Duong |