jemalloc分配64K、128K固定大内存耗时超300us如何优化？

• 64K、128K属于jemalloc的*大对象（large class）*范畴，默认配置下这类对象分配不会走线程缓存（tcache），每次分配都需要直接访问所属arena的内存资源、持有arena全局锁，高并发场景下锁冲突会直接导致分配耗时升高。
• 你观测到的2~3秒规律毛刺，完全匹配jemalloc默认的脏页回收（purge）触发周期：默认配置下jemalloc每3秒会扫描所有arena的空闲脏页归还操作系统，若后台异步回收线程未开启，回收动作会直接同步插入到用户的内存分配流程中执行，单次大页回收的耗时正好是百微秒级。
• 默认arena数量配置不足：jemalloc默认的arena数量为CPU核心数 * 4，如果业务并发线程数远高于这个值，多个线程会共享同一个arena，大对象分配时的锁冲突概率会指数级上升。

• 开启jemalloc后台异步回收线程，避免同步purge阻塞分配流程
  程序启动前设置环境变量 MALLOC_CONF=background_thread:true，或在代码中调用mallctl("background_thread", ...)主动开启即可。开启后脏页回收逻辑完全在后台独立线程执行，不会阻塞用户态分配请求。

  备注：如果使用jemalloc 4.x及更早版本，不支持background_thread参数，可设置dirty_decay_ms:-1关闭主动脏页回收（仅适合内存资源充足的场景，会提升进程的内存占用）。

• 调整arena数量，降低大对象分配的锁冲突
  在环境变量中新增narenas:<数值>，建议设置为业务并发线程数/4 ~ 业务并发线程数/2，最高不要超过128（过多arena会增加内存碎片）。示例配置：MALLOC_CONF=background_thread:true,narenas:32
• 针对64K、128K大对象开启tcache缓存，避免每次分配都访问arena
  默认配置下tcache只缓存≤32K的对象，可通过lg_tcache_max参数调整tcache的最大缓存对象大小：2的17次方为128K，设置lg_tcache_max:17即可让128K及以下的对象都走线程缓存，完全规避arena锁冲突。完整配置示例：MALLOC_CONF=background_thread:true,narenas:32,lg_tcache_max:17
• 可选调整：修改脏页回收频率
  开启后台线程后仍有零星毛刺的话，可调整dirty_decay_ms参数（默认3000ms即3秒），调大该值降低回收频率，或调小让回收更分散。比如设置dirty_decay_ms:10000可将回收周期拉长到10秒，减少回收触发次数。

• 调用malloc_stats_print()接口打印jemalloc运行状态，确认调整后的参数已生效
• 观测大对象分配耗时的毛刺分布，若毛刺消失或降至100us以内即说明调整生效
• 同步观测进程内存占用，确认调整tcache和arena参数后内存碎片率在业务可接受范围内

内容的提问来源于stack exchange，提问作者yuandaxing