Re: после yum update остались активны два мастер-процесса nginx

2017-03-30 Пенетрантность Vadim A. Misbakh-Soloviov 
> Для systemd-based исправим, чтобы тоже можно было переопределить аналогичным
> образом.

В systemd же вполне работает systemctl edit svcname. И так администратор может 
добавить Environment=VAR=VALUE...

> Спасибо!

___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

Re: после yum update остались активны два мастер-процесса nginx

2017-03-30 Пенетрантность Gena Makhomed 

On 30.03.2017 22:07, Konstantin Pavlov wrote:


Сколько по времени занимает проверка конфигурационного файла (nginx -t)?


Около секунды, но иногда - проверка конфига занимает 6 или 11 секунд.
Наверное сказывается нагрузка на диски другими контейнерами сервера.

А насколько я понял исходники nginx - он создает pid-файл
только после успешного чтения конфигурационного файла. (!)

Причина глюка видимо в том, что за секунду ни разу не выполнилось
условие if [ -f ${oldbinpidfile} -a -f ${pidfile} ], потому что
нового ${pidfile} просто еще не было на тот момент на диске.


Да, именно поэтому я и спросил про время.


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

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

А так как сейчас есть - получается race condition.
Собственно именно это и наблюдалось в моем случае.


Мы посчитали, что секунды по-умолчанию должно быть достаточно для всех =)



Как мне кажется, задержка в 1 секунду пошла из Makefile,
который генерируется командой ./configure из состава nginx:

upgrade:
/usr/local/nginx/sbin/nginx -t

kill -USR2 `cat /usr/local/nginx/logs/nginx.pid`
sleep 1
test -f /usr/local/nginx/logs/nginx.pid.oldbin

kill -QUIT `cat /usr/local/nginx/logs/nginx.pid.oldbin`

Но тут никто не ждет появления pid-файла от нового мастера,
одна секунда дается старому мастеру на то чтобы получить
сигнал, переименовать nginx.pid в nginx.pid.oldbin
и запустить новый мастер (без лимита времени на старт)

В скрипте /usr/libexec/initscripts/legacy-actions/nginx/upgrade
логика теперь уже совсем другая, там ожидается что за 1 секунду
новый мастер успеет прочитать конфиг и записать свой pid-файл.

Когда включается много мелких конфигурационных файлов в основной конфиг
и когда дисковая подсистема сервера загружена - легко может получиться
и 11 секунд и даже больше.

Можно ли увеличить значение по-умолчанию переменной UPGRADEWAITLOOPS
до UPGRADEWAITLOOPS=450 ?

Это вполне безопасно и не будет приводить к каким-либо проблемам.

В том же systemd значением по-умолчанию для TimeoutStartSec=
и TimeoutStopSec= является 90 секунд и это не вызывает никаких проблем.

Тут у нас, по сути, счетчик UPGRADEWAITLOOPS играет роль TimeoutStartSec


В инит-скрипте для centos/rhel 5-6 используется вот такое для переопределения 
администраторами:

 30 sysconfig=`/bin/basename $initscript`
 31
 32 if [ -f /etc/sysconfig/$sysconfig ]; then
 33 . /etc/sysconfig/$sysconfig
 34 fi

 ...

 42 UPGRADEWAITLOOPS=${UPGRADEWAITLOOPS-5}
 43 CHECKSLEEP=${CHECKSLEEP-3}

Соответственно администратор может переназначить значения переменных так, как 
подходит для его системы.

Для systemd-based исправим, чтобы тоже можно было переопределить аналогичным 
образом.


Только сделайте, пожалуйста, значение по-умолчанию UPGRADEWAITLOOPS=450

И тогда очень мало кому понадобится менять новое дефолтовое значение 
UPGRADEWAITLOOPS=450 на какое-то другое, 99.99% пользователей

вполне устроит то, как будет работать новый service nginx upgrade

--
Best regards,
 Gena

___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

Re: после yum update остались активны два мастер-процесса nginx

2017-03-30 Пенетрантность Konstantin Pavlov 
On 30/03/2017 19:59, Gena Makhomed wrote:
> On 30.03.2017 17:26, Konstantin Pavlov wrote:
> 
>>> в файле /var/run/nginx.pid записано 26112
>>> в файле /var/run/nginx.pid.oldbin записано 603
>>>
>>> при обновлении nginx с версии 1.11.10 на версию 1.11.12
>>> через yum update он ругнулся, что во время обновления произошла
>>> ошибка и остались висеть оба мастер-процесса со своими воркерами.
> 
>> Сообщения какие-нибудь остались в терминале?
> 
> Только это: "Binary upgrade failed, please check nginx's error.log"
> 
> Но судя по pid-файлам, "Starting new master nginx" получилось сделать,
> а операция "Graceful shutdown of old nginx" вообще не была выполнена.
> 
>> Что либо есть в error log'ах в эпсилон-окрестности времени обновления?
> 
> В /var/log/nginx/error.log пусто, проверка nginx -t проходит без ошибок.
> 
>> Сколько по времени занимает проверка конфигурационного файла (nginx -t)?
> 
> Около секунды, но иногда - проверка конфига занимает 6 или 11 секунд.
> Наверное сказывается нагрузка на диски другими контейнерами сервера.
> 
> А насколько я понял исходники nginx - он создает pid-файл
> только после успешного чтения конфигурационного файла. (!)
> 
> Причина глюка видимо в том, что за секунду ни разу не выполнилось
> условие if [ -f ${oldbinpidfile} -a -f ${pidfile} ], потому что
> нового ${pidfile} просто еще не было на тот момент на диске.

Да, именно поэтому я и спросил про время.

> Может быть имеет смысл сделать UPGRADEWAITLOOPS побольше, так чтобы
> максимальное время ожидания было не 1 секунда, а 30 секунд например?
> 
> Это будет очень актуально для конфигураций с большим количеством
> включаемых файлов на серверах с нагруженной дисковой подсистемой.
> 
> А так как сейчас есть - получается race condition.
> Собственно именно это и наблюдалось в моем случае.

Мы посчитали, что секунды по-умолчанию должно быть достаточно для всех =)

В инит-скрипте для centos/rhel 5-6 используется вот такое для переопределения 
администраторами:

 30 sysconfig=`/bin/basename $initscript`
 31
 32 if [ -f /etc/sysconfig/$sysconfig ]; then
 33 . /etc/sysconfig/$sysconfig
 34 fi

 ...

 42 UPGRADEWAITLOOPS=${UPGRADEWAITLOOPS-5}
 43 CHECKSLEEP=${CHECKSLEEP-3}

Соответственно администратор может переназначить значения переменных так, как 
подходит для его системы.

Для systemd-based исправим, чтобы тоже можно было переопределить аналогичным 
образом.

Спасибо!

-- 
Konstantin Pavlov
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

Re: после yum update остались активны два мастер-процесса nginx

2017-03-30 Пенетрантность Gena Makhomed 

On 30.03.2017 17:26, Konstantin Pavlov wrote:


в файле /var/run/nginx.pid записано 26112
в файле /var/run/nginx.pid.oldbin записано 603

при обновлении nginx с версии 1.11.10 на версию 1.11.12
через yum update он ругнулся, что во время обновления произошла
ошибка и остались висеть оба мастер-процесса со своими воркерами.



Сообщения какие-нибудь остались в терминале?


Только это: "Binary upgrade failed, please check nginx's error.log"

Но судя по pid-файлам, "Starting new master nginx" получилось сделать,
а операция "Graceful shutdown of old nginx" вообще не была выполнена.


Что либо есть в error log'ах в эпсилон-окрестности времени обновления?


В /var/log/nginx/error.log пусто, проверка nginx -t проходит без ошибок.


Сколько по времени занимает проверка конфигурационного файла (nginx -t)?


Около секунды, но иногда - проверка конфига занимает 6 или 11 секунд.
Наверное сказывается нагрузка на диски другими контейнерами сервера.

А насколько я понял исходники nginx - он создает pid-файл
только после успешного чтения конфигурационного файла. (!)

Причина глюка видимо в том, что за секунду ни разу не выполнилось
условие if [ -f ${oldbinpidfile} -a -f ${pidfile} ], потому что
нового ${pidfile} просто еще не было на тот момент на диске.

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

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

А так как сейчас есть - получается race condition.
Собственно именно это и наблюдалось в моем случае.

--
Best regards,
 Gena

___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

Re: после yum update остались активны два мастер-процесса nginx

2017-03-30 Пенетрантность Maxim Dounin 
Hello!

