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

[Konstantin Dolgachov]

> Это нужно проверять не сейчас, а когда возникают проблемы.

При повторе выловил:
$ netstat -Lan | grep 1026

tcp4  81/0/4096       10.10.10.56.1026

В какую сторону копать? С какими опциями и переменными оперировать?


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
>>
>>      
>
>    
-------------- next part --------------
A non-text attachment was scrubbed...
Name: forum.vcf
Type: text/x-vcard
Size: 231 bytes
Desc: not available
URL: <http://nginx.org/pipermail/nginx-ru/attachments/20090812/3d767b4b/attachment.vcf>