На исходе LowMem с ядром Ubuntu PAE и 32 ГБ оперативной памяти
Я запускаю процесс импорта данных Java на 32-битной машине с ядром Ubuntu 10 PAE. После некоторого запуска процесса oom-killer запускает мой Java-процесс. После некоторого поиска и поиска в документации, похоже, что в системе заканчивается LowMem. Я начал процесс в третий раз и смотрю free -lm Покажи мне Low: 464 386 77 со свободным значением (77 МБ), медленно уменьшающимся.
Почему у меня заканчивается lowmem и как мне его увеличить?
Некоторые детали:
$ cat / proc / sys / vm / lowmem_reserve_ratio
256 256 32
$ free -lm
общее количество использованных свободных общих буферов в кеше
Память: 32086 24611 7475 0 0 24012
Низкий: 464 407 57
Высокая: 31621 24204 7417
-/+ буферы / кэш: 598 31487
Своп: 2047 0 2047
4 ответа
Проблема заключается в том, что многие структуры данных ядра, такие как дескрипторы страниц (одна структура на каждую страницу размером 4 КБ в системе), должны находиться в нехватке памяти. Так как общий объем памяти в машине увеличивается, все больше и больше памяти требуется, и в конечном итоге низкий объем памяти становится очень дефицитным ресурсом.
Обычное эмпирическое правило IIRC гласит, что общий объем 16 ГБ соответствует верхнему разумному пределу для 32-разрядного ядра. Там не очень много вы можете с этим поделать.
Вы можете попробовать загрузиться с меньшим объемом памяти (mem= параметр командной строки для ядра). Но реальное решение - перейти на 64-битное ядро.
Управление памятью в этом отношении довольно плохо в Linux. Это займет первые 4G памяти и разделит их на 3/1. 1 ГБ, будучи LowMem. Если в системе 32 ГБ памяти, то для адресации уже потребуется существенная часть этого 1 ГБ. В течение 2,4 дней шла дискуссия о том, как приложить некоторые усилия для того, чтобы сделать этот предел настраиваемым или интегрировать патч 4G/4G, чего не произошло, поскольку Линус не видел в этом необходимости, и все было и без того некрасиво, не говоря уже о том, что 4G/4G тоже не очень. Существует патч 4g для 2.6, но изначально он был написан для 2.6.6, который сегодня сильно устарел. В версии 2.6.7 было совершенно ясно, что она никогда не будет объединена, ее производительность все равно была гигантской, поэтому было принято решение, что система VM была достаточно хороша, как есть. Таким образом, в 32-битной системе, вероятно, нет пути к решению этой проблемы, поскольку система памяти просто не предназначена для масштабирования до таких объемов памяти.
С другой стороны, в 64-битной системе адресация значительно изменилась, поэтому вы не найдете там этой проблемы.
Ну, я не уверен, что я прав, размер нехватки памяти является одним из параметров ядра. Я думаю, что один процесс не может расти из-за нехватки памяти из-за PAE, но проверьте это http://www.makelinux.net/ldd3/chp-15-sect-1.shtml
Отключите oom killer и посмотрите, каков будет конечный результат. Также публикуйте информацию об использовании памяти процесса, если это применимо. Взгляните на вывод pmap, чтобы помочь расшифровать. Я запускал очень большие кучи Java под RHEL5 64-bit и никогда не видел этой проблемы.