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
|
