Фризы системы при исчерпании виртуальной памяти

А призыв OOM-killer по alt-sysrq-f не помогает?

http://catap.ru/blog/2009/05/03/about-memory-oom-killer/
http://catap.ru/blog/2009/05/05/about-memory-overcommit-memory/

>Собственно, вопрос: что это такое и как это лечить?

sed -e '/swap/d' -i /etc/fstab && /sbin/swapoff -a

Своп в 21-м веке — это анахронизм.

>Своп в 21-м веке — это анахронизм.

Я так вижу, что для анонимной школоты в 21-м веке мозг - это анахронизм.

школота нынче бохатая пошла, памяти под 100500 гб воткнут и айда свопы вырубать

>Своп в 21-м веке — это анахронизм.

А как же сон?

> метод решения.

Описан в man ulimit

А как же выключение через ресет? Вы ж никнейм видите - анонимус: они не спят

посмотрите доколе?

Ты мой брат-близнец. Весной я проделывал точь-в-точь то же самое.

Что удалось выяснить:

1. Вот такая программа:

#include <stdlib.h>
#include <stdio.h>

int main(void) {
	unsigned totalsize = 0;
	unsigned allocsize = 1024 * 1024 * 10;
	
	while (1) {
		char* p = malloc(allocsize);
		if (p) {
			totalsize += allocsize;
			printf("%uMiB\n", totalsize / (1024 * 1024));
		}
	}
}

Мгновенно сжирает 3 гига адресного пространства и просто крутится в цикле дальше. Реально память при это этом не выделяется. Сюрприз. Я видимо что-то пропустил в жизни Linux, просидев в криокамере, или просто с самого начала чего-то не знал — но выделять память malloc-ом, не гарантируя при этом наличия реальных страниц памяти или свопа — похоже на бред.

2. Курил ulimit и limits.conf. В конфиге ничего, похожего на лимиты выделения памяти не обнаружилось. В ulimit обнаружилась опция -v. К сожалению она не работает: ограничивает только размер виртуального адресного пространства отдельного процесса. А учётом предыдущего пункта, опция и вовсе бесполезна. Нужно, чтобы был ограничитель реального количества выделенных старниц, и не для процесса, а для всех процессов пользователя суммарно.

3. Вот такая программа:

#include <stdlib.h>
#include <stdio.h>

int main(void) {
	unsigned totalsize = 0;
	unsigned allocsize = 1024 * 1024 * 10;
	unsigned i;
	
	while (1) {
		char* p = malloc(allocsize);
		if (p) {
			totalsize += allocsize;
			printf("%uMiB\n", totalsize / (1024 * 1024));
			for (i =0; i < allocsize; i++)
				p[i] = (char)i;
		}
	}
}

за несколько секунд сжирает реальную доступную память и полность вешает систему. (Ctrl+Alt+F? не работают, если были запущены иксы. Если не были, то работают, но консоли висят и бесполезны. Ctrl+Alt+Del не работает тоже.) Если работать со свопом, полный висяк системы чуть отсрочивается, поскольку начинается активный свопинг и тормоза. Но в финале результат всё-равно тот же. Это в Archlinux. В Debian Lenny такую программу, крепко выматерившись в консоль, прибивает автоматический oom-killer.

В общем, копаю дальше. Вопросы, которые щас буду пытаться нагуглить:

1. Как заставить систему malloc-чить память только в случае, если её наличие гарантировано реально доступной в системе памятью. И кто «виноват» в текущем поведении malloc: glibc или ядро.

2. Как назначить квоты памяти, действующие per user. А также общую квоту, действующую на все процесс системы, кроме рутовский.

3. Как включить автоматический oom-killer в Archlinux.

> Как включить автоматический oom-killer в Archlinux.

Ты вообще читаешь, что тебе в топике отвечают?

Еще нет: запостил, что вчера не дописал. Щас вкурю.

Аналогичная проблема на сервере с lenny: две сотни одновременных подключений к веб-серверу и апач c php сжирают всю доступную память и своп. Oom-killer пытается убить самый жирный процесс - mysql - что, естественно, не помогает. Пока прикрутил скрипт, которые каждые 30 секунд мониторит LA, своп и память и при наступлении сабжа делает killall -9 php

Перепиши на эрланге! :3

>http://catap.ru/blog/2009/05/03/about-memory-oom-killer/

объяснения исходника, а не общей картины для простого понимания.

>http://catap.ru/blog/2009/05/03/about-memory-oom-killer/

http://catap.ru/blog/2009/05/05/about-memory-overcommit-memory/

Почитал, спасибо. Стало намного яснее. Хорошие статьи.


1. С malloc-м ясно. Ощущение, что Линус троллит пользователей таким способом. Покручу опции overcommit, посмотрю, что получится.

2. С квотами по-прежнему не ясно. Гугл релевантного ничего не нашел, по указанным ссылкам — тоже нет.

3. С oom-киллером ситуация оказалось еще запутаннее. Оказалось, что в Debian он работал, поскольку я тестировал бесконечный malloc на ненагруженной системе. В Arch, пока процессов запущено мало, всё тоже работает: при исчерпании памяти процесс прибивается как ему и положено. Если нагрузить систему хотя бы запуском хромиума, исчерпание памяти приводит к полному зависанию. alt-sysrq-f выводит сообщение о запуске OOM killer, но система висит дальше. alt-sysrq-e приводит к kernel panic (сфотографировать не смог, фотик разряжен). Похоже, причина не в кривых настройках, а в баге ядра.

> а не общей картины для простого понимания.
И что?
Вместо своего мусорного сообщения, ты бы лучше взял бы да и описал общую картину для простого понимания.

Что именно не получилось с квотами?

>Вместо своего мусорного сообщения, ты бы лучше взял бы да и описал общую картину для простого понимания.

ты чего такой агрессивный? я написал, что тот материал для начинающего ничего толкового не привнесет в знания. ну да, потыкали носом в исходники и про формулы рассказали, а общей картины как не было, так и нет. и это нормально, когда обозначают малозначимость или бесполезность статьи. лично для меня такая критика обычно оказывает только позитивное влияние - заставляет задуматься о формате преподносимой информации.

AITap> alt-sysrq-f

alt-sysrq-k же!

Поставил:
vm.overcommit_memory = 2
vm.overcommit_ratio = 90
Тестировал систему без свопа, со свопом 400MiB и со свопом 4400MiB. Всеми возможными способами, включая запуск всех установленных браузеров, воспроизведение звука, открытие больших файлов в GIMP, запуск бесконечного malloc-а (в том числе, от рута).
Фризов, зависаний, kernel panic-ов или срабатывания oom-киллера добиться не удалось никоим образом. Не смотря на интенсивный so и si, wa не превышало 30%. Система ведёт себя адекватно: при исчерпывании памяти отпинывает malloc-и NULL-ом, и процессы самостоятельно оканчивают жизнь самоубийством или же умеряют свои аппетиты.

Выводы:

1. Поставить по умолчанию режим «бесконечной памяти» vm.overcommit_memory = 0 додумались какие-то очень тонкие тролли. Хотя если это решение самого Торвальдса, я ничуть не удивлюсь — это в его стиле.
2. Слухи о бесполезности свопа в Linux оказались сильно преивеличены. Своп — торт, поскольку на его основе вычисляются лимиты доступной памяти. Ставить чем больше, тем лучше. Оставил пока 4гига. Поставил бы и больше, но надо партишены передвинуть сначала.
3. Оом киллер не нужен.

>Что именно не получилось с квотами?

Не получилось нагуглить сабж.
Требуется: назначать UID-ам квоту на количество занятой всеми процессами с данным UID-ом памяти. Т.е. чтобы процессы данного пользователя в сумме не занимали больше, чем, например, 1000 мегабайт.
Вопрос: есть ли такой механизм в Linux, и если есть, через что настраивается.
man limits.conf и man getrlimit смотрел — не то. Там, если я правильно понимаю, даются лимиты только per process, а требуется — per UID.

две сотни одновременных подключений к веб-серверу и апач c php сжирают всю доступную память и своп.

Вам не рассказывали про memory_limit (или как оно там) в php.ini?

>две сотни одновременных подключений к веб-серверу и апач c php сжирают всю доступную память и своп

Выделил жирным проблемные места. Избавишься от них — избавишься от проблемы.

>Я так вижу, что для анонимной школоты в 21-м веке мозг - это анахронизм.

Консервативно-агрессивно настроенное лоробыдло детектед. Батя, скажи, зачем нужен своп в 21-м веке при работе? swapon /dev/sdX в скрипте для хибернейта написать не проблема, ровно как и swapoff -a в скрипте «просыпания». Зато будет меньше дебильных воплей «у миня гибабаит памети свабодный, а в свопе пицот мигабайт занято!!1»

Теперь мне абсолютно ясно, что режим vm.overcommit_memory = 0 создан специально для ЛОРовских анонимусов, не умеющих читать.

>Вам не рассказывали про memory_limit (или как оно там) в php.ini?

32 мегабайта. 8 гигов памяти на сервере. ~700 виртхостов.

ути-пути, опять адепты эрланга в треде? вы еще забыли посоветовать сменить муксуль на коучдб

Скажите, а у кого-нибудь падает (сильно) производительность системы, как только начинает использоваться свап (например, 2 Гб ОЗУ, 300 Мб Swap) на .35 ядре. Такая проблема/фича появилась в Бубунте 10.10. Когда памяти хватает, система работает быстро, как только задел свап - система начинает фризить. Мне интересно, пора валить с Бубунты или дело в ядре?