maffei 14 мар 2012 в 18:48

Nginx — уходим на технические работы

3 мин

49K

Nginx*

Из песочницы

+54

Комментарии 69

mifa 14 мар 2012 в 19:03

Интересно, а насколько «дорого» будет проверка наличия файл при каждом запросе? Ведь если на сервер приходится, скажем, 1000 запросов / сек, то это еще 1000 дополнительных обращений к ФС?

+21

haskel 14 мар 2012 в 19:08

нет.

-8

romy4 14 мар 2012 в 19:08

ФС кеширует такие штуки, но это всё равно плохо. Если это только на время чтения конфига, то подходит решение.

fzfx 14 мар 2012 в 19:36

зависит от того, в каком месте иерархии ФС создавать триггер.
если мы имеем дело с *nix, то можно ведь создать файлик и в оперативке.

VBart 14 мар 2012 в 19:43

Это не избавит вас от лишнего сискола на каждый запрос.

Наиболее правильный и корректный способ закрытия на обслуживание — это релоад nginx-а с соответствующим конфигом.

p.s. imho закрытие сайта для проведения «работ» это какой-то каменный век вообще.

+14

startsevdenis 14 мар 2012 в 19:48

Сегодня на хабре пол дня висело сообщение о проведении «работ»

+11

VBart 14 мар 2012 в 19:50

Да, я знаю, а ещё хабр падал иногда, а ещё в хабре дырки находят, а ещё хабр глючил несколько дней, когда они учились настраивать кэш nginx-а. Таков хабр, что поделать. Со временем может быть научатся.

+14

fzfx 14 мар 2012 в 20:48

ну, всех проблем в мире не решить. если частота системных вызовов в 1 килогерц кого-то устраивает, то почему бы и нет, если про реакцию nginx'а на SIGHUP и SIGUSR1 прочитать не довелось.
да и потом, идея с проверкой файл-триггера хоть и ресурсоёмка, зато проста и понятна; а релоад пойди-ка ещё найди как правильно сделать. =)

Evengard 14 мар 2012 в 22:34

ЛОЛ. В Арче /etc/rc.d/nginx reload — это разве сложно?)

anthonio 15 мар 2012 в 02:53

или так: rc.d reload nginx

TROODON 15 мар 2012 в 01:29

service nginx reload

debian-like:

/etc/init.d/nginx reload

Если уж совсем потеряли исполяемый файл:

/find / -name nginx -type f -perm -o+rx

maffei 14 мар 2012 в 19:40

Глянул только что показатели по IO до и после модификации конфига. Разница меньше 0.1%. Но и загрузка сервера, конечно, на порядок меньше.

sam002 15 мар 2012 в 01:01

Может, просто делать rsync на другой сервер и на время работ через изменения записи DNS перенаправлять на него? Можно развить идею и для маломощного второго сервера вставить «всплывающее уведомление», ограничиться отдачей статики.

maffei 15 мар 2012 в 11:05

Я описал лишь один из способов решения проблемы. Ваш вариант также имеет право на существование.

Klef 7 июл 2014 в 15:58

ДНС, для всего мира, обновляет не мгновенно.

Azy 14 мар 2012 в 22:30

Если у вас 1000 запросов в секунду, то в любом случае жинкс как минимум тянет статитики на это количество соединений.
Так что 1000 обращений к ФС это не большая проблема, особенно если вынести файл в RAM

Второй вариант это использовать nginx.org/ru/docs/http/ngx_http_memcached_module.html
устанавливая ключ.

НЛО прилетело и опубликовало эту надпись здесь

zhovner 14 мар 2012 в 19:06

Для этого специально придумали try_files.

Пример из документации:

location / {
    try_files /system/maintenance.html
              $uri 
 }

+15

seriyPS 14 мар 2012 в 19:23

оно вернет не 503 а 200, на что поисковики болезненно реагируют.

zhovner 14 мар 2012 в 19:52

location / {
    try_files /system/maintenance.html
     
}

location /system/maintenance.html {
    return 503;     
}

VBart 14 мар 2012 в 19:55

Таким образом вы будете отдавать дефолтную 503 на любой запрос и в независимости от наличия/отсутствия /system/maintenance.html

zhovner 14 мар 2012 в 19:57

Наверное предполагается что try_files /system/maintenance.html не единственная строчка в директиве locataion / {}

VBart 14 мар 2012 в 19:59

