[HDDS-6722] Memory leak after updating to RocksDB 7

• Type: Bug
• Status: Resolved
• Priority: Blocker
• Resolution: Fixed
• Affects Version/s: 1.3.0
• Fix Version/s: 1.3.0
• Labels: pull-request-available
• Assignee: Duong
• Reporter: Wei-Chiu Chuang
• Created: 10/May/22 20:02
• Updated: 21/Jan/24 15:43
• Resolved: 17/Aug/22 23:46

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.

Issue Links

• is broken by: HDDS-6456 Update RocksDB Version to 7.x
• relates to: HDDS-5821 Improve the usage of RocksDB JNI interface
• links to: GitHub Pull Request #3646

Sub-Tasks

• Close Rocks objects properly in OzoneManager: Resolved
• Close Rocks objects properly in DataNode: Resolved
• Close Rocks objects properly in StorageContainerManager: Resolved
• Close Rocks objects properly in tools and Recon: Resolved
• Close Rocks objects properly in TrashOzoneFilesystem: Resolved
• Tracker to detect RocksObject leaks: Resolved
• Avoid leaking RocksObject from DBProfile: Resolved