получил плоды ожидания корок $ file /usr/sbin/nginx /usr/sbin/nginx: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.32, BuildID[sha1]=4d0f52094f7acaa1c4b08de27913eb50815bbdfe, not stripped
$ nm -g /usr/sbin/nginx | grep main U __libc_start_main@@GLIBC_2.2.5 000000000045a4c0 T main 000000000048fdb0 T ngx_ssl_get_client_v_remain 00000000005c9cf0 T rand_pool_bytes_remaining нападало две группы корок (то есть, осыпается сразу аж группами): -rw------- 1 httpd www-data 105082880 май 31 20:29 core.nginx.8434 … всего порядка 20 штук за раз -rw------- 1 httpd www-data 64528384 май 31 20:29 core.nginx.11635 и через пол часа: -rw------- 1 httpd www-data 66285568 май 31 21:11 core.nginx.8426 … ешё 30 штук за раз -rw------- 1 httpd www-data 64516096 май 31 21:11 core.nginx.12302 падает стабильно в точке 0x00007f8512e2ea1e (и странный предыдущий адрес 0x0…0) но gdb символов в точке падения не видит: # gdb core.nginx.11620 GNU gdb (GDB) … Missing separate debuginfo for the main executable file Try: yum --enablerepo='*debug*' install /usr/lib/debug/.build-id/4d/0f52094f7acaa1c4b08de27913eb50815bbdfe (этой штуки нет) Core was generated by `nginx: worker pr'. Program terminated with signal 11, Segmentation fault. #0 0x00007f8512e2ea1e in ?? () "/tmp/core.nginx.11620" is a core file. Please specify an executable to debug. (gdb) bt full #0 0x00007f8512e2ea1e in ?? () No symbol table info available. #1 0x0000000000000000 in ?? () No symbol table info available. (gdb) куда копать? On 31 May 2019, 15:32 +0300, Илья Шипицин <chipits...@gmail.com>, wrote: > В error_log ничего на сегфолте не может записаться, нет особого смысла его > включать в debug > > По bt full больше инфы будет > > > On Fri, May 31, 2019, 5:26 PM Alexey Galygin <m...@me.com> wrote: > > > Илья, модули все из коробки > > > > > > ничего лишнего не доливаем > > > > > > из экстрима, пожалуй, только 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, Илья Шипицин <chipits...@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
_______________________________________________ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