On Thu, Mar 30, 2017 at 05:26:11PM +0300, Konstantin Pavlov wrote:

[...]

> > в конфиге nginx прописано worker_processes 8;
> > у старого мастера их почему-то было в два раза больше запущено.
> 
> У старого мастера могли быть reload'ы и долгоиграющие 
> соединения, что может обьяснять количество воркеров.

При релоаде заголовок процесса меняется на "worker process is 
shutting down", тут же у всех "worker process".

-- 
Maxim Dounin
http://nginx.org/
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

Re: Cache TTL = 0

2017-03-30 Пенетрантность S.A.N 
Проще всего сделать как в Amazon CloudFront, если бекенд отдал
Cache-Control: max-age=0, кешировать эти ответы, если в заголовках ответа
есть валидаторы ETag или Last-Modified.

Posted at Nginx Forum: 
https://forum.nginx.org/read.php?21,273298,273299#msg-273299

___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

Re: после yum update остались активны два мастер-процесса nginx

2017-03-30 Пенетрантность Konstantin Pavlov 
On 30/03/2017 09:33, Gena Makhomed wrote:
> Здравствуйте!
> 
> в файле /var/run/nginx.pid записано 26112
> в файле /var/run/nginx.pid.oldbin записано 603
> 
> при обновлении nginx с версии 1.11.10 на версию 1.11.12
> через yum update он ругнулся, что во время обновления произошла
> ошибка и остались висеть оба мастер-процесса со своими воркерами.
> 
> официальная сборка из репозитория nginx.org mainline для centos 7.
> 
> в sysctl.conf сервера прописано net.ipv4.ip_nonlocal_bind=1
> и эта CentOS 7 - контейнер на OpenVZ 2.6.32-042stab120.18
> если это может быть важно.

Сообщения какие-нибудь остались в терминале?  Что либо есть в error log'ах в 
эпсилон-окрестности времени обновления?

Сколько по времени занимает проверка конфигурационного файла (nginx -t)? Была 
ли высокая нагрузка на диски в момент обновления?

> ожидалось что после yum update останется только один мастер nginx.
> и только его воркер-процессы.
> 
> в конфиге nginx прописано worker_processes 8;
> у старого мастера их почему-то было в два раза больше запущено.

У старого мастера могли быть reload'ы и долгоиграющие соединения, что может 
обьяснять количество воркеров.

