LINUX.ORG.RU
решено ФорумAdmin

nginx_status: reading 100-200, writing 1-5. Как побороть?

 ,


0

2

Подскажите, как бороться с тем что большое количество запросов висит в статуcе reading? На сайте немало мелких файлов, поэтому запросов на чтение много. Но проблема почему-то не в отдаче (после соединения отдается практически мгновенно), а в установке самого соединения. Соединение временами по 300-500 мс устанавливается, что совсем не радует. worker_processes менял в промежутке от 8 до 32, но как-то особо не влияет.

Сервер debian 6.05, не особо загруженный (la < 0.5-0.7), процессор и диск шустрые, оперативной памяти навалом.
----------------------
http://coolsite.ru/nginx-status

Active connections: 1319
server accepts handled requests
25124 25124 46243
Reading: 128 Writing: 1 Waiting: 1190

----------------------
nginx -v
nginx version: nginx/1.2.3

----------------------
cat nginx.conf
user www-data;

timer_resolution 100ms;
worker_priority -5;
worker_processes 16;
worker_rlimit_nofile 65536;
worker_rlimit_sigpending 32768;

pid /var/run/nginx.pid;

events {
worker_connections 8192;
use epoll;
}

http {
include /etc/nginx/mime.types;
default_type application/octet-stream;
server_names_hash_bucket_size 128;

log_format main '$remote_addr = $time_local = $request_time = $body_bytes_sent = «$status» = «$request» = «$http_referer» = «$http_user_agent»';
access_log /dev/null;
error_log /var/log/nginx/error.log error;

client_header_timeout 10;
client_body_timeout 15;
client_max_body_size 20m;
client_header_buffer_size 16k;
large_client_header_buffers 8 64k;
send_timeout 10;

proxy_read_timeout 15s;
proxy_connect_timeout 15s;
proxy_send_timeout 15s;
proxy_buffers 16 64k;
proxy_buffer_size 32k;

msie_padding on;
ignore_invalid_headers on;

gzip on;
gzip_static on;
gzip_vary on;
gzip_min_length 2048;
gzip_comp_level 5;
gzip_buffers 16 8k;
gzip_types text/plain text/css text/xml text/javascript application/x-javascript;

directio 4m;
sendfile on;
sendfile_max_chunk 256k;
tcp_nopush on;
tcp_nodelay on;
reset_timedout_connection on;

output_buffers 16 512k;
postpone_output 1460;

keepalive_timeout 30 15;
#optimize_server_names off;
server_name_in_redirect off;

index index.php;

open_file_cache max=8192 inactive=600s;
open_file_cache_valid 600s;
open_file_cache_min_uses 3;
open_file_cache_errors on;

server_tokens off;

client_body_temp_path /var/lib/nginx/body;
proxy_temp_path /var/lib/nginx/proxy;
fastcgi_temp_path /var/lib/nginx/fastcgi;
fastcgi_buffers 8 16k;
fastcgi_buffer_size 32k;
fastcgi_cache_path /var/lib/nginx/cache levels= keys_zone=main_site_zone:32m inactive=5m max_size=1024m;

server {
listen 80 default_server sndbuf=512k;
server_name coolsite.ru http://www.coolsite.ru;
root /var/www/vhosts/coolsite.ru/httpdocs;
index index.php;
fastcgi_index index.php;

location = /_.gif {
empty_gif;
expires 30d;
}

location ~ \.php$ {
fastcgi_pass 127.0.0.1:9000;
fastcgi_param SCRIPT_FILENAME /var/www/vhosts/coolsite.ru/httpdocs$fastcgi_script_name;
include /etc/nginx/fastcgi_params;

access_log /var/log/nginx/access.log main;
}
}
}

в статуcе reading

в установке самого соединения

что-то тут не то

melkor217 ★★★★★
()

А не висит ли соединение в статусе reading до того момента, как fcgi начнёт слать данные?

melkor217 ★★★★★
()

Но проблема почему-то не в отдаче (после соединения отдается практически мгновенно), а в установке самого соединения.

Ну да, похопе из буфера выплёвывает после секунды тупняка.

melkor217 ★★★★★
()
Ответ на: комментарий от melkor217

ну да, наверное я неправильно выразился.

если считать что

