nginx. Статистика

[Maxim Dounin]

Hello!

On Sat, Feb 28, 2009 at 02:02:50AM +0300, Lin wrote:

> > > > > > > поискать в error лог строчки вид:
> > > > > > > 
> > > > > > > worker process %d exited on signal %d
> > > > > > > 
> > > > > > Есть строчки:
> > > > > > worker process 80481 exited on signal 9
> > > > > > worker process 80498 exited with code 0
> > > > > 
> > > > > Worker покинул нас, он отправился в лучший мир, наверное. И покинул
> > > > > настолько быстро, что не успел открутить счетчики назад.
> > > > > 
> > > > > Для KILL это странно, на самом деле. Я бы поверил в этот вариант, если
> > > > > у нас был бы TERM(15) или SEGV(11).
> > > > 
> > > > SIGKILL не перехватывается.  Если процессу кто-то послал SIGKILL - то 
> > > > у него уже нет шансов что-либо сделать.
> > > > 
> > > > Отдельный вопрос - что за добрая душа это сказала, но тут 
> > > > вариантов не особо много - либо администратор, либо какой-то 
> > > > управляющий софт.  Если на линуксе - то вероятно это был OOM 
> > > > killer.
> > > 
> > > Операционная система - FreeBSD 7 amd64. Что может посылать этот сигнал?
> > > в результате получается, что в статистике выдает тысячи активных соединений, скорость скачки файла 2-3 Кб/с.
> > 
> > Под фрёй может прибить система за:
> > 
> > $ grep -r killproc *
> > kern/kern_resource.c:                   killproc(p, "exceeded maximum CPU limit");
> > nfsclient/nfs_bio.c:                            killproc(p, "text file modification");
> > vm/vm_pageout.c:                        killproc(bigproc, "out of swap space");
> > 
> > Во всех перечисленных случаях будет недвусмысленное объяснение 
> > происходящего в /var/log/messages.
> > 
> > Ну и администратор руками / посредством скриптов тоже может.
> 
> /var/log/messages проверил, там нет никаких упоминаний про nginx и его воркеров.
> кто может прибивать воркеров и по какой причине?
> 
> В error_log появляются такие группы сообщений почти сразу после запуска:
> 
> signal 15 (SIGTERM) received, exiting
> signal 23 (SIGIO) received
> *256169 kevent() reported about an closed co
> signal 23 (SIGIO) received
> signal 23 (SIGIO) received
> signal 23 (SIGIO) received
> signal 23 (SIGIO) received
> signal 20 (SIGCHLD) received
> worker process 59013 exited on signal 9
> signal 23 (SIGIO) received
> signal 20 (SIGCHLD) received
> worker process 59011 exited on signal 9
> signal 23 (SIGIO) received
> signal 20 (SIGCHLD) received
> worker process 58987 exited on signal 9
> signal 23 (SIGIO) received
> signal 20 (SIGCHLD) received
> worker process 59004 exited on signal 9
> signal 23 (SIGIO) received
> signal 20 (SIGCHLD) received

Это похоже на завершение работы nginx'а после SIGTERM'а, 
присланного мастеру.  При этом воркеры чем-то заняты настолько, 
что на указания мастера не реагируют.  В результате мастер их 
прибивает по SIGKILL.

Разбирайтесь чем именно заняты воркеры, и почему nginx'у сразу 
после запуска присылают SIGTERM (вероятно, это не запуск, а вполне 
себе restart, и SIGTERM присылают старому мастеру?).  Для начала 
рекомендую сделать

ps -alx | grep nginx

до "запуска" и после, и сравнить с записями в error_log'е.  Если 
не поможет - пересобрать nginx с --with-debug, сделать debug log, 
и посмотреть что происходит уже по нему.

Впрочем, если это всё действительно происходит при завершении 
nginx'а по SIGTERM, то на subj это влиять не должно.  Но лишний 
повод обнаружить какую-нибудь глупость в конфигурации вроде 
раздачи больших файлов через sendfile быстрым клиентам без 
указания sendfile_max_chunk.

Maxim Dounin

p.s. Тут где-то в архивах должно быть хорошое письмо Андрея 
Копейко о том, почему логи надо предоставлять в том виде, в 
котором они пишутся.  Поищите, занимательное чтение.  Хотя удалять 
из логов время и pid'ы до вас по моему никто не догадывался.