正如在 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 服务器，在硬件、软件和 100% 相同的索引以及服务器之间的负载均衡方面完全一致

在 se03 和 se03-2 上，我启用了 jemalloc 并禁用了 THP（透明巨页），并在 se03-2 上重新启动了 Manticore。
在 se04-2 上，我只是重新启动了 Manticore，没有动 se04。se04/04-2 是一个对照组。
在 se05-2 上，我启用了 jemalloc，但没有禁用 THP。

以下是我在 2 周内得到的结果：

RSS RAM 消耗：

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

汇总延迟统计：

结论：

1. RSS RAM：启用 jemalloc 无论是否禁用 THP，均使 searchd 的 RSS RAM 消耗降低 **5-6%**2)

2. 启用 jemalloc 而不禁用 THP（se05-2）显著增加延迟 更糟：平均（响应时间） - 增加 23%，95/99百分位可能不受影响，因为差异在误差范围内（请参见没有变动的 se04/04-2 对照组）

3. 启用 jemalloc 并禁用 THP（se03-2）使得：

   • 平均延迟改善 10%

   • 95% 延迟变差 8%

   • 99% 延迟改善 3.6%，但这在误差范围内，因此我们不能计算这个
     因此，在这种情况下，我们需要决定我们更倾向于哪种情况：

4. 节省 5% RAM，平均延迟改善 10%，但 5% 的重请求延迟高峰更高

5. 或者不做任何改变：没有 RAM 节省，平均延迟更糟，但对于更重的查询延迟更好

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

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