Время от времени «мой» сервер останавливается, потому что ему не хватает как памяти, так и места подкачки. (он продолжает отвечать на пинг, но не более того, даже по ssh).
Мне сказали, что Linux выполняет чрезмерное использование памяти, что, насколько я понимаю, аналогично тому, как банки делают с деньгами: он предоставляет процессам больше памяти, чем фактически доступно, при условии, что большинство процессов фактически не будут использовать всю запрашиваемую ими память, при по крайней мере, не все одновременно.
Предположим, что это действительно причина того, что моя система иногда зависает, давайте не будем здесь обсуждать, так ли это на самом деле (см. Что может привести к тому, что ВСЕ службы на сервере отключатся, но все равно будут отвечать на пинг? и как выяснить).
Так,
как мне отключить или резко уменьшить чрезмерную загрузку памяти в CentOS? Я читал, что есть две настройки, называемые vm.overcommit_memory (значения 0, 1 или 2) и vm.overcommit_ratiom, но я понятия не имею, где мне их найти и изменить (надеюсь, какой-то файл конфигурации), какие значения я должен попробовать , и нужно ли мне перезагружать сервер, чтобы изменения вступили в силу.
и это безопасно? Какие побочные эффекты я мог ожидать? Когда я ищу в Google overcommit_memory, я нахожу пугающие вещи, например, люди говорят, что их сервер больше не может загружаться ....
Поскольку причиной внезапного увеличения использования памяти является mysql из-за запросов, выполняемых php, который, в свою очередь, вызывается при обслуживании HTTP-запросов, я бы ожидал, что только какой-то скрипт php не будет завершен и, следовательно, время от времени откликнется примерно 500, когда сервер слишком занят, это риск, на который я могу пойти (конечно, лучше, если весь сервер станет недоступным и придется его жестко перезагружать).
Или это действительно может привести к тому, что мой сервер не сможет перезагрузиться, если я выберу неправильные настройки?
Перегрузку памяти можно отключить с помощью vm.overcommit_memory=2
0 - это режим по умолчанию, в котором ядро эвристически определяет выделение, вычисляя свободную память по сравнению с выполняемым запросом на выделение. А установка его в 1 включает волшебный режим, когда ядро всегда сообщает, что у него достаточно свободной памяти для любого распределения. Значение 2 означает, что процессы могут выделять только до настраиваемой суммы (overcommit_ratio) RAM и начнет получать сообщения об ошибке выделения или OOM, когда он превысит это количество.
Насколько это безопасно, нет. Я не видел ни одного подходящего варианта использования, где бы действительно помогло отключение избыточной памяти, если вы не на 100% уверены в рабочей нагрузке и мощности оборудования. Если вам интересно, установите kernel-docs пакет и перейти к /Documentation/sysctl/vm.txt читать больше или читать онлайн.
Если вы установите vm.overcommit_memory=2 тогда он будет чрезмерно загружать до процента физической RAM, настроенной в vm.overcommit_ratio (по умолчанию 50%).
echo 0/1/2 > /proc/sys/vm/overcommit_memory
Это не выдержит перезагрузки. Для настойчивости вставьте это в /etc/sysctl.conf файл:
vm.overcommit_memory=X
и беги sysctl -p. Перезагрузка не требуется.
Абсолютно неквалифицированное утверждение: отключение избыточного выделения памяти определенно «безопаснее», чем его включение.
$ customer установил его на несколько сотен веб-серверов, и это очень помогло с проблемами стабильности. Есть даже проверка Nagios, которая очень громко вызывает огонь, если он НЕ отключен.
С другой стороны, люди могут не посчитать «безопасным» выгрузку своих процессов из памяти, когда они просто хотят перегрузить небольшую память и никогда не будут ее использовать. (т.е. SAP будет очень хорошим примером)
Итак, вы снова видите, улучшит ли это ситуацию для вас. Поскольку вы уже изучаете его, чтобы избавиться от связанных проблем - я думаю, это может вам помочь.
(Я знаю, что рискну получить против какого-нибудь сварливого человека)
Я согласен с тем, что в некоторых случаях отключение избыточной фиксации безопаснее, чем включение. Если сервер выполняет только несколько больших заданий памяти (например, моделирование схем в моем случае), гораздо безопаснее заранее отказать приложению в запросе памяти, чем ждать события OOM (которое обязательно последует вскоре). Довольно часто мы видим серверы возникли проблемы после того, как убийца OOM выполнил свою работу.