Skip to content

Conversation

@jt2594838
Copy link
Contributor

By default, we use the native (JNI) LZ4 implementation, which is expected to be faster than the Java implementation.
However, the JNI mechanism has a drawback: native calls will hold the GCLock, which prevents GCs.
Consequently, if there are many parallel compression tasks, a typical scenario in IoTDB, GCs will be constantly blocked by native calls and can only run effectively for a short time.
OOM occurs when the CPU is not powerful enough to collect enough garbage during the limited GC time.

In this PR, the new configuration item "lz4_use_jni" allows the user to choose to adjust the LZ4 implementation.
When it is true (by default), TsFile will use the native implementation. Otherwise, it falls back to the Java implementation.
Although some performance loss is expected due to the less efficient Java implementation, reducing the chance of OOM when the GC pressure is high will reduce the need to hold GCLock.

@HTHou HTHou merged commit c731ba0 into develop Apr 29, 2025
10 of 11 checks passed
@HTHou HTHou deleted the add_switch_to_disable_native_lz4 branch April 29, 2025 01:51
jt2594838 added a commit that referenced this pull request Jun 16, 2025
jt2594838 added a commit that referenced this pull request Jun 16, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants