Время от времени «мой» сервер останавливается, потому что ему не хватает памяти и пространства подкачки. (он продолжает отвечать на ping, но не более того, даже ssh).
Мне сказали, что linux выполняет чрезмерную загрузку памяти, что, насколько я понимаю, то же самое, что банки делают с деньгами: он предоставляет процессам больше памяти, чем фактически доступно, при условии, что большинство процессов на самом деле не будут использовать всю память, которую они запрашивают, в хотя бы не все одновременно.
Пожалуйста, предположите, что это на самом деле причина, по которой моя система иногда зависает, давайте не будем здесь обсуждать, так ли это (см. Что может привести к остановке ВСЕХ служб на сервере, но при этом все еще реагировать на ping? И как это выяснить ) ,
Так,
Как я могу отключить или резко уменьшить чрезмерное использование памяти в CentOS? Я читал, что есть две настройки, называемые vm.overcommit_memory (значения 0, 1 или 2) и vm.overcommit_ratiom, но я понятия не имею, где я должен найти и изменить их (надеюсь, некоторые файлы конфигурации), какие значения я должен попробовать и нужно ли перезагрузить сервер, чтобы изменения вступили в силу.
и это безопасно? Какие побочные эффекты можно ожидать? При поиске по overcommit_memory я нахожу страшные вещи, как люди говорят, что их сервер больше не может загружаться ....
Так как причиной внезапного увеличения использования памяти является mysql из-за запросов, выполняемых php, который, в свою очередь, вызывается при обслуживании http-запросов, я ожидаю, что какой-то сценарий php не будет завершен, и, следовательно, время от времени будет происходить около 500 ответов, когда сервер слишком занят, и это риск, на который я могу пойти (конечно, лучше, если весь сервер станет недоступным и придется его перезагрузить).
Или это может привести к невозможности перезагрузки моего сервера, если я выберу неправильные настройки?
Ответы:
Перегрузка памяти может быть отключена
vm.overcommit_memory=20 - это режим по умолчанию, в котором ядро эвристически определяет распределение путем вычисления свободной памяти по сравнению с выполняемым запросом выделения. И, установив его в 1, вы включите режим Wizardry, где ядро всегда объявляет, что у него достаточно свободной памяти для любого выделения. Значение 2 означает, что процессы могут выделять только до настраиваемого количества (
overcommit_ratio) ОЗУ и начнут получать ошибки выделения или сообщения OOM, когда они превысят этот объем.Насколько это безопасно, нет. Я не видел ни одного правильного варианта использования, где бы действительно помогло отключение overcommit памяти, если только вы не уверены на 100% в рабочей нагрузке и аппаратной емкости. Если вам интересно, установите
kernel-docsпакет и перейдите/Documentation/sysctl/vm.txtпо ссылке, чтобы узнать больше, или прочитайте его онлайн .Если вы установите
vm.overcommit_memory=2его, то будет превышен процент физической памяти, сконфигурированной вvm.overcommit_ratio(по умолчанию 50%).Это не переживет перезагрузку. Для сохранения поместите это в
/etc/sysctl.confфайл:и беги
sysctl -p. Нет необходимости перезагружаться.источник
Абсолютно неквалифицированное утверждение: отключение переполнения памяти определенно «безопаснее», чем его включение.
Он установлен на несколько сотен веб-серверов, и это сильно помогло с проблемами стабильности. Есть даже проверка Nagios, которая громко вызывает огонь, если он НЕ отключен.
С другой стороны, люди могут не посчитать «безопасным» вытеснение своих процессов из памяти, когда им просто хочется перегружать небольшую оперативную память и никогда не использовать это на самом деле. (то есть SAP был бы очень хорошим примером)
Итак, вы вернулись, чтобы увидеть, улучшит ли это вещи для вас. Поскольку вы уже изучаете это, чтобы избавиться от связанных с этим проблем, я думаю, что это может помочь вам.
(Я знаю, что рискну понизить какой-нибудь сварливый человек)
источник
Я согласен, что отключение overcommit более безопасно, чем включение его в некоторых обстоятельствах. Если на сервере выполняется только несколько больших заданий памяти (например, в моем случае имитация схем), гораздо безопаснее отказать приложению в запросе памяти заранее, чем ожидать события OOM (которое обязательно последует в ближайшее время) Довольно часто мы видим серверы возникли проблемы после того, как убийца ООМ сделал свою работу.
источник