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.999999% пользователей
вполне устроит то, как будет работать новый service nginx upgrade
--
Best regards,
Gena
_______________________________________________
nginx-ru mailing list
[email protected]
http://mailman.nginx.org/mailman/listinfo/nginx-ru