Reading - количество запросов, заголовки которых nginx читает в данный момент
Writing - количество запросов, тело которых читает nginx + количество запросов для которых nginx отдает данные

то у меня почему-то очень большое количество запросов, которые вроде как уже соединились с nginx но при этом он никак не может прочитать их заголовок чтобы потом отдать на обработку

буферы для чтения заголовков в конфиге заданы, в чем тут еще может быть проблема?..

mikhal123
() автор топика
Ответ на: комментарий от mikhal123

и кстати к fastcgi это не имеет никакого отношения и fastcgi, и статика (как я понимаю) одинаково долго проводят времени в состоянии reading прежде чем за них берется nginx

mikhal123
() автор топика
Ответ на: комментарий от mikhal123

Можно повысить информативность error_logа:

error_log /var/log/nginx/error.log info;
Обычно nginx начинает туда сыпать некритичные жалобы где ему чего не хватает.

процессор и диск шустрые, оперативной памяти навалом.

Какой тогда смысл добавлять столько второстепенных оптимизирующих опций? Например, где-то в рассылке читал, что на sendfile и tcp_nopush - могут вести себя плохо при некоторых условиях. Вероятно, уже пофиксили, но я бы убрал все оптимизации. Оставил бы только опции, отвечающие за функционал. А дальше добавлял бы их по одной и смотрел на результат.

fjoe
()

Зачем же кросспостить? Вам в рассылке nginx ответили.

ventilator ★★★
()

fjoe, при уровне info в лог пачками попадают сообщения вида

2012/09/18 21:42:50 [info] 38986#0: *95981 client 95.72.119.26 closed keepalive connection 2012/09/18 21:42:50 [info] 38986#0: *96001 client 95.72.119.26 closed keepalive connection 2012/09/18 21:42:50 [info] 38974#0: *95954 client 95.72.119.26 closed keepalive connection 2012/09/18 21:42:50 [info] 38986#0: *95980 client 95.72.119.26 closed keepalive connection 2012/09/18 21:42:50 [info] 38974#0: *96037 client 95.72.119.26 closed keepalive connection 2012/09/18 21:42:50 [info] 38974#0: *96036 client 95.72.119.26 closed keepalive connection 2012/09/18 21:42:50 [info] 38974#0: *96041 client 95.72.119.26 closed keepalive connection 2012/09/18 21:42:50 [info] 38986#0: *95985 client 95.72.119.26 closed keepalive connection 2012/09/18 21:42:50 [info] 38974#0: *96034 client 95.72.119.26 closed keepalive connection 2012/09/18 21:42:50 [info] 38974#0: *96039 client 95.72.119.26 closed keepalive connection 2012/09/18 21:42:50 [info] 38986#0: *95987 client 95.72.119.26 closed keepalive connection 2012/09/18 21:42:50 [info] 38974#0: *96038 client 95.72.119.26 closed keepalive connection 2012/09/18 21:42:50 [info] 38986#0: *95993 client 95.72.119.26 closed keepalive connection 2012/09/18 21:42:50 [info] 38987#0: *96804 client timed out (110: Connection timed out) while reading client request line, client: 188.244.37.2, server: 0.0.0.0:80 2012/09/18 21:42:50 [info] 38981#0: *97910 client 95.221.106.38 closed keepalive connection 2012/09/18 21:42:50 [info] 38987#0: *96814 client timed out (110: Connection timed out) while reading client request line, client: 46.48.88.157, server: 0.0.0.0:80 2012/09/18 21:42:50 [info] 38987#0: *96815 client timed out (110: Connection timed out) while reading client request line, client: 46.48.88.157, server: 0.0.0.0:80 2012/09/18 21:42:50 [info] 38987#0: *96816 client timed out (110: Connection timed out) while reading client request line, client: 46.48.88.157, server: 0.0.0.0:80 2012/09/18 21:42:50 [info] 38987#0: *96817 client timed out (110: Connection timed out) while reading client request line, client: 46.48.88.157, server: 0.0.0.0:80 2012/09/18 21:42:50 [info] 38987#0: *96818 client timed out (110: Connection timed out) while reading client request line, client: 46.48.88.157, server: 0.0.0.0:80 2012/09/18 21:42:50 [info] 38987#0: *96819 client timed out (110: Connection timed out) while reading client request line, client: 46.48.88.157, server: 0.0.0.0:80 2012/09/18 21:42:50 [info] 38987#0: *96820 client timed out (110: Connection timed out) while reading client request line, client: 46.48.88.157, server: 0.0.0.0:80 2012/09/18 21:42:50 [info] 38987#0: *96821 client timed out (110: Connection timed out) while reading client request line, client: 46.48.88.157, server: 0.0.0.0:80 2012/09/18 21:42:50 [info] 38987#0: *96822 client timed out (110: Connection timed out) while reading client request line, client: 46.48.88.157, server: 0.0.0.0:80 2012/09/18 21:42:50 [info] 38987#0: *96823 client timed out (110: Connection timed out) while reading client request line, client: 46.48.88.157, server: 0.0.0.0:80 2012/09/18 21:42:50 [info] 38987#0: *96824 client timed out (110: Connection timed out) while reading client request line, client: 46.48.88.157, server: 0.0.0.0:80 2012/09/18 21:42:50 [info] 38987#0: *96825 client timed out (110: Connection timed out) while reading client request line, client: 46.48.88.157, server: 0.0.0.0:80 2012/09/18 21:42:50 [info] 38987#0: *96826 client timed out (110: Connection timed out) while reading client request line, client: 46.48.88.157, server: 0.0.0.0:80 2012/09/18 21:42:50 [info] 38987#0: *96827 client timed out (110: Connection timed out) while reading client request line, client: 46.48.88.157, server: 0.0.0.0:80 2012/09/18 21:42:50 [info] 38987#0: *96828 client timed out (110: Connection timed out) while reading client request line, client: 46.48.88.157, server: 0.0.0.0:80 2012/09/18 21:42:50 [info] 38987#0: *96829 client timed out (110: Connection timed out) while reading client request line, client: 46.48.88.157, server: 0.0.0.0:80

