Как отключить OOM killer в Ubuntu 14.04? Там есть описание здесь, но это , кажется, не работали на ОП. Было бы здорово получить ответ с четкими шагами.
1
2 ответа
7
Это проблема XY; то есть у вас есть проблема (X), знаете ли вы это или нет, и считаете, что можете решить проблемы, решив другую проблему, которая является проблемой Y.
Почему вы хотите отключить oomkiller? Это проблема X, которую вам нужно решить. Что вам нужно сделать, так это расследовать и детализировать проблему X. Дайте подробную информацию об этом, и, возможно, мы сможем вам помочь.
Переход к проблеме Y и отключение oomkiller - это, как правило, очень плохая идея, которая наверняка создаст гораздо большие проблемы, которые он может решить.
Вызывать oomkiller - это отчаянное, последнее прибежище, когда что-то пошло не так в памяти, и гибель неизбежна. В вашей системе шесть пассажиров, один час в пути и всего пять человеко-часов снабжения кислородом. Вы можете подумать, что убить одного пассажира наугад (а не наугад - тот, у кого на самом деле более высокий метаболизм) - ужасная вещь, но альтернативой является смерть всех шести пассажиров от удушья за десять долгих минут до стыковки.
Предположим, вы делаете это
Вы преуспели в отключении oomkiller. Система перезагружается и идет своим путем. Теперь могут произойти две вещи:
- oomkiller никогда не требует вызова. Вы сделали все это ни за что.
- oomkiller действительно требует вызова.
Но зачем нужен был oomkiller? Это было потому, что некоторому процессу требовалась память, и система обнаружила, что не может обслуживать эту память.
Есть процесс, который мы называем "memoryhog", который был бы убит oomkiller, и теперь это не то, что происходит. Что происходит?
Вариант 1: ООМ означает смерть
Вы дали эти команды при загрузке
sysctl vm.panic_on_oom=1
sysctl kernel.panic=5
или добавил это в /etc/sysctl.conf и перезагрузил
vm.panic_on_oom=1
kernel.panic=5
и как только система перегружена, через 5 секунд она начнет паниковать и перезагружаться.
Вариант 2: убить кого-то еще, если это возможно
При загрузке вы классифицируете некоторые процессы как "расходуемые", а некоторые другие как "нерасходуемые". Например, Apache может быть расходуемым, а не MySQL. Поэтому, когда Apache сталкивается с каким-то нелепо большим запросом (в системах LAMP, как правило, вытекающим из "простого исправления" установки выделения памяти PHP на смехотворно большие значения вместо изменения какого-либо подхода, связанного с памятью или утечки), дочерний элемент Apache убивается, даже если MySQL это большая свинья. Таким образом, клиент просто увидит пустую страницу, нажмет RELOAD, получит другую ... и, наконец, откажется.
Вы делаете это, записывая PID MySQL при запуске и корректируя его рейтинг OOM:
echo -15 > /proc/$( pidof mysql )/oom_adj
Однако в этой ситуации я бы также настроил дочерний конф Apache.
Обратите внимание, что если эта опция решает вашу проблему, это означает, что у вас есть проблема в других процессах (например, слишком большой процесс PHP). Что происходит от неоптимального алгоритма или стадии выбора данных. Вы следуете по цепочке, пока не достигнете единственной проблемы, которую действительно нужно решить).
Вероятно, установка большего объема оперативной памяти имела бы такой же эффект.
В этом варианте, если сам MySQL растет слишком сильно (например, вы испортили значение innodb_pool_size), MySQL все равно будет уничтожен.
Вариант 3: никогда не прерывать процесс $ MYPRECIOUSSS
Как и выше, но теперь настройка установлена на -17.
Я сейчас говорю о MySQL, но большинство программ будут вести себя одинаково. Я точно знаю, что и PostgreSQL, и Oracle делают (и имеют на это право. Вы злоупотребляете СУРБД на свой страх и риск).
Эта опция опасна тем, что oomkiller убьет кого-то другого, возможно, многократно, но прежде всего, возможно, из-за самого $ MYPRECIOUSSS.
Таким образом, безудержный процесс вытеснит всех остальных из памяти, пока система не станет непригодной для использования, и вы даже не сможете войти, чтобы проверить или сделать что-нибудь. Вскоре после этого MySQL испортит свою собственную информацию о состоянии и ужасно аварийно завершится, и у вас останется долгий сеанс fsck , за которым следует кропотливое восстановление таблицы и тщательное восстановление транзакций.
По собственному опыту могу сказать, что руководство будет крайне недовольно тем, кто установил бомбу замедленного действия. В этом будет много обвинений (MySQL был неправильно настроен, Apache был дырявым, OOMKiller был сумасшедшим, это был хакер ...), поэтому "одним" может быть "многие". Однако для этого третьего варианта я не могу особо подчеркнуть необходимость создания полных, адекватных и постоянно обновляемых и отслеживаемых резервных копий с тестами восстановления.
Вариант 4 - "выключение" OOMkiller
Этот вариант может выглядеть как шутка. Как старый трюк Windows XP, чтобы «Как избежать синих экранов навсегда!"- что действительно сработало... установив малоизвестную переменную, которая превратила их в пурпурный
Но вы можете сделать так, чтобы oomkiller никогда не вызывался, отредактировав /etc/sysctl.conf и добавив следующие строки:
vm.overcommit_memory = 2
vm.overcommit_kbytes = 0
Затем также выполните команды sysctl vm.overcommit_memory=2 и sysctl vm.overcommit_kbytes=0 чтобы избежать необходимости перезагрузки.
Что происходит сейчас? Если в системе достаточно памяти, ничего не происходит - как если бы вы ничего не делали.
Когда в системе недостаточно памяти, новые процессы не смогут запуститься или будут зависать при запуске. Им нужна память, а памяти там нет. Таким образом, они не будут "убиты", а вместо этого "убиты из-за ошибки нехватки памяти". Результаты абсолютно идентичны, и поэтому некоторые могут подумать, что это шутка.
Моя собственная рекомендация
Выясните, почему системе не хватает памяти. Это может быть или неизбежно неизбежно, исправимо, или полностью избегаемо. Если это неизбежно, поднимите проблему выше и потребуйте больше памяти для установки.
Если это вызвано процессом сбоя, ошибкой, неправильным вводом или условием, которое может быть распознано до наступления критичности, это исправимо. Вам необходимо реинжинирировать процесс и подготовить к этому дело.
Также может случиться так, что проблему можно полностью избежать путем разделения служб между различными серверами, или путем более тщательной настройки одного или нескольких процессов, или (снова) реинжиниринга неисправного процесса (ов).
В некоторых сценариях более эффективным решением может быть "потратить на это немного денег" - если у вас проблемы с сервером с 256 ГБ ОЗУ и вы знаете, что в обозримом будущем вам потребуется максимум 280, обновление до 320 ГБ может стоить Всего 3 000 долларов США, все включено, и будет сделано в выходные дни, что, по сравнению с затратами в 150 000 долларов США в день или четырьмя программируемыми человеко-месяцами по 14 000 долларов США, является очень приятной сделкой, и , скорее всего, улучшить производительность даже в повседневных условиях.
Альтернативой может быть установка действительно большой области подкачки и активация ее по требованию. Предположим, у нас есть 32 ГБ свободного места в /var/tmp (и что он не поддерживается памятью):
dd if=/dev/zero of=/var/tmp/oomswap bs=1M count=32768
# or: fallocate -l 32g /var/tmp/oomswap
chmod 600 /var/tmp/oomswap
mkswap /var/tmp/oomswap
swapon /var/tmp/oomswap
Это создаст 32-гигабайтный файл, который будет полезен для дыхания различных процессов. Вы также можете проверить и, возможно, увеличить swappiness:
cat /proc/sys/vm/swappiness
Ubuntu 14.04 имеет стандартную перестановку в 60, что хорошо для большинства пользователей.
sysctl vm.swappiness=70
1
echo 2 > /proc/sys/vm/overcommit_memory
echo 0 > /proc/sys/vm/overcommit_kbytes
См. https://www.kernel.org/doc/Documentation/sysctl/vm.txt для описания параметров.
Применяется стандартное предостережение: когда системе не хватает памяти, а ваша программа запрашивает больше, ей будет отказано; и это точка, в которой происходит сбой или заклинивание многих программ.