Хабр Курсы для админов
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Поток Администрирование доступен 24/7 благодаря поддержке друзей Хабра
Комментарии 23
Выглядит так, словно Роскомнадзор заблокировал вас в Гугле.
В man systemd.resource-control есть описание опции MemoryMax которая лимитирует использования памяти процессами юнита. Выставляете заданный лимит опираясь на то, сколько памяти позволено отъесть вашему сервису, и система возьмет работу на себя.
Спасибо за комментарий! С Вашим замечанием я полностью согласен, по-хорошему все рабочие сервера надо грамотно настраивать, но не всегда есть такая возможность. Я работаю не с "рассвета" организации, поэтому частенько приходится пожинать плоды.
Выгрузить скрипт на рабочую машину - решение крайне спонтанное, этакое "6-е чувство", на всякий случай, перед концом рабочего дня. Я даже предположить не мог, что данный сервер поведёт себя подобным образом, тк за время моей работы не было ни одного подобного инцидента.
В остальном, Вы правы буквально на все 100%. Обязательно дотянусь до данного сервера. Спасибо!
Один экземпляр чего-либо, даже не текущего - вот это гарантированный даунтайм. Ну, и "быстро поднятое упавшим не считается" в 2025 году - это только для какой-нибудь госухи ок.
Ну если там нормальный стейтлесный сервис - то в общем то да, быстро перезапущеный не считается упавшим.
Механизм обнаружения утечек памяти в долговременно запущенном ПО - да, обязательно должен быть. Проекты, с которыми сталкивался я - имеют прогнозируемый uptime, измеряемый в годах. Т.е. перезапуск - при штатном сервисном обслуживании. Раз в год, а то и реже.
Может быть очень медленная утечка памяти, когда проблемы начнут проявляться не через сутки и даже не через неделю.
Более того, лично я сталкивался с ситуацией, когда утечка памяти начинала проявляться не как "нет памяти/падают процессы" - а замедлением работы системы, т.к. тот же аналог кэша разрастался настолько, что поиск в нём стал занимать существенное время.
Поэтому - все наши разработки включают механизм, который отслеживает потребление памяти. Чтобы не мучиться с настройкой для каждого процесса - через сутки после запуска берём текущее потребление, удваиваем, добавляем константу - и считаем это жёстким лимитом сверху.
Спасибо за комментарий!
Поэтому - все наши разработки включают механизм, который отслеживает потребление памяти. Чтобы не мучиться с настройкой для каждого процесса - через сутки после запуска берём текущее потребление, удваиваем, добавляем константу - и считаем это жёстким лимитом сверху.
Очень интересный подход, ранее не думал о подобном. Возьму себе на заметку, спасибо!
А ещё бывает прекрасная ситуация, когда сервис - вещь в себе, написанная когда-то, со своими закидонами, которую нельзя исправить, можно только заменить - и вот такое решение, хоть и костыль, прекрасно решает задачу.
Причем скрипту в общем все равно что именно проверять: свободную память, доступность сервиса и т.д. Не прошла проверка - перезапуск!
В этом преимущество подобных скриптов перед другими путями решения проблемы - они универсальны по сути.
А так-то конечно память не должна утекать, программа не должна глючить, сферический конь должен быть помыт, начищен и отполирован, чтобы сверкать в вакууме...
как процессы хаотично умрут от OOM Killer
Оом не убивает процессы "хаотично". Он убивает либо самого жирного по скорингу, либо процесс который непосредственно вызвал out of memory. Это зависит от значения vm.oom_kill_allocating_task
0 и умрет самый жирный. 0 по дефолту, если что.
1 и будет убивать того кто запросил память которой нет.
При 0, с гарантией будет убиваться процесс с утечкой памяти.
А есть же monit, который такое делает искаропки
Всё здорово, но если память сожрёт кто-то другой, скрипт всё равно задушит убьет невинного Питона. Т.е. это соломка, подстеленная именно туда, куда собираешься упасть.
Ещё бы одну строчку, чтобы убивать именно то, что занимает большего всего памяти..
https://docs.gunicorn.org/en/stable/settings.html#max-requests
Автоматический рестарт воркера после обработки N запросов, причём так как это делает сам gunicorn, то он сразу снимает нагрузку с воркера и не отправляет туда больше запросов, а потом уже делает его рерстарт. В этом случае сервис у вас остаётся доступным всегда
Пару раз пока искали утечки приходилось этот "костыль" использовать
Я бы запустил все это в докер и тот сам бы перезапускал бы процесс в случае самостоятельного падения или по причине утечки
Уф-ф-ф, пятничный деплой, какая завязка! Па-атрясающий сюжет!
Есть у меня хомяк с Apache, что живёт на промо VDS от RuVDS. После недавнего переезда с 18.04 на 22.04, стал изредка отваливаться. Вместо того, чтобы нормально разобраться в причине (я просто маску нашёл), сделал аналогичным образом. Ну, оно работает. Однако, будь это не мой личный сайт, вполне справедливо было бы гнать взашей ссаными тряпками.
замерить потребление процесса в норме и прописать в cgroup нет? и ничего не сожрет больше, максимум сам крашнется
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Тихий герой воскресного утра: как bash-скрипт спас нас от OOM Killer