Я не знаю, что вы предполагали. Последний параметр директивы try_files (а в вашем случае и единственный) всегда задает внутренний редирект.

seriyPS 14 мар 2012 в 20:02

Т.е. полный пример будет выглядеть как

location / {
    try_files /system/maintenance.html @backend;
     
}

location /system/maintenance.html {
    return 503;     
}

Если это работает то это офигенно!

VBart 14 мар 2012 в 20:05

В вашем примере /system/maintenance.html будет обработана в location / с кодом 200.
А на запрос /system/maintenance.html будет возвращена дефолтная 503я.

zhovner 14 мар 2012 в 20:10

Напишите как правильно.

VBart 14 мар 2012 в 20:14

#comment_4676665

Hint 14 мар 2012 в 20:17

Я делаю так:

location / {
error_page 503 /503.html;
return 503;
}

le0pard 14 мар 2012 в 19:17

Картинки то можно обслуживать даже при работах, да и на самой странице maintenance могут использоватся картинки с сервера:

 set $maintenance 0; 

 if (-f $document_root/system/maintenance.html) { set $maintenance 1; }

 if ($request_uri ~* (jpg|jpeg|gif|png|js|css)$) { set $maintenance 0; }

 if ($maintenance) { rewrite ^(.*)$ /system/maintenance.html; break; }

-1

VBart 14 мар 2012 в 19:32

Не надо программировать на конфигах nginx. Для всего этого есть специальные директивы.

le0pard 14 мар 2012 в 19:38

Так покажите как правильно такое сделать.

VBart 14 мар 2012 в 19:44

Много раз в рассылке обсуждалось.
mailman.nginx.org/pipermail/nginx/2011-November/030165.html

le0pard 14 мар 2012 в 20:38

спасибо

karellen 14 мар 2012 в 19:18

С 503-й еще не забывайте про заголовок Retry-After.

karellen 14 мар 2012 в 19:21

Рано отправил. Я обычно в своем рабочем конфиге держу в апстриме бэкенд специально для выдачи maintenance notice. Если надо уйти в maintenance, я помечаю текущий бэкенд как нерабочий. Заодно оно и само срабатывает, если с бэкендом что-то случилось. Почему именно бэкенд — предпочитаю считать и знать сколько и кто конкретно видел ошибки или maintenance период на сайте, для этого пользуюсь statsd + uid_module.

xRemaLx 14 мар 2012 в 19:32

А чем
sudo /etc/init.d/nginx reload
не устроил?
Вроде как он мягко вводит в силу новый конфиг — новые подключения на новом конфиге, старые отрабатывают и мрут.

+13

balaganski 14 мар 2012 в 19:39

Поддерживаю.

Регулярно пользуюсь, никаких проблем не замечено.

maffei 14 мар 2012 в 19:43

С Вами полностью согласен. Подойдет как restart так reload.

xRemaLx 14 мар 2012 в 20:01

Рестарт выключает сервер, проверяет конфиг и запускает. Релоад в таком случаее лучше — проверка и потом перечитывание конфига.

zhovner 14 мар 2012 в 19:55

Еще проще killall -HUP nginx
И не нужно искать где лежать стартовые скрипты.

-2

xRemaLx 14 мар 2012 в 20:02

Возьму на заметку ;)

VBart 14 мар 2012 в 20:09

Так вы отправите HUP-сигнал всем процессам nginx, полагаю ничего плохого от этого не будет, но лучше отправлять только мастеру. Правильный пример есть в документации: nginx.org/ru/docs/control.html

Ещё проще, nginx -s reload, опять же man nginx

coolcold 15 мар 2012 в 01:39

До кучи может задеть контейнеры(openvz,lxc)/jails

Aux 14 мар 2012 в 20:32

В FreeBSD всё лежит в одном стандартом месте. Как и в других деривативах.

zhovner 14 мар 2012 в 22:22

Да?

FreeBSD/OpenBSD:        /usr/local/etc/rc.d/
NetBSD:                 /usr/pkg/etc/rc.d/
Arch/Slackware:         /etc/rc.d/
Alt Linux:              /etc/rc.d/init.d/
Популярные rpm/deb-based: /etc/init.d

bost84 14 мар 2012 в 21:46

kill -HUP {pid root процесса}

dmitriid 14 мар 2012 в 21:48

sudo invoke-rc.d nginx restart ;)

вбивается по автодополнению в шелле. Но это в Убунту

