LINUX.ORG.RU
Форум — Admin  

Перезагрузка из-за переполнения ОЗУ


0

1

Ситуация: вычислительный кластер, на узлах запускается приложение в 20 потоков потребляющее много памяти. В один момент ОЗУ заканчивается и узлы тут же уходят в перезагрузку. Что бы пользовательское приложение уводило систему в перезагрузку мне кажется мало вероятным, более вероятным кажется, что систему выводит из строя либо какая-то служба (например, ganglia), либо драйвер Infiniband. Если что ОС Redhat 6, ОЗУ 64Гб, своп 2 Гб. Что можно сделать?

★★★★★
← Автозапуск Apache в chroot
Тупняк с сетью →
 ← 1 2

OOMKiller не просыпается? Вообще при нехватки памяти он должен запускаться и убивать кого попало, порой он убивает что-то жизненно важное и система встаёт колом. Но не перезагружается. Да и результат должен быть разным по идее, а не повторяться из раза в раз.

Где-то в настройках ядра можно заставить его не перезагружаться при кернелпаниках, а выаливать в консоль отладочную информацию и просто останавливаться. Смотри sysctl -a.
Хоть узнаешь что там происходит.

MrClon ★★★★★
()
Ответ на: комментарий от MrClon

«система встаёт колом» не из-за того что «он убивает что-то жизненно важное», а именно из-за oom killer и чтения всего с диска.

anonymous
()
Ответ на: комментарий от anonymous

Чтения чего с диска? На сколько я понимаю по умолчанию при нехватке памяти oom killer просто киляет случайно выбранный процесс (и так пока не освободится достаточно памяти). А что будет дальше зависит уже от того какой процесс убило, воркер веб-сервера, базу данных, sshd, syslogd, запущенный админом ls -l ~ или init

Но тут похоже дело не в oom killer.

MrClon ★★★★★
()

2 гига свапа при 64 гига рамы — это считай что совсем без свапа.

Я бы для начала увеличил бы его раза в 32 так минимум.

beastie ★★★★★
()
Ответ на: комментарий от ii343hbka

Чем-то задним чувствую что 2 Гб свопа при 64 Гб памяти пользы не принесут, а вот навредить могут.
И опять-же чем-то задним чувствую что 64 Гб свопа это как-то не очень правильно.

MrClon ★★★★★
()
Ответ на: комментарий от MrClon

ну просто пока что диагноз ТСу - ООМкиллер
как-то отсрочить можно наличием большого количества ОЗУ
правда тогда система станет раком

кстате
вспомнил, что у в sysctl есть параметр типа panic_on_oomkiller
такие дела

ii343hbka ★★★
()
Ответ на: комментарий от MrClon

Чтения чего с диска?

Того, что было бы в кэше, лол.

при нехватке памяти oom killer просто киляет

Не просто а такая ситуация называется memory pressure, и вызывает сброс кэшей и swap trashing.

случайно выбранный процесс

Не случайно а по набору эвристик и значений в /proc/[pid]/oom_score.

anonymous
()

Что можно сделать?

Для начала поставить хотя бы atop и собрать более адекватную статистику.

frozen_twilight ★★
()

Я бы сделал /proc/sys/kernel/panic=0 и посмотрел бы на консоль. Если это что-то с ядром/софтом - оно остановится и будет видна причина, а если это что-то аппаратное, то не будет останова. только нужно чтоб консоль не гасилась по таймауту (setterm -blank 0).

vel ★★★★★
()
Ответ на: комментарий от anonymous

К моменту прихода киллера дисковый кэш по идее уже и так вытесняется из памяти.

MrClon ★★★★★
()
Ответ на: комментарий от ii343hbka

Да, может быть такое. Не знал про эту опцию.
В любом случае нужно смотреть что ядро выпукивает на консоль при панике.

MrClon ★★★★★
()
Ответ на: комментарий от MrClon

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

