<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<title></title>
</head>
<body>
<div name="messageBodySection" style="font-size: 14px; font-family: -apple-system, BlinkMacSystemFont, sans-serif;">Илья, модули все из коробки
<div><br /></div>
<div>ничего лишнего не доливаем</div>
<div><br /></div>
<div>из экстрима, пожалуй, только perl-модуль для ряда мелких задачек</div>
<div><br /></div>
<div>--with-cc-opt='-g -O2 -fstack-protector --param=ssp-buffer-size=4 -Wformat -Werror=format-security -D_FORTIFY_SOURCE=2' --with-ld-opt='-Wl,-Bsymbolic-functions -Wl,-z,relro' --prefix=/usr/share/nginx --sbin-path=/usr/sbin/nginx --conf-path=/etc/nginx/nginx.conf --http-log-path=/var/log/nginx/access.log --error-log-path=/var/log/nginx/error.log --lock-path=/var/lock/nginx.lock --pid-path=/run/nginx.pid --http-client-body-temp-path=/var/lib/nginx/body --http-proxy-temp-path=/var/lib/nginx/proxy --user=httpd --group=robot --with-http_ssl_module --with-http_realip_module --with-http_sub_module --with-http_flv_module --with-http_mp4_module --with-http_stub_status_module --with-file-aio --with-threads --with-http_v2_module --with-http_geoip_module --with-http_image_filter_module --with-http_perl_module --without-http_fastcgi_module --without-http_uwsgi_module --without-http_scgi_module --without-http_memcached_module --with-openssl=../openssl-1.1.1b --with-debug<br /></div>
</div>
<div name="messageSignatureSection" style="font-size: 14px; font-family: -apple-system, BlinkMacSystemFont, sans-serif;"><br />
<div>--with-debug ещё добавил только что на время теста… и уровень отладки error_log включил debug</div>
<div>но у нас за пару минут лог в таком режиме достигает 40 Мб ;-)</div>
<div><br /></div>
<div>корки сейчас включу и буду ловить</div>
<div>но это ещё умудриться словить момент и дождаться, когда упадёт, может за час несколько раз свалится</div>
<div><br /></div>
<div><br /></div>
</div>
<div name="messageReplySection" style="font-size: 14px; font-family: -apple-system, BlinkMacSystemFont, sans-serif;">On 31 May 2019, 14:48 +0300, Илья Шипицин <chipitsine@gmail.com>, wrote:<br />
<blockquote type="cite" style="margin: 5px 5px; padding-left: 10px; border-left: thin solid #1abc9c;">
<div dir="ltr">
<div>привет!</div>
<div><br /></div>
<div>segfault - с очень-очень-очень большой вероятностью из-за сторонних модулей nginx.</div>
<div> можете показать вывод "nginx -V" ?</div>
<div><br /></div>
<div>как бороться с сегфолтами - весьма просто. надо скомпилировать nginx с отладкой, при это не strip-нуть ее в момент инсталяции</div>
<div>команда "file `which nginx`" должна показыват "not stripped"</div>
<div><br /></div>
<div>далее - в вашей операционной системе разрешаете сохранение core dump (алгоритм варьируется в зависимости от наличия systemd и еще ряда вещей)</div>
<div><br /></div>
<div>потом, берете сохраненный core dump, при помощи gdb открываете, делаете "bt full", смотрите на чем именно упало.</div>
<div><br /></div>
<div>если что, обращайтесь. тут в рассылке куча людей умеет такое делать ))<br /></div>
</div>
<br />
<div class="gmail_quote">
<div dir="ltr" class="gmail_attr">пт, 31 мая 2019 г. в 15:47, Alexey Galygin via nginx-ru <<a href="mailto:nginx-ru@nginx.org">nginx-ru@nginx.org</a>>:<br /></div>
<blockquote class="gmail_quote" style="margin: 5px 5px; padding-left: 10px; border-left: thin solid #e67e22;">
<div>
<div name="messageBodySection" style="font-size:14px;font-family:-apple-system,BlinkMacSystemFont,sans-serif">
<div>всем привет</div>
<div><br /></div>
<div>ПРОБЛЕМА</div>
<div><br /></div>
<div>давно (уже не первый год обновление за обновлением nginx и OpenSSL) наблюдаем,</div>
<div>что ряд страниц при обновлении кэша входят в вечный статус UPDATING</div>
<div><br /></div>
<div>см. curl вызовы ниже (ждали, что проблема уйдёт с обновлениями, но нет)</div>
<div><br /></div>
<div>происходит это совершенно на рандомных страницах, и способа воспроизвести нет – только по прецедентной жалобе от пользователей, что закешированный контент не обновляется пол дня (ночью у нас рестарт nginx, который приводи всё в норму, но ждать до утра никто не хочет)</div>
<div><br /></div>
<div>КОНФИГУРАЦИЯ</div>
<div><br /></div>
<div>релевантные настройки такие:</div>
<div><br /></div>
<div>proxy_cache_use_stale error timeout invalid_header updating http_500 http_502 http_503 http_504;</div>
<div>proxy_cache_background_update on;</div>
<div>proxy_cache_lock on;</div>
<div>proxy_cache_lock_timeout 25s;</div>
<div><br /></div>
<div>недавно поставили последнюю стабильную версию nginx + OpenSSL (сборка кастомная):</div>
<div><br /></div>
<div>nginx version: nginx/1.16.0 built with OpenSSL 1.1.1b 26 Feb 2019 TLS SNI support enabled</div>
<div><br /></div>
<div>при этом:</div>
<div><br /></div>
<div>nginx -s reload # не помогает…</div>
<div><br /></div>
<div>а помогает только явный «мягкий» перезапуск сервера (процедура похожая на обновление бинарника):</div>
<div><br /></div>
<div>#!/usr/bin/env bash</div>
<div># скрипт перезапуска или обновления бинарника:</div>
<div>sudo kill -s USR2 `cat /run/nginx.pid`</div>
<div>sudo kill -s WINCH `cat /run/nginx.pid.oldbin`</div>
<div>echo 'waiting for 5 minutes required for graceful reload'</div>
<div>sleep 300</div>
<div>sudo kill -s TERM `cat /run/nginx.pid.oldbin`</div>
<div><br /></div>
<div>ЛОГИ И ДЕМО</div>
<div><br /></div>
<div>есть предположение, что это из-за эпозодического падения worker'ов (таких набирается несколько десятков за день, при сотнях тысяч запросов)</div>
<div><br /></div>
<div>dmesg:</div>
<div><br /></div>
<div>[4505268.063116] nginx[22951]: segfault at 48 ip 00007f501a38682e sp 00007fff830e1470 error 4 in nginx.so[7f501a384000+5000]</div>
<div>…</div>
<div><br /></div>
<div>error.log:</div>
<div><br /></div>
<div>2019/05/31 10:35:23 [alert] 15685#15685: worker process 27862 exited on signal 11 (core dumped)</div>
<div>…</div>
<div><br /></div>
<div>подобные падения нас пресделуют много лет (их в день не много), на самых разных версиях nginx, в разных ДЦ, на разных серверах, при разных окружениях;</div>
<div>(по хорошему, надо включить сбор корок и попытаться разобраться, где оно падает…)</div>
<div><br /></div>
<div>наше предположение такое:</div>
<div><br /></div>
<div>воркер, который должен был обновить истёкшие данные умирает, а статус так и остаётся UPDATING (на вечно),</div>
<div>всём клиентам отдаётся старый контент,</div>
<div>а новые воркеры уже не планируют запрос обновления с бэка</div>
<div><br /></div>
<div>вот свежий пример (в заголовке x-ireland-cache-status выводим значение $upstream_cache_status):</div>
<div><br /></div>
<div>H27: ~ $ curl -I <a href="https://www.hse.ru/our/" target="_blank">https://www.hse.ru/our/</a></div>
<div>HTTP/2 200</div>
<div>server: nginx</div>
<div>date: Thu, 30 May 2019 14:54:52 GMT</div>
<div>…</div>
<div>x-ireland-cache-status: UPDATING</div>
<div><br /></div>
<div>… можно очень долго ждать – статус так и будет UPDATING …</div>
<div><br /></div>
<div>H27: ~ $ curl -I <a href="https://www.hse.ru/our/" target="_blank">https://www.hse.ru/our/</a></div>
<div>HTTP/2 200</div>
<div>server: nginx</div>
<div>date: Thu, 30 May 2019 14:56:47 GMT</div>
<div>…</div>
<div>x-ireland-cache-status: UPDATING</div>
<div><br /></div>
<div>после перезапуска nginx по SIGUSR2 скриптом (код перезапускатора был приведён выше):</div>
<div><br /></div>
<div>H27: ~ $ curl -I <a href="https://www.hse.ru/our/" target="_blank">https://www.hse.ru/our/</a></div>
<div>HTTP/2 200</div>
<div>server: nginx</div>
<div>date: Thu, 30 May 2019 14:57:37 GMT</div>
<div>…</div>
<div>x-ireland-cache-status: STALE</div>
<div><br /></div>
<div>H27: ~ $ curl -I <a href="https://www.hse.ru/our/" target="_blank">https://www.hse.ru/our/</a></div>
<div>HTTP/2 200</div>
<div>server: nginx</div>
<div>date: Thu, 30 May 2019 14:57:39 GMT</div>
<div>…</div>
<div>x-ireland-cache-status: HIT</div>
<div><br /></div>
<div>всё, кэш успешно обновлён после перезапуска nginx! мы победили и ждём следующего звоночка…</div>
<div><br /></div>
<div>у нас нет инструмента по отслеживанию «застрявших UPDATING»,</div>
<div>и нет способа точечно их пнуть</div>
<div>(если только не отслеживать $upstream_cache_status по каждому ресурсу и переходы статусов со временем, которые в 99.99% переходят из UPDATING в правильные статусы);</div>
<div><br /></div>
<div>приходится ждать только сигнала от недовольных пользователей…</div>
<div><br /></div>
<div>РЕЗЮМИРУЕМ</div>
<div><br /></div>
<div>ещё раз, сценарий, как мы видим откуда растёт проблема:</div>
<div><br /></div>
<div>1. некоторая страница успешно кэшируется</div>
<div>2. в какой-то момент идёт запрос на её обновление, но исполняющий воркер падает по SIGSEGV (таких падений несколько десятков за день из сотен тысяч запросов)</div>
<div>3. никакой больше воркер это задание не получает до перезапуска nginx</div>
<div>4. недовольные клиенты получают устаревший контент</div>
<div><br /></div>
<div>РЕШЕНИЕ?</div>
<div><br /></div>
<div>перезапускать nginx раз в 30 минут по cron для её решения не хотелось бы.</div>
<div><br /></div>
<div>какие варианты решения подобной проблемы существуют? в чём может быть возможная причина?</div>
<div><br /></div>
<div>может есть рекомендации по дополнительным настройкам?</div>
<div><br /></div>
<div>да, падения могут быть обусловлены нашим кодом, или кастомной сборкой, но их (падения воркеров) надо учитывать в работе nginx:</div>
<div><br /></div>
<div>если это рассматривать как баг nginx – можно ли найти ему решение в будущих обновлениях, в виде отправки повторной задачи воркерам на обновление кэша, по таймауту?..</div>
</div>
<div name="messageReplySection" style="font-size:14px;font-family:-apple-system,BlinkMacSystemFont,sans-serif">
<blockquote type="cite" style="margin: 5px 5px; padding-left: 10px; border-left: thin solid #3498db;"></blockquote>
</div>
</div>
_______________________________________________<br />
nginx-ru mailing list<br />
<a href="mailto:nginx-ru@nginx.org" target="_blank">nginx-ru@nginx.org</a><br />
<a href="http://mailman.nginx.org/mailman/listinfo/nginx-ru" rel="noreferrer" target="_blank">http://mailman.nginx.org/mailman/listinfo/nginx-ru</a></blockquote>
</div>
</blockquote>
</div>
</body>
</html>