如 http://jemalloc.net/ 所述：
jemalloc 是一个通用的 malloc(3) 实现，强调避免碎片化和可扩展的并发支持。
一些 Sphinx 和 Manticore Search 用户更喜欢 jemalloc 而不是 malloc，并表示它可以节省一些 RAM。我测试了 jemalloc 对资源消耗和响应时间的影响，持续了 2 周，在 3 个 Manticore 集群上（se03/03-2，se04/04-2，se05/05-2），每个集群：
- 接收相同数量的流量
- 托管大约相同数量的数据
- 拥有 2 台在硬件、软件方面完全相同的 Manticore 服务器，并且索引 100% 相同，甚至在服务器之间进行负载均衡
在 se03 和 se03-2 上，我启用了 jemalloc 并禁用了 THP（透明大页），并在 se03-2 上重启了 Manticore
在 se04-2 上，我只是重启了 Manticore，没有触碰 se04。se04/04-2 是一个对照组。
在 se05-2 上，我启用了 jemalloc，但没有禁用 THP
这是我在 2 周内得到的结果：
RSS RAM 消耗：
延迟动态（我使用了移动平均（响应时间））：
汇总延迟统计：
结论：
- RSS RAM：启用 jemalloc 无论是否禁用 THP，都使 searchd 的 RSS RAM 消耗减少了 **5-6%**2)
- 启用 jemalloc 而不禁用 THP（se05-2）使延迟 显著变差：平均（响应时间） - 增加 23%，95/99p 可能不受影响，因为差异在误差范围内（参见 se04/04-2 的对照组，那里没有任何变化）
- 启用 jemalloc 并禁用 THP（se03-2）使得：
- 平均延迟改善 10%**
- 95% 延迟变差 8%
- 99% 延迟改善 3.6%，但这在误差范围内，因此我们不能算这个
所以在这种情况下，我们需要决定我们更喜欢什么：
- 节省 5% RAM 并且平均延迟改善 10%，但对于 5% 较重请求的延迟峰值更高
- 或者保持现状：没有 RAM 节省，平均延迟变差，但对于较重查询的延迟更好
结果可能依赖于许多因素：硬件、工作负载（数据量、OPS 等），但看起来 jemalloc 是一个值得尝试的有趣东西，尤其是在大型安装中，节省 5% 可能意味着不需要购买几台新服务器。
如果您需要我们在您的安装中应用它的帮助，请告诉我们。我们也可以帮助您进行其他性能和资源优化。
P.S. 感谢 https://www.sphinxconnector.net/ 提出尝试 jemalloc 的想法。