# Research on Jemalloc

Как сказано на <http://jemalloc.net/>:

> jemalloc — это реализация malloc(3) общего назначения, которая делает акцент на избежание фрагментации и поддерживает масштабируемую конкурентность.

Некоторые пользователи Sphinx и Manticore Search предпочитают jemalloc вместо malloc и утверждают, что он позволяет экономить ОЗУ. Я протестировал, как jemalloc влияет на потребление ресурсов и время отклика в течение 2 недель на 3 кластерах Manticore (se03/03-2, se04/04-2, se05/05-2), каждый из которых:
- получал одинаковый объём трафика
- хранил примерно одинаковый объём данных
- имел 2 сервера Manticore, полностью идентичные по аппаратному обеспечению, программному обеспечению и с 100 % одинаковыми индексами, а также балансировкой нагрузки между серверами

На se03 и se03-2 я включил jemalloc и отключил THP (transparent huge pages), после чего перезапустил Manticore на se03-2  
На se04-2 я просто перезапустил Manticore, не трогая se04. se04/04-2 — контрольная группа.  
На se05-2 я включил jemalloc, но не отключал THP


Вот что я получил за 2 недели:

Потребление RSS ОЗУ:

![jemalloc_rss](./research-on-jemalloc/jemalloc_rss.png)Динамика задержек (я использовал скользящее среднее (время отклика)):

![jemalloc_latency_1](./research-on-jemalloc/jemalloc_latency_1.png)Сводная статистика задержек:

![jemalloc_latency_2](./research-on-jemalloc/jemalloc_latency_2.png)  

# Выводы:

1. RSS ОЗУ: включение jemalloc с отключением или без отключения THP уменьшает потребление RSS ОЗУ процессом searchd на **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%, но это находится в пределах погрешности, поэтому учитывать его нельзя

Таким образом, нам нужно решить, что предпочтительнее:
1. сэкономить 5 % ОЗУ и получить 10 % улучшения средней задержки, но с более высокими всплесками задержки для 5 % тяжёлых запросов
2. оставить всё как есть: без экономии ОЗУ, худшая средняя задержка, но лучшая задержка для тяжёлых запросов

Результаты могут зависеть от множества факторов: аппаратного обеспечения, нагрузки (объём данных, OPS и т.д.), но кажется, что jemalloc — интересный инструмент, который может сэкономить ОЗУ/деньги, особенно в крупных установках, где экономия в 5 % может означать отсутствие необходимости в покупке нескольких новых серверов.

**Дайте знать, если вам нужна помощь с внедрением этого решения в вашей установке. Мы также можем помочь с другими оптимизациями производительности и ресурсов.**

P.S. Спасибо <https://www.sphinxconnector.net/> за идею попробовать jemalloc.