Приложение на старте засасывает в себя данные из базы, занимая 80 ГБ ОЗУ и работает 3 дня, после которых сжирает все 128 ГБ ОЗУ. По логам (которые, может быть и кривые) и по заявлениям разраба, приложение хранит всегда строго ограниченное число "записей", выкидывая самые старые при необходимости.

valgrind и valgrind --massif ничего подозрительного для сокращённого набора данных не сообщают. Приложение работает сутками и не жрёт ничего лишнего. На полном наборе данных про "продуктовой" нагрузкой запускать приложение под valgrind нельзя, оно будет запускаться до второго присшествия.

Сначала грешили на фрагментацию памяти в аллокаторе. Запилили отдельный pool-аллокатор, разгрузив системный. Не помогло. Немного изучив устройство аллокатора jemalloc во FreeBSD стало ясно, что разработчики аллокатора сделали очень много для решения подобных проблем и обычный быдлокодер там ничего не сможет просто так дефрагментировать. Например, в jemalloc предусмотрены специальные "обоймы" с кусочками разных размеров - 4, 8, 16... байт, занятость ячеек в "обоймах" хранится в битовой маске. Фрагменты по 8 и 32 байт ложатся в ячейки в своих специальных "обоймах". Занятость ячеек в обойме хранится в битовой маске, которая позволяет быстро освободить-выделить ячейку, быстро найти первую свободную ячейку в ряду занятых ячеек в кассете. То есть игры в виде хаотичного выделения-освобождения кусочков разного размера сводятся внутри аллокатора просто с работой с разными кассетами, которые друг с другом никак не связаны. То есть устроить таким образом "аццкий замес" фрагментов в общем "хипе" нереально.

Основное хранилище приложения - b-tree от гугла. Стали думать про дефрагментацию b-tree, которая вполне реальна. В одном узле b-tree много ключей. Если ты удаляешь один ключ, дерево не может моментально занять памяти меньше. Чтобы в таком дереве весь узел был удалён, нужно удалить все ключи из этого узла или прийти к каком-то условию, когда в дереве сработает алгоритм смерживания узлов... То есть, удаляя-добавляя случайные ключи, можно приводить это дерево в фрагментированное состояние, где в узлах будут дырки. Чтобы такое дерево причесать, понадобится полная перестройка. Админам баз данных должна быть знакома процедура перестройки индекса, который они иногда вынуждены делать - делают они её по вышеописанным причинам - "дырок много становится". Эксперименты на эту тему продолжаются, но пока не дают каких-то интересных результатов. Да, фрагментация есть, но чтобы она была очень существенной, нужно удалять ключи в разных местах и по одному, а в приложении удаления немного не такие - удаляются ключи соседние, пачками.

Обсудите. Посоветуйте.

MasterZivvalgrind и valgrind --massif ничего подозрительного для сокращённого набора данных не сообщают. Приложение работает сутками и не жрёт ничего лишнего. На полном наборе данных про "продуктовой" нагрузкой запускать приложение под valgrind нельзя, оно будет запускаться до второго присшествия.


На сокращённом наборе данных объём потребляемой памяти растёт ?(1)
Есщё в каких то сценариях кроме боевого обнаружен рост памяти ?(2)
Потому что уж очень сложно будет отлаживаться на 80-гиговом массиве данных...(3)



Основное хранилище приложения - b-tree от гугла.

Какое конкретно?(3.5)
На таких больших-то наборах данных лучше было бы b-bree не применять.
Накладуха, знаешь ли ...(4)


Стали думать про дефрагментацию b-tree, которая вполне реальна. В одном узле b-tree много ключей. Если ты удаляешь один

Т.е. ты думаешь, что дефрагментация памяти сжират 128 -80 = 48 гигабайт памяти ?(5)
А код не знаешь (судя по всему)?
Мне кажется, ты не программист, ты -- писатель-фантаст.
(1) нет
(2) других и нет...
(3) +1
(3.5) Сейчас не могу сказать... Может не от гугла, а может это - https://code.google.com/p/cpp-btree/, не знаю точно сейчас
(4) Какая именно накладуха? Фрагментация от удалений-добавлений?
(5) Весь код знать нереально, нужна куча времени на чтение всех исходников проекта. Чтобы прочитать все исходники этого btree и всё уложить у себя в голове только неделя нужна или около того...

luislomgbl37004

Сатистика занимаемой памяти формируется не по факту выделения/освобождения виртуальных кусков
памяти, которые осуществляют все *malloc, а по факту пометки ядром физической страницы как используемой.
То есть если вы сделали *malloc( 10000000000000) , но не произвели ни одной записи туда, то ни одной страницы
ядро реально не выделит и не пометит как используемую, а просто сформирует структуру vm_area_struct (на примере Linux )
с виртуальными адресами с vm_start до vm_end, и пихнёт её в список-дерево таких же регионов вирт. памяти текущего процесса.
Если вы выделили сначала кучу кусков разного размера, которые после записи в них сопоставились нескольким разным страницам,
то все страницы будут реально помечены как используемые и отразятся в статистике потребления памяти как занятость памяти
равной сумме их PAGE_SIZE.
Если после будут удалены виртуальные куски памяти, но ни одна из этих страниц не будет освобождена полностью, то ни одна
страница не будет помечена ядром как свободная. И статистика потребления памяти не изменится, несмотря на то, что сделано
было free многим кускам виртуальной памяти. Просто ядро реальную память для сопоставления кускам виртуальной памяти
выделяет всегда страницами. И если с страницей сопоставлен хоть один не освобождённые кусок виртуальной памяти, пусть он
хоть один байт занимает, в статистике отразится занятость целой страницы памяти.
И в догонку
Вы пишете о статистике работы менеджера памяти ядра, а я пишу о статистике аллокатора уровня libc.

maytongbl37004, думаю что в алгоритме Google-b-tree существует некоторый "гистерезис" пространства.
Тоесть он растёт до определённой нормы скачком (это 128G) а потом останавливается когда 99%
всех обойм аллоцированы. Можно попробовать сломать алгоритм изменив размер обоймы но это
может быть либо очень сложно (размер прописан неявно во многих частях кода) либо это будет
иметь малый КПД. Уменьшили в 50% но реальной пользы получили в 10%.

Можно попробовать пересмотреть UPDATE (если таковый существует). Проверить, мигрирует
ли значение из "обоймы 16" в "обойму 2".
"обоймы" не относятся к алгоритмам контейнера b-tree, это понятие из jemalloc, аллокатора libc freebsd.