Comments 20
Гаврила был не робкий малый.
Гаврила ядра собирал…
(с) (тм)
Гаврила ядра собирал…
(с) (тм)
Хм. Имена героев заменены. Или Родина не должна их знать?
Наконец, в мониторинге заббикса был настроен мониторинг корректности конфигурации nginx на всех серверах с установленным nginx: команда nginx -t вызывалась на них раз в минуту.
А какой вообще в этом смысл?
я думаю, что в этой фразе из статьи потерялся некий великий смысл.
Например, «вызывалась на них всего лишь раз в минуту.». Или «был найден оптимальный интервал времени проверки». Или «были убраны дублирующиеся проверки». Или еще что-то. Надо спросить автора статьи :-)
Например, «вызывалась на них всего лишь раз в минуту.». Или «был найден оптимальный интервал времени проверки». Или «были убраны дублирующиеся проверки». Или еще что-то. Надо спросить автора статьи :-)
Спасибо за интересный вопрос. Основной смысл в том, что хостинг-провайдеру нужно мониторить корректность конфигурации nginx. Иначе он может столкнуться с ситуацией:
— из-за ошибки в коде или из-за ручного вмешательства создаётся невалидная конфигурация nginx;
— пользователи пытаются создать сайт / привязать новый домен к сайту / сменить версию PHP на сайте и у них ничего не получается. Потому что nginx не загружает новую конфигурацию;
— пользователи звонят / пишут в техподдержку;
— от техподдержки администраторы рано или поздно узнают о проблемах и исправляют их.
Наличие триггера в Zabbix всё упрощает — можно оперативно устранять такие проблемы.
— из-за ошибки в коде или из-за ручного вмешательства создаётся невалидная конфигурация nginx;
— пользователи пытаются создать сайт / привязать новый домен к сайту / сменить версию PHP на сайте и у них ничего не получается. Потому что nginx не загружает новую конфигурацию;
— пользователи звонят / пишут в техподдержку;
— от техподдержки администраторы рано или поздно узнают о проблемах и исправляют их.
Наличие триггера в Zabbix всё упрощает — можно оперативно устранять такие проблемы.
Администраторы сразу же определили причину – нехватка оперативной памяти. В логах легко было увидеть случаи OOM, когда на сервере кончалась память и ядро убивало nginx.
А настроить своп религия не позволяет?
Я думаю, что
1. своп не помогает в абсолютно всех случаях ООМ
2. использование свопа — это зло. Поясню почему — если мы вылезли за объем ОЗУ, то у нас УЖЕ очень большие проблемы. Дальше система будет попросту тормозить и скидывать странички на диск. Зачем устраивать себе проблемы и потом продолжать агонию? Лучше сразу отстрелить процесс, который не нужен, перезапустиь его и продолжить ковылять дальше. Кстати, утечки, как показывает практика, есть везде. В любом коде. Поэтому не нужно гнаться за аптайм, который «uptime-который-общее-время-после-последней-перезагрузки-сервера.», а строить автоматически лечащую себя систему. И в новых проектах я стараюсь по максимум пользоваться опциями изоляции (docker/namespaces etc) и опциями ограничения ресурсов (cgroups etc).
Я более того скажу — мне известны случаи, когда ООМ Киллер работал некорректно, а именно была регрессия в ядре, которая делала его слишком агрессивным и он убивал процессы, хотя памяти было навалом. Потом это пофиксили. Повторюсь, что такое было в строго определенной версией ядра.
1. своп не помогает в абсолютно всех случаях ООМ
2. использование свопа — это зло. Поясню почему — если мы вылезли за объем ОЗУ, то у нас УЖЕ очень большие проблемы. Дальше система будет попросту тормозить и скидывать странички на диск. Зачем устраивать себе проблемы и потом продолжать агонию? Лучше сразу отстрелить процесс, который не нужен, перезапустиь его и продолжить ковылять дальше. Кстати, утечки, как показывает практика, есть везде. В любом коде. Поэтому не нужно гнаться за аптайм, который «uptime-который-общее-время-после-последней-перезагрузки-сервера.», а строить автоматически лечащую себя систему. И в новых проектах я стараюсь по максимум пользоваться опциями изоляции (docker/namespaces etc) и опциями ограничения ресурсов (cgroups etc).
Я более того скажу — мне известны случаи, когда ООМ Киллер работал некорректно, а именно была регрессия в ядре, которая делала его слишком агрессивным и он убивал процессы, хотя памяти было навалом. Потом это пофиксили. Повторюсь, что такое было в строго определенной версией ядра.
использование свопа — это зло
Я и НЕ ПИСАЛ, что использование свопа для штатных задач — это круто. Но своп позволяет избежать краха системы, если что-то пошло не так, и какой-нибудь процесс сожрал слишком много памяти. Своп — это как буфер, использование которого даёт админу запас времени, чтоб решить проблему.
Дальше система будет попросту тормозить и скидывать странички на диск.
Да, система будет тормозить, НО РАБОТАТЬ! Думаю, многие со мной согласятся, что это гораздо лучше для репутации, чем ошибки в браузерах клиентов.
Далее, настраиваете метрику для Заббикс, которая будет сообщать админу, что сервер залез в своп. А уже админ руками убъёт (или перезапустит) жадный процесс.
После этого останется всего лишь выполнить 2 команды, которые пренесут оставшиеся в свопе данные в оперативку:
sudo swapoff -a
sudo swapon -a
Да, система будет тормозить, НО РАБОТАТЬ! Думаю, многие со мной согласятся, что это гораздо лучше для репутации, чем ошибки в браузерах клиентов.
в случае с каким-нибудь php, тормоза приведут либо к тому, что страничка у клиента будет грузиться сильно дольше обычного (что приведет к тому, что клиент закроет страницу и уйдет к конкурентам), либо к тому, что тот же php-бекенд будет очень долго рендерить, что приведет к 503 или аналогичной ошибке (опять же клиент потерян).
Тем более — в случае, когда проблемы начались, любой повтор запроса от клиента приводит только к каскадному нарастанию проблемы.
что сервер залез в своп.
Особенность работы линукса такова, что он все равно будет скидывать в своп, даже если оперативка полностью свободна. Т.е. правильная метрика — не то, что своп используется, а как активно он используется.
в случае с каким-нибудь php, тормоза приведут либо к тому, что страничка у клиента будет грузиться сильно дольше обычного (что приведет к тому, что клиент закроет страницу и уйдет к конкурентам), либо к тому, что тот же php-бекенд будет очень долго рендерить, что приведет к 503 или аналогичной ошибке (опять же клиент потерян).
Тем более — в случае, когда проблемы начались, любой повтор запроса от клиента приводит только к каскадному нарастанию проблемы.
что сервер залез в своп.
Особенность работы линукса такова, что он все равно будет скидывать в своп, даже если оперативка полностью свободна. Т.е. правильная метрика — не то, что своп используется, а как активно он используется.
в случае с каким-нибудь php, тормоза приведут либо к тому, что страничка у клиента будет грузиться сильно дольше обычного (что приведет к тому, что клиент закроет страницу и уйдет к конкурентам), либо к тому, что тот же php-бекенд будет очень долго рендерить, что приведет к 503 или аналогичной ошибке (опять же клиент потерян).
Специально для вас сделал простое нагрузочное тестирование тестового виртуального сервера: 1 CPU / 1Gb Ram / 4 Gb swap SSD. Характеристики выбрал, чтоб максимально переложить нагрузку на своп. На сервере Ubuntu 18 LTS, Nginx, Php7.2-fpm, Mysql, в качестве приложения сайт на Wordpress с 50 страницами.
1. Останавливаем Nginx, Php-fpm:
sudo systemctl stop nginx
sudo systemctl stop php7.2-fpm2. Запускаем простой скрипт, чтоб забить память и уйти в своп:
i=0; while true; do a[${i}]=100000000000000000000000000000; i=$(($i+1)); doneЖдём, чтоб оперативка полностью забилась (к примеру, можно отследить в другом терминале через htop) и останавливаем скрипт Crtl+Z (скрипт нужно именно остановить, а не убить посредством Ctrl+C, чтоб данные остались в памяти).
3. Запускаем Nginx, Php-fpm:
sudo systemctl stop nginx
sudo systemctl stop php7.2-fpmТеоретически, система им должна выделить память в свопе.
4. Открываем локально 5 терминалов и в случайном порядке запрашиваем страницы в бесконечном цикле:
while true; do curl http://hostname/?p=$(echo $((RANDOM%50)) ); sleep 1; doneКак результат мы создали нагрузку примерно 5 запросов в секунду. Да, сервер тормозит, что в принципе логично. Но задержка не 30 секунд (необходимо для ошибки 503 при дефолтном max_execution_time), а всего 1-3 секунды. Как я и писал выше: да, сервер тормозит, но отвечает. Из-за пары секунд ожидания на интервале 5-10 минут (пока админ фиксит проблему) клиент точно не уйдет к конкурентам. А вот если в браузере ошибка 502, то у него не будет никаких оснований чего-то ждать.
Теоретически, система им должна выделить память в свопе.
Теоретически — нет. Ядро должно быть достаточно умным, чтобы скинуть все башевские скрипты в своп, а nginx и php-fpm гонять в оперативе. К тому же, «горячие» данные у обоих сервисов не такие большие по объему.
Запускаем Nginx, Php-fpm:
sudo systemctl stop nginx
sudo systemctl stop php7.2-fpm
Неудачный копипаст? В 4 утра спать надо, а не комментарии писать :-)
Специально для вас сделал простое нагрузочное тестирование тестового виртуального сервера: 1 CPU / 1Gb Ram / 4 Gb swap SSD.
Насколько корректно экстраполировать результаты этого теста на услугу «виртуальный хостинг», которая обеспечивается мощным сервером, на котором «пасется» несколько десятков пользователей с несколькими сотнями сайтом?
Неудачный копипаст? В 4 утра спать надо, а не комментарии писать :-)
:)
Насколько корректно экстраполировать результаты этого теста на услугу «виртуальный хостинг», которая обеспечивается мощным сервером, на котором «пасется» несколько десятков пользователей с несколькими сотнями сайтом?
Как-то мне приходилось работать админом в компании, занимающейся хостингом. В большинстве случаев, количество сайтов на сервер колебалось от 20 до 100. А вот совокупная нагрузка как раз таки была не очень большой и колебалась в пределах 0...10 запросов в секунду (в зависимости от времени суток), что в принципе и логично: серьёзные высоконагруженные проекты обычно на виртуальном хостинге не размещают.
Я вообще не склонен спорить, а скорее дружить со всеми.
Не знаю, что там в Таймвеб, но
Что и даёт оценку порядка 20-300 сайтов на типовой сервер.
Касательно высоконагруженных проектов — соглашусь, ставить их на ВХ чуть более, чем странно. Что для меня ещё более странно — почему услуга ВХ до сих пор жива, учитывая конкурентные ценники на VDS/VPS. В теории можно было сделать вообще прозрачное управление сайтами для пользователя, т.к. ему (пользователю) все равно, что там за технология под капотом. Ему лишь бы было дёшево, ну, и качество услуги было не очень плохим.
В этом аспекте очень интересно выглядят перспективы развития докер-хостинга. Такое реализовано у beget.ru и netangels («облачный хостинг»).
Как-то мне приходилось работать админом в компании, занимающейся хостингом. В большинстве случаев, количество сайтов на сервер колебалось от 20 до 100. А вот совокупная нагрузка как раз таки была не очень большой и колебалась в пределах 0...10 запросов в секунду (в зависимости от времени суток), что в принципе и логично: серьёзные высоконагруженные проекты обычно на виртуальном хостинге не размещают.
Не знаю, что там в Таймвеб, но
- скорее всего количество пользователей на каждом сервере исчисляется десятками (вряд ли сотнями)
- у каждого пользователя от одного до десятка сайтов
Что и даёт оценку порядка 20-300 сайтов на типовой сервер.
Касательно высоконагруженных проектов — соглашусь, ставить их на ВХ чуть более, чем странно. Что для меня ещё более странно — почему услуга ВХ до сих пор жива, учитывая конкурентные ценники на VDS/VPS. В теории можно было сделать вообще прозрачное управление сайтами для пользователя, т.к. ему (пользователю) все равно, что там за технология под капотом. Ему лишь бы было дёшево, ну, и качество услуги было не очень плохим.
В этом аспекте очень интересно выглядят перспективы развития докер-хостинга. Такое реализовано у beget.ru и netangels («облачный хостинг»).
Оценки количества пользователей на сервере некорректные. Они ближе к 1000-3000 пользователей на сервере. И соответствующему количеству сайтов(от 2000 до 15000). Сервера при этом могут быть очень мощными.
Вообще в таймвебе по-моему можно было посмотреть список пользователей на сервере сделав cat /etc/passwd.
Обычно своп только ухудшает OOM. Так как если нет свопа, linux быстро убивает какой-нибудь большой процесс. А при своп он ещё десять раз проверит, нельзя ли что поплотнее запихать в своп.
Такой опыт. Ну, возможно, нужно как-то очень тонко настраивать своп.
Такой опыт. Ну, возможно, нужно как-то очень тонко настраивать своп.
Sign up to leave a comment.
Как мы выстрелили себе в ногу и пытались разобраться, из чего именно