AlexWinner 15 мар 2012 в 13:06

В Убунту вроде вообще sudo restart nginx

mascmail 15 мар 2012 в 14:50

reload и restart — разные вещи. reload перезагружает файл конфига, не перезапуская сервис.

AlexWinner 15 мар 2012 в 15:39

Я в курсе, отвечал на комментарий про restart, поэтому написал restart.
Действительно, как ниже написали, надо через sudo service. А вот с mongodb, например, и короткий вариант работает:

alexwinner@acer:~$ sudo restart mongodb

mongodb start/running, process 6765

ha2bj 15 мар 2012 в 14:53

sudo service nginx restart

ha2bj 15 мар 2012 в 14:55

т.е. reload

disc 15 мар 2012 в 18:26

У меня почему-то перестает работать rewrite правила, указанные в .htaccess при добавлении в конфиг такого условие, даже если оно пустое:

if (-f /path_to_file/maintenance.file) {

}

Вот что в конфиге location /

location / {

 if (-f /etc/nginx/maint.file) {

 set $tmp clo;

 }

 proxy_pass 192.168.1.100:8000/;

}

Без указанного условия работает все верно.
версия nginx/1.0.13
nginx проксирует запросы в apache, используется как фронтенд сервер.

Куда стоит копать?

lncognito 15 мар 2012 в 19:18

Оверхед на проверку существования файла — небольшой. Да и происходит он только при попадании в локейшн с динамикой (из конфига это, правда, однозначно не видно). Вариант с использованием geo и закрытии сайта только для мира также вполне себе кошерен. Вариант с проверкой файла хорош тем, что непривилегированный пользователь может сам «включать-выключать» свой сайтег и вы не хотите давать ему какие-то права. Данная схема с проверкой файлов вполне себе работоспособна (и даже используется на проекте из первой 10-ки рунета, но для немного иных целей). Как всегда, нужно понимать, как и для чего вы используете тот или иной инструмент.

cadmi 15 мар 2012 в 21:28

if в конфигах nginx — это плохо. Чем их меньше, тем лучше. if на каждый запрос — откровенно плохо.
Уж сколько раз твердили миру… Но нет, документацию не читают, почтовую рассылку тем более, Игоря Сысоева не слушают. И раз за разом появляются разнообразные хауту на какие угодно темы… С if-ами.

seriyPS 15 мар 2012 в 21:43

Да просто у Nginx язык конфига недостаточно продуманный изначально и не очевидный — вот все и путаются.
Авторских статей с типичными кейсами нет, официальных примеров мало.

-1

cadmi 15 мар 2012 в 21:49

Вы что-то путаете. Язык конфига nginx прекрасно продуман и с возложенными на него задачами [обычно] справляется. В том, что набигает похапешнеков, которые на нем пытаются «программировать» с тремя if-ами (пример выше), язык конфига не виноват. Виноваты те набигающие, которые пытаются утюгом гвозди ногебать.

Слова «почтовую рассылку» Вы, конечно, непредумышленно пропустили при чтении, сокрушаясь про авторские кейсы.

Кто хочет «запутаться», тот это непременно сделает. Пробежал глазами по диагонали и аляулю «о! иф есть, аааатлична, щас наворотим же!».

seriyPS 16 мар 2012 в 04:28

Почтовая рассылка это конечно хорошо, но там информация разрозненная и не всегда правильная, опять же. Я уверен что авторы многочисленных статей а ля «Как выкинуть апач и настроить Nginx за 5 минут» рассылки не читают, а потом такие статьи читают, копируют и пошло поехало.

По поводу очевиден/неочевиден простой аргумент: если значительная часть пользователей (действуя, зачастую, интуитивно) используют что-то неправильно и не по назначению то это что-то неочевидно.

Вот говорят if плохо… Но тут об этом не написано nginx.org/ru/docs/http/ngx_http_rewrite_module.html#if (да, тут об этом сказано, ок wiki.nginx.org/Pitfalls)

Может я и не прав на самом деле, но не покидает ощущение что можно было сделать существенно лучше.

VBart 16 мар 2012 в 11:46

99% проблем возникают от того, что люди пытаются настраивать nginx также, как они настраивали апач, видят реврайт и давай в nginx тоже писать реврайт, и т. д. У тех, кто по какой-то причине не был испорчен апачем, как правило, таких проблем не возникает, при условии, что они читают документацию, а не всякие левые туториалы от таких же чайников. Настраивать сервер согласно не документации, а туториалам — это уж извините, просто профнепригодность. Представьте, что вы придете к врачу, а врач будет лечить вас по советам других пациентов.

