dosubot[bot] commented on issue #3059: URL: https://github.com/apache/hugegraph/issues/3059#issuecomment-4679765876
<!-- Answer --> This behavior aligns with a known design limitation. Here's what's likely happening: **The 85% threshold triggers GC but can't reclaim everything** because the memory isn't all garbage — much of it is actively held by: 1. **Accumulated task results in backend storage.** While completed tasks are removed from the in-memory `ConcurrentHashMap`, their results persist as `~task` and `~taskresult` vertices in the backend and get loaded back into memory when accessed [[1]](https://github.com/apache/hugegraph/issues/3057#issuecomment-4668834701). These are **never automatically cleaned up**. 2. **Vertex/edge caches (LRU, capacity-based only).** HugeGraph's caches evict based on capacity limits and TTL — there is no reactive memory-pressure eviction that shrinks caches when heap is high [[2]](https://github.com/apache/hugegraph/blob/9126c80e414c073b60fc074361b211cfb409e0eb/hugegraph-server/hugegraph-core/src/main/java/org/apache/hugegraph/backend/cache/CacheManager.java) [[3]](https://github.com/apache/hugegraph/blob/9126c80e414c073b60fc074361b211cfb409e0eb/hugegraph-server/hugegraph-core/src/main/java/org/apache/hugegraph/backend/cache/OffheapCache.java). So even under memory pressure, caches remain full up to their configured capacity. 3. **Off-heap RocksDB allocations** (memtables, block cache) are completely invisible to G1 GC and the 85% heap monitor. **What you can do:** - **Clean up old task results** — periodically delete `~task` and `~taskresult` vertices for completed tasks, especially any with large result sets. This is currently a manual operation [[1]](https://github.com/apache/hugegraph/issues/3057#issuecomment-4668834701). - **Reduce cache capacities** — lower `vertex.cache_capacity` and `edge.cache_capacity` so the LRU caches consume less heap. Also set a shorter `cache_expire` to let entries age out faster. - **Limit task result sizes** — configure `task.result_size_limit` to a smaller value so individual tasks don't accumulate huge results in memory. - **For large data exports**, avoid the task result mechanism entirely. Use shard/scan APIs or write results to external storage from within your Gremlin scripts [[1]](https://github.com/apache/hugegraph/issues/3057#issuecomment-4668834701). - **Tune `InitiatingHeapOccupancyPercent`** — your current setting of 40 is reasonable, but with 16GB heap and long-lived objects, G1 mixed GC may not keep up. Consider adding `-XX:G1HeapWastePercent=5` and `-XX:G1MixedGCCountTarget=16` to be more aggressive about collecting old-gen regions. The core issue is that the 85% monitor can trigger GC, but if the heap is full of **live** objects (cached data, task results, RocksDB JNI references), GC has nothing to collect. The fix has to come from reducing what's held alive at the application level. <!-- Dosu Comment Footer --> *To reply, just mention [@dosu](https://go.dosu.dev/dosubot?utm_source=github&utm_medium=bot-comment&utm_campaign=github-comment-footer-20260415&utm_content=reply-with-mention&utm_term=apache%2Fhugegraph).* --- Docs are dead. Just use [Dosu](https://dosu.dev?utm_source=github&utm_medium=bot-comment&utm_campaign=github-comment-footer-20260415&utm_content=static-docs-tagline&utm_term=apache%2Fhugegraph). [](https://app.dosu.dev/response-feedback?utm_source=github&utm_medium=bot-comment&utm_campaign=github-comment-footer-20260415&utm_content=static-docs-feedback&utm_term=apache%2Fhugegraph&message_id=64478e70-67b9-4079-96a6-413c8c080457) [](https://github.dosu.com/apache/hugegraph?utm_source=github&utm_medium=bot-comment&utm_campaign=github-comment-footer-20260415&utm_content=static-docs-ask-repo&utm_term=apache%2Fhugegraph) [](https://app.dosu.dev/signup?referrer=openSource&source=github-footer&utm_source=github&utm_medium=bot-comment&utm_campaign=github-comment-footer-20260415&utm_content=static-docs-share-team&utm_term=apache%2Fhugegraph) -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