> # pstree -cp
> systemd(1)─┬─nginx(603)─┬─nginx(26112)─┬─nginx(26826)
>││  ├─nginx(26827)
>││  ├─nginx(26828)
>││  ├─nginx(26829)
>││  ├─nginx(26830)
>││  ├─nginx(26831)
>││  ├─nginx(26832)
>││  └─nginx(26833)
>│├─nginx(25993)
>│├─nginx(25994)
>│├─nginx(25995)
>│├─nginx(25996)
>│├─nginx(25997)
>│├─nginx(25998)
>│├─nginx(25999)
>│├─nginx(26000)
>│├─nginx(26160)
>│├─nginx(26161)
>│├─nginx(26162)
>│├─nginx(26163)
>│├─nginx(26164)
>│├─nginx(26165)
>│├─nginx(26166)
>│└─nginx(26167)
> 
> 
> # ps aux | grep nginx
> USER   PID %CPU %MEMVSZ   RSS TTY  STAT START   TIME COMMAND
> root   603  0.0  3.5 143696 73680 ?Ss   Mar05   0:10 nginx: 
> master process /usr/sbin/nginx -c /etc/nginx/nginx.conf
> nginx25993  0.0  3.9 152352 82552 ?S<   Mar29   0:02 nginx: 
> worker process
> nginx25994  0.0  3.9 152352 82580 ?S<   Mar29   0:02 nginx: 
> worker process
> nginx25995  0.0  3.9 152352 82556 ?S<   Mar29   0:02 nginx: 
> worker process
> nginx25996  0.0  3.9 152352 82580 ?S<   Mar29   0:02 nginx: 
> worker process
> nginx25997  0.0  3.9 152352 82604 ?S<   Mar29   0:03 nginx: 
> worker process
> nginx25998  0.0  3.9 152352 82588 ?S<   Mar29   0:04 nginx: 
> worker process
> nginx25999  0.0  3.9 152352 82588 ?S<   Mar29   0:04 nginx: 
> worker process
> nginx26000  0.0  3.9 152352 82640 ?S<   Mar29   0:05 nginx: 
> worker process
> root 26112  0.0  3.7 145824 77672 ?SMar29   0:01 nginx: 
> master process /usr/sbin/nginx -c /etc/nginx/nginx.conf
> nginx26160  0.0  3.9 152352 82632 ?S<   Mar29   0:05 nginx: 
> worker process
> nginx26161  0.0  3.9 152352 82620 ?S<   Mar29   0:06 nginx: 
> worker process
> nginx26162  0.0  3.9 152352 82632 ?S<   Mar29   0:08 nginx: 
> worker process
> nginx26163  0.0  3.9 152352 82652 ?S<   Mar29   0:09 nginx: 
> worker process
> nginx26164  0.0  3.9 152352 82652 ?S<   Mar29   0:10 nginx: 
> worker process
> nginx26165  0.0  3.9 152352 82660 ?S<   Mar29   0:12 nginx: 
> worker process
> nginx26166  0.0  3.9 152352 82648 ?S<   Mar29   0:14 nginx: 
> worker process
> nginx26167  0.0  3.9 152352 82672 ?S<   Mar29   0:16 nginx: 
> worker process
> nginx26826  0.0  3.6 145828 76444 ?S<   05:00   0:05 nginx: 
> worker process
> nginx26827  0.0  3.6 145828 76456 ?S<   05:00   0:06 nginx: 
> worker process
> nginx26828  0.0  3.6 145828 76456 ?S<   05:00   0:07 nginx: 
> worker process
> nginx26829  0.0  3.6 145828 76488 ?S<   05:00   0:12 nginx: 
> worker process
> nginx26830  0.0  3.6 145828 76464 ?S<   05:00   0:09 nginx: 
> worker process
> nginx26831  0.1  3.6 145828 76468 ?S<   05:00   0:17 nginx: 
> worker process
> nginx26832  0.1  3.6 145828 76488 ?S<   05:00   0:26 nginx: 
> worker process
> nginx26833  0.1  3.6 145828 76488 ?S<   05:00   0:21 nginx: 
> worker process
> 


-- 
Konstantin Pavlov
___
nginx-ru mailing list
nginx-ru@nginx.org

Cache TTL = 0

2017-03-30 Пенетрантность S.A.N 
Здравствуйте.

Я уже когда-то писал, что некоторые запросы бекенды должны всегда
ревалидировать, в спецификации это документировано в трех параметрах
заголовка Cache-Control.

max-age=0 - кешировать если есть валидатор (ETag или Last-Modified)
no-cache - не использовать кеш без ревалидации
must-revalidate - нужна ревалидация

Есть тикеты в багтрекере
https://trac.nginx.org/nginx/ticket/1182

Amazon CloudFront, уже это потдерживает в своих патчах Nginx
http://stackoverflow.com/questions/10621099/what-is-a-ttl-0-in-cloudfront-useful-for

Я провел маленькое исследования, многие веб фреймворки используют параметр
no-cache чтобы отключить кеширование, реже для этого используют max-age=0,
но никто не использует для отключения кеширования параметр must-revalidate.

Чтобы не нарушить обратную совместимость со многими фрейворками, безопасней
всего научить Nginx понимать параметр must-revalidate.

Если не указаны no-store, no-cache, max-age=0 но указан must-revalidate и
бекенд отдал валидаторы ETag или Last-Modified, тогда Nginx сохраняет ответ
в свой кеш и при запросах всегда проводит ревалидацию.

Это потребность из реальных кейсов, спасибо.

Posted at Nginx Forum: 
https://forum.nginx.org/read.php?21,273298,273298#msg-273298

___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

после yum update остались активны два мастер-процесса nginx

2017-03-30 Пенетрантность Gena Makhomed 

Здравствуйте!

в файле /var/run/nginx.pid записано 26112
в файле /var/run/nginx.pid.oldbin записано 603

при обновлении nginx с версии 1.11.10 на версию 1.11.12
через yum update он ругнулся, что во время обновления произошла
ошибка и остались висеть оба мастер-процесса со своими воркерами.

официальная сборка из репозитория nginx.org mainline для centos 7.

