Re: Вечный UPDATING для рандомных страниц портала

Alexey Galygin mif на me.com
Пт Май 31 12:25:45 UTC 2019


Илья, модули все из коробки

ничего лишнего не доливаем

из экстрима, пожалуй, только perl-модуль для ряда мелких задачек

--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

--with-debug ещё добавил только что на время теста… и уровень отладки error_log включил debug
но у нас за пару минут лог в таком режиме достигает 40 Мб ;-)

корки сейчас включу и буду ловить
но это ещё умудриться словить момент и дождаться, когда упадёт, может за час несколько раз свалится


On 31 May 2019, 14:48 +0300, Илья Шипицин <chipitsine на gmail.com>, wrote:
> привет!
>
> 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
----------- следущая часть -----------
Вложение в формате HTML было извлечено…
URL: <http://mailman.nginx.org/pipermail/nginx-ru/attachments/20190531/42b52f1b/attachment-0001.html>


Подробная информация о списке рассылки nginx-ru