Re: Nginx reload, выедает CPU

[Maxim Dounin <mdounin@xxxxxxxxxx>]

Hello!

On Tue, Aug 27, 2013 at 10:59:25PM +0300, Serge Negodyuck wrote:

> 2013/8/27 Serge Negodyuck <serg@xxxxxxxxxxxxxxxxx>:
> >>> Имеет смысл либо походить по коду в gdb, либо посмотреть на
> >>> картину с помощью ktrace + kdump -T.  Ну и на банальный top тоже
> >>> имеет смысл посмотреть внимательно.
> >>
> >> Ок, попробую нарыть больше информации для диагностики. И воспроизвести
> >> в минимальной конфигурации.
> >
> > Поигравшись с  "while true; do gdb66 -ex "backtrace full" --batch -p
> > 41159; done"
> > получилось, что бОльшую часть времени эти процессы проводят в
> > состоянии: " if (c[i].fd != -1 && c[i].idle) {":
> 
> Добавление usleep(1) решило все проблемы:
> 
> --- ngx_process_cycle.c.orig 2013-08-27 22:42:36.000000000 +0300
> +++ ngx_process_cycle.c 2013-08-27 22:42:46.000000000 +0300
> @@ -792,6 +792,7 @@
>                      c[i].close = 1;
>                      c[i].read->handler(c[i].read);
>                  }
> +               usleep(1);
>              }
> 
>              if (ngx_event_timer_rbtree.root == 
> ngx_event_timer_rbtree.sentinel)
> 
> 
> IMHO, как-то грязновато. Может можно как-то по событиям? Или вынести
> цикл по дескрипторам соединений в отдельный поток.

Этот цикл - занимается закрытием idle-соединений, и выполняется 
только при получении из ядра каких-либо событий (i.e. - редко).  
Если время теряется в нём - это как бы намекает, что в ядре nginx 
почему-то не остаётся, а сразу возвращается обратно.  В этом и 
есть настоящая проблема.

Было бы интересно посмотреть на nginx -V (интересует, в первую 
очередь, отсутствие сторонних модулей/патчей), полный конфиг и 
debug log.  Ссылка на всякий случай:

http://nginx.org/ru/docs/debugging_log.html

> В любом случаю, надеюсь, авторы nginx подумают над этим куском кода к
> ближайшему релизу. IMHO, причина: появление вебсокетов, и
> необходимость увеличения proxy_read_timeout вкупе с увеличением числов
> конектов.

Сам по себе этот кусок кода, конечно, можно слегка 
пооптимизировать, но проблема где-то в другом месте.

-- 
Maxim Dounin
http://nginx.org/en/donation.html

_______________________________________________
nginx-ru mailing list
nginx-ru@xxxxxxxxx
http://mailman.nginx.org/mailman/listinfo/nginx-ru