Comments 69
Интересно, а насколько «дорого» будет проверка наличия файл при каждом запросе? Ведь если на сервер приходится, скажем, 1000 запросов / сек, то это еще 1000 дополнительных обращений к ФС?
+21
нет.
-8
ФС кеширует такие штуки, но это всё равно плохо. Если это только на время чтения конфига, то подходит решение.
+3
зависит от того, в каком месте иерархии ФС создавать триггер.
если мы имеем дело с *nix, то можно ведь создать файлик и в оперативке.
если мы имеем дело с *nix, то можно ведь создать файлик и в оперативке.
+1
Это не избавит вас от лишнего сискола на каждый запрос.
Наиболее правильный и корректный способ закрытия на обслуживание — это релоад nginx-а с соответствующим конфигом.
p.s. imho закрытие сайта для проведения «работ» это какой-то каменный век вообще.
Наиболее правильный и корректный способ закрытия на обслуживание — это релоад nginx-а с соответствующим конфигом.
p.s. imho закрытие сайта для проведения «работ» это какой-то каменный век вообще.
+14
Сегодня на хабре пол дня висело сообщение о проведении «работ»
+11
ну, всех проблем в мире не решить. если частота системных вызовов в 1 килогерц кого-то устраивает, то почему бы и нет, если про реакцию nginx'а на SIGHUP и SIGUSR1 прочитать не довелось.
да и потом, идея с проверкой файл-триггера хоть и ресурсоёмка, зато проста и понятна; а релоад пойди-ка ещё найди как правильно сделать. =)
да и потом, идея с проверкой файл-триггера хоть и ресурсоёмка, зато проста и понятна; а релоад пойди-ка ещё найди как правильно сделать. =)
0
Глянул только что показатели по IO до и после модификации конфига. Разница меньше 0.1%. Но и загрузка сервера, конечно, на порядок меньше.
0
Если у вас 1000 запросов в секунду, то в любом случае жинкс как минимум тянет статитики на это количество соединений.
Так что 1000 обращений к ФС это не большая проблема, особенно если вынести файл в RAM
Второй вариант это использовать nginx.org/ru/docs/http/ngx_http_memcached_module.html
устанавливая ключ.
Так что 1000 обращений к ФС это не большая проблема, особенно если вынести файл в RAM
Второй вариант это использовать nginx.org/ru/docs/http/ngx_http_memcached_module.html
устанавливая ключ.
+1
UFO just landed and posted this here
Для этого специально придумали try_files.
Пример из документации:
Пример из документации:
location / { try_files /system/maintenance.html $uri }
+15
оно вернет не 503 а 200, на что поисковики болезненно реагируют.
0
location / { try_files /system/maintenance.html } location /system/maintenance.html { return 503; }
+2
Таким образом вы будете отдавать дефолтную 503 на любой запрос и в независимости от наличия/отсутствия /system/maintenance.html
0
Т.е. полный пример будет выглядеть как
Если это работает то это офигенно!
location / {
try_files /system/maintenance.html @backend;
}
location /system/maintenance.html {
return 503;
}
Если это работает то это офигенно!
0
Картинки то можно обслуживать даже при работах, да и на самой странице 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
Не надо программировать на конфигах nginx. Для всего этого есть специальные директивы.
+2
Так покажите как правильно такое сделать.
0
Много раз в рассылке обсуждалось.
mailman.nginx.org/pipermail/nginx/2011-November/030165.html
mailman.nginx.org/pipermail/nginx/2011-November/030165.html
+7
С 503-й еще не забывайте про заголовок Retry-After.
+1
Рано отправил. Я обычно в своем рабочем конфиге держу в апстриме бэкенд специально для выдачи maintenance notice. Если надо уйти в maintenance, я помечаю текущий бэкенд как нерабочий. Заодно оно и само срабатывает, если с бэкендом что-то случилось. Почему именно бэкенд — предпочитаю считать и знать сколько и кто конкретно видел ошибки или maintenance период на сайте, для этого пользуюсь statsd + uid_module.
0
А чем
sudo /etc/init.d/nginx reload
не устроил?
Вроде как он мягко вводит в силу новый конфиг — новые подключения на новом конфиге, старые отрабатывают и мрут.
sudo /etc/init.d/nginx reload
не устроил?
Вроде как он мягко вводит в силу новый конфиг — новые подключения на новом конфиге, старые отрабатывают и мрут.
+13
Поддерживаю.
Регулярно пользуюсь, никаких проблем не замечено.
Регулярно пользуюсь, никаких проблем не замечено.
+3
С Вами полностью согласен. Подойдет как restart так reload.
+2
Еще проще killall -HUP nginx
И не нужно искать где лежать стартовые скрипты.
И не нужно искать где лежать стартовые скрипты.
-2
Возьму на заметку ;)
0
Так вы отправите HUP-сигнал всем процессам nginx, полагаю ничего плохого от этого не будет, но лучше отправлять только мастеру. Правильный пример есть в документации: nginx.org/ru/docs/control.html
Ещё проще, nginx -s reload, опять же man nginx
Ещё проще, nginx -s reload, опять же man nginx
+2
В FreeBSD всё лежит в одном стандартом месте. Как и в других деривативах.
+2
kill -HUP {pid root процесса}
0
sudo invoke-rc.d nginx restart ;)
вбивается по автодополнению в шелле. Но это в Убунту
вбивается по автодополнению в шелле. Но это в Убунту
+1
В Убунту вроде вообще sudo restart nginx
+1
reload и restart — разные вещи. reload перезагружает файл конфига, не перезапуская сервис.
0
sudo service nginx restart
+1
У меня почему-то перестает работать rewrite правила, указанные в .htaccess при добавлении в конфиг такого условие, даже если оно пустое:
Вот что в конфиге location /
Без указанного условия работает все верно.
версия nginx/1.0.13
nginx проксирует запросы в apache, используется как фронтенд сервер.
Куда стоит копать?
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, используется как фронтенд сервер.
Куда стоит копать?
0
Оверхед на проверку существования файла — небольшой. Да и происходит он только при попадании в локейшн с динамикой (из конфига это, правда, однозначно не видно). Вариант с использованием geo и закрытии сайта только для мира также вполне себе кошерен. Вариант с проверкой файла хорош тем, что непривилегированный пользователь может сам «включать-выключать» свой сайтег и вы не хотите давать ему какие-то права. Данная схема с проверкой файлов вполне себе работоспособна (и даже используется на проекте из первой 10-ки рунета, но для немного иных целей). Как всегда, нужно понимать, как и для чего вы используете тот или иной инструмент.
0
if в конфигах nginx — это плохо. Чем их меньше, тем лучше. if на каждый запрос — откровенно плохо.
Уж сколько раз твердили миру… Но нет, документацию не читают, почтовую рассылку тем более, Игоря Сысоева не слушают. И раз за разом появляются разнообразные хауту на какие угодно темы… С if-ами.
Уж сколько раз твердили миру… Но нет, документацию не читают, почтовую рассылку тем более, Игоря Сысоева не слушают. И раз за разом появляются разнообразные хауту на какие угодно темы… С if-ами.
+1
Да просто у Nginx язык конфига недостаточно продуманный изначально и не очевидный — вот все и путаются.
Авторских статей с типичными кейсами нет, официальных примеров мало.
Авторских статей с типичными кейсами нет, официальных примеров мало.
-1
Вы что-то путаете. Язык конфига nginx прекрасно продуман и с возложенными на него задачами [обычно] справляется. В том, что набигает похапешнеков, которые на нем пытаются «программировать» с тремя if-ами (пример выше), язык конфига не виноват. Виноваты те набигающие, которые пытаются утюгом гвозди ногебать.
Слова «почтовую рассылку» Вы, конечно, непредумышленно пропустили при чтении, сокрушаясь про авторские кейсы.
Кто хочет «запутаться», тот это непременно сделает. Пробежал глазами по диагонали и аляулю «о! иф есть, аааатлична, щас наворотим же!».
Слова «почтовую рассылку» Вы, конечно, непредумышленно пропустили при чтении, сокрушаясь про авторские кейсы.
Кто хочет «запутаться», тот это непременно сделает. Пробежал глазами по диагонали и аляулю «о! иф есть, аааатлична, щас наворотим же!».
0
Почтовая рассылка это конечно хорошо, но там информация разрозненная и не всегда правильная, опять же. Я уверен что авторы многочисленных статей а ля «Как выкинуть апач и настроить Nginx за 5 минут» рассылки не читают, а потом такие статьи читают, копируют и пошло поехало.
По поводу очевиден/неочевиден простой аргумент: если значительная часть пользователей (действуя, зачастую, интуитивно) используют что-то неправильно и не по назначению то это что-то неочевидно.
Вот говорят if плохо… Но тут об этом не написано nginx.org/ru/docs/http/ngx_http_rewrite_module.html#if (да, тут об этом сказано, ок wiki.nginx.org/Pitfalls)
Может я и не прав на самом деле, но не покидает ощущение что можно было сделать существенно лучше.
По поводу очевиден/неочевиден простой аргумент: если значительная часть пользователей (действуя, зачастую, интуитивно) используют что-то неправильно и не по назначению то это что-то неочевидно.
Вот говорят if плохо… Но тут об этом не написано nginx.org/ru/docs/http/ngx_http_rewrite_module.html#if (да, тут об этом сказано, ок wiki.nginx.org/Pitfalls)
Может я и не прав на самом деле, но не покидает ощущение что можно было сделать существенно лучше.
0
99% проблем возникают от того, что люди пытаются настраивать nginx также, как они настраивали апач, видят реврайт и давай в nginx тоже писать реврайт, и т. д. У тех, кто по какой-то причине не был испорчен апачем, как правило, таких проблем не возникает, при условии, что они читают документацию, а не всякие левые туториалы от таких же чайников. Настраивать сервер согласно не документации, а туториалам — это уж извините, просто профнепригодность. Представьте, что вы придете к врачу, а врач будет лечить вас по советам других пациентов.
Информация в рассылке в большинстве случаев правильная. Хотя бы уже потому, что её читают и отвечают на письма люди более опытные, не говоря уже о самих разработчиках.
Информация в рассылке в большинстве случаев правильная. Хотя бы уже потому, что её читают и отвечают на письма люди более опытные, не говоря уже о самих разработчиках.
0
Быстро, но глупо, откровенно хреново. Вплоть до SIGSEGV в перспективе. Но пофиг, что неправильно, главное — быстро.
Я повторяю и настаиваю. Есть люди, которые привыкли сначала читать и разбираться, потом делать. Для них информации достаточно. И есть, простите, олени, которые всегда найдут способ прострелить себе ногу, максимально быстро, удобно и наглядно, лишь бы не читать. Из-за наличия вторых обобщать первых до «все путаются» и «язык конфига недостаточно очевидный» — это ерунда. Этим оленям никто ничего не должен. На самом деле этим оленям и nginx никакой не нужен. Они повелись на моду («nginx эт куууул!»), они где-то услышали, что «сразу прям быстро все работать начинает» и «если ты не лох, ставь nginx». Этот шлак («вторые», «олени») мало кого интересует в экосистеме, которая построена «первыми»/«людьми».
Всегда найдется и повод для самооправданий, и куча методов.
В рассылке не всегда правильная информация? Ну да, конечно, особенно та, которая в письмах от Igor Sysoev. А какая тогда правильная? Благородные доны не уточняют.
В рассылке разрозненно, вот на сайте бы! Извольте, вот wiki, wiki.nginx.org/IfIsEvil и с кейсами, и с объяснением причин, почему нельзя, и с методиками, что делать вместо.
Ой, а чета по английски-то, где по-русски?
И далее по кругу. Большинство, которое действует интуитивно, не интересует никого, повторюсь.
Я повторяю и настаиваю. Есть люди, которые привыкли сначала читать и разбираться, потом делать. Для них информации достаточно. И есть, простите, олени, которые всегда найдут способ прострелить себе ногу, максимально быстро, удобно и наглядно, лишь бы не читать. Из-за наличия вторых обобщать первых до «все путаются» и «язык конфига недостаточно очевидный» — это ерунда. Этим оленям никто ничего не должен. На самом деле этим оленям и nginx никакой не нужен. Они повелись на моду («nginx эт куууул!»), они где-то услышали, что «сразу прям быстро все работать начинает» и «если ты не лох, ставь nginx». Этот шлак («вторые», «олени») мало кого интересует в экосистеме, которая построена «первыми»/«людьми».
Всегда найдется и повод для самооправданий, и куча методов.
В рассылке не всегда правильная информация? Ну да, конечно, особенно та, которая в письмах от Igor Sysoev. А какая тогда правильная? Благородные доны не уточняют.
В рассылке разрозненно, вот на сайте бы! Извольте, вот wiki, wiki.nginx.org/IfIsEvil и с кейсами, и с объяснением причин, почему нельзя, и с методиками, что делать вместо.
Ой, а чета по английски-то, где по-русски?
И далее по кругу. Большинство, которое действует интуитивно, не интересует никого, повторюсь.
+1
Кармы мало, парсер ссылку сьел. «Пример выше» — это про это: habrahabr.ru/post/139968/#comment_4676569
0
Описанный выше способ ни в коем случае не претендует на универсальность. В условиях проекта для которого разрабатывался — оправдан на 100%. Быстро, наглядно, не влияет общую на производительность, но «плохими» с if-ами.
Пользоваться им или нет — каждый должен оценивать, исходя из собственных реалий.
Пользоваться им или нет — каждый должен оценивать, исходя из собственных реалий.
0
Никак он не оправдан, ответ выше. Это только в девичьих мечтах он «на производительность не влияет». Потенциальные SISEGV вообще оправдать нельзя ничем, кроме общей криворукости и частной близорукости.
If-ы не просто «плохие», нечего тут кокетничать кавычками. Они имеют право на существование в конфиге, в некоторых случаях, которые к данному примеру отношения не имеют. И с определенными ограничениями.
В контексте тех примеров, что приводятся в статье, if-ы не просто плохи. Они отвратительны, как бы это ни было обидно автору. Просто примите это.
И приучать толпы хомячков при каждом случае, нужном и не нужном, хреначить в конфиг потенциальные грабли — не нужно этого делать. Даже отмазываясь перед своей совестью аргументами вроде «каждый должен оценивать сам».
If-ы не просто «плохие», нечего тут кокетничать кавычками. Они имеют право на существование в конфиге, в некоторых случаях, которые к данному примеру отношения не имеют. И с определенными ограничениями.
В контексте тех примеров, что приводятся в статье, if-ы не просто плохи. Они отвратительны, как бы это ни было обидно автору. Просто примите это.
И приучать толпы хомячков при каждом случае, нужном и не нужном, хреначить в конфиг потенциальные грабли — не нужно этого делать. Даже отмазываясь перед своей совестью аргументами вроде «каждый должен оценивать сам».
0
if-ы отвратительны. Принял. Без них сделать уход на мейнтенанс с соблюдением приведенных в начале статьи условий не смог, видимо по причине «общей криворукости и частной близорукости». Уверен, что существует сотня других способов — лучше этого. Но пока только так, извините.
0
Вы что-то путаете. Язык конфига nginx прекрасно продуман и с возложенными на него задачами [обычно] справляется. В том, что набигает похапешнеков, которые на нем пытаются «программировать» с тремя if-ами (пример выше), язык конфига не виноват. Виноваты те набигающие, которые пытаются утюгом гвозди ногебать.
Слова «почтовую рассылку» Вы, конечно, непредумышленно пропустили при чтении, сокрушаясь про авторские кейсы.
Кто хочет «запутаться», тот это непременно сделает. Пробежал глазами по диагонали и аляулю «о! иф есть, аааатлична, щас наворотим же!».
Слова «почтовую рассылку» Вы, конечно, непредумышленно пропустили при чтении, сокрушаясь про авторские кейсы.
Кто хочет «запутаться», тот это непременно сделает. Пробежал глазами по диагонали и аляулю «о! иф есть, аааатлична, щас наворотим же!».
0
Sign up to leave a comment.
Nginx — уходим на технические работы