LINUX.ORG.RU

Нужен альтернативный аллокатор для контейнеров

 


4

5

Есть несколько STL контейнеров, которые в некоторый момент хранят в себе огромное количество мелких объектов съедая большое количество памяти. Потом все данные этих контейнеров освобождаются. Но из-за фрагментации данных в куче стандартный аллокатор не отдает ОС память.

Есть ли какие-нибудь готовые аллокаторы для таких случаев? Или надо писать свой велосипед?

Я подробностей не помню, но александреску писал свой small object allocator. Попробуй на него посмотреть.

DELIRIUM ☆☆☆☆☆
()

Но из-за фрагментации данных в куче стандартный аллокатор не отдает ОС память.

Пробовал вызывать malloc_trim(0)?

i-rinat ★★★★★
()

https://github.com/jemalloc/jemalloc/wiki/Background#intended-use

jemalloc is a general purpose malloc(3) implementation that emphasizes fragmentation avoidance and scalable concurrency support

As an extreme example, arenas can be used as pool allocators; i.e. an arena can be used for general purpose allocation, and then the entire arena destroyed as a single operation.

vertexua ★★★★★
()

Здесь можно взять монолитный аллокатор, может поможет. В C++17 оно должно быть из коробки.

Ну и в boost тоже есть, можно и их посмотреть.

xaizek ★★★★★
()
Последнее исправление: xaizek (всего исправлений: 1)

jemalloc, насколько я помню, ещё очень давно начал использовать Firefox. После чего он перестал жрать RAM и стал потреблять куда меньше памяти, чем Chrome. До перехода на jemalloc было наоборот.

EXL ★★★★★
()

Тоже голосую за jemalloc. У меня растишка на нем быстрее на 30-35%, где как раз много создается мелких объектов, но они краткоживущие.

dave ★★★★★
()

Есть ли какие-нибудь готовые аллокаторы для таких случаев? Или надо писать свой велосипед?

Тут все зависит от природы объектов и их жизненного цикла. Во многих ситуациях может быть уместен memory pool. Особенно если эти объекты одинакового размера, тогда фрагментации можно вообще избежать.

Если разных размеров объектов много, то имеет смысл попробовать другой аллокатор уровня malloc, такой как jemalloc

А есть доказательства, что фрагментация имеет место быть? Статистику аллокатора распечатали?

annulen ★★★★★
()

И я вот не понял. Наверное, память все же отдается, просто не может выделить большой кусок? Или что тогда?

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

А есть доказательства, что фрагментация имеет место быть? Статистику аллокатора распечатали?

Доказательств нет. Просто понавыделяли разных объектов на 8Гб, потом 95% из них освободили. Приложение как занимало 8Гб в момент пика выделения памяти, так и осталось занимать 8Гб, после освобождения. Не исключаю возможность, что истинная причина проблемы в чем-то другом.

pathfinder ★★★★
() автор топика
Последнее исправление: pathfinder (всего исправлений: 2)
Ответ на: комментарий от pathfinder

Действительно похоже на фрагментацию, но лучше все-таки посмотреть malloc_stats/malloc_info или что там есть в вашем аллокаторе

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

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

Просто понавыделяли разных объектов на 8Гб, потом 95% из них освободили.

А кто тебе обещал, что должно быть иначе? У тебя ещё 5% объектов в памяти, и какие страницы они держат ещё тот вопрос.

AlexVR ★★★★★
()

Не парься. Просто используй jemalloc. Фрагментация, которую он не разрулит, исправится swap'ом (почти забесплатно).

anonymous
()
Ответ на: комментарий от Einstok_Fair

А вот была бы Java - был бы там Memory Compaction

С непредсказуемыми остановками работы программы. К тому же GC для обеспечения той же скорости работы программы нужно в 4-6 раз больше памяти...

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

гугли про realtime gc. там только предсказуемые остановки.

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

Ну не только аллокатор помог, ещё и тюнинг под него. Был там у них какой-то проект по поиску впустую расходуемой памяти. Среди прочего были забавные баги типа выделения множества буферов по 4100 байт, которые аллокатор превращал в 8192. Подкрутили размеры, чтобы в 4096 влезало, и на пару процентов общее потребление памяти уменьшилось.

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

был бы там Memory Compaction

и GC, позволяющий забороть часть утечек

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

Не парься. Просто используй jemalloc

Карго-культ до добра не доведет. Нужно четкое понимание, какой реальный оверхед от фрагментации и как он меняется с jemalloc. А то может быть, что основная проблема вообще не в ней, или достаточно всего лишь подтюнить MMAP_THRESHOLD

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

Или наоборот, фрагментация настолько суровая, что только memory pool по-настоящему поможет

annulen ★★★★★
()

Помню похожую тему. Вылечилось вызовом malloc_trim и жгучей ненавистью к аллокатору. Qt Linux memory leaks

nev3rfail
()

Прогони под валгриндом. Если нет утечек то проблема скорее всего мнимая.

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

Memory Compaction
И боксинг.

Отлично. Будет чем развлечся во время затяжных GC пауз.

rupert ★★★★★
()

Всем спасибо. Просто переход на jemalloc дал весьма неплохие результаты.

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