У меня есть VPS-сервер Debian Wheezy, на котором я запускаю пару приложений Django в производстве. В идеале, я бы попытался решить мои текущие проблемы с объемом памяти, оптимизировав приложения, добавив больше оперативной памяти или расширив Swap. Но проблема в том, что я сомневаюсь, что есть большая оптимизация памяти, которую я бы использовал для оптимизации приложений Django (стек является открытым и надежным), а добавление оперативной памяти является для меня ограничением затрат (это удаленный VPS), а также, хост не предлагает варианты использования Swap!
Итак, тем временем (пока я жду, чтобы получить больше ресурсов, чтобы позволить себе больше оперативной памяти), я хочу смягчить сценарии, когда у сервера заканчивается память, чтобы мне просто нужно было запросить перезапуск VPS (как, например, в этот момент я не может даже SSH в коробку!).
Итак, что мне бы понравилось в решении, так это возможность определять, когда процесс (или, как правило, общее использование системной памяти) превышает определенное критическое количество (на данный момент, например, СВОБОДНАЯ ОЗУ падает до 10%) - что я Замечено, происходит после того, как VPS работает долгое время, а также когда внезапно увеличивается объем трафика для некоторых тяжелых приложений (в любом случае большинство из них просто промежуточные).
Итак, я хочу иметь возможность убить / перезапустить нарушающий процесс (ы) - скорее всего, Apache. Какое решение, выполненное вручную в этих ситуациях, восстановило нормальные уровни использования памяти - намек на то, что, возможно, в одном или нескольких приложениях Django есть утечка памяти?
Вкратце:
Ядро linux имеет встроенный так называемый OOM Killer. Это «убийца нехватки памяти». Поэтому, когда ваш ящик исчерпал свою оперативную память и подкачку, ядро начнет убивать вещи, чтобы сделать сервер доступным.
Вы можете настроить приоритеты процессов, чтобы определить «вероятность» остановки процесса. Узнать больше на эта ссылкасм. раздел «Настройка OOM Killer».
По сути, вы настраиваете вероятность в файле / proc / * / oom_adj. Например. повысить вероятность убийства любого из запущенных в данный момент экземпляров apache?
pgrep apache2 | sudo xargs -I% PID sh -c 'echo 10> / proc /% PID / oom_adj'
Или уменьшите вероятность того, что SSH будет убит:
pgrep sshd | sudo xargs -I% PID sh -c 'echo -17> / proc /% PID / oom_adj'
Также я рекомендую полностью отключить свопинг на сервере, где у вас возникла эта проблема, потому что своп настолько медленный, что может привести к виртуальному останову сервера, даже если пространство подкачки все еще осталось, что никогда не запускает убийцу OOM.
Прежде всего, я бы сказал, что перезапуск не является проблемой решения, и лучший способ - найти проблемный процесс и выяснить, почему он потребляет много памяти. Как уже упоминалось выше, в Linux уже есть механизм OOM, чтобы найти проблемный процесс и убить его, чтобы уменьшить давление на память.
Другой способ узнать это с помощью Kdump, настройте этот параметр vm.panic_on_oom = 1 (/etc/sysctl.conf), это будет генерировать vmcore, когда системе не хватает памяти. Вы можете найти больше информации об этом здесь
http://people.redhat.com/anderson/crash_whitepaper/
Также limits.conf имеет много ограничений, лучшим решением является использование контрольных групп для ограничения использования памяти для каждого процесса.
Итак, в /etc/cgconfig.conf вы можете определить контрольную группу следующим образом (здесь я ограничиваю свое приложение, чтобы использовать только 256 МБ памяти)
group test {
memory {
memory.limit_in_bytes = 256m;
}
}
а затем в /etc/cgrules.conf я могу определить, что использование вашего приложения (в вашем случае django не может превышать 256)
*:django memory test/
Для получения дополнительной информации о cgroup вы можете обратиться
Но идея перезапуска приложения кажется плохой.
Если эти приложения работают внутри apache2 server, вы можете настроить сервер. Рассматривать:
Если в ваших процессах происходит утечка памяти, вы можете использовать /etc/security/limits.conf чтобы ограничить объем памяти, который может содержать сервер. Это предотвратит слишком большой рост серверов. Такого же эффекта можно добиться на временной основе с помощью ulimit команда. Возможно, лучше использовать ulimit чтобы найти подходящий размер, а затем установите эти значения в limits.conf файл. Если ваш сервер поддерживает это, перетащите файл в /etc/security/limits.d а не редактирование /etc/security/limits.conf.