Увеличение Writing запросов

[Andrei Nigmatulin]

On Wednesday 12 August 2009 17:12, Konstantin Dolgachov wrote:
> > Это нужно проверять не сейчас, а когда возникают проблемы.
>
> При повторе выловил:
> $ netstat -Lan | grep 1026
>
> tcp4  81/0/4096       10.10.10.56.1026
>
> В какую сторону копать? С какими опциями и переменными оперировать?

Вам поможет http://pinba.org/

> On 08/12/2009 03:50 PM, Igor Sysoev wrote:
> > On Wed, Aug 12, 2009 at 03:32:28PM +0300, Konstantin Dolgachov wrote:
> >> Можно ли как нибудь разделить статистику отдачи ответа клиенту и
> >> обработку его бэкендом.
> >
> > Сейчас - нет.
> >
> >> Бэкендов стоит много и я не думаю, что проблема с ними. Потому что во
> >> врмя так сказать завала, сервера с php стоят  с нагрузкой в ноль
> >> процентов. Очень похоже на атаку.
> >>
> >> На всех серверах выполнил команду, вывод везде таков:
> >> $ netstat -Lan | grep 1026
> >> tcp4  0/0/4096       10.10.10.56.1026
> >
> > Это нужно проверять не сейчас, а когда возникают проблемы.
> >
> >> да и трудно думаю завалить такие бэкенды таким небольшим каличеством.
> >>
> >> $ sysctl -a | grep hw
> >> hw.machine: amd64
> >> hw.model: Intel(R) Xeon(R) CPU           E5320  @ 1.86GHz
> >> hw.ncpu: 8
> >> hw.byteorder: 1234
> >> hw.physmem: 8573952000
> >> hw.usermem: 8071954432
> >>
> >> On 08/12/2009 03:08 PM, Igor Sysoev wrote:
> >>> On Wed, Aug 12, 2009 at 12:46:46PM +0300, Konstantin Dolgachov wrote:
> >>>> Добрый день.
> >>>> Направьте в нужном направление.
> >>>> Второй день ложится веб сервер с nginx. Проанализоровав график срузу
> >>>> видно, что как только увеличивается количество writing запросов
> >>>> происходит падение.
> >>>> (смотрите график)
> >>>> В логах ничего подозрительного.
> >>>> Структура:
> >>>> Freebsd + nginx транслирует на десяток freebsd серверов с  php-cgi.
> >>>>
> >>>> events {
> >>>>      worker_connections  10000;
> >>>>      use kqueue;
> >>>> }
> >>>>      sendfile            on;
> >>>>      tcp_nopush          on;
> >>>>      tcp_nodelay         on;
> >>>>      server_tokens       off;
> >>>>
> >>>>      keepalive_timeout 65 50;
> >>>>
> >>>>      server_names_hash_max_size 2048;
> >>>>      server_names_hash_bucket_size 128;
> >>>>
> >>>>      upstream backend {
> >>>>          ..........
> >>>>          server 10.10.10.37:1026 weight=1;
> >>>>          server 10.10.10.38:1026 weight=1;
> >>>>          server 10.10.10.39:1026 weight=1;
> >>>>          server 10.10.10.41:1026 weight=1;
> >>>>          server 10.10.10.42:1026 weight=1;
> >>>>          server 10.10.10.56:1026 weight=1;
> >>>>          ...........
> >>>>      }
> >>>>
> >>>>      fastcgi_temp_path /tmp/nginx/fastcgi_temp;
> >>>>      client_body_temp_path  /tmp/nginx/client_body_temp 1 2;
> >>>>      client_max_body_size 4m;
> >>>
> >>> Writing в данном случае означет не только отдачу ответа клиенту, но
> >>> и обработку его бэкендом. Скорее всего, проблема именно в бэкендах.
> >>> Можно запустить на них
> >>>
> >>> netstat -Lan | grep 1026
> >>>
> >>> чтобы убедиться, что бэкенды не успевают обрабатывать приходящие
> >>> запросы.
> >>
> >> begin:vcard
> >> fn:Konstantin Dolgachiov
> >> n:Dolgachiov;Konstantin
> >> org:DKD
> >> adr:;;;Visaginas;;;Lithuania
> >> email;internet:admin at tusovka.lt
> >> title:Network Administrator
> >> tel;work:+370 386 60 608
> >> tel;cell:+370 612 20 503
> >> version:2.1
> >> end:vcard

-- 
Andrei Nigmatulin
GPG PUB KEY 6449830D

Now I lay me down to sleep(3)
Pray the OS my core to keep
If I die before I wake
Pray the Disk my core to take