ПРОЕКТЫ 


  АРХИВ 


Apache-Talk @lexa.ru 

Inet-Admins @info.east.ru 

Filmscanners @halftone.co.uk 

Security-alerts @yandex-team.ru 

nginx-ru @sysoev.ru 


  СТАТЬИ 


  ПЕРСОНАЛЬНОЕ 


  ПРОГРАММЫ 



ПИШИТЕ
ПИСЬМА












     АРХИВ :: nginx-ru
Nginx-ru mailing list archive (nginx-ru@sysoev.ru)

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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



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, как-то грязновато. Может можно как-то по событиям? Или вынести
цикл по дескрипторам соединений в отдельный поток.

В любом случаю, надеюсь, авторы nginx подумают над этим куском кода к
ближайшему релизу. IMHO, причина: появление вебсокетов, и
необходимость увеличения proxy_read_timeout вкупе с увеличением числов
конектов.
_______________________________________________
nginx-ru mailing list
nginx-ru@xxxxxxxxx
http://mailman.nginx.org/mailman/listinfo/nginx-ru


 




Copyright © Lexa Software, 1996-2009.