привет! segfault - с очень-очень-очень большой вероятностью из-за сторонних модулей nginx. можете показать вывод "nginx -V" ?
как бороться с сегфолтами - весьма просто. надо скомпилировать nginx с отладкой, при это не strip-нуть ее в момент инсталяции команда "file `which nginx`" должна показыват "not stripped" далее - в вашей операционной системе разрешаете сохранение core dump (алгоритм варьируется в зависимости от наличия systemd и еще ряда вещей) потом, берете сохраненный core dump, при помощи gdb открываете, делаете "bt full", смотрите на чем именно упало. если что, обращайтесь. тут в рассылке куча людей умеет такое делать )) пт, 31 мая 2019 г. в 15:47, Alexey Galygin via nginx-ru <nginx-ru@nginx.org >: > всем привет > > ПРОБЛЕМА > > давно (уже не первый год обновление за обновлением nginx и OpenSSL) > наблюдаем, > что ряд страниц при обновлении кэша входят в вечный статус UPDATING > > см. curl вызовы ниже (ждали, что проблема уйдёт с обновлениями, но нет) > > происходит это совершенно на рандомных страницах, и способа воспроизвести > нет – только по прецедентной жалобе от пользователей, что закешированный > контент не обновляется пол дня (ночью у нас рестарт nginx, который приводи > всё в норму, но ждать до утра никто не хочет) > > КОНФИГУРАЦИЯ > > релевантные настройки такие: > > proxy_cache_use_stale error timeout invalid_header updating http_500 > http_502 http_503 http_504; > proxy_cache_background_update on; > proxy_cache_lock on; > proxy_cache_lock_timeout 25s; > > недавно поставили последнюю стабильную версию nginx + OpenSSL (сборка > кастомная): > > nginx version: nginx/1.16.0 built with OpenSSL 1.1.1b 26 Feb 2019 TLS SNI > support enabled > > при этом: > > nginx -s reload # не помогает… > > а помогает только явный «мягкий» перезапуск сервера (процедура похожая на > обновление бинарника): > > #!/usr/bin/env bash > # скрипт перезапуска или обновления бинарника: > sudo kill -s USR2 `cat /run/nginx.pid` > sudo kill -s WINCH `cat /run/nginx.pid.oldbin` > echo 'waiting for 5 minutes required for graceful reload' > sleep 300 > sudo kill -s TERM `cat /run/nginx.pid.oldbin` > > ЛОГИ И ДЕМО > > есть предположение, что это из-за эпозодического падения worker'ов (таких > набирается несколько десятков за день, при сотнях тысяч запросов) > > dmesg: > > [4505268.063116] nginx[22951]: segfault at 48 ip 00007f501a38682e sp > 00007fff830e1470 error 4 in nginx.so[7f501a384000+5000] > … > > error.log: > > 2019/05/31 10:35:23 [alert] 15685#15685: worker process 27862 exited on > signal 11 (core dumped) > … > > подобные падения нас пресделуют много лет (их в день не много), на самых > разных версиях nginx, в разных ДЦ, на разных серверах, при разных > окружениях; > (по хорошему, надо включить сбор корок и попытаться разобраться, где оно > падает…) > > наше предположение такое: > > воркер, который должен был обновить истёкшие данные умирает, а статус так > и остаётся UPDATING (на вечно), > всём клиентам отдаётся старый контент, > а новые воркеры уже не планируют запрос обновления с бэка > > вот свежий пример (в заголовке x-ireland-cache-status выводим значение > $upstream_cache_status): > > H27: ~ $ curl -I https://www.hse.ru/our/ > HTTP/2 200 > server: nginx > date: Thu, 30 May 2019 14:54:52 GMT > … > x-ireland-cache-status: UPDATING > > … можно очень долго ждать – статус так и будет UPDATING … > > H27: ~ $ curl -I https://www.hse.ru/our/ > HTTP/2 200 > server: nginx > date: Thu, 30 May 2019 14:56:47 GMT > … > x-ireland-cache-status: UPDATING > > после перезапуска nginx по SIGUSR2 скриптом (код перезапускатора был > приведён выше): > > H27: ~ $ curl -I https://www.hse.ru/our/ > HTTP/2 200 > server: nginx > date: Thu, 30 May 2019 14:57:37 GMT > … > x-ireland-cache-status: STALE > > H27: ~ $ curl -I https://www.hse.ru/our/ > HTTP/2 200 > server: nginx > date: Thu, 30 May 2019 14:57:39 GMT > … > x-ireland-cache-status: HIT > > всё, кэш успешно обновлён после перезапуска nginx! мы победили и ждём > следующего звоночка… > > у нас нет инструмента по отслеживанию «застрявших UPDATING», > и нет способа точечно их пнуть > (если только не отслеживать $upstream_cache_status по каждому ресурсу и > переходы статусов со временем, которые в 99.99% переходят из UPDATING в > правильные статусы); > > приходится ждать только сигнала от недовольных пользователей… > > РЕЗЮМИРУЕМ > > ещё раз, сценарий, как мы видим откуда растёт проблема: > > 1. некоторая страница успешно кэшируется > 2. в какой-то момент идёт запрос на её обновление, но исполняющий воркер > падает по SIGSEGV (таких падений несколько десятков за день из сотен тысяч > запросов) > 3. никакой больше воркер это задание не получает до перезапуска nginx > 4. недовольные клиенты получают устаревший контент > > РЕШЕНИЕ? > > перезапускать nginx раз в 30 минут по cron для её решения не хотелось бы. > > какие варианты решения подобной проблемы существуют? в чём может быть > возможная причина? > > может есть рекомендации по дополнительным настройкам? > > да, падения могут быть обусловлены нашим кодом, или кастомной сборкой, но > их (падения воркеров) надо учитывать в работе nginx: > > если это рассматривать как баг nginx – можно ли найти ему решение в > будущих обновлениях, в виде отправки повторной задачи воркерам на > обновление кэша, по таймауту?.. > > _______________________________________________ > nginx-ru mailing list > nginx-ru@nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru
_______________________________________________ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru