съедание проца

[Igor Sysoev]

On Wed, Jan 09, 2008 at 01:08:55AM +0500, Nick S. Knutov wrote:

> Тот сервер, на котором проблема была в начале, сейчас имеет большой
> трафик и его трогать нельзя. Пытался воспроизвести на
> 2.6.18-53.el5.028stab051.1
> 
> Ситуация полносю повторяется
>   PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
> 28255 nobody    15   0  6232 4644  628 S 35.6  0.4   0:08.90 nginx:
> worker process is shutting down
> 
> Условия воспроизведения - nginx проксирует apache, которые отдает
> большой файл.
> 
> Но - до первого релоада nginx тоже съедает много проца. Тестировал ab 
> локально.

С отладкой он, конечно, ест процессор.

> http://supervds.ru/nginx.error_log.1.gz
> 
> Не уверен что поймал именно нужную ситуацию.
> 
> У меня появились сомнения в том, что я делаю дебаг лог правильно, но я 
> могу дать чистую вдс для эксперементов, может быть так будет лучше? 
> Можно на обоих серверах с обоими ядрами.

Проблема в том, что для каждого сервера ведётся свой error_log и
отладка туда не попадает. Поэтому я и просил сделать отдельный конфиг,
например, на 8000 порту и сделать тест.

> Igor Sysoev пишет:
> >On Fri, Jan 04, 2008 at 12:31:08AM +0500, Nick S. Knutov wrote:
> >
> >>Hello Igor,
> >>
> >>Thursday, January 3, 2008, 11:24:23 PM, you wrote:
> >>>Похоже на ошибку в epoll:
> >>>2008/01/03 20:38:47 [debug] 25623#0: epoll: fd:11 ev:0001 d:B7550008
> >>>...
> >>>2008/01/03 20:38:47 [debug] 25623#0: close listening 0.0.0.0:80 #11 
> >>>...
> >>>2008/01/03 20:38:47 [debug] 25623#0: epoll: stale event B7550008
> >>>По идее, после закрытия сокета ядро не должно возвращать события.
> >>>Прилагаемый патч должен помочь.
> >>>На каких ядрах это стало появляться ?
> >>Помогло, спасибо.
> >>Нагрузка подобного характера у меня есть только на одном сервере, там
> >>2.6.18-8.1.8.el5.028stab039.1
> >>На двух предыдущих OpenVZ-шных ядрах было такое же.
> >>
> >>Думаю, что проявляется на всех ядрах, включая 2.6.18-53.el5.028stab051.1
> >>Кажется там тоже такое пару раз ловил, но там редко когда отдаются
> >>большие ответы через проксирование к апачу, потому уверенности нету.
> >
> >Хотелось бы убедиться, что это баг именно системы, а не nginx'а.
> >К сожалению, предыдущий отладочный лог был не полный, поэтому из него
> >этог понять было нельзя.
> >
> >Нужно собрать nginx без патча и запусить с конфигурацией проксирования
> >одного сайта. После чего запусить ab, и послать nginx'у -HUP.
> >Если рабочие процессы едят процессор, то повторить то же самое с отладочным
> >логом.
> >
> >>ps: в отладочном логе есть вот такое.
> >>[warn] 28028#0: 2048 worker_connections are more than open file resource 
> >>limit: 1024
> >>Почему оно такое? У самой вдс стоит лимит в 16384 открытых файла и
> >>судя по счетчикам там бывает больше открытых файлов, чем 1024. Это
> >>nginx неверно определяет предел или есть какое-то дополнительное
> >>ограничение?
> >
> >16384  - это на всю VDS. А на процесс внтури VDS - 1024. Можно увеличить
> >или средствами nginx
> >
> >worker_rlimit_nofile  8000;
> >
> >или системы.
> >
> >
> 
> 
> -- 
> Ник Кнутов
> http://knutov.com
> ICQ: 272873706
> Voice: +7-904-84-23-130
> 
> 
> 
> 

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