Re: Не запускается PhpMyAdmin
Попробуйте проанализировать core-dump'ы php-fpm. Как анализировать написано тут по русски, но про апач: http://habrahabr.ru/company/bitrix/blog/153001/ А тут - по-английски, но про php-fpm: https://rtcamp.com/tutorials/php/core-dump-php5-fpm/ 10 августа 2015 г., 8:48 пользователь Maksim Kulik kulm...@gmail.com написал: Весьма вероятна проблема с порядком загрузки расширений php (файл extensions.ini). Некоторым расширениям очень важно загружаться пораньше, т.к. следующие используют их функционал. Попробуйте запустить php в консоли - он в таком случае выдаст как минимум несколько варнингов, по которым можно будет предположить что ему не нравится. 2015-08-10 11:50 GMT+03:00 termit-200 nginx-fo...@nginx.us: В логе php-fpm сообщения вот такого вида: [10-Aug-2015 11:42:05] WARNING: [pool www] child 1627 exited on signal 11 (SIGSEGV) after 0.944585 seconds from start [10-Aug-2015 11:42:05] NOTICE: [pool www] child 1629 started [10-Aug-2015 11:42:05] WARNING: [pool www] child 1628 exited on signal 11 (SIGSEGV) after 1.275092 seconds from start [10-Aug-2015 11:42:05] NOTICE: [pool www] child 1631 started [10-Aug-2015 11:42:05] WARNING: [pool www] child 1629 exited on signal 11 (SIGSEGV) after 0.484413 seconds from start [10-Aug-2015 11:42:05] NOTICE: [pool www] child 1632 started Posted at Nginx Forum: http://forum.nginx.org/read.php?21,260893,260896#msg-260896 ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru -- Alexey Malov ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: nginx без причины перестал запускаться
29 июля 2015 г., 14:56 пользователь tfox nginx-fo...@nginx.us написал: Всем привет. Вот такая ситуация. root@maxserver:/# sudo service nginx start root@maxserver:/# sudo service nginx stop root@maxserver:/# sudo service nginx restart * Restarting nginx nginx [fail] root@maxserver:/# Получается говоришь nginx старт он молчит. Говоришь стоп он тоже молчит. Говоришь рестарт он отвечает fail root@maxserver:/# sudo service nginx status * nginx is not running root@maxserver:/# grep -h '[n]ginx' (ps aux) (service --status-all 21) www-data 11700 0.0 0.3 3465836 31896 ? SJul28 0:14 nginx: worker process www-data 11701 0.0 0.4 3465836 32364 ? SJul28 0:13 nginx: worker process www-data 11702 0.0 0.3 3465836 31940 ? SJul28 0:14 nginx: worker process www-data 11703 0.0 0.3 3465836 31916 ? SJul28 0:15 nginx: worker process www-data 11704 0.0 0.3 3465836 25504 ? SJul28 0:00 nginx: cache manager process [ - ] nginx root@maxserver:/# Насколько я понимаю. Первая команда сообщает, что nginx не запущен. Но сайты при этом работают. Вторая команда сообщает, что какие то процессы nginx работают. Posted at Nginx Forum: http://forum.nginx.org/read.php?21,260631,260631#msg-260631 Попробуйте: sudo killall -9 nginx sudo service nginx start ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru -- Alexey Malov ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: Маршрутизация запросов
29 июля 2015 г., 0:43 пользователь Budulianin nginx-fo...@nginx.us написал: Но hash же не гарантирует равномерного распределения запросов по бэкендам, он как раз гарантирует, что запросы с одинаковым id будут идти на одну и ту же ноду. А где-то описывается алгоритм работы hash? Вообще вот тут вот:-) http://hg.nginx.org/nginx/file/341e4303d25b/src/http/modules/ngx_http_upstream_hash_module.c Чтобы можно было понять наверняка, всегда ли с одним id на одну и туже ноду или нет. Можно в debug-логах посмотреть, какой хеш получается у какого клиента и у какого id, и посмотреть на какую ноду он уходит. Я конечно проверю, но ещё хотелось бы что-то в документации прочитать по этому поводу. Posted at Nginx Forum: http://forum.nginx.org/read.php?21,260591,260602#msg-260602 ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru -- Alexey Malov ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: Добавление заголовка после upstream
29 июля 2015 г., 0:34 пользователь Budulianin nginx-fo...@nginx.us
написал:
В ответ клиенту добавить?
Добавить в запрос, который перенаправится какой-то ноде, после того, как
она
будет выбрана в upstream.
Т.е. upstream уже выбран, мы его только теперь знаем(адрес ноды) и тогда мы
добавляем его в header и он отправляется в ноду.
Если ставить proxy_set_header рядом с proxy_pass, то заголовок не
добавляется, я так понимаю, что переменная ещё пустая, поэтому
заголовок не ставится. Но где уже известна эта переменная? Только в блоке
upstream? Но там нельзя устанавливать заголовок.
Она известна уже после получения конечного ответа от бэкендов.
А разве ноды бэкенда сами свои адреса не знают? Зачем им этот заголовок
посылать?
map $http_upgrade $connection_upgrade {
default upgrade;
'' close;
}
upstream tornado {
hash $arg_key;
server 127.0.0.1:9995;
server 127.0.0.1:9996;
server 127.0.0.1:9997;
server 127.0.0.1:9998;
server 127.0.0.1:;
}
server {
listen 8080 default_server;
access_log /var/log/nginx/prototypes-nginx-access.log;
error_log /var/log/nginx/prototypes-nginx-error.log;
location /ws/ {
proxy_pass http://tornado;
proxy_set_header Test-Header1 123;
proxy_set_header Test-Header2 $upstream_addr;
proxy_set_header Test-Header3 $host;
proxy_http_version 1.1;
proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection $connection_upgrade;
}
}
Posted at Nginx Forum:
http://forum.nginx.org/read.php?21,260596,260601#msg-260601
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru
--
Alexey Malov
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: Добавление заголовка после upstream
28 июля 2015 г., 17:39 пользователь Budulianin nginx-fo...@nginx.us написал: Можно ли как-то добавить заголовок c адресом, куда был отправлен запрос директивой upstream? В ответ клиенту добавить? В upstream нельзя использовать add_header. В upstream и не надо, надо там, где проксируете: proxy_pass http://upstream_name; add_header $upstream_addr; Posted at Nginx Forum: http://forum.nginx.org/read.php?21,260596,260596#msg-260596 ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru -- Alexey Malov ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: Маршрутизация запросов
2015-07-28 15:15 GMT-05:00 Budulianin nginx-fo...@nginx.us:
Да, надо было вставить.
map $http_upgrade $connection_upgrade {
default upgrade;
'' close;
}
upstream tornado {
hash $arg_key;
server 127.0.0.1:9995;
server 127.0.0.1:9996;
server 127.0.0.1:9997;
server 127.0.0.1:9998;
server 127.0.0.1:;
}
server {
listen 8080 default_server;
access_log /var/log/nginx/nginx-access.log;
error_log /var/log/nginx/nginx-error.log;
location /ws/ {
proxy_pass http://tornado;
proxy_http_version 1.1;
proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection $connection_upgrade;
}
}
Вроде вы всё делаете правильно..
Но hash же не гарантирует равномерного распределения запросов по бэкендам,
он как раз гарантирует, что запросы с одинаковым id будут идти на одну и ту
же ноду. Попробуйте протестировать с большим разнообразием id, штук 20,
например. Тогда должны, скорее всего, все ноды задействоваться.
Если включите debug-лог, то там можно будет увидеть, какой hash у каждого
клиента посчитан будет, может, с ними нагляднее будет.
Posted at Nginx Forum:
http://forum.nginx.org/read.php?21,260591,260595#msg-260595
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru
--
Alexey Malov
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: Кастомная сборка NGINX под Debian 7
27 июля 2015 г., 17:40 пользователь Michael Kechinov s...@mkechinov.ru написал: Возникла проблема на другом сервере. Собрал по инструкции, при обращении к бинарнику выпадает с такой ошибкой: # /etc/init.d/nginx start Invalid version format (non-numeric data) at /usr/lib/perl/5.14/DynaLoader.pm line 207. Compilation failed in require. BEGIN failed--compilation aborted. nginx: [alert] perl_parse() failed: 2 Что может быть не так? Баг в debian? https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=672356 On Thu, Jul 16, 2015 at 11:41 AM, Michael Kechinov s...@mkechinov.ru wrote: Свершилось, благодарю. 2015-07-15 13:29 GMT+03:00 Aleksandr Sytar sytar.a...@gmail.com: 15 июля 2015 г., 10:10 пользователь Michael Kechinov s...@mkechinov.ru написал: Unable to locate package nignx ^^ Опечатка - nginx ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru -- *Michael Kechinov http://linkedin.com/in/mkechinov* | s...@mkechinov.ru | +7 950 0099233 Startups development studio: mkechinov.ru | en http://mkechinov.com Personalization for e-commerce: rees46.com HackDay: hackday.ru Twitter-wall: twijector.com -- *Michael Kechinov http://linkedin.com/in/mkechinov* | s...@mkechinov.ru | +7 950 0099233 Startups development studio: mkechinov.ru | en http://mkechinov.com Personalization for e-commerce: rees46.com HackDay: hackday.ru Twitter-wall: twijector.com ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru -- Alexey Malov ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: Маршрутизация запросов
28 июля 2015 г., 13:42 пользователь Budulianin nginx-fo...@nginx.us написал: Всем привет. Есть задача: каждого определённого пользователя всегда отправлять на определённую ноду. Пытаюсь решить её с помощью балансировки, через директиву upstream + hash. Задаю каждому пользователю уникальный id, передаю его в запросе и потом nginx делает из него hash и в соответствии с ним отправляет запрос на определённую ноду. Но не все запросы равномерно распределяются по нодам. Например: у меня 5 нод, отправляю 4 запроса с одним id, они приходят на 1 ноду, отправляю следующие 4 запроса c новым id, они приходят на 2 ноду, отправляю следующие 4 запроса c новым id, они приходят на 3 ноду, повторяю те же действия с новыми id, но на ноду 4 и 5 ничего не приходит, запросы распределяются между 1, 2 и 3. Подскажите пожалуйста: Как происходит выбор ноды, когда upstream + hash? А конфиг покажите, пожалуйста? Как решают подобные задачи? Может вообще по другому? Если nginx вычислил hash от id и отправил на ноду n, то он всегда будет отправлять с тем же id на ноду n?(если список нод не менялся) Posted at Nginx Forum: http://forum.nginx.org/read.php?21,260591,260591#msg-260591 ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru -- Alexey Malov ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: nginx забивает все место в корневом разделе linux
13 июля 2015 г., 9:11 пользователь Иван Мишин simplebo...@gmail.com написал: это же тема прям из учебника... Кроме шуток, будьте добры ткните носом пожалуйста, буду очень признателен. sudo lsof | grep nginx http://nginx.org/ru/docs/http/ngx_http_proxy_module.html#proxy_buffering http://nginx.org/ru/docs/http/ngx_http_proxy_module.html#proxy_cache_path 13 июля 2015 г., 17:06 пользователь Daniel Podolsky onoko...@gmail.com написал: Помогите понять куда и чего пишет nginx в корневом разделе. это же тема прям из учебника... nginx пишет свой кеш. например - при заборе с бекенда больших файлов, или при приеме больших файлов от клиентов. файлы кеша nginx удаляет сразу после создания - чтобы за процессом не оставалось мусора. поэтому du их не видит. однако, реальное удаление файла и освобождение места в *nix происходит только после закрытия файла, поэтому место таки занято. если вам очень надо знать имена этих файлов - возьмите в руки программу lsof. ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru -- Alexey Malov ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Высокий IO на серверах с nginx
;
proxy_cache exe_cache;
proxy_cache_valid 200 48h;
proxy_ignore_headers Set-Cookie;
add_header Cache-Control public;
expires 36h;
}
location ~ ^/_(a|b|c|d|e|f|m|x|i|h)\.jsp$ {
proxy_pass http://127.0.0.1:5885/banners/ba/_$1.jsp$is_args$args;
proxy_cache_key
$http_host$scheme$proxy_host$uri$is_args$arg_tc$arg_t$arg_callback;
proxy_cache exe_cache;
proxy_cache_valid 200 8h;
proxy_ignore_headers Set-Cookie;
expires 8h;
deny all;
}
location /api/v1/stabucket {
proxy_pass
http://127.0.0.1:5885/adsnetto_backend/api/v1/stabucket$is_args$args;
proxy_cache_key
$http_host$scheme$proxy_host$uri$is_args$arg_tc$arg_t$arg_callback$arg_r;
proxy_cache exe_cache;
proxy_cache_valid 200 8h;
proxy_ignore_headers Set-Cookie;
expires 8h;
}
location /_.jsp {
proxy_pass http://127.0.0.1:5885/banners/ba/_.jsp;
proxy_cache_key
$http_host$scheme$proxy_host$uri$is_args$arg_tc$arg_t$arg_callback;
proxy_cache exe_cache;
proxy_cache_valid 200 12h;
proxy_ignore_headers Set-Cookie;
expires 12h;
}
location /tag_test.jsp {
proxy_pass http://127.0.0.1:5885/banners/ba/tag_test.jsp;
expires 36h;
}
location /clk.action {
proxy_pass http://search.utop.it;
proxy_set_header Host search.utop.it;
}
location /exe {
proxy_pass http://127.0.0.1:5885/banners/exe;
proxy_cache exe_cache;
proxy_cache_valid 200 24h;
}
location /ini.jsp {
proxy_pass http://127.0.0.1:5885/banners/loca/ini.jsp;
proxy_cache exe_cache;
proxy_cache_valid 4h;
expires 12h;
}
location /img/px.png {
alias /tomcat/webapps/banners##1.3/img/px.png;
userid on;
userid_nameuid;
userid_domain example.com; HttpOnly;
userid_expires max;
expires epoch;
}
access_log /var/log/nginx/example.com_access.log ub_cloudflare
buffer=10m flush=1m;
error_log /var/log/nginx/example.com_error.log error;
}
nginx -V:
# nginx -V
nginx version: nginx/1.6.2
built by gcc 4.4.7 20120313 (Red Hat 4.4.7-4) (GCC)
TLS SNI support enabled
configure arguments: --prefix=/usr/share/nginx --sbin-path=/usr/sbin/nginx
--conf-path=/etc/nginx/nginx.conf --error-log-path=/var/log/nginx/error.log
--http-log-path=/var/log/nginx/access.log
--http-client-body-temp-path=/var/lib/nginx/tmp/client_body
--http-proxy-temp-path=/var/lib/nginx/tmp/proxy
--http-fastcgi-temp-path=/var/lib/nginx/tmp/fastcgi
--http-uwsgi-temp-path=/var/lib/nginx/tmp/uwsgi
--http-scgi-temp-path=/var/lib/nginx/tmp/scgi --pid-path=/var/run/nginx.pid
--lock-path=/var/lock/subsys/nginx --user=nginx --group=nginx
--with-file-aio --with-ipv6 --with-http_ssl_module
--with-http_realip_module --with-http_addition_module
--with-http_xslt_module --with-http_image_filter_module
--with-http_geoip_module --with-http_sub_module --with-http_dav_module
--with-http_flv_module --with-http_mp4_module
--with-http_gzip_static_module --with-http_random_index_module
--with-http_secure_link_module --with-http_degradation_module
--with-http_stub_status_module --with-debug --with-cc-opt='-O2 -g -pipe
-Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector
--param=ssp-buffer-size=4 -m64 -mtune=generic'
В sysctl подкручивали:
net.ipv4.tcp_fin_timeout = 15
net.ipv4.tcp_tw_reuse = 1
net.ipv4.tcp_tw_recycle = 0
net.core.netdev_max_backlog = 65536
net.ipv4.tcp_max_syn_backlog = 262144
net.core.somaxconn = 262144
net.core.rmem_max = 8388608
net.core.wmem_max = 8388608
net.core.rmem_default = 65536
net.core.wmem_default = 65536
net.ipv4.tcp_rmem = 8192 873800 8388608
net.ipv4.tcp_wmem = 4096 655360 8388608
net.ipv4.tcp_synack_retries = 2
net.ipv4.tcp_syn_retries=2
Картина в netstat:
# netstat -ant | grep tcp | tr -s ' ' ' ' | awk '{print $6}' | sort | uniq
-c
8 CLOSE_WAIT
32970 ESTABLISHED
22 FIN_WAIT1
3 LAST_ACK
17 LISTEN
23 SYN_RECV
27976 TIME_WAIT
--
Alexey Malov
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: Высокий IO на серверах с nginx
11 июля 2015 г., 17:09 пользователь Alexey Malov scukon...@gmail.com
написал:
Добрый день,
Второй день наблюдаю проблему с высоким IO на серверах с nginx при не
очень большой нагрузке.
Схема такая - 11 серверов с nginx и tomcat. Nginx на каждому сервере
принимает трафик от CloudFlare CDN, большую часть отдаёт из кеша, остальное
балансирует на томкаты (и ещё один статический файлик отдаёт сам).
Всё было замечательно до вчера, трафик в пике был до 40 мегабайтов в
секунду, 40к параллельных соединений и ~1500 запросов в секунду на каждом
из серверов.
Вчера же трафик подскочил раза в полтора (сбрасывали кеш на CloudFlare и
сами запросы тоже поменялись), резко выроз IO на сервере (раньше его вообще
практически не было, а стало около 15-20%) и всё начало тупить.
Изначально думали на диск, но отключение логов практически никак не
повлияло.
В dmesg стали вылезать сообщения про synflood, увеличили бэклоги как в
nginx, так и в sysctl, сообщения про synflood пропали, но проблема с IO
осталась.
Немного помогло отключение лоад-балансинга в nginx, теперь каждый nginx
проксирует на локальный томкат. Нагрузка на сеть понизилась, IO понизилось,
но всё равно осталось.
Трафик с тех пор понизился даже ниже, чем был до проблемы, сейчас около
1100 запросов в секунду. Но IO осталось. Nginx даже иногда по нескольку
секунд отвечает на запросы к странице stub_status.
Пробовали разделять сервера с tomcat и nginx, IO оставалось на стороне
nginx.
Был бы очень признателен, если бы кто-нибудь подсказал хотя бы куда
копать. Потому что уже вроде как чем только не пробовали. Спасибо заранее!
Конфиги следующие:
nginx.conf:
user nginx;
worker_processes 8;
worker_rlimit_nofile 512000;
worker_rlimit_core 500M;
error_log /var/log/nginx/error.log;
pid/var/run/nginx.pid;
events {
worker_connections 256000;
}
http {
include /etc/nginx/mime.types;
default_type application/octet-stream;
ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
log_format main '$remote_addr - $remote_user [$time_local]
$request '
'$status $body_bytes_sent $http_referer '
'$http_user_agent $http_x_forwarded_for';
log_format upstream_balancing '$remote_addr - $remote_user
[$time_local] '
'$request $status $bytes_sent '
'$http_referer $http_user_agent '
'$upstream_addr $upstream_response_time
$geoip_country_code/$http_cf_ipcountry $http_host
$upstream_cache_status '
'$http_cf_connecting_ip';
log_format ub_cloudflare '$http_cf_connecting_ip - $remote_user
[$time_local] '
'$request $status $bytes_sent '
'$http_referer $http_user_agent '
'$upstream_addr $upstream_response_time
$geoip_country_code/$http_cf_ipcountry $http_host
$upstream_cache_status '
'$remote_addr $cookie___cfduid $cookie_uid';
access_log /var/log/nginx/access.log main;
sendfileon;
keepalive_timeout 65;
proxy_cache_methods GET;
include /etc/nginx/conf.d/*.conf;
include /etc/nginx/sites-enabled/*;
}
virtual host:
server {
listen 1.1.1.1:80;
listen 1.1.1.1:443 ssl;
ssl_certificate /etc/nginx/ssl/cert.crt;
ssl_certificate_key /etc/nginx/ssl/key.key;
server_name example.com;
proxy_set_header clientCountryCode $http_cf_ipcountry ;
proxy_ignore_headers Set-Cookie;
proxy_hide_header Set-Cookie;
proxy_next_upstream error timeout http_500;
location / {
deny all;
}
location /manager {
proxy_pass http://127.0.0.1:5885;
}
location /crossdomain.xml {
root /tomcat/static_xml;
expires 31d;
}
location ~ ^(/display.htm)$ {
proxy_pass http://127.0.0.1:5885/banners/$1$is_args$args;
proxy_cache exe_cache;
proxy_cache_valid 2h;
expires 24h;
}
location ~ ^(/secure.jsp)$ {
proxy_pass http://127.0.0.1:5885/banners/mojo/$1$is_args$args;
proxy_cache exe_cache;
proxy_cache_valid 2h;
expires 12h;
}
location ~ ^(/hela.jsp)$ {
proxy_pass http://127.0.0.1:5885/banners/hela$1$is_args$args;
proxy_cache exe_cache;
proxy_cache_valid 2h;
expires 12h;
}
location ~ ^(/hela.exe)$ {
proxy_pass http://127.0.0.1:5885/banners/hela$1$is_args$args;
proxy_cache exe_cache;
proxy_cache_valid 24h;
}
location /wl/ba.jsp {
proxy_pass http://127.0.0.1:5885/banners/wl/ba.jsp;
#proxy_cache_key proxy_cache_key;
proxy_cache exe_cache;
proxy_cache_valid 200 48h;
expires 1w;
}
location /wl/po.jsp {
proxy_pass http://127.0.0.1:5885/banners/wl/po.jsp;
proxy_cache exe_cache;
proxy_cache_valid 200 48h;
expires 1w;
}
location
Re: Высокий IO на серверах с nginx
Как выяснилось, IO было дисковое, перенос cache в RAM всё излечил. Странно
только, почему раньше работало. Сейчас вариантов URL стало даже меньше. И
трафик опустился.
11 июля 2015 г., 17:57 пользователь Alexey Malov scukon...@gmail.com
написал:
11 июля 2015 г., 17:09 пользователь Alexey Malov scukon...@gmail.com
написал:
Добрый день,
Второй день наблюдаю проблему с высоким IO на серверах с nginx при не
очень большой нагрузке.
Схема такая - 11 серверов с nginx и tomcat. Nginx на каждому сервере
принимает трафик от CloudFlare CDN, большую часть отдаёт из кеша, остальное
балансирует на томкаты (и ещё один статический файлик отдаёт сам).
Всё было замечательно до вчера, трафик в пике был до 40 мегабайтов в
секунду, 40к параллельных соединений и ~1500 запросов в секунду на каждом
из серверов.
Вчера же трафик подскочил раза в полтора (сбрасывали кеш на CloudFlare и
сами запросы тоже поменялись), резко выроз IO на сервере (раньше его вообще
практически не было, а стало около 15-20%) и всё начало тупить.
Изначально думали на диск, но отключение логов практически никак не
повлияло.
В dmesg стали вылезать сообщения про synflood, увеличили бэклоги как в
nginx, так и в sysctl, сообщения про synflood пропали, но проблема с IO
осталась.
Немного помогло отключение лоад-балансинга в nginx, теперь каждый nginx
проксирует на локальный томкат. Нагрузка на сеть понизилась, IO понизилось,
но всё равно осталось.
Трафик с тех пор понизился даже ниже, чем был до проблемы, сейчас около
1100 запросов в секунду. Но IO осталось. Nginx даже иногда по нескольку
секунд отвечает на запросы к странице stub_status.
Пробовали разделять сервера с tomcat и nginx, IO оставалось на стороне
nginx.
Был бы очень признателен, если бы кто-нибудь подсказал хотя бы куда
копать. Потому что уже вроде как чем только не пробовали. Спасибо заранее!
Конфиги следующие:
nginx.conf:
user nginx;
worker_processes 8;
worker_rlimit_nofile 512000;
worker_rlimit_core 500M;
error_log /var/log/nginx/error.log;
pid/var/run/nginx.pid;
events {
worker_connections 256000;
}
http {
include /etc/nginx/mime.types;
default_type application/octet-stream;
ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
log_format main '$remote_addr - $remote_user [$time_local]
$request '
'$status $body_bytes_sent $http_referer '
'$http_user_agent $http_x_forwarded_for';
log_format upstream_balancing '$remote_addr - $remote_user
[$time_local] '
'$request $status $bytes_sent '
'$http_referer $http_user_agent '
'$upstream_addr $upstream_response_time
$geoip_country_code/$http_cf_ipcountry $http_host
$upstream_cache_status '
'$http_cf_connecting_ip';
log_format ub_cloudflare '$http_cf_connecting_ip - $remote_user
[$time_local] '
'$request $status $bytes_sent '
'$http_referer $http_user_agent '
'$upstream_addr $upstream_response_time
$geoip_country_code/$http_cf_ipcountry $http_host
$upstream_cache_status '
'$remote_addr $cookie___cfduid $cookie_uid';
access_log /var/log/nginx/access.log main;
sendfileon;
keepalive_timeout 65;
proxy_cache_methods GET;
include /etc/nginx/conf.d/*.conf;
include /etc/nginx/sites-enabled/*;
}
virtual host:
server {
listen 1.1.1.1:80;
listen 1.1.1.1:443 ssl;
ssl_certificate /etc/nginx/ssl/cert.crt;
ssl_certificate_key /etc/nginx/ssl/key.key;
server_name example.com;
proxy_set_header clientCountryCode $http_cf_ipcountry ;
proxy_ignore_headers Set-Cookie;
proxy_hide_header Set-Cookie;
proxy_next_upstream error timeout http_500;
location / {
deny all;
}
location /manager {
proxy_pass http://127.0.0.1:5885;
}
location /crossdomain.xml {
root /tomcat/static_xml;
expires 31d;
}
location ~ ^(/display.htm)$ {
proxy_pass http://127.0.0.1:5885/banners/$1$is_args$args;
proxy_cache exe_cache;
proxy_cache_valid 2h;
expires 24h;
}
location ~ ^(/secure.jsp)$ {
proxy_pass http://127.0.0.1:5885/banners/mojo/$1$is_args$args;
proxy_cache exe_cache;
proxy_cache_valid 2h;
expires 12h;
}
location ~ ^(/hela.jsp)$ {
proxy_pass http://127.0.0.1:5885/banners/hela$1$is_args$args;
proxy_cache exe_cache;
proxy_cache_valid 2h;
expires 12h;
}
location ~ ^(/hela.exe)$ {
proxy_pass http://127.0.0.1:5885/banners/hela$1$is_args$args;
proxy_cache exe_cache;
proxy_cache_valid 24h;
}
location /wl/ba.jsp {
proxy_pass http://127.0.0.1:5885/banners/wl/ba.jsp;
#proxy_cache_key proxy_cache_key;
proxy_cache exe_cache