Информация в рассылке в большинстве случаев правильная. Хотя бы уже потому, что её читают и отвечают на письма люди более опытные, не говоря уже о самих разработчиках.

cadmi 16 мар 2012 в 12:10

Плюсанусь. Пока писал ответ (ниже), Вы уже многое сказали о причинах.

cadmi 16 мар 2012 в 12:05

Быстро, но глупо, откровенно хреново. Вплоть до SIGSEGV в перспективе. Но пофиг, что неправильно, главное — быстро.

Я повторяю и настаиваю. Есть люди, которые привыкли сначала читать и разбираться, потом делать. Для них информации достаточно. И есть, простите, олени, которые всегда найдут способ прострелить себе ногу, максимально быстро, удобно и наглядно, лишь бы не читать. Из-за наличия вторых обобщать первых до «все путаются» и «язык конфига недостаточно очевидный» — это ерунда. Этим оленям никто ничего не должен. На самом деле этим оленям и nginx никакой не нужен. Они повелись на моду («nginx эт куууул!»), они где-то услышали, что «сразу прям быстро все работать начинает» и «если ты не лох, ставь nginx». Этот шлак («вторые», «олени») мало кого интересует в экосистеме, которая построена «первыми»/«людьми».

Всегда найдется и повод для самооправданий, и куча методов.

В рассылке не всегда правильная информация? Ну да, конечно, особенно та, которая в письмах от Igor Sysoev. А какая тогда правильная? Благородные доны не уточняют.

В рассылке разрозненно, вот на сайте бы! Извольте, вот wiki, wiki.nginx.org/IfIsEvil и с кейсами, и с объяснением причин, почему нельзя, и с методиками, что делать вместо.

Ой, а чета по английски-то, где по-русски?

И далее по кругу. Большинство, которое действует интуитивно, не интересует никого, повторюсь.

cadmi 15 мар 2012 в 21:50

Кармы мало, парсер ссылку сьел. «Пример выше» — это про это: habrahabr.ru/post/139968/#comment_4676569

maffei 15 мар 2012 в 22:49

Описанный выше способ ни в коем случае не претендует на универсальность. В условиях проекта для которого разрабатывался — оправдан на 100%. Быстро, наглядно, не влияет общую на производительность, но «плохими» с if-ами.
Пользоваться им или нет — каждый должен оценивать, исходя из собственных реалий.

cadmi 16 мар 2012 в 12:23

Никак он не оправдан, ответ выше. Это только в девичьих мечтах он «на производительность не влияет». Потенциальные SISEGV вообще оправдать нельзя ничем, кроме общей криворукости и частной близорукости.

If-ы не просто «плохие», нечего тут кокетничать кавычками. Они имеют право на существование в конфиге, в некоторых случаях, которые к данному примеру отношения не имеют. И с определенными ограничениями.

В контексте тех примеров, что приводятся в статье, if-ы не просто плохи. Они отвратительны, как бы это ни было обидно автору. Просто примите это.

И приучать толпы хомячков при каждом случае, нужном и не нужном, хреначить в конфиг потенциальные грабли — не нужно этого делать. Даже отмазываясь перед своей совестью аргументами вроде «каждый должен оценивать сам».

maffei 16 мар 2012 в 14:07

if-ы отвратительны. Принял. Без них сделать уход на мейнтенанс с соблюдением приведенных в начале статьи условий не смог, видимо по причине «общей криворукости и частной близорукости». Уверен, что существует сотня других способов — лучше этого. Но пока только так, извините.

cadmi 16 мар 2012 в 14:09

Да без проблем, особенно если сначала придумать себе искусственные ограничения («Перезагружать Nginx при проведении работ тоже нельзя, ни restart, ни reload»), а потом, героически разбив о них лоб, аппелировать к этому, как к последнему шансу на оправдание костылей.

maffei 16 мар 2012 в 14:18

Спасибо за понимание.

cadmi 15 мар 2012 в 21:48

cadmi 15 мар 2012 в 21:49

Прошу прощения, не туда ответил, по ссылке из почты.

Зарегистрируйтесь на Хабре, чтобы оставить комментарий

Показать лучшие за всё время