LINUX.ORG.RU

Примеры эффективного применения сторонних malloc allocators

 


0

2

Привет, лор!

Мне, рядовому юзеру GNU/Linux, интересно: в каких случаях я могу получить профит от использования сабжа?

TL;DR
Понравилось мнение, выраженное одним из разработчиков федоры: разные аллокаторы проявляют свои преимущества под специфичными нагрузками, поэтому в пакетах не должно быть жёсткой привязки к не-glibc-аллокаторам, чтобы у пользователей была свобода подключать при помощи LD_PRELOAD подходящий для нагрузки сабж.

Для примера: замерял время сборки ядра (в максимально идентичных условиях с одним и тем же конфигом) с разными malloc. Результаты получились такие:

glibc       25:51
talloc      26:05
tbbmalloc   26:13
mimalloc    26:16
jemalloc    27:10
hoard       28:02
tcmalloc    29:00

Т.е. никакого профита от LD_PRELOAD в случае с компилятором я на своём железе не получаю.

Благодарю за интересные примеры.

★★

Давно слышал, что Firefox начал использовать jemalloc, и действительно, после перехода на этот аллокатор он стал жрать весьма немного RAM в сравнении с тем же Chrom{e,ium}. Судя по последнему опыту использования современных браузеров, такая тенденция всё ещё сохраняется и Firefox самый экономичный по использованию RAM браузер.

Использует ли Firefox сейчас jemalloc или нет?

EXL ★★★★★
()
Ответ на: комментарий от EXL

Нет, давно туда уже не заглядывал. Помню только, что выключать jemalloc полезно, если хочется с Valgrind поиграться.

Cудя по ссылке от @rmu, на Linux по умолчанию включен jemalloc.

i-rinat ★★★★★
()
Ответ на: комментарий от EXL

после перехода на этот аллокатор он стал жрать весьма немного RAM

Это не столько заслуга аллокатора, сколько результата целенаправленного снижения потребления памяти. Например, для буфера выделялось 4096 байт под данные и один байт под нуль-терминатор. Получалось 4097 байт, поэтому аллокатор выделял 8192 байт, почти половина из которых улетала в трубу. Уменьшили размер одного экземпляра буфера на несколько байт, получили экономию на всей группе в мегабайты. Подробности можно найти по слову «memshrink».

Просто сменой аллокатора автоматической экономии не получишь, к сожалению. Нужно вникать в особенности его работы. Например, аллокатор из glibc метаданные кладёт рядом с данными, а значит если запросишь ровно 4096 байт, он будет искать сплошной кусок в 4096+16 байт, что тоже в одну страницу не влазит. Насколько я понял, у jemalloc метаданные лежат отдельно, поэтому он при выделении 4096 байт аккуратно уместит их в одну страницу.

i-rinat ★★★★★
()
Ответ на: комментарий от i-rinat

Вау, классный коммент. Спасибо за подробности, очень интересно.

rmu ★★
() автор топика

Тот же tcmalloc несколько больше чем аллокатор - он напримр может работать как профайлер, позволяя определять где сколько памяти заалокейтили, сколько освободили и т.д.

Nastishka ★★★★★
()
Ответ на: комментарий от rmu

Откуда мне знать про ваши повседневные задачи на ноуте? Мне возможности профайлера в tcmalloc пригодились. Хоть и не «в повседневных задачах на ноуте». Как и его адаптированность под многопоточный профиль использования - определенная магия позволяет поднять производительность процентов на 5-7 для некоторых задач в которых в много потоков аллокейтится/освобождается память. Ну и опять же для примера - Ceph версии 12 с подгруженным через LD_PRELOAD jemalloc иногда устривал sgementation fault.

Nastishka ★★★★★
()

Разница эффективности аллокаторов должна проявлятся на приложениях с частым запросом/освобождением памяти, работающих оочень долго и с конкуренцией (многотредовые приложения).

Компиляция ядра в данном случае это только тест быстродействия. (ты ведь даже не стал собрать данные сколько компилятор потребил памяти!)

Интересны тесты показывающие эффективность сборки мусора.

Интересны тесты показывающие скорость выделения/освобождения памяти при множественном конкурентом доступе. Это достаточно специфический класс задач, явно не для ноута.

А аллокаторы с профилированием интересны только разработчикам.

Оставь стандартный glibc и не мучайся.

vel ★★★★★
()
Ответ на: комментарий от vel

Оставь стандартный glibc и не мучайся.

Тесты показали, что достойной замены стандартного из glibc нет.

При компиляции потребляется несколько гигабайт RAM, надеялся что в этом случае подключаемые аллокаторы могут быть полезны.

rmu ★★
() автор топика
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.