正如 http://jemalloc.net/ 上所述：

jemalloc 是一个通用的 malloc(3) 实现，强调避免碎片和可扩展的并发支持。

一些 Sphinx 和 Manticore Search 用户更倾向于使用 jemalloc 而非 malloc，并表示它能够节省一些 RAM。我在 3 个 Manticore 集群（se03/03-2、se04/04-2、se05/05-2）上测试了 2 周 jemalloc 对资源消耗和响应时间的影响，每个集群：

• 接收到相同数量的流量
• 主持大约相同数量的数据
• 有 2 个 Manticore 服务器在硬件、软件方面完全相同，索引和服务器之间的负载均衡也完全相同

在 se03 和 se03-2 上我启用了 jemalloc 并禁用了 THP（透明大页），并在 se03-2 上重启了 Manticore
在 se04-2 上我仅重启了 Manticore，没有对 se04 做任何改动。se04/04-2 是对照组。
在 se05-2 上我启用了 jemalloc，但没有禁用 THP

以下是 2 周内的结果：

RSS 内存消耗：

延迟动态（我使用了移动平均（响应时间））：

聚合延迟统计：

结论：

1. RSS 内存：启用 jemalloc（无论是否禁用 THP）都会使 searchd 的 RSS 内存消耗减少 **5-6%**2)
2. 启用 jemalloc 但未禁用 THP（se05-2）会使延迟 显著变差：平均响应时间 - 23%，95/99p 可能不受影响，因为差异在误差范围内（参见对照组 se04/04-2，其中没有任何改动）
3. 启用 jemalloc 并禁用 THP（se03-2）会使：
   • 平均延迟提高 10%
   • 95% 延迟变差 8%
   • 99% 延迟改善 3.6%，但这一改善在误差范围内，因此我们无法确认

在这种情况下，我们需要决定我们更倾向于：

1. 节省 5% 的内存并使平均延迟提高 10%，但较重请求的延迟峰值会增加 5%
2. 或者保持原样：不节省内存，平均延迟更差，但较重查询的延迟更好

结果可能取决于许多因素：硬件、工作负载（数据量、OPS 等），但看起来 jemalloc 是一个值得尝试的有趣工具，尤其是在大型安装中，节省 5% 可能意味着无需购买几台新服务器，从而节省一些内存/成本。

如果您需要我们帮助在您的安装中应用它，请告诉我们。我们还可以帮助您进行其他性能和资源优化。

P.S. 感谢 https://www.sphinxconnector.net/ 提出尝试 jemalloc 的想法。