<6>[ pid ]   uid  tgid total_vm      rss cpu oom_adj oom_score_adj name
<6>[  918]     0   918     2835        0   0     -17         -1000 udevd
<6>[ 2617]     0  2617     1539        1   0	   0             0 portreserve
...
<6>[13520]     0 13520     1015        1   0	   0             0 mingetty
<6>[13523]     0 13523     2834        0  13     -17         -1000 udevd
<6>[13524]     0 13524     2834        0   1     -17         -1000 udevd
<6>[14070] 10014 14070    13534      174  13     -17         -1000 orted
<6>[14071] 10014 14071   910736   837442   3     -17         -1000 neb.x
<6>[14072] 10014 14072   910844   830214   9     -17         -1000 neb.x
<6>[14073] 10014 14073   911979   832413   6     -17         -1000 neb.x
<6>[14074] 10014 14074   911280   832569  15     -17         -1000 neb.x
<6>[14075] 10014 14075   911941   837900   5     -17         -1000 neb.x
<6>[14076] 10014 14076   910477   835887   8     -17         -1000 neb.x
<6>[14077] 10014 14077   911717   837873  19     -17         -1000 neb.x
<6>[14078] 10014 14078   910684   832173   4     -17         -1000 neb.x
<6>[14079] 10014 14079   912813   344073  14     -17         -1000 neb.x
<6>[14080] 10014 14080   910843   832467   1     -17         -1000 neb.x
<6>[14081] 10014 14081   912380   750601   5     -17         -1000 neb.x
<6>[14082] 10014 14082   911942   674454   0     -17         -1000 neb.x
<6>[14083] 10014 14083   910622   813706  10     -17         -1000 neb.x
<6>[14084] 10014 14084   910870   836270   1     -17         -1000 neb.x
<6>[14085] 10014 14085   911092   831407  13     -17         -1000 neb.x
<6>[14086] 10014 14086   910840   836496  11     -17         -1000 neb.x
<6>[14087] 10014 14087   911496   838205  16     -17         -1000 neb.x
<6>[14088] 10014 14088   912364   837873  12     -17         -1000 neb.x
<6>[14089] 10014 14089   910839   833506   5     -17         -1000 neb.x
<6>[14090] 10014 14090   913281   839929   7     -17         -1000 neb.x

AlexVR ★★★★★
() автор топика
Ответ на: комментарий от AlexVR

Т.е. получалось что есть только два значения oom_adj/oom_score_adj 0/0 и -17/-1000 при этом процессы запущенные на вычисления от имени обычных пользователей получат каким-то образом поблажку, и как следствие в момент переполнения ОЗУ срубаются все службы подряд и только потом udevd/т.п. и виновники.

AlexVR ★★★★★
() автор топика
Ответ на: комментарий от AlexVR

Тогда это похоже на то, что в ядре кто-то неадекватно реагирует на нехватку памяти :(

Не пробовал настроить что-нибудь для отлова кернельных сообщений на момент перезагрузки типа network console или ramoops/pstore (ядра 3.10 - ramoops с человеческим лицом!)

vel ★★★★★
()

Давайте и я попробую угадать. ООМ киллер ставит систему колом и срабатывает watchdog?

sergej ★★★★★
()
Ответ на: комментарий от AlexVR

Вообще управление OOM Killer-ом больной вопрос. Изначально он будт вообще неуправляем и туп, потом его вроде как сделали умнее (добавили какие-то там волшебные эвристики) но это не помогло, к нему прикрутили ручки что-бы объяснить кого мочить а кого не надо, но и с ними вроде не всё ладно было. Сейчас к нему приделали cgroup-консольку, вроде как говорят что она хороша, и позволяет делать всякое (например ограничивать буйства киллера той группой процессов запрос памяти которой спровоцировал его вызов), но сам я её не щупал. И не факт что в твоём ядре эта ручка уже есть.

И не факт что дело вообще в OOM Killer-е

MrClon ★★★★★
()
Ответ на: комментарий от AlexVR

Так убить ведро что-бы оно не успело даже запаниковать, это уметь надо. Подозреваю что тут что-то не так.

MrClon ★★★★★
()
Ответ на: комментарий от MrClon

по умолчанию при нехватке памяти oom killer просто киляет случайно выбранный процесс

это неправда. На самом деле oom вычисляет скор каждого процесса, и убивает тот, у которого score максимальный. Скор вычисляется по сложной эмпирической формуле, и обычно oom успешно устанавливает виновника аварии.

Но тут похоже дело не в oom killer.

ну как сказать, если OOM убьёт основной процесс, ради которого работает вся система, то перезагрузка в этом случае — единственное разумное решение.

emulek ★
()
Ответ на: комментарий от MrClon

Или полностью отключил.

не нужно. Если его полностью отключить, то будет так, как ты говорил: oom не успеет провести анализ, и убьёт рандомное приложение(или оно само рухнет). Ну или сама система рухнет полностью. Короче ☣ случится.

emulek ★
()
Ответ на: комментарий от emulek

это неправда. На самом деле oom вычисляет скор каждого процесса, и убивает тот, у которого score максимальный. Скор вычисляется по сложной эмпирической формуле, и обычно oom успешно устанавливает виновника аварии.

Это проверено на собственном опыте, или из обещаний разработчиков ядра?

ну как сказать, если OOM убьёт основной процесс, ради которого работает вся система, то перезагрузка в этом случае — единственное разумное решение.

Например какой? Убийство какого процесса в linux по умолчанию вызывает перезагрузку системы?

MrClon ★★★★★
()
Ответ на: комментарий от AlexVR

при этом процессы запущенные на вычисления от имени обычных пользователей получат каким-то образом поблажку

потому что oom предназначен для защиты от аварий. Т.е. если какой-то быдлокод начинает ВНЕЗАПНО жрать МНОГО памяти, из-за утечки или иного бага. А у тебя просто тупо мало памяти. Тут никакой OOM не поможет, смирись и добавь. Сам подумай, ну убьёт OOM вычислительный процесс, и чем это лучше перезагрузки?

emulek ★
()
Ответ на: комментарий от MrClon

сделали умнее (добавили какие-то там волшебные эвристики) но это не помогло

помогло. Но если тебе нужно N памяти, а у тебя есть M<N, то тебе поможет только чудо, или ещё N-M памяти. А ты думал, ядро из OOM родит тебе нужные N-M памяти, да?

emulek ★
()
Ответ на: комментарий от MrClon

Это проверено на собственном опыте

проверенно конечно. Я лично запускал нагруженные сервера на слабых серверах, с малым объёмом памяти. Там как СУБД разогревается, так всё и падает. И оом выдаёт табличку с указанием виновника. Также и на десктопах. Также я свой код пишу, и про утечки в C/C++ знаю не понаслышке.

или из обещаний разработчиков ядра?

это не только обещания. Старое ядро в RHEL/CentOS иногда ошибалось, прибивая не то. Новое практически всегда убивает то, что надо. Только необходимо сделать маленький своп. Ну и настройки НЕ крутить(если точно не знаешь, что делаешь).

Например какой? Убийство какого процесса в linux по умолчанию вызывает перезагрузку системы?

в общем случае никакой. В частном, зачем нужен узел кластера, который тупо стоит и ничего не считает? Может у ТСа есть специальный костыль. Я не в курсе. Но думаю, что если основной процесс ВНЕЗАПНО рухнул, то перезагрузиться — хорошая идея.

emulek ★
()
Ответ на: комментарий от MrClon

Давай ты не будешь додумывать за меня, ладно?

ну тогда сам расскажи, что делать узлу, если рухнул единственный нужный процесс? ИМХО перезагрузка — самое лучшее, ведь авария может быть вызвана чем угодно, и есть смысл пройти POST, и загрузку OS с тестированием и инициализацией железа. Подразумевается, что памяти хватает.

emulek ★
()
Ответ на: комментарий от emulek

Вообще-то мы не про авторебут говорили. Но коли тебе интересно моё мнение: написать в логи, послать аллерт админу. Ребут тоже вариант, но я-бы сильно подумал перед тем как такое программировать, а если-бы и стал такое писать то перед ребутом всё-рано записал-бы сообщение в лог и отправил алерт админу.
В любом случае едва-ли это поведение по умолчанию.

MrClon ★★★★★
()
Ответ на: комментарий от MrClon

Но коли тебе интересно моё мнение: написать в логи, послать аллерт админу.

дык ребут пишет в лог и направляет(может) аллерт. А что стоять-то? Возможно это случайный сбой.

В любом случае едва-ли это поведение по умолчанию.

я не про систему. В системе конечно такого нет. Но может софт ставит собачку.

PS: хотя ТС вроде говорил, что у него системные службы падают, а не его софтина. Т.ч. я так, рассуждаю.

emulek ★
()
Ответ на: комментарий от AlexVR

Эм, ты так думаешь? Ну ладно. Лучше уж своп, чем куищще, но хозяин — барин.

beastie ★★★★★
()
Ответ на: комментарий от MrClon

А ещё ТС не говорил что ему аллерты приходят.

а откуда он узнал, что у него узлы перезагружаются постоянно?

А вообще всё зависит от специфики приложения.

согласен.

emulek ★
()
Ответ на: комментарий от emulek

а откуда он узнал, что у него узлы перезагружаются постоянно?

Мониторинг? Отсутствие ответа от запущенных заданий?
Но аллерт от мониторилки вида «Хост такой-то не пинжится, о запинжился» или от управляющей ноды вида «что-то рабочая нода давно не присылает результаты работы» это не вполне тот аллерт который я имел в виду.

MrClon ★★★★★
()
Ответ на: комментарий от MrClon

«что-то рабочая нода давно не присылает результаты работы»

может ей почему-то сырцы не дали. А может задачка попалась сложная. Не вариант ИМХО. Лучше уж послать «ой, у меня беда непонятная, я пошла перезагружаться! Если не вернусь, считайте меня комсомолкой».

emulek ★
()
Ответ на: комментарий от emulek

Дык и я говорю что это не то чего хотелось-бы. Твой вариант тоже не особо нравится, как минимум нужно указать с чего скрипт взял что произошла какая-то беда (какая из существующих проверок дола положительный результат).

Те аллерты которые назвал я это то что можно получить либо от внешнего мониторинга (какого-то нагиоса пинжащего сервера), либо от контрольной ноды кластера (разумно предположить что хоть какой-то мониторинг у неё есть). Т.е. это то как ТС мог узнать что беда в принципе есть.

MrClon ★★★★★
()
Ответ на: комментарий от MrClon

Твой вариант тоже не особо нравится, как минимум нужно указать с чего скрипт взял что произошла какая-то беда

ещё раз: ну узле работает одно приложение. Оно считает. Все остальные процессы вспомогательные. Скрипт ставит приложение при установке. Скрипт знает, что ему контролировать. Вот и контролирует. Если его программа сдохла, он посылает аллерт и перезагружает узел.

emulek ★
()

Ещё один вброс лога. Порядок убивания процессов: 

<3>Killed process 2617, UID 0, (portreserve) total-vm:6156kB, anon-rss:0kB, file-rss:4kB
<3>Killed process 2624, UID 0, (rsyslogd) total-vm:335256kB, anon-rss:212kB, file-rss:4kB
<3>Killed process 2637, UID 0, (irqbalance) total-vm:10884kB, anon-rss:164kB, file-rss:4kB
<3>Killed process 2651, UID 32, (rpcbind) total-vm:18972kB, anon-rss:56kB, file-rss:4kB
<3>Killed process 2997, UID 29, (rpc.statd) total-vm:23344kB, anon-rss:0kB, file-rss:4kB
<3>Killed process 3036, UID 0, (acpid) total-vm:4076kB, anon-rss:0kB, file-rss:0kB
<3>Killed process 3054, UID 28, (nscd) total-vm:796052kB, anon-rss:156kB, file-rss:4kB
<3>Killed process 3080, UID 0, (snmpd) total-vm:197364kB, anon-rss:972kB, file-rss:12kB
<3>Killed process 3115, UID 0, (amDaemon) total-vm:1119704kB, anon-rss:5072kB, file-rss:4kB
<3>Killed process 3123, UID 0, (xinetd) total-vm:20200kB, anon-rss:0kB, file-rss:0kB
<3>Killed process 3215, UID 0, (eecd) total-vm:869860kB, anon-rss:424kB, file-rss:8kB
<3>Killed process 3276, UID 0, (SVRemoteConnect) total-vm:8784kB, anon-rss:0kB, file-rss:4kB
<3>Killed process 3529, UID 0, (scagt) total-vm:17184kB, anon-rss:20kB, file-rss:12kB
<3>Killed process 3542, UID 0, (sc2agt) total-vm:72432kB, anon-rss:96kB, file-rss:4kB
<3>Killed process 3553, UID 0, (busagt) total-vm:16988kB, anon-rss:100kB, file-rss:4kB
<3>Killed process 3564, UID 0, (hdagt) total-vm:17156kB, anon-rss:108kB, file-rss:4kB
<3>Killed process 3575, UID 0, (unixagt) total-vm:17132kB, anon-rss:116kB, file-rss:4kB
<3>Killed process 3586, UID 0, (etheragt) total-vm:16952kB, anon-rss:28kB, file-rss:4kB
<3>Killed process 3597, UID 0, (biosagt) total-vm:16952kB, anon-rss:24kB, file-rss:4kB
<3>Killed process 3610, UID 0, (securagt) total-vm:17700kB, anon-rss:80kB, file-rss:36kB
<3>Killed process 3621, UID 0, (statusagt) total-vm:40028kB, anon-rss:140kB, file-rss:4kB
<3>Killed process 3633, UID 0, (invagt) total-vm:17168kB, anon-rss:140kB, file-rss:8kB
<3>Killed process 3646, UID 0, (thragt) total-vm:40340kB, anon-rss:112kB, file-rss:4kB
<3>Killed process 3658, UID 0, (vvagt) total-vm:48808kB, anon-rss:28kB, file-rss:8kB
<3>Killed process 3669, UID 0, (hpsimagt) total-vm:31804kB, anon-rss:128kB, file-rss:28kB
<3>Killed process 3683, UID 0, (svupdateagt) total-vm:50844kB, anon-rss:164kB, file-rss:8kB
<3>Killed process 3699, UID 0, (vmeagt) total-vm:63680kB, anon-rss:2092kB, file-rss:8kB
<3>Killed process 3799, UID 0, (vmeagt) total-vm:63680kB, anon-rss:2092kB, file-rss:8kB
<3>Killed process 3800, UID 0, (vmeagt) total-vm:63680kB, anon-rss:2092kB, file-rss:8kB
<3>Killed process 3728, UID 0, (gf_agent) total-vm:5372kB, anon-rss:36kB, file-rss:8kB
<3>Killed process 3756, UID 99, (gmond) total-vm:243752kB, anon-rss:17732kB, file-rss:68kB
<3>Killed process 3913, UID 0, (ipmiutil) total-vm:15372kB, anon-rss:32kB, file-rss:4kB
<3>Killed process 3936, UID 0, (crond) total-vm:115316kB, anon-rss:68kB, file-rss:0kB
<3>Killed process 4449, UID 0, (rpc.rquotad) total-vm:107608kB, anon-rss:0kB, file-rss:0kB
<3>Killed process 4453, UID 0, (rpc.mountd) total-vm:21652kB, anon-rss:0kB, file-rss:0kB
<3>Killed process 4597, UID 0, (sendmail) total-vm:87284kB, anon-rss:160kB, file-rss:0kB
<3>Killed process 4605, UID 51, (sendmail) total-vm:74400kB, anon-rss:0kB, file-rss:0kB
<3>Killed process 4641, UID 38, (ntpd) total-vm:24564kB, anon-rss:104kB, file-rss:4kB
<3>Killed process 4686, UID 0, (cfmd) total-vm:24288kB, anon-rss:0kB, file-rss:0kB
<3>Killed process 4705, UID 0, (kusu-nodeheartb) total-vm:14884kB, anon-rss:0kB, file-rss:4kB
<3>Killed process 13510, UID 0, (mingetty) total-vm:4060kB, anon-rss:0kB, file-rss:4kB
<3>Killed process 13512, UID 0, (mingetty) total-vm:4060kB, anon-rss:0kB, file-rss:4kB
<3>Killed process 13514, UID 0, (mingetty) total-vm:4060kB, anon-rss:0kB, file-rss:4kB
<3>Killed process 13516, UID 0, (mingetty) total-vm:4060kB, anon-rss:0kB, file-rss:4kB
<3>Killed process 13518, UID 0, (mingetty) total-vm:4060kB, anon-rss:0kB, file-rss:4kB
<3>Killed process 13520, UID 0, (mingetty) total-vm:4060kB, anon-rss:0kB, file-rss:4kB
При этом до виновного прикладного процесса даже не доходит

AlexVR ★★★★★
() автор топика
Ответ на: комментарий от sergej

Давайте и я попробую угадать. ООМ киллер ставит систему колом и срабатывает watchdog?

Вот это самый тот диагноз!

... Watchdog 2 #0x93 | Hard reset | Asserted
AlexVR ★★★★★
() автор топика
Ответ на: комментарий от emulek

... Скрипт знает, что ему контролировать ...

Задания распределяет PBS.

З.Ы.: пошёл гуглить oomkiller+pbs

AlexVR ★★★★★
() автор топика

а) Настрой поведение системы при OOM.

