RockteMQ-AI commented on issue #10521: URL: https://github.com/apache/rocketmq/issues/10521#issuecomment-4727496736
**Issue Evaluation** Category: `type/enhancement` | Status: **Evaluated** **Feasibility:** Feasible **Scope:** Store layer — `ConsumeQueue.correctMinOffset` binary search path **Compatibility:** Backward compatible (new config switch, default off) Strong production-validated proposal. The technical analysis is precise: 1. **Root cause identification** — 244x read amplification from kernel read-ahead on NVMe during binary search is a real and measurable problem. The observation that `posix_fadvise(FADV_RANDOM)` does NOT affect the mmap readahead path (`do_sync_mmap_readahead` only checks `VM_RAND_READ`) is correct and an important distinction that many miss. 2. **Solution approach** — Using `madvise(MADV_RANDOM)` before binary search and restoring `madvise(MADV_NORMAL)` in the finally block is the correct approach. The scope is narrow (only during binary search), so the impact on sequential read performance is contained. 3. **Config switch** — Defaulting to `false` is the right call. This allows gradual rollout and provides a safe fallback path. The naming `correctMinOffsetMadviseEnable` follows existing RocketMQ config conventions. 4. **Platform handling** — Skipping on Windows (no `madvise`) and relying on existing JNA LibC interface keeps the change dependency-free. 5. **Production evidence** — The benchmark data showing p99 send latency improvement from ~26ms to ~4ms is compelling. This directly addresses cloud disk bandwidth contention. This is a well-scoped, low-risk optimization with clear production benefit. Recommended for implementation. --- *Automated evaluation by RockteMQ-AI* -- 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]
