ПРОЕКТЫ 


  АРХИВ 


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: Увеличение Writing за просов



81 - это число запросов в очереди, который на данный момент не обслужил
сервер на 10.10.10.56.1026. Копать нужно в этом сервере.

На всех php серверах были разные приблизительные значения. Буду думать.

On 08/12/2009 04:26 PM, Igor Sysoev wrote:
On Wed, Aug 12, 2009 at 04:12:44PM +0300, Konstantin Dolgachov wrote:

Это нужно проверять не сейчас, а когда возникают проблемы.
При повторе выловил:
$ netstat -Lan | grep 1026

tcp4  81/0/4096       10.10.10.56.1026

В какую сторону копать? С какими опциями и переменными оперировать?
81 - это число запросов в очереди, который на данный момент не обслужил
сервер на 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@xxxxxxxxxx
title:Network Administrator
tel;work:+370 386 60 608
tel;cell:+370 612 20 503
version:2.1
end:vcard



begin:vcard
fn:Konstantin Dolgachiov
n:Dolgachiov;Konstantin
org:DKD
adr:;;;Visaginas;;;Lithuania
email;internet:admin@xxxxxxxxxx
title:Network Administrator
tel;work:+370 386 60 608
tel;cell:+370 612 20 503
version:2.1
end:vcard


begin:vcard
fn:Konstantin Dolgachiov
n:Dolgachiov;Konstantin
org:DKD
adr:;;;Visaginas;;;Lithuania
email;internet:admin@xxxxxxxxxx
title:Network Administrator
tel;work:+370 386 60 608
tel;cell:+370 612 20 503
version:2.1
end:vcard



 




Copyright © Lexa Software, 1996-2009.