В последнее время я заметил такие записи в kern.log одного из моих серверов:
Feb 16 00:24:05 aramis kernel: swapper: page allocation failure. order:0, mode:0x20
Я хотел бы знать:
Использование свопа довольно низкое (менее 10%), и до сих пор я не заметил, чтобы какие-либо процессы были убиты из-за нехватки памяти.
Дополнительная информация:
Ошибка Debian 666021 похоже, отчет об этой же проблеме. Предложение есть:
#change value for this boot
sysctl -w vm.min_free_kbytes=65536
#change value for subsequent boots
echo "vm.min_free_kbytes=65536" >> /etc/sysctl.conf
http://russ.garrett.co.uk/2009/01/01/linux-kernel-tuning/ есть некоторые обсуждения того, когда изменение этого параметра может быть полезно, воспроизведено здесь:
Это говорит ядру, что нужно постоянно держать 64 МБ ОЗУ свободными. Это полезно в двух основных случаях:
Машины без свопинга, на которых вы не хотите, чтобы входящий сетевой трафик перегружал ядро и принудительно запускал OOM до того, как он успеет очистить все буферы.
Машины x86 по той же причине: архитектура x86 допускает передачу DMA только объемом менее 900 МБ ОЗУ. Таким образом, вы можете столкнуться с странной ситуацией с ошибкой OOM с тоннами свободной оперативной памяти.
Я применил этот параметр на моем компьютере 3.2.12-gentoo x86, но все еще получаю эти ошибки.
Также может быть стоит проверить vm.zone_reclaim_mode: видеть http://www.kernel.org/doc/Documentation/sysctl/vm.txt
Я только что справился с этой ошибкой на Lenovo NAS под управлением Debian 5 и ядра 2.6.39.3 64bit.
Сообщения носят информационный характер, несмотря на то, что выглядят устрашающе, по словам https://www.novell.com/support/kb/doc.php?id=7002803
Однако они заполняли мой очень ограниченный корневой раздел (это устройство имеет корневой раздел размером 50 МБ ?!)
Исправление для меня было установить vm.min_free_kbytes из 65536 вплоть до 16384.
После этого в ОС остается 107 МБ свободной памяти и 2 ГБ в буферах. В этом нет смысла, но он остановил все журналы.