странности в работе nginx

Igor Sysoev is at rambler-co.ru
Sun Apr 24 16:38:22 MSD 2005


On Sun, 24 Apr 2005, Alexey Bestciokov wrote:

> По моему я уже это спрашивал, но в прошлый раз так и не разобрались
> nginx после -HUP начинает странно себя вести
> часть старых процессов резкро увеличивают количество используемого процессорного времени
> в данном выводе это PID 6733 и 6745:
>
> root at udaff /var/log/nginx>ps ax -o pid,ppid,user,%cpu,vsz,wchan,command | egrep '(nginx|PID)'
>  PID  PPID USER     %CPU   VSZ WCHAN  COMMAND
> 12519     1 root      0.0  4252 rt_sig nginx: master process /usr/local/sbin/nginx
> 12521 12519 www-data  0.6  9140 -      nginx: worker process is shutting down
> 17338 12519 www-data  0.7  8988 -      nginx: worker process is shutting down
> 20458 12519 www-data  0.7  8728 -      nginx: worker process is shutting down
> 20482 12519 www-data  0.7  6956 -      nginx: worker process is shutting down
> 6733 12519 www-data 13.7  7916 -      nginx: worker process is shutting down
> 6745 12519 www-data 13.2  7612 -      nginx: worker process is shutting down
> 6856 12519 www-data  0.8  8172 -      nginx: worker process is shutting down
> 16432 12519 www-data  0.5  7932 -      nginx: worker process is shutting down
> 18980 12519 www-data  0.9  8032 sync_b nginx: worker process
> 18981 12519 www-data  0.9  7928 sync_p nginx: worker process
> 18982 12519 www-data  0.9  7756 sync_p nginx: worker process
> 18983 12519 www-data  0.9  7896 sync_p nginx: worker process
> 18984 12519 www-data  1.0  8136 sync_p nginx: worker process
> 18985 12519 www-data  0.9  7856 sync_p nginx: worker process
> 18986 12519 www-data  1.0  8092 sync_p nginx: worker process
> 18987 12519 www-data  1.0  8216 sync_b nginx: worker process
> 22522 32078 root      0.0  1628 -      grep -E (nginx|PID)
>
> strace показывает
> блоки повторяющщихся строк
> epoll_wait(195, {{EPOLLIN, {u32=3084277592, u64=3084277592}}}, 8192, 48197) = 1
> gettimeofday({1114260172, 940343}, NULL) = 0
>
> которые время от времени меняются блоками строк
> epoll_wait(195, {{EPOLLIN, {u32=3084277672, u64=3084277672}}, {EPOLLERR|0x807a020, {u32=134717480, u64=28969689129000}}}, 8192, 48197) = 2
> gettimeofday({1114260172, 940615}, NULL) = 0
>
> полный вывод strace в течении минуты - http://maloletka.ru/dead_nginx.strace.bz2 (630 Кб)
> со временем они конечно умирают, не не сразу и сервер грузят весьма заметно.
> nginx 0.1.12+, linux 2.6.3+ SMP
> в конфиге nginx прописано: debug_points  abort;

Правильно ли я понимаю, что
1) используется много логов, около сотни ?
2) используется limit_rate ?
Проблема не в них, просто я хочу убедиться что правильно понял strace.

В логе есть два момента, которые мне не нравятся:

1) сообщения
{EPOLLERR|0x807a020, {u32=134717480, u64=28969689129000}}
очень похоже, что ядро возврщает мусор.

2) одно сообщения
{EPOLLET|0x3fffd820, {u32=3086058770, u64=578613461717714194}},
{EPOLLET|0x37e8b000, {u32=134717480, u64=578607170934251560}}
тоже очень похоже на ядерный мусор.

Цикл вызывает бесконечные
epoll_wait(195, {{EPOLLIN, {u32=3084277592, u64=3084277592}}}, 8192, 575) = 1

У меня есть подозрение, чтобы это могло быть. Нужно попробовать следующее:

1) запустить nginx с простой конфигурацией с полной отладкой, можно только
    с одним рабочим процессом.
2) присоединиться с помощью telnet'а, ничего не передавая.
3) послать -HUP основному процессу.
4) повторять пункты 2 и 3 до тех пор, пока рабочий процесс не начнёт есть
    процессор. Лог прислать мне.

Если пожирания процессора не будет, то я пришлю описание, как сделать
промоделировать ситуацию с несколькими рабочими процессами.


Игорь Сысоев
http://sysoev.ru





More information about the nginx-ru mailing list