б) Ограничь потребление оперативки твоим приложением на узле, чтобы и системе хватало. Тогда при нехватке памяти твоему приложению падать будет гарантированно твоё приложение, а не то, на что OOMKiller косо посмотрит.

в) убери с узлов всё лишнее, что теоретически может употребить много памяти.

blexey ★★★★★
()
Ответ на: комментарий от beastie

Я бы для начала увеличил бы его раза в 32 так минимум.

Со свопом в 64 гига и острой нехватке памяти он только и будет что свопиться. Разве что надежда на то что там осядет редко используемый хлам.

true_admin ★★★★★
()
Последнее исправление: true_admin (всего исправлений: 1)

Вот эта штука выдаст тебе список предпочтений OOM Killer'а на ноде: 

#!/bin/bash
A=`find /proc -maxdepth 2 -name oom_score | sed -e "s/[^([:digit:]\ )+]//g"`
for PID in $A; do
  SCORE=`cat /proc/$PID/oom_score 2>/dev/null`
  if [ -n "$SCORE" ]; then
    echo $SCORE $PID `readlink -f /proc/$PID/exe`
  fi
done | sort -n

blexey ★★★★★
()
Ответ на: комментарий от blexey

Список предпочтений и порядок убийств служебных процессов мне видно и из vmcore-dmesg.txt

З.Ы. Кто его создаёт я ещё не разбирался, но там всё поэтапно расписано.

AlexVR ★★★★★
() автор топика
Ответ на: комментарий от blexey

а) Настрой поведение системы при OOM.

Watchdog быстрее успевает

б) Ограничь потребление оперативки твоим приложением на узле, чтобы и системе хватало. Тогда при нехватке памяти твоему приложению падать будет гарантированно твоё приложение, а не то, на что OOMKiller косо посмотрит.

В эту сторону и смотрю, сейчас пытаюсь задействовать ulimits

в) убери с узлов всё лишнее, что теоретически может употребить много памяти.

А на них и ничего лишнего нет.

AlexVR ★★★★★
() автор топика
Ответ на: комментарий от AlexVR

/proc/pid/oom_score_adj можно подкрутить, тем более, что он наследуется.

Может есть смысл сделать overcommit_memory=2 ?

Вообще надо понять почему резко кончается память. Либо плодится слишком много процессов, либо кто-то из работающих процессов начинает жрать память.

vel ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.
 ← 1 2
← Автозапуск Apache в chroot
Admin
Тупняк с сетью →