<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:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">



<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;padding-left:10px;border-left:thin solid rgb(26,188,156)"></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>