Будет много букв, но проблема довольно сложная и странная.
Есть некоторый замороченный код (числодробилка), работающий на кластере под MPI. В процессе работы в рамках одной итерации накапливается информация (в виде маленьких структурок по 32 байта каждая, будем называть их треками), затем информация перелопачивается нетривиальным образом и все по новой. При этом ключевым ресурсом является доступная память.
Заранее число треков неизвестно, хотя можно строить какие то оценки. Сейчас накопление происходит в контейнеры устроенные как односвязный список блоков, каждый блок по 32К. Когда очередной блок полностью заполнен, при помощи new выделяется новый блок и т.д. Таких списков в рамках одного процесса много, и они заполняются параллельно.
При обработке информации последовательно берется очередной список, треки из него перепаковываются/переупорядочиваются, некоторые выбрасываются, результаты пишутся в обычный вектор который потом будет дальше обработан. Важно что при этом память, выделенная под список, должна быть освобождена - иначе потом ничего не влезет. Общий размер занятой под треки памяти порядка 500-1000М, таких процессов на одном узле пасется несколько (по числу ядер), и кроме этих данных они оперируют еще всяким разным. Поскольку никакой виртуальной памяти (свопа) нет, когда память заканчивается задача крэшится (все 1000 процессов), поэтому прежде чем переходить к очередному этапу процесс сморит сколько в систем свободной памяти вообще, и ждет пока освободится нужное кол-во.
Есть три вопроса:
1) Поскольку блоки уничтожаются в каком то непонятном порядке (не в том, котором выделялись), куча оказывается фрагментированной. При этом наблюдается некий значительный лаг по времени между вызовом delete и тем моментом когда освобожденная память становится в системе видна как свободная. Может ли этот лаг быть связан с фрагментацией?
2) На одном из доступных кластеров вообще наблюдается утечка памяти, т.е. память в систему не возвращается. Отличается кластер от остальных древним и странным компайлером - там связка icpc17 и gcc4.2 (нет, я не могу на том кластере выбрать что то более свежее). Может ли утечка быть связана с фрагментацией?
3) Вообще насколько такая фрагментация плоха, и если плоха то как с ней бороться? Сейчас я переработал стратегию освобождения памяти, теперь блоки сортируются по адресам и уничтожаются из этого списка с конца (при этом при необходимости данные переносятся в другой блок). Результатов тестирования этого варианта пока не знаю. Альтернативой насколько я понимаю является ваяние своего менеджера, т.е. выделяем из кучи сразу много памяти и как то ее раздает всем страждущим?