в sysctl.conf сервера прописано net.ipv4.ip_nonlocal_bind=1
и эта CentOS 7 - контейнер на OpenVZ 2.6.32-042stab120.18
если это может быть важно.

ожидалось что после yum update останется только один мастер nginx.
и только его воркер-процессы.

в конфиге nginx прописано worker_processes 8;
у старого мастера их почему-то было в два раза больше запущено.

# pstree -cp
systemd(1)─┬─nginx(603)─┬─nginx(26112)─┬─nginx(26826)
   ││  ├─nginx(26827)
   ││  ├─nginx(26828)
   ││  ├─nginx(26829)
   ││  ├─nginx(26830)
   ││  ├─nginx(26831)
   ││  ├─nginx(26832)
   ││  └─nginx(26833)
   │├─nginx(25993)
   │├─nginx(25994)
   │├─nginx(25995)
   │├─nginx(25996)
   │├─nginx(25997)
   │├─nginx(25998)
   │├─nginx(25999)
   │├─nginx(26000)
   │├─nginx(26160)
   │├─nginx(26161)
   │├─nginx(26162)
   │├─nginx(26163)
   │├─nginx(26164)
   │├─nginx(26165)
   │├─nginx(26166)
   │└─nginx(26167)


# ps aux | grep nginx
USER   PID %CPU %MEMVSZ   RSS TTY  STAT START   TIME COMMAND
root   603  0.0  3.5 143696 73680 ?Ss   Mar05   0:10 nginx: 
master process /usr/sbin/nginx -c /etc/nginx/nginx.conf
nginx25993  0.0  3.9 152352 82552 ?S<   Mar29   0:02 nginx: 
worker process
nginx25994  0.0  3.9 152352 82580 ?S<   Mar29   0:02 nginx: 
worker process
nginx25995  0.0  3.9 152352 82556 ?S<   Mar29   0:02 nginx: 
worker process
nginx25996  0.0  3.9 152352 82580 ?S<   Mar29   0:02 nginx: 
worker process
nginx25997  0.0  3.9 152352 82604 ?S<   Mar29   0:03 nginx: 
worker process
nginx25998  0.0  3.9 152352 82588 ?S<   Mar29   0:04 nginx: 
worker process
nginx25999  0.0  3.9 152352 82588 ?S<   Mar29   0:04 nginx: 
worker process
nginx26000  0.0  3.9 152352 82640 ?S<   Mar29   0:05 nginx: 
worker process
root 26112  0.0  3.7 145824 77672 ?SMar29   0:01 nginx: 
master process /usr/sbin/nginx -c /etc/nginx/nginx.conf
nginx26160  0.0  3.9 152352 82632 ?S<   Mar29   0:05 nginx: 
worker process
nginx26161  0.0  3.9 152352 82620 ?S<   Mar29   0:06 nginx: 
worker process
nginx26162  0.0  3.9 152352 82632 ?S<   Mar29   0:08 nginx: 
worker process
nginx26163  0.0  3.9 152352 82652 ?S<   Mar29   0:09 nginx: 
worker process
nginx26164  0.0  3.9 152352 82652 ?S<   Mar29   0:10 nginx: 
worker process
nginx26165  0.0  3.9 152352 82660 ?S<   Mar29   0:12 nginx: 
worker process
nginx26166  0.0  3.9 152352 82648 ?S<   Mar29   0:14 nginx: 
worker process
nginx26167  0.0  3.9 152352 82672 ?S<   Mar29   0:16 nginx: 
worker process
nginx26826  0.0  3.6 145828 76444 ?S<   05:00   0:05 nginx: 
worker process
nginx26827  0.0  3.6 145828 76456 ?S<   05:00   0:06 nginx: 
worker process
nginx26828  0.0  3.6 145828 76456 ?S<   05:00   0:07 nginx: 
worker process
nginx26829  0.0  3.6 145828 76488 ?S<   05:00   0:12 nginx: 
worker process
nginx26830  0.0  3.6 145828 76464 ?S<   05:00   0:09 nginx: 
worker process
nginx26831  0.1  3.6 145828 76468 ?S<   05:00   0:17 nginx: 
worker process
nginx26832  0.1  3.6 145828 76488 ?S<   05:00   0:26 nginx: 
worker process
nginx26833  0.1  3.6 145828 76488 ?S<   05:00   0:21 nginx: 
worker process


--
Best regards,
 Gena

___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru