geniusjoe commented on PR #25522: URL: https://github.com/apache/pulsar/pull/25522#issuecomment-4305285845
> @geniusjoe The back pressure for BK reads is handled by configuring `managedLedgerMaxReadsInFlightSizeInMB `. Please see https://github.com/apache/pulsar/blob/master/pip/pip-442.md for more details about broker memory management and related backpressure configuration. The memory limits aren't accurate since a Netty ByteBuf can be holding on to a larger underlying buffer where it was split off. > > In tuning, it's necessary to set the limits low enough that memory limit doesn't ever reach the scenario where Netty direct memory would run out. That might be impossible to achieve in all cases. One of the reasons is what you touched upon in #25274. Memory allocations, either pooled or "direct" (handled by malloc/OS), will cause fragmentation over time and there will be less memory available in certain workloads. > > > As mentioned in my comment [#25021 (comment)](https://github.com/apache/pulsar/issues/25021#issuecomment-3584774110), AutoMQ's blog post ["Challenges of Custom Cache Implementation in Netty-Based Streaming Systems: Memory Fragmentation and OOM Issues"](https://www.automq.com/blog/netty-based-streaming-systems-memory-fragmentation-and-oom-issues) describes some of the problems with fragmentation in the Netty PooledByteBufAllocator. The AutoMQ article doesn't evaluate AdaptiveByteBufAllocator. I'd assume that it handles caching usecases in a better way than PooledByteBufAllocator. It would be great to get some feedback from real tests. Lari, thank you for your response. I think the `managedLedgerMaxReadsInFlightSizeInMB` configuration you mentioned is a good workaround to avoid back pressure in bandwidth‑limited scenarios. I also agree with your point. Ideally, we could compare the two memory allocation algorithms—`AdaptiveByteBufAllocator` and `PooledByteBufAllocator` —under the same Pulsar conditions. By using the `top` command to observe the actual memory consumption of the Java process and leveraging the JVM’s Native Memory Tracking to obtain metrics on direct physical memory usage, we could likely reveal the performance differences between the two allocators. -- 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]
