Это мой первый вопрос! Несколько дней назад я обнаружил, что что-то пошло не так с nginx: домены A-C в порядке, другие - таймаут. Позже: другие домены в порядке и первый тайм-аут; или каждый домен работает нормально. Если перезапустить nginx - ничего не изменится. После перезагрузки все работает нормально.
Может быть, причина в том, что иногда слишком много посетителей и nginx сбрасывают соединения, с которыми он не справляется? (Раньше был apache и иногда зависал VDS). Но ошибок в логах нет, ничего. В верхнем выводе я вижу, что используется только 2-4 МБ пространства подкачки.
Это: arch linux, nginx, php-fpm.
файл конфигурации: пользователь http http;
worker_processes 1;
error_log /var/log/nginx/nginx.error.log;
events {
worker_connections 2048;
}
http {
include mime.types;
default_type application/octet-stream;
error_log /var/log/nginx/http.error.log;
sendfile on;
gzip on;
gzip_static on;
gzip_vary on;
client_body_buffer_size 1k;
client_header_buffer_size 1k;
client_max_body_size 5m;
large_client_header_buffers 2 1k;
client_body_timeout 10;
client_header_timeout 10;
keepalive_timeout 5 5;
send_timeout 10;
server {
listen 80;
server_name www.A.com www.B.org www.F.net;
if ($host ~* ^www\.(.+)) {set $domain $1;}
return 301 $scheme://$domain$request_uri;
}
server {
listen 80;
server_name A.com *.A.com B.org F.net;
root /home/user/public_html/$host;
access_log /var/log/nginx/$host-access.log;
error_log /var/log/nginx/server.error.log;
location / {
try_files $uri $uri/ /index.php?$args;
index index.html index.htm index.php;
}
error_page 500 502 503 504 /50x.html;
location = /50x.html {
root /usr/share/nginx/html;
}
# pass the PHP scripts to FastCGI server listening on 127.0.0.1:9000
location ~ \.php$ {
fastcgi_pass unix:/var/run/php-fpm/php-fpm.sock;
try_files $uri =404;
fastcgi_index index.php;
fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
include fastcgi_params;
}
}
}
И, конечно же, я считаю, что должен найти причину, а не только исправить проблему.
Большое спасибо!
Если у вас есть что-то подобное - попробуйте tracert и проверьте DNS. Я не уверен, но, скорее всего, наша проблема была с DNS-серверами.
Это может вам помочь ... из Nignx wiki
client_body_buffer_size Синтаксис: client_body_buffer_size размер По умолчанию: 8k | 16k Контекст: расположение http-сервера Ссылка: client_body_buffer_size
Директива определяет размер буфера тела запроса клиента.
Если размер тела запроса больше, чем размер буфера, то все (или частично) тело запроса записывается во временный файл.
Размер по умолчанию равен размеру страницы, умноженному на 2. В зависимости от платформы размер страницы составляет 8 КБ или 16 КБ.
Когда заголовок запроса Content-Length указывает меньшее значение размера, чем размер буфера, тогда Nginx будет использовать меньшее значение. В результате Nginx не всегда выделяет буфер такого размера для каждого запроса.
сериализация запросов с accept_mutex on
тоже может помочь ... Обычно я тоже проверяю журнал php-fpm. Лучше всего проверить поведение, как / почему сервер не обслуживает заданную страницу. Журнал - единственный друг, который у нас здесь есть, поэтому, если вы знаете время, когда сервер не отвечает на запрос, возможно, что-то в журнале есть.
Ой и Nginx reload
может сделать трюк вместо restart
, что на некоторое время остановит обслуживание.
Попробуйте увеличить tvice worker_connection. Или, если у вас более одного ядра - увеличьте worker_processes до количества ядер.