но относится ли это к рассматриваемой проблеме - мне неизвестно.

насчет оптимизаций - сомневаюсь что последние версии nginx и дебиана могут глючить из-за них, опции то достаточно общеупотребительные. в любом случае, я отключал их группами, и опять же ни к чему это не привело.

ventilator, вам это сильно помешало? проблема пока не решена, то что мне отписали в рассылке никак не помогло

mikhal123
() автор топика
Ответ на: комментарий от mikhal123

Записи с повторяющимся IP:

2012/09/18 21:42:50 [info] 38987#0: *96822 client timed out (110: Connection timed out) while reading client request line, client: 46.48.88.157, server: 0.0.0.0:80 2012/09/18 21:42:50
Выглядят подозрительно. Досят? Как обстоят дела с качеством связи на сервере?

Тут можно просто временно отключить keepalive хотя бы для проверки. Сильно нагрузить сервер не должно. И лог почище будет.

2012/09/18 21:42:50 [info] 38986#0: *95981 client 95.72.119.26 closed keepalive connection

Ну и пофильтровать логи в поисках чего-то кроме этих сообщений c таймаутами:

tail -f /var/log/nginx/error.log | fgrep -v '110: Connection timed out'

Соединение временами по 300-500 мс устанавливается

А вот это как было измерено? Соединением извне к серверу или локально?

fjoe
()
Ответ на: комментарий от fjoe

Тут можно просто временно отключить keepalive хотя бы для проверки.

если много статики, то его лучше совсем отключать

greyl
()

в общем проблема осознана и решена. кому интересно:

описанная выше ситуация происходит из-за того, что добрый хром при подключении к сайту делает сразу 10-15 соединений, и большую часть из них он никак не использует. мне кажется что это не очень хорошо с его стороны, но это лирика. спустя client_header_timeout эти соединения отваливаются по таймауту у сервера, либо секунд через 10 их закрывает сам хром - что наступит раньше.

для того, чтобы не долбить nginx этими ненужными никому соединениями, достаточно двух опций

client_header_timeout 15; #не меньше 10 (вроде именно столько таймаут у хрома)
listen 80 default_server deferred; #для linux
#для freebsd вместо deferred нужно использовать accept_filter=dataready или еще круче accept_filter=httpready 

после этого лично у меня все нормализовалось

Active connections: 2825 
server accepts handled requests
 507907 507907 1094551 
Reading: 11 Writing: 3 Waiting: 2811 

mikhal123
() автор топика
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.