From nginx-forum на forum.nginx.org Mon Jan 2 15:03:35 2017 From: nginx-forum на forum.nginx.org (Vvedensky) Date: Mon, 02 Jan 2017 10:03:35 -0500 Subject: =?UTF-8?B?UmU6INCV0YnRkSDQvtC00LjQvSDRgNC10LTQuNGA0LXQutGC?= In-Reply-To: <7346754.VFfpR5iQ1W@note> References: <7346754.VFfpR5iQ1W@note> Message-ID: Да, спасибо, так попробовал, всё работает. Сначала не сообразил с путями. Posted at Nginx Forum: https://forum.nginx.org/read.php?21,271763,271796#msg-271796 From nginx-forum на forum.nginx.org Wed Jan 4 18:03:41 2017 From: nginx-forum на forum.nginx.org (Seriyyy95) Date: Wed, 04 Jan 2017 13:03:41 -0500 Subject: =?UTF-8?B?0JrQsNC6INC+0YfQuNGB0YLQuNGC0Ywg0LrRjdGIIE5naW54?= Message-ID: Здравствуйте! Внес несколько изменений в файл стиля style.css. Но веб-сервер возвращает старую версию файла. Что было сделано: - Установил директиву sendfile off - Удалил все что было в папке /var/cache/nginx/ - Обнулил кэш страниц ядра - Перезапустил nginx. Ничего не изменилось, если оригинальный файл удалить тоже возвращается файл из кэша. Чего еще ему нужно? Версия nginx/1.10.2. Posted at Nginx Forum: https://forum.nginx.org/read.php?21,271820,271820#msg-271820 From stalker на altlinux.ru Wed Jan 4 18:38:30 2017 From: stalker на altlinux.ru (Anton Gorlov) Date: Wed, 4 Jan 2017 21:38:30 +0300 Subject: =?UTF-8?B?UmU6INCa0LDQuiDQvtGH0LjRgdGC0LjRgtGMINC60Y3RiCBOZ2lueA==?= In-Reply-To: References: Message-ID: <04996718-6870-613c-2e81-f8218156073f@altlinux.ru> Почистить кеш браузера как минимум. 04.01.2017 21:03, Seriyyy95 пишет: > Здравствуйте! Внес несколько изменений в файл стиля style.css. Но веб-сервер > возвращает старую версию файла. Что было сделано: > > - Установил директиву sendfile off > - Удалил все что было в папке /var/cache/nginx/ > - Обнулил кэш страниц ядра > - Перезапустил nginx. > > Ничего не изменилось, если оригинальный файл удалить тоже возвращается файл > из кэша. Чего еще ему нужно? Версия nginx/1.10.2. From nginx-forum на forum.nginx.org Wed Jan 4 18:55:38 2017 From: nginx-forum на forum.nginx.org (Seriyyy95) Date: Wed, 04 Jan 2017 13:55:38 -0500 Subject: =?UTF-8?B?UmU6INCa0LDQuiDQvtGH0LjRgdGC0LjRgtGMINC60Y3RiCBOZ2lueA==?= In-Reply-To: <04996718-6870-613c-2e81-f8218156073f@altlinux.ru> References: <04996718-6870-613c-2e81-f8218156073f@altlinux.ru> Message-ID: <70b7453840f0e483429b5005a291c43e.NginxMailingListRussian@forum.nginx.org> Браузер не при чем. Кэш уже несколько раз чищен. Плюс сейчас для проверки использую curl и wget: wget https://losst.ru/wp-content/themes/themes/arcade-basic-child/style.css curl -I https://losst.ru/wp-content/themes/themes/arcade-basic-child/style.css curl -H 'Cache-Control: no-cache' https://losst.ru/wp-content/themes/themes/arcade-basic-child/style.css -o style.css Результат тот же во всех случаях, файл старый. Last-Modified для файла возвращается 20 сентября, хотя он изменен сегодня. Posted at Nginx Forum: https://forum.nginx.org/read.php?21,271820,271823#msg-271823 From skobolo на gmail.com Wed Jan 4 19:10:34 2017 From: skobolo на gmail.com (SK) Date: Wed, 4 Jan 2017 22:10:34 +0300 Subject: =?UTF-8?B?UmU6INCa0LDQuiDQvtGH0LjRgdGC0LjRgtGMINC60Y3RiCBOZ2lueA==?= In-Reply-To: <70b7453840f0e483429b5005a291c43e.NginxMailingListRussian@forum.nginx.org> References: <04996718-6870-613c-2e81-f8218156073f@altlinux.ru> <70b7453840f0e483429b5005a291c43e.NginxMailingListRussian@forum.nginx.org> Message-ID: Емнип в wp статика отдаётся через php. Посмотрите в эту сторону — например, плагины WP для кеширования и так далее. Если я помню неверно, то дайте конфиг nginx посмотреть. SK > 4 янв. 2017 г., в 21:55, Seriyyy95 написал(а): > > Браузер не при чем. Кэш уже несколько раз чищен. Плюс сейчас для проверки > использую curl и wget: > > wget https://losst.ru/wp-content/themes/themes/arcade-basic-child/style.css > curl -I > https://losst.ru/wp-content/themes/themes/arcade-basic-child/style.css > curl -H 'Cache-Control: no-cache' > https://losst.ru/wp-content/themes/themes/arcade-basic-child/style.css -o > style.css > > Результат тот же во всех случаях, файл старый. Last-Modified для файла > возвращается 20 сентября, хотя он изменен сегодня. > > Posted at Nginx Forum: https://forum.nginx.org/read.php?21,271820,271823#msg-271823 > > _______________________________________________ > nginx-ru mailing list > nginx-ru на nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru From nginx-forum на forum.nginx.org Wed Jan 4 19:19:20 2017 From: nginx-forum на forum.nginx.org (Seriyyy95) Date: Wed, 04 Jan 2017 14:19:20 -0500 Subject: =?UTF-8?B?UmU6INCa0LDQuiDQvtGH0LjRgdGC0LjRgtGMINC60Y3RiCBOZ2lueA==?= In-Reply-To: References: Message-ID: Конфиг w3 total cache: # BEGIN W3TC Page Cache cache location ~ /wp-content/cache/page_enhanced.*html$ { expires modified 36000s; add_header X-Powered-By "W3 Total Cache/0.9.5.1"; add_header Vary "Accept-Encoding, Cookie"; add_header Pragma "public"; add_header Cache-Control "max-age=36000, public"; } location ~ /wp-content/cache/page_enhanced.*gzip$ { gzip off; types {} default_type text/html; expires modified 36000s; add_header X-Powered-By "W3 Total Cache/0.9.5.1"; add_header Vary "Accept-Encoding, Cookie"; add_header Pragma "public"; add_header Cache-Control "max-age=36000, public"; add_header Content-Encoding gzip; } # END W3TC Page Cache cache # BEGIN W3TC Browser Cache gzip on; gzip_types text/css text/x-component application/x-javascript application/javascript text/javascript text/x-js text/richtext image/svg+xml text/plain text/xsd text/xsl text/xml image/bmp application/java application/msword application/vnd.ms-fontobject application/x-msdownload image/x-icon application/json application/vnd.ms-access application/vnd.ms-project application/x-font-otf application/vnd.ms-opentype application/vnd.oasis.opendocument.database application/vnd.oasis.opendocument.chart application/vnd.oasis.opendocument.formula application/vnd.oasis.opendocument.graphics application/vnd.oasis.opendocument.spreadsheet application/vnd.oasis.opendocument.text audio/ogg application/pdf application/vnd.ms-powerpoint application/x-shockwave-flash image/tiff application/x-font-ttf audio/wav application/vnd.ms-write application/font-woff application/font-woff2 application/vnd.ms-excel; location ~ \.(css|htc|less|js|js2|js3|js4)$ { expires -1s; add_header Pragma "public"; add_header Cache-Control "max-age=-1, public"; add_header X-Powered-By "W3 Total Cache/0.9.5.1"; try_files $uri $uri/ $uri.html /index.php?$args; } location ~ \.(html|htm|rtf|rtx|svg|svgz|txt|xsd|xsl|xml)$ { expires 36000s; add_header Pragma "public"; add_header Cache-Control "max-age=36000, public"; add_header X-Powered-By "W3 Total Cache/0.9.5.1"; try_files $uri $uri/ $uri.html /index.php?$args; } location ~ \.(asf|asx|wax|wmv|wmx|avi|bmp|class|divx|doc|docx|eot|exe|gif|gz|gzip|ico|jpg|jpeg|jpe|json|mdb|mid|midi|mov|qt|mp3|m4a|mp4|m4v|mpeg|mpg|mpe|mpp|otf|_otf|odb|odc|odf|odg|odp|ods|odt|ogg|pdf|png|pot|pps|ppt|pptx|ra|ram|svg|svgz|swf|tar|tif|tiff|ttf|ttc|_ttf|wav|wma|wri|woff|woff2|xla|xls|xlsx|xlt|xlw|zip)$ { expires 31536000s; add_header Pragma "public"; add_header Cache-Control "max-age=31536000, public"; add_header X-Powered-By "W3 Total Cache/0.9.5.1"; try_files $uri $uri/ $uri.html /index.php?$args; } add_header strict-transport-security "max-age=31536000"; # END W3TC Browser Cache # BEGIN W3TC Page Cache core set $w3tc_rewrite 1; if ($request_method = POST) { set $w3tc_rewrite 0; } if ($query_string != "") { set $w3tc_rewrite 0; } if ($http_cookie ~* "(comment_author|wp\-postpass|w3tc_logged_out|wordpress_logged_in|wptouch_switch_toggle)") { set $w3tc_rewrite 0; } set $w3tc_preview ""; if ($http_cookie ~* "(w3tc_preview)") { set $w3tc_preview _preview; } set $w3tc_ssl ""; if ($scheme = https) { set $w3tc_ssl _ssl; } set $w3tc_enc ""; if ($http_accept_encoding ~ gzip) { set $w3tc_enc _gzip; } if (!-f "$document_root/wp-content/cache/page_enhanced/$http_host/$request_uri/_index$w3tc_ssl$w3tc_preview.html$w3tc_enc") { set $w3tc_rewrite 0; } if ($w3tc_rewrite = 1) { rewrite .* "/wp-content/cache/page_enhanced/$http_host/$request_uri/_index$w3tc_ssl$w3tc_preview.html$w3tc_enc" last; } # END W3TC Page Cache core Но кэш w3tc тоже чищен, плюс expires в -1 выставил. Дальше конфиг самого сайта: server { server_name losst.ru www.losst.ru; ssl on; ssl_certificate "/var/www/httpd-cert/losst/losst.ru_le2.crtca"; ssl_certificate_key "/var/www/httpd-cert/losst/losst.ru_le2.key"; ssl_ciphers EECDH+AESGCM:EDH+AESGCM:AES256+EECDH:AES256+EDH; ssl_prefer_server_ciphers on; ssl_protocols TLSv1 TLSv1.1 TLSv1.2; add_header Strict-Transport-Security "max-age=31536000;"; charset off; index index.php; disable_symlinks if_not_owner from=$root_path; include /etc/nginx/vhosts-includes/*.conf; include /etc/nginx/vhosts-resources/losst.ru/*.conf; access_log /var/www/httpd-logs/losst.ru.access.log; error_log /var/www/httpd-logs/losst.ru.error.log notice; ssi off; set $root_path /var/www/losst/data/www/losst.ru; root $root_path; listen 194.67.215.125:443 default_server; include /var/www/losst/data/www/losst.ru/nginx.conf; location = /nginx.conf { deny all; } location / { try_files $uri $uri/ /index.php?$args; location ~ [^/]\.ph(p\d*|tml)$ { try_files /does_not_exists @php; } try_files $uri $uri/ /index.php?$args; location ~ [^/]\.ph(p\d*|tml)$ { try_files /does_not_exists @php; } } location = /robots.txt { allow all; log_not_found off; access_log off; } location = /favicon.ico { log_not_found off; access_log off; } location @php { fastcgi_index index.php; fastcgi_param PHP_ADMIN_VALUE "sendmail_path = /usr/sbin/sendmail -t -i -f admin на losst.ru"; fastcgi_pass unix:/var/www/php-fpm/losst.sock; fastcgi_split_path_info ^((?U).+\.ph(?:p\d*|tml))(/?.+)$; try_files $uri =404; include fastcgi_params; } } Насколько я понял nginx выдает статику напрямую, в том и все дело. Posted at Nginx Forum: https://forum.nginx.org/read.php?21,271820,271825#msg-271825 From mitroko на gmail.com Wed Jan 4 19:37:01 2017 From: mitroko на gmail.com (Dzmitry Stremkouski) Date: Wed, 4 Jan 2017 22:37:01 +0300 Subject: =?UTF-8?Q?server=5Fname_=D0=B2_X-Original-URL?= Message-ID: Здравствуйте, активно использую auth_request на сервере. Использую server { listen 443 ssl http2; listen [::]:443 ssl http2; server_name secure.stremki.net ssl.stremki.net; ... location = /auth { proxy_set_header X-Original-URL $scheme://$server_name$request_uri; ... и у меня на бекенд авторизации вне зависимости от того, пришёл ли я на secure или ssl, приходит server_name = secure.stremki.net Если имена server_name варьировать, то выбирается первое. Если разбить секцию server на две, в каждой свой server_name с одним и тем же сертификатом, то на локейшн /auth прилетает правильный server_name Сборку использую свою, основанную на вашей с небольшим вкраплением модулей. [mitroko на y core_nginx]$ nginx -V nginx version: nginx/1.10.1 built by gcc 4.8.5 20150623 (Red Hat 4.8.5-11) (GCC) built with OpenSSL 1.0.1e-fips 11 Feb 2013 TLS SNI support enabled configure arguments: --prefix=/etc/nginx --sbin-path=/usr/sbin/nginx --modules-path=/usr/lib64/nginx/modules --conf-path=/etc/nginx/nginx.conf --error-log-path=/var/log/nginx/error.log --http-log-path=/var/log/nginx/access.log --pid-path=/var/run/nginx.pid --lock-path=/var/run/nginx.lock --http-client-body-temp-path=/var/cache/nginx/client_temp --http-proxy-temp-path=/var/cache/nginx/proxy_temp --http-fastcgi-temp-path=/var/cache/nginx/fastcgi_temp --http-uwsgi-temp-path=/var/cache/nginx/uwsgi_temp --http-scgi-temp-path=/var/cache/nginx/scgi_temp --user=nginx --group=nginx --with-http_ssl_module --with-http_realip_module --with-http_addition_module --with-http_sub_module --with-http_dav_module --with-http_flv_module --with-http_mp4_module --with-http_gunzip_module --with-http_gzip_static_module --with-http_random_index_module --with-http_secure_link_module --with-http_stub_status_module --with-http_auth_request_module --with-http_xslt_module=dynamic --with-http_image_filter_module=dynamic --with-http_geoip_module=dynamic --with-http_perl_module=dynamic --add-dynamic-module=njs-1c50334fbea6/nginx --with-threads --with-stream --with-stream_ssl_module --with-http_slice_module --with-mail --with-mail_ssl_module --with-file-aio --with-ipv6 --add-dynamic-module=ngx_devel_kit-v0.3.0 --add-module=nginx-upstream-fair --add-dynamic-module=lua-nginx-module-v0.10.7 --add-module=headers-more-nginx-module-v0.261 --with-http_v2_module --with-cc-opt='-O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector-strong --param=ssp-buffer-size=4 -grecord-gcc-switches -m64 -mtune=generic' пакеты для тестирования можно взять тут: https://secure.stremki.net/mirror/repos/centos/RPMS/7/x86_64/ https://secure.stremki.net/mirror/repos/centos/SRPMS/ Centos 7 / ядро 3.10.0-514.2.2.el7.x86_64 Возможно, баг, возможно, кривизна моей пересборки вашего пакета отсюда - https://nginx.org/packages/rhel/7/SRPMS/. -- 
(o_ - Dzmitry Stremkouski.
//\ - cel: +7 (916) 090-85-68
V_/_- web: http://mitroko.com
----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From laa на laa.zp.ua Wed Jan 4 20:03:40 2017 From: laa на laa.zp.ua (Lystopad Aleksandr) Date: Wed, 4 Jan 2017 22:03:40 +0200 Subject: =?UTF-8?B?UmU6INCa0LDQuiDQvtGH0LjRgdGC0LjRgtGMINC60Y3RiCBOZ2lueA==?= In-Reply-To: References: Message-ID: <20170104200340.GB19421@laa.zp.ua> Здравствуйте! 1. Попробуйте понять где у вас происходит обработка вашего запроса к стилям. Для этого, как вариант, можно добавить access_log внутри разных location для записи отдельного лог-файла на время тестирования. Так вы поймете в каком location обрабатывается. 2. Далее, когда поймете в каком location -- попробуйте понять КАК именно обрабатывается. Скорее всего внутри try_files. Но! Там может быть отдан статически с диска, если он есть внутри описанного root, или может произойти обработка php-скриптом. Я в вашей конфигурации не вижу кэша у nginx, скорее всего кэшируют ваш файл какие-то php-скрипты. Возможно, nginx не может найти css файл внутри сконфигурированного root. Удачи в поиске решения! From nginx на mva.name Wed Jan 4 20:06:59 2017 From: nginx на mva.name (Vadim A. Misbakh-Soloviov) Date: Thu, 05 Jan 2017 03:06:59 +0700 Subject: =?UTF-8?Q?Re=3A_server=5Fname_=D0=B2_X-Original-URL?= In-Reply-To: References: Message-ID: <2521032.NMJaNRv4xK@note> В письме от среда, 4 января 2017 г. 22:37:01 +07 пользователь Dzmitry Stremkouski написал: > приходит server_name = secure.stremki.net Насколько я знаю, приходит не "server_name", а заголовок. либо HTTP_HOST, либо HTTP_SERVER_NAME, либо ещё какой. И в зависимости от того, какой из них вы проверяете, это может быть и just as planned. Я сейчас по памяти не помню, но какой-то заголовок и в самом деле передаёт первый хост из server_name, а какой-то — реальный хост, на который постучался клиент. From laa на laa.zp.ua Wed Jan 4 20:09:50 2017 From: laa на laa.zp.ua (Lystopad Aleksandr) Date: Wed, 4 Jan 2017 22:09:50 +0200 Subject: =?UTF-8?Q?Re=3A_server=5Fname_=D0=B2_X-Original-URL?= In-Reply-To: References: Message-ID: <20170104200950.GC19421@laa.zp.ua> Hello, Dzmitry Stremkouski! On Wed, Jan 04, 2017 at 10:37:01PM +0300 mitroko на gmail.com wrote about "server_name в X-Original-URL": > Здравствуйте, активно использую auth_request на сервере. > > Использую > server { > listen 443 ssl http2; > listen [::]:443 ssl http2; > server_name secure.stremki.net ssl.stremki.net; > ... > location = /auth { > proxy_set_header X-Original-URL $scheme://$server_name$request_uri; > ... > > и у меня на бекенд авторизации вне зависимости от того, пришёл ли я на > secure или ssl, приходит server_name = secure.stremki.net > > Если имена server_name варьировать, то выбирается первое. А вам не подойдет $host вместо $server_name ? Лишнее туда не попадет по-идее в вашем случае. From mitroko на gmail.com Wed Jan 4 21:03:11 2017 From: mitroko на gmail.com (Dzmitry Stremkouski) Date: Thu, 5 Jan 2017 00:03:11 +0300 Subject: =?UTF-8?Q?Re=3A_server=5Fname_=D0=B2_X-Original-URL?= In-Reply-To: <20170104200950.GC19421@laa.zp.ua> References: <20170104200950.GC19421@laa.zp.ua> Message-ID: Да, думаю, это как раз тот случай $server_name - name of the server which accepted a request $host - in this order of precedence: host name from the request line, or host name from the “Host” request header field, or the server name matching a request $server_name вполне логично может быть первым именем в списке, остальное считается за алиасы. $host подходит. Спасибо! 2017-01-04 23:09 GMT+03:00 Lystopad Aleksandr : > Hello, Dzmitry Stremkouski! > > On Wed, Jan 04, 2017 at 10:37:01PM +0300 > mitroko на gmail.com wrote about "server_name в X-Original-URL": > > Здравствуйте, активно использую auth_request на сервере. > > > > Использую > > server { > > listen 443 ssl http2; > > listen [::]:443 ssl http2; > > server_name secure.stremki.net ssl.stremki.net; > > ... > > location = /auth { > > proxy_set_header X-Original-URL $scheme://$server_name$request_uri; > > ... > > > > и у меня на бекенд авторизации вне зависимости от того, пришёл ли я на > > secure или ssl, приходит server_name = secure.stremki.net > > > > Если имена server_name варьировать, то выбирается первое. > > А вам не подойдет $host вместо $server_name ? Лишнее туда не попадет > по-идее > в вашем случае. > > _______________________________________________ > nginx-ru mailing list > nginx-ru на nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru > -- 
(o_ - Dzmitry Stremkouski.
//\ - cel: +7 (916) 090-85-68
V_/_- web: http://mitroko.com
----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From nginx-forum на forum.nginx.org Wed Jan 4 21:44:00 2017 From: nginx-forum на forum.nginx.org (vitcool) Date: Wed, 04 Jan 2017 16:44:00 -0500 Subject: =?UTF-8?B?UmU6INCa0LDQuiDQvtGH0LjRgdGC0LjRgtGMINC60Y3RiCBOZ2lueA==?= In-Reply-To: References: Message-ID: <1186296910102fee57e7cc6e7ae05f4a.NginxMailingListRussian@forum.nginx.org> а изменение в шаблоне имени файла стилей помогает? например с "../style.css" на "../style.css?v0.0.1" чудес не бывает, либо кеширует nginx (cache или proxy) либо ваш аппликейшен который отдает стили nginx-у Posted at Nginx Forum: https://forum.nginx.org/read.php?21,271820,271831#msg-271831 From nginx-forum на forum.nginx.org Thu Jan 5 03:22:13 2017 From: nginx-forum на forum.nginx.org (den68) Date: Wed, 04 Jan 2017 22:22:13 -0500 Subject: =?UTF-8?Q?Re=3A_proxy_=D0=B8_upstrem?= In-Reply-To: References: Message-ID: <50c8b9c9f9b15477303072de395ad775.NginxMailingListRussian@forum.nginx.org> >судя по симптомам, эту ошибку выдает http.sys на стороне приложения. да, именно так, это я вроде и описал.. >"netsh http show iplisten" покажет список серверных привязок одно НО, это на линуксе под моно. >если вы делаете "proxy_pass http://up-socserver" и при этом у вас закомментирована строчка с заголовком Host, то nginx выставляет Host по имени апстрима. ага, здравая мысль, спасибо! Posted at Nginx Forum: https://forum.nginx.org/read.php?21,271786,271833#msg-271833 From chipitsine на gmail.com Thu Jan 5 14:22:50 2017 From: chipitsine на gmail.com (=?UTF-8?B?0JjQu9GM0Y8g0KjQuNC/0LjRhtC40L0=?=) Date: Thu, 5 Jan 2017 17:22:50 +0300 Subject: =?UTF-8?Q?Re=3A_proxy_=D0=B8_upstrem?= In-Reply-To: <50c8b9c9f9b15477303072de395ad775.NginxMailingListRussian@forum.nginx.org> References: <50c8b9c9f9b15477303072de395ad775.NginxMailingListRussian@forum.nginx.org> Message-ID: Чт, 5 янв. 2017 г. в 8:22, den68 : > >судя по симптомам, эту ошибку выдает http.sys на стороне приложения. > > > > да, именно так, это я вроде и описал.. > в mono нет http.sys, http.sys (он же http-драйвер) это сугубо windows. с ним связаны наиболее частые подземные стуки (например, он может вернуть 400, в то время как до вашего приложения запрос даже не дойдет). > > > >"netsh http show iplisten" покажет список серверных привязок > > одно НО, это на линуксе под моно. > > > > >если вы делаете "proxy_pass http://up-socserver" и при этом у вас > > закомментирована строчка с заголовком Host, то nginx выставляет Host по > > имени апстрима. > > > > ага, здравая мысль, спасибо! > > > > Posted at Nginx Forum: https://forum.nginx.org/read. > php?21,271786,271833#msg-271833 > > > > _______________________________________________ > > nginx-ru mailing list > > nginx-ru на nginx.org > > http://mailman.nginx.org/mailman/listinfo/nginx-ru ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From nginx-forum на forum.nginx.org Thu Jan 5 15:28:51 2017 From: nginx-forum на forum.nginx.org (vaarsn) Date: Thu, 05 Jan 2017 10:28:51 -0500 Subject: =?UTF-8?B?0J7RiNC40LHQutCwOiBvcGVuIHNvY2tldCAjIGxlZnQgaW4gY29ubmVjdGlvbg==?= Message-ID: Имеется Nginx 1.10.0 включающий следующую конфигурацю: ---------------------------------------------------------------------------------------------- user www-data; worker_processes auto; pid /run/nginx.pid; events { worker_connections 1024; multi_accept on; use epoll; } http { sendfile on; tcp_nopush on; tcp_nodelay on; keepalive_timeout 25; types_hash_max_size 2048; server_tokens off; send_timeout 2; reset_timedout_connection on; include /etc/nginx/mime.types; default_type application/octet-stream; access_log off; error_log /var/log/nginx/error.log debug; log_not_found off; ssl_protocols TLSv1 TLSv1.1 TLSv1.2; # Dropping SSLv3, ref: POODLE ssl_prefer_server_ciphers on; gzip on; gzip_disable "msie6"; ---------------------------------------------------------------------------------------------- При рестарте наблюдаю в логах следующую ошибку: 2017/01/05 15:01:35 [alert] 1186#1186: *13388 open socket #15 left in connection 17 2017/01/05 15:01:35 [alert] 1186#1186: *13441 open socket #45 left in connection 22 2017/01/05 15:01:35 [alert] 1186#1186: *13444 open socket #48 left in connection 26 .......................... Включил режим отладки, но толком тоже ничего: 2017/01/05 15:18:17 [debug] 1566#1566: epoll del event: fd:6 op:2 ev:00000000 2017/01/05 15:18:17 [debug] 1566#1566: epoll del event: fd:8 op:2 ev:00000000 2017/01/05 15:18:43 [debug] 1565#1565: post event 0000561F259CD460 2017/01/05 15:18:43 [debug] 1565#1565: delete posted event 0000561F259CD460 2017/01/05 15:18:43 [debug] 1565#1565: accept on 0.0.0.0:80, ready: 1 2017/01/05 15:18:43 [debug] 1565#1565: posix_memalign: 0000561F25A59750:512 @16 2017/01/05 15:18:43 [debug] 1565#1565: *5055 accept: 40.77.167.4:11355 fd:36 2017/01/05 15:18:43 [debug] 1565#1565: *5055 event timer add: 36: 60000:1483629583790 2017/01/05 15:18:43 [debug] 1565#1565: *5055 reusable connection: 1 2017/01/05 15:18:43 [debug] 1565#1565: *5055 epoll add event: fd:36 op:1 ev:80002001 2017/01/05 15:18:43 [debug] 1565#1565: accept() not ready (11: Resource temporarily unavailable) 2017/01/05 15:18:43 [debug] 1565#1565: *5055 post event 0000561F259CDD60 2017/01/05 15:18:43 [debug] 1565#1565: *5055 delete posted event 0000561F259CDD60 2017/01/05 15:18:43 [debug] 1565#1565: *5055 http wait request handler 2017/01/05 15:18:43 [debug] 1565#1565: *5055 malloc: 0000561F25A79AC0:1024 2017/01/05 15:18:43 [debug] 1565#1565: *5055 recv: fd:36 242 of 1024 2017/01/05 15:18:43 [debug] 1565#1565: *5055 reusable connection: 0 2017/01/05 15:18:43 [debug] 1565#1565: *5055 posix_memalign: 0000561F25A4A620:4096 @16 2017/01/05 15:18:43 [debug] 1565#1565: *5055 http process request line 2017/01/05 15:18:43 [debug] 1565#1565: *5055 http request line: "GET /robots.txt HTTP/1.1" 2017/01/05 15:18:43 [debug] 1565#1565: *5055 http uri: "/robots.txt" 2017/01/05 15:18:43 [debug] 1565#1565: *5055 http args: "" 2017/01/05 15:18:43 [debug] 1565#1565: *5055 http exten: "txt" 2017/01/05 15:18:43 [debug] 1565#1565: *5055 http process request header line 2017/01/05 15:18:43 [debug] 1565#1565: *5055 http header: "Cache-Control: no-cache" 2017/01/05 15:18:43 [debug] 1565#1565: *5055 http header: "Connection: Keep-Alive" 2017/01/05 15:18:43 [debug] 1565#1565: *5055 http header: "Pragma: no-cache" 2017/01/05 15:18:43 [debug] 1565#1565: *5055 http header: "Accept: */*" 2017/01/05 15:18:43 [debug] 1565#1565: *5055 http header: "Accept-Encoding: gzip, deflate" 2017/01/05 15:18:44 [debug] 1566#1566: epoll add event: fd:6 op:1 ev:00002001 2017/01/05 15:18:44 [debug] 1566#1566: epoll add event: fd:8 op:1 ev:00002001 2017/01/05 15:18:44 [debug] 1565#1565: epoll del event: fd:6 op:2 ev:00000000 2017/01/05 15:18:44 [debug] 1565#1565: epoll del event: fd:8 op:2 ev:00000000 Вроде все работает, как и должно. Системные лимиты увеличил\снял: root на thumborsrv:~# ulimit -n 64000 Добавил в /etc/sysctl.conf: net.ipv4.tcp_tw_reuse=1 net.ipv4.tcp_tw_recycle=1 Параметры единственного виртуалхоста, который задействован на сервере: upstream thumbor { server 127.0.0.1:8000; server 127.0.0.1:8001; server 127.0.0.1:8002; server 127.0.0.1:8003; keepalive 512; } server { listen 80; listen 443; server_name img.server.com; keepalive_timeout 10; add_header Strict-Transport-Security "max-age=63072000; includeSubdomains; preload"; add_header X-Frame-Options "DENY"; ssl_session_cache builtin:1000 shared:SSL:10m; # block if specific token in header is not there for port 80 # but allow requests from port 8080 set $block_by_header 0; if ($server_port = '80') { set $block_by_header 1; } set $header_ok 0; if ($http_x_cf_secret = 'd41d8cd-98f00b2-04e980099-8ecf8427e') { set $header_ok 1; } set $block_key $block_by_header$header_ok; if ($block_key = "10") { return 418; } client_max_body_size 50M; error_log /var/log/nginx/thumbor-error.log; # SSL certificates to use on secure connections ssl on; ssl_protocols TLSv1 TLSv1.1 TLSv1.2; ssl_ciphers EECDH+AESGCM:EDH+AESGCM:AES256+EECDH:AES256+EDH; ssl_certificate /etc/nginx/ssl/img.server.com.crt; ssl_certificate_key /etc/nginx/ssl/img.server.com.key; ssl_dhparam /etc/nginx/ssl/dhparam.pem; ssl_prefer_server_ciphers on; # Forward requests to thumbor. location / { proxy_pass http://thumbor; proxy_read_timeout 300; proxy_connect_timeout 300; # Default is HTTP/1, keepalive is only enabled in HTTP/1.1 proxy_http_version 1.1; } } В логе самой тулзы вижу следующее: [error] 1189#1189: *24 no live upstreams while connecting to upstream, client: 41.182.178.150 И таких ошибок много. Помогите пожалуйста найти корень проблемы и устранить его. Posted at Nginx Forum: https://forum.nginx.org/read.php?21,271840,271840#msg-271840 From nginx-forum на forum.nginx.org Fri Jan 6 02:15:06 2017 From: nginx-forum на forum.nginx.org (den68) Date: Thu, 05 Jan 2017 21:15:06 -0500 Subject: =?UTF-8?Q?Re=3A_proxy_=D0=B8_upstrem?= In-Reply-To: References: Message-ID: Илья Шипицин Wrote: ------------------------------------------------------- > в mono нет http.sys, http.sys (он же http-драйвер) это сугубо windows. > с ним связаны наиболее частые подземные стуки (например, он может > вернуть 400, в то время как до вашего приложения запрос даже не дойдет). > да, конечно, но там его функциональный заменитель с теми же симптомами. в детали я не углублялся, но работают они схоже.. стак трейс только под моно работает странно, остальное вроде одинаково. Posted at Nginx Forum: https://forum.nginx.org/read.php?21,271786,271841#msg-271841 From nginx-forum на forum.nginx.org Fri Jan 6 16:21:14 2017 From: nginx-forum на forum.nginx.org (Seriyyy95) Date: Fri, 06 Jan 2017 11:21:14 -0500 Subject: =?UTF-8?B?UmU6INCa0LDQuiDQvtGH0LjRgdGC0LjRgtGMINC60Y3RiCBOZ2lueA==?= In-Reply-To: <20170104200340.GB19421@laa.zp.ua> References: <20170104200340.GB19421@laa.zp.ua> Message-ID: <092e17ebda8b60608a1f24bc39697abb.NginxMailingListRussian@forum.nginx.org> Так и не смог разобраться. Стиль обрабатывается здесь: location ~ \.(css|htc|less|js|js2|js3|js4)$ { access_log /var/log/nginx/access_css.log; expires -1s; add_header Pragma "public"; add_header Cache-Control "max-age=-1, public"; add_header X-Powered-By "W3 Total Cache/0.9.5.1"; try_files $uri $uri/ $uri.html /index.php?$args; } Если добавить access log, то все стили исправно пишутся в лог файл. Дальше php обрабатывается здесь: location @php { access_log /var/log/nginx/access_css3.log; fastcgi_index index.php; fastcgi_param PHP_ADMIN_VALUE "sendmail_path = /usr/sbin/sendmail -t -i -f admin на losst.ru"; fastcgi_pass unix:/var/www/php-fpm/losst.sock; fastcgi_split_path_info ^((?U).+\.ph(?:p\d*|tml))(/?.+)$; try_files $uri =404; include fastcgi_params; } Причем в получившемся логе строк к запросами к css нет. Значит PHP не кэширует? Тогда кто? Я не понимаю. В первый раз я не прикрепил главный конфиг /etc/nginx/nginx.conf. Может в нем дело: user apache; worker_processes 1; error_log /var/log/nginx/error.log warn; pid /var/run/nginx.pid; events { worker_connections 1024; } http { include /etc/nginx/mime.types; default_type application/octet-stream; log_format main '$remote_addr - $remote_user [$time_local] "$request" ' '$status $body_bytes_sent "$http_referer" ' '"$http_user_agent" "$http_x_forwarded_for"'; access_log /var/log/nginx/access.log main; sendfile on; #tcp_nopush on; keepalive_timeout 65; #gzip on; gzip on; gzip_min_length 1100; gzip_buffers 4 32k; gzip_vary on; gzip_types text/css text/plain application/json application/x-javascript text/xml application/xml application/xml+rss text/javascript application/javascript text/x-js; gzip_proxied any; include /etc/nginx/conf.d/*.conf; include /etc/nginx/vhosts/*/*.conf; server { server_name localhost; disable_symlinks if_not_owner; listen 80; include /etc/nginx/vhosts-includes/*.conf; location @fallback { error_log /dev/null crit; proxy_pass http://127.0.0.1:8080; proxy_redirect http://127.0.0.1:8080 /; proxy_set_header Host $host; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_set_header X-Forwarded-Proto $scheme; access_log /var/log/nginx/access_proxy.log ; } } client_max_body_size 128m; } Лог access_proxy пуст. Posted at Nginx Forum: https://forum.nginx.org/read.php?21,271820,271848#msg-271848 From nginx-ru на sadok.spb.ru Fri Jan 6 16:59:39 2017 From: nginx-ru на sadok.spb.ru (Dmitry Ivanov) Date: Fri, 6 Jan 2017 19:59:39 +0300 Subject: =?UTF-8?B?UmU6INCa0LDQuiDQvtGH0LjRgdGC0LjRgtGMINC60Y3RiCBOZ2lueA==?= In-Reply-To: <092e17ebda8b60608a1f24bc39697abb.NginxMailingListRussian@forum.nginx.org> References: <20170104200340.GB19421@laa.zp.ua> <092e17ebda8b60608a1f24bc39697abb.NginxMailingListRussian@forum.nginx.org> Message-ID: <599790203.20170106195939@sadok.spb.ru> Здравствуйте, Seriyyy95. Вы писали 6 января 2017 г., 19:21:14: > Так и не смог разобраться. Стиль обрабатывается здесь: Меня терзают сомнения смутные. Там целый чемодан инклюдов в конфиге, нам не показанный. -- С уважением, Dmitry nginx-ru на sadok.spb.ru From nginx-forum на forum.nginx.org Sat Jan 7 12:19:51 2017 From: nginx-forum на forum.nginx.org (Seriyyy95) Date: Sat, 07 Jan 2017 07:19:51 -0500 Subject: =?UTF-8?B?UmU6INCa0LDQuiDQvtGH0LjRgdGC0LjRgtGMINC60Y3RiCBOZ2lueA==?= In-Reply-To: <1186296910102fee57e7cc6e7ae05f4a.NginxMailingListRussian@forum.nginx.org> References: <1186296910102fee57e7cc6e7ae05f4a.NginxMailingListRussian@forum.nginx.org> Message-ID: <3b7febd4f7d8e8c8ecc1db886fd0d8f9.NginxMailingListRussian@forum.nginx.org> Изменение версии не помогает. В других инклудах ничего нет связанного с прокси нет. /etc/nginx/conf.d/ содержит пустой файл default.conf, что касается /etc/nginx/vhosts-includes, то вот они: location /afterlogic/ { alias /usr/local/mgr5/www/webmail-afterlogic/webmail/; index index.php; error_page 404 @apache; } location ~ ^/afterlogic/(.+\.php)$ { alias /usr/local/mgr5/www/webmail-afterlogic/webmail/$1; fastcgi_pass unix:/var/run/php-fpm.apache.sock; fastcgi_index index.php; fastcgi_param SCRIPT_FILENAME $request_filename; include fastcgi_params; error_page 502 = @apache; error_page 404 = @apache; } location @apache { error_log /dev/null crit; proxy_pass http://127.0.0.1:8080; proxy_redirect http://127.0.0.1:8080 /; proxy_set_header Host $host; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_set_header X-Forwarded-Proto $scheme; } location @blacklist { proxy_redirect off ; proxy_pass https://194.67.215.125:1500; rewrite (.*) /mancgi/ddos break; proxy_set_header Host $host; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_set_header X-Forwarded-Proto $scheme; proxy_set_header X_ISP_FIREWALLSEC строка; } location /phpmyadmin { alias /usr/share/phpMyAdmin; index index.php; } location ~* ^/phpmyadmin/(.+\.(jpg|jpeg|gif|css|png|js|ico|html|xml|txt))$ { alias /usr/share/phpMyAdmin/$1; error_page 404 @apache; } location ~ ^/phpmyadmin/(.+\.php)$ { alias /usr/share/phpMyAdmin/$1; fastcgi_pass unix:/var/run/php-fpm.apache.sock; fastcgi_index index.php; fastcgi_param SCRIPT_FILENAME $request_filename; include fastcgi_params; error_page 502 = @apache; error_page 404 = @apache; } location @apache { error_log /dev/null crit; proxy_pass http://127.0.0.1:8080; proxy_redirect http://127.0.0.1:8080 /; proxy_set_header Host $host; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_set_header X-Forwarded-Proto $scheme; } location ^~ /phpmyadmin/setup { deny all; } Но css обрабатывается в файле /var/www/losst/data/www/losst.ru/nginx.conf: location ~ \.(css|htc|less|js|js2|js3|js4)$ { access_log /var/log/nginx/access_css.log; expires -1s; add_header Pragma "public"; add_header Cache-Control "max-age=-1, public"; add_header X-Powered-By "W3 Total Cache/0.9.5.1"; try_files $uri $uri/ $uri.html /index.php?$args; } Даже строка try_files $uri =404; выдает старую версию файла (файл же берется из диска?). Но если заменить $url на что-то не существующее, то получаем 404, например try_files $uri/foobar =404; Файл возвращается при отключенном php, и apache. Posted at Nginx Forum: https://forum.nginx.org/read.php?21,271820,271854#msg-271854 From laa на laa.zp.ua Sat Jan 7 17:18:40 2017 From: laa на laa.zp.ua (Lystopad Aleksandr) Date: Sat, 7 Jan 2017 19:18:40 +0200 Subject: =?UTF-8?B?UmU6INCa0LDQuiDQvtGH0LjRgdGC0LjRgtGMINC60Y3RiCBOZ2lueA==?= In-Reply-To: <092e17ebda8b60608a1f24bc39697abb.NginxMailingListRussian@forum.nginx.org> References: <20170104200340.GB19421@laa.zp.ua> <092e17ebda8b60608a1f24bc39697abb.NginxMailingListRussian@forum.nginx.org> Message-ID: <20170107171840.GD19421@laa.zp.ua> Hello, Seriyyy95! On Fri, Jan 06, 2017 at 11:21:14AM -0500 nginx-forum на forum.nginx.org wrote about "Re: Как очистить кэш Nginx": > Так и не смог разобраться. Стиль обрабатывается здесь: > > location ~ \.(css|htc|less|js|js2|js3|js4)$ { > access_log /var/log/nginx/access_css.log; > expires -1s; > add_header Pragma "public"; > add_header Cache-Control "max-age=-1, public"; > add_header X-Powered-By "W3 Total Cache/0.9.5.1"; > try_files $uri $uri/ $uri.html /index.php?$args; > } Погодите, стиль обрабатывается тут, но каким образом? У вас try_files с несколькими вариантами поиска. Какой из них срабатывает? Чтобы разобраться, вы можете добавить $document_root в вывод лога (log_format) и делать тестовые запросы к стилю и смотреть. Добавить можно и еще других переменных в вывод лога, они помогут вам. Также, можете включить дебаг в error_log для отдельного location и разбираться в нем что происходит для вашего проблемного стиля. В идеале, ваш стиль должен отдаваться просто с диска, так правильно и быстро. Но, возможно, он отдается пхп-скриптом. Я почти уверен, что проблема в WP total cache . > Если добавить access log, то все стили исправно пишутся в лог файл. Дальше > php обрабатывается здесь: > > location @php { > access_log /var/log/nginx/access_css3.log; > > fastcgi_index index.php; > fastcgi_param PHP_ADMIN_VALUE "sendmail_path = > /usr/sbin/sendmail -t -i -f admin на losst.ru"; > fastcgi_pass unix:/var/www/php-fpm/losst.sock; > fastcgi_split_path_info ^((?U).+\.ph(?:p\d*|tml))(/?.+)$; > try_files $uri =404; > include fastcgi_params; > } > > Причем в получившемся логе строк к запросами к css нет. Значит PHP не > кэширует? Тогда кто? Я не понимаю. В первый раз я не прикрепил главный > конфиг /etc/nginx/nginx.conf. Может в нем дело: > > > user apache; > worker_processes 1; > > error_log /var/log/nginx/error.log warn; > pid /var/run/nginx.pid; > > > events { > worker_connections 1024; > } > > > http { > include /etc/nginx/mime.types; > default_type application/octet-stream; > > log_format main '$remote_addr - $remote_user [$time_local] "$request" > ' > '$status $body_bytes_sent "$http_referer" ' > '"$http_user_agent" "$http_x_forwarded_for"'; > > access_log /var/log/nginx/access.log main; > > sendfile on; > #tcp_nopush on; > > keepalive_timeout 65; > > #gzip on; > > gzip on; > gzip_min_length 1100; > gzip_buffers 4 32k; > gzip_vary on; > gzip_types text/css text/plain application/json > application/x-javascript text/xml application/xml application/xml+rss > text/javascript application/javascript text/x-js; > gzip_proxied any; > include /etc/nginx/conf.d/*.conf; > include /etc/nginx/vhosts/*/*.conf; > server { > server_name localhost; > disable_symlinks if_not_owner; > listen 80; > include /etc/nginx/vhosts-includes/*.conf; > location @fallback { > error_log /dev/null crit; > proxy_pass http://127.0.0.1:8080; > proxy_redirect http://127.0.0.1:8080 /; > proxy_set_header Host $host; > proxy_set_header X-Forwarded-For > $proxy_add_x_forwarded_for; > proxy_set_header X-Forwarded-Proto $scheme; > access_log /var/log/nginx/access_proxy.log ; > } > } > client_max_body_size 128m; > } > > Лог access_proxy пуст. Значит в location @fallback не попадают запросы. По поводу кучи разных инклудов советую почитать что об этом думает автор nginx Игорь Сысоев: https://habrahabr.ru/company/oleg-bunin/blog/313666/ Еще раз, вам лучше добиться того, чтобы статический объект отдавался простым чтением с диска, а не в результате обработки скрипта. Попробуйте сделать как-то так и посмотреть результат: location = /style.css { root /directory/with/style; expires -1; access_log /log-dir/my-test.log; } Удачи. From nginx-forum на forum.nginx.org Sun Jan 8 10:42:02 2017 From: nginx-forum на forum.nginx.org (Seriyyy95) Date: Sun, 08 Jan 2017 05:42:02 -0500 Subject: =?UTF-8?B?UmU6INCa0LDQuiDQvtGH0LjRgdGC0LjRgtGMINC60Y3RiCBOZ2lueA==?= In-Reply-To: <20170107171840.GD19421@laa.zp.ua> References: <20170107171840.GD19421@laa.zp.ua> Message-ID: <79494bdd667110a440667fd8afab98ce.NginxMailingListRussian@forum.nginx.org> Сделал так, как вы сказали: location = /style.css { root /var/www/losst/data/www/losst.ru/wp-content/themes/themes/arcade-basic-child/; expires -1; access_log /var/log/nginx/access_css_exclude.log css; } Вот что в логе: 37.52.110.246 - - [08/Jan/2017:13:34:30 +0300] "GET /style.css HTTP/1.1" 200 9991 "-" "Wget/1.14 (linux-gnu)" "/var/www/losst/data/www/losst.ru/wp-content/themes/themes/arcade-basic-child" "/style.css" "" "/style.css" "-" "-" "37.52.110.246" "/var/www/losst/data/www/losst.ru/wp-content/themes/themes/arcade-basic-child" Возвращается старая версия. Из этого можно сделать вывод что wordpress вообще не причем. Это было ясно еще тогда, когда я отключал php и тоже возвращался старый файл. Как бы он его возвратил без php? Вот еще лог для версии location по умолчанию: 178.65.1.134 - - [08/Jan/2017:13:19:58 +0300] "GET /wp-content/themes/themes/arcade-basic/style.css HTTP/1.1" 200 28748 "https://losst.ru/wp-content/themes/themes/arcade-basic-child/style.css?x29372" "Mozilla/5.0 (X11; Linux i686; rv:45.0) Gecko/20100101 Firefox/45.0" "/var/www/losst/data/www/losst.ru" "/wp-content/themes/themes/arcade-basic/style.css" "" "/wp-content/themes/themes/arcade-basic/style.css" "-" "-" "178.65.1.134" "/var/www/losst/data/www/losst.ru" Формат лога: log_format css '$remote_addr - $remote_user [$time_local] ' '"$request" $status $body_bytes_sent ' '"$http_referer" "$http_user_agent" ' '"$document_root" "$document_uri" ' '"$fastcgi_path_info" "$fastcgi_script_name" ' '"$proxy_host" ' '"$proxy_host" "$proxy_add_x_forwarded_for" ' '"$realpath_root"'; Приложение не при чем. На сервере установлен memcached. Может nginx его подхватывает как-то? Или там еще один кэш? Где и как очистить? Posted at Nginx Forum: https://forum.nginx.org/read.php?21,271820,271859#msg-271859 From laa на laa.zp.ua Sun Jan 8 13:06:54 2017 From: laa на laa.zp.ua (Lystopad Aleksandr) Date: Sun, 8 Jan 2017 15:06:54 +0200 Subject: =?UTF-8?B?UmU6INCa0LDQuiDQvtGH0LjRgdGC0LjRgtGMINC60Y3RiCBOZ2lueA==?= In-Reply-To: <79494bdd667110a440667fd8afab98ce.NginxMailingListRussian@forum.nginx.org> References: <20170107171840.GD19421@laa.zp.ua> <79494bdd667110a440667fd8afab98ce.NginxMailingListRussian@forum.nginx.org> Message-ID: <20170108130654.GA53324@laa.zp.ua> Hello, Seriyyy95! On Sun, Jan 08, 2017 at 05:42:02AM -0500 nginx-forum на forum.nginx.org wrote about "Re: Как очистить кэш Nginx": > Сделал так, как вы сказали: > > location = /style.css { > root > /var/www/losst/data/www/losst.ru/wp-content/themes/themes/arcade-basic-child/; > expires -1; > access_log /var/log/nginx/access_css_exclude.log css; > } > > Вот что в логе: > > 37.52.110.246 - - [08/Jan/2017:13:34:30 +0300] "GET /style.css HTTP/1.1" 200 > 9991 "-" "Wget/1.14 (linux-gnu)" > "/var/www/losst/data/www/losst.ru/wp-content/themes/themes/arcade-basic-child" > "/style.css" "" "/style.css" "-" "-" "37.52.110.246" > "/var/www/losst/data/www/losst.ru/wp-content/themes/themes/arcade-basic-child" > > Возвращается старая версия. Из этого можно сделать вывод что wordpress Стоп, а сам файл новый в этой директории? > вообще не причем. Это было ясно еще тогда, когда я отключал php и тоже > возвращался старый файл. Как бы он его возвратил без php? Вот еще лог для > версии location по умолчанию: > 178.65.1.134 - - [08/Jan/2017:13:19:58 +0300] "GET > /wp-content/themes/themes/arcade-basic/style.css HTTP/1.1" 200 28748 > "https://losst.ru/wp-content/themes/themes/arcade-basic-child/style.css?x29372" > "Mozilla/5.0 (X11; Linux i686; rv:45.0) Gecko/20100101 Firefox/45.0" > "/var/www/losst/data/www/losst.ru" > "/wp-content/themes/themes/arcade-basic/style.css" "" > "/wp-content/themes/themes/arcade-basic/style.css" "-" "-" "178.65.1.134" > "/var/www/losst/data/www/losst.ru" Вы понимаете, что у вас разные location будут обрабатывать два разных запроса: GET /style.css HTTP/1.1 GET /wp-content/themes/themes/arcade-basic/style.css HTTP/1.1 ? From nginx-forum на forum.nginx.org Sun Jan 8 13:33:12 2017 From: nginx-forum на forum.nginx.org (Seriyyy95) Date: Sun, 08 Jan 2017 08:33:12 -0500 Subject: =?UTF-8?B?UmU6INCa0LDQuiDQvtGH0LjRgdGC0LjRgtGMINC60Y3RiCBOZ2lueA==?= In-Reply-To: <20170108130654.GA53324@laa.zp.ua> References: <20170108130654.GA53324@laa.zp.ua> Message-ID: Да, новый файл в директории. И в текстовом редакторе все в порядке. Location то разные, и запросы разные. А файл один и тот же, и результат один и тот же. Posted at Nginx Forum: https://forum.nginx.org/read.php?21,271820,271861#msg-271861 From nginx-forum на forum.nginx.org Sun Jan 8 15:17:52 2017 From: nginx-forum на forum.nginx.org (Seriyyy95) Date: Sun, 08 Jan 2017 10:17:52 -0500 Subject: =?UTF-8?B?UmU6INCa0LDQuiDQvtGH0LjRgdGC0LjRgtGMINC60Y3RiCBOZ2lueA==?= In-Reply-To: References: <20170108130654.GA53324@laa.zp.ua> Message-ID: <5a10956886bc8de21b8a87180f0730d4.NginxMailingListRussian@forum.nginx.org> Если в этой же директории создать еще один файл style.css_1 и попытаться запросить его через интернет, то программа говорит, что его там нет. Posted at Nginx Forum: https://forum.nginx.org/read.php?21,271820,271863#msg-271863 From a.vasilishin на kpi.ua Sun Jan 8 16:19:47 2017 From: a.vasilishin на kpi.ua (=?UTF-8?B?0JDQvdC00YDQtdC5INCS0LDRgdC40LvQuNGI0LjQvQ==?=) Date: Sun, 8 Jan 2017 18:19:47 +0200 Subject: =?UTF-8?B?bmdpbngg0Lgg0YHRgtCw0YLQuNGH0LXRgdC60LjQuSBobHMsINGB0YLRgNCw0L0=?= =?UTF-8?B?0L3Ri9C1INC/0LDQtNC10L3QuNGPINGB0LrQvtGA0L7RgdGC0Lg=?= Message-ID: <0c010804-f2eb-4be6-e377-f1fab5113d2a@kpi.ua> Есть странная проблема, нгинкс после определенного времени начинает медленно отдавать сегменты hls, которые являются статикой на диске (4хSSD Kingston SH103S3 LVM ext4) при этом резко возрастает writing и падает waiting. https://i.gyazo.com/b4f7745c2fdf0ef63614684fa91177af.png В логах в это время пусто, при релоаде нгинкс, все снова стает в порядке до определенного момента, который может быть как через 5 минут, так и через пару часов. Что это может быть? # nginx -V nginx version: nginx/1.11.8 built by gcc 4.7.2 (Debian 4.7.2-5) built with OpenSSL 1.0.1t 3 May 2016 TLS SNI support enabled configure arguments: --prefix=/etc/nginx --sbin-path=/usr/sbin/nginx --modules-path=/usr/lib/nginx/modules --conf-path=/etc/nginx/nginx.conf --error-log-path=/var/log/nginx/error.log --http-log-path=/var/log/nginx/access.log --pid-path=/var/run/nginx.pid --lock-path=/var/run/nginx.lock --http-client-body-temp-path=/var/cache/nginx/client_temp --http-proxy-temp-path=/var/cache/nginx/proxy_temp --http-fastcgi-temp-path=/var/cache/nginx/fastcgi_temp --http-uwsgi-temp-path=/var/cache/nginx/uwsgi_temp --http-scgi-temp-path=/var/cache/nginx/scgi_temp --user=nginx --group=nginx --with-compat --with-file-aio --with-threads --with-http_addition_module --with-http_auth_request_module --with-http_dav_module --with-http_flv_module --with-http_gunzip_module --with-http_gzip_static_module --with-http_mp4_module --with-http_random_index_module --with-http_realip_module --with-http_secure_link_module --with-http_slice_module --with-http_ssl_module --with-http_stub_status_module --with-http_sub_module --with-http_v2_module --with-mail --with-mail_ssl_module --with-stream --with-stream_realip_module --with-stream_ssl_module --with-stream_ssl_preread_module --with-cc-opt='-g -O2 -fstack-protector --param=ssp-buffer-size=4 -Wformat -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2' --with-ld-opt='-Wl,-z,relro -Wl,-z,now -Wl,--as-needed' user stream; worker_processes 32; worker_rlimit_nofile 65535; error_log /var/log/nginx/error.log warn; pid /var/run/nginx.pid; events { use epoll; worker_connections 65535; multi_accept on; } http { include /etc/nginx/mime.types; default_type application/octet-stream; server_tokens off; access_log off; sendfile off; tcp_nopush on; tcp_nodelay on; keepalive_timeout 30; reset_timedout_connection on; output_buffers 1 1M; log_format IP '[$time_local] $http_referer $request $remote_addr'; upstream php { server 127.0.0.1:9000; } server { listen 80; server_name site.com; charset utf8; access_log off; root /home/stream/www; rewrite ^/stream/(\d+)$ /player/stream.php?id=$1 last; location ~ \.php$ { fastcgi_index index.php; fastcgi_pass php; include fastcgi_params; fastcgi_read_timeout 300; } valid_referers none blocked server_names site.tv site.net 1.1.1.1; location ~* \.(m3u8|ts)$ { if ($invalid_referer) { return 403; access_log /var/log/nginx/referer.log IP; } sendfile on; sendfile_max_chunk 512k; output_buffers 1 128k; } location = /nginx_status { stub_status on; } } } From laa на laa.zp.ua Sun Jan 8 16:53:23 2017 From: laa на laa.zp.ua (Lystopad Aleksandr) Date: Sun, 8 Jan 2017 18:53:23 +0200 Subject: =?UTF-8?B?UmU6INCa0LDQuiDQvtGH0LjRgdGC0LjRgtGMINC60Y3RiCBOZ2lueA==?= In-Reply-To: <5a10956886bc8de21b8a87180f0730d4.NginxMailingListRussian@forum.nginx.org> References: <20170108130654.GA53324@laa.zp.ua> <5a10956886bc8de21b8a87180f0730d4.NginxMailingListRussian@forum.nginx.org> Message-ID: <20170108165323.GB53324@laa.zp.ua> Hello, Seriyyy95! On Sun, Jan 08, 2017 at 10:17:52AM -0500 nginx-forum на forum.nginx.org wrote about "Re: Как очистить кэш Nginx": > Если в этой же директории создать еще один файл style.css_1 и попытаться > запросить его через интернет, то программа говорит, что его там нет. А какой location его обработал? From vbart на nginx.com Mon Jan 9 13:26:59 2017 From: vbart на nginx.com (=?utf-8?B?0JLQsNC70LXQvdGC0LjQvSDQkdCw0YDRgtC10L3QtdCy?=) Date: Mon, 09 Jan 2017 16:26:59 +0300 Subject: =?UTF-8?B?UmU6INCe0YjQuNCx0LrQsDogb3BlbiBzb2NrZXQgIyBsZWZ0IGluIGNvbm5lY3Rp?= =?UTF-8?B?b24=?= In-Reply-To: References: Message-ID: <2964042.fBicP6c9Wy@vbart-laptop> On Thursday 05 January 2017 10:28:51 vaarsn wrote: [..] > 2017/01/05 15:18:43 [debug] 1565#1565: post event 0000561F259CD460 > 2017/01/05 15:18:43 [debug] 1565#1565: delete posted event 0000561F259CD460 > 2017/01/05 15:18:43 [debug] 1565#1565: accept on 0.0.0.0:80, ready: 1 > 2017/01/05 15:18:43 [debug] 1565#1565: posix_memalign: 0000561F25A59750:512 > @16 > 2017/01/05 15:18:43 [debug] 1565#1565: *5055 accept: 40.77.167.4:11355 > fd:36 > 2017/01/05 15:18:43 [debug] 1565#1565: *5055 event timer add: 36: > 60000:1483629583790 > 2017/01/05 15:18:43 [debug] 1565#1565: *5055 reusable connection: 1 > 2017/01/05 15:18:43 [debug] 1565#1565: *5055 epoll add event: fd:36 op:1 > ev:80002001 > 2017/01/05 15:18:43 [debug] 1565#1565: accept() not ready (11: Resource > temporarily unavailable) > 2017/01/05 15:18:43 [debug] 1565#1565: *5055 post event 0000561F259CDD60 > 2017/01/05 15:18:43 [debug] 1565#1565: *5055 delete posted event > 0000561F259CDD60 > 2017/01/05 15:18:43 [debug] 1565#1565: *5055 http wait request handler > 2017/01/05 15:18:43 [debug] 1565#1565: *5055 malloc: 0000561F25A79AC0:1024 > 2017/01/05 15:18:43 [debug] 1565#1565: *5055 recv: fd:36 242 of 1024 > 2017/01/05 15:18:43 [debug] 1565#1565: *5055 reusable connection: 0 > 2017/01/05 15:18:43 [debug] 1565#1565: *5055 posix_memalign: > 0000561F25A4A620:4096 @16 > 2017/01/05 15:18:43 [debug] 1565#1565: *5055 http process request line [..] Судя по логу, соединение принято на 80 порту без SSL. [..] > server { > listen 80; > listen 443; [..] > ssl on; [..] Судя по конфигурации, у вас SSL включен на обоих портах в данном блоке server. В совокупности это позволяет предположить, что у вас это не единственный сервер, как вы пишите. Или вообще загружена не та конфигурация, что была показана. -- Валентин Бартенев From vbart на nginx.com Mon Jan 9 13:32:39 2017 From: vbart на nginx.com (=?utf-8?B?0JLQsNC70LXQvdGC0LjQvSDQkdCw0YDRgtC10L3QtdCy?=) Date: Mon, 09 Jan 2017 16:32:39 +0300 Subject: =?UTF-8?B?UmU6INC60L7Qu9C40YfQtdGB0YLQstC+IG9wZW4gc29ja2V0cw==?= In-Reply-To: References: Message-ID: <2071721.PtxWHHSfeL@vbart-laptop> On Thursday 29 December 2016 09:47:53 Иван Мишин wrote: > Есть несколько одинаковых nginx, обслуживающих около 100 хостов. На каждом > nginx используется кеш ramfs объемом 30Гб на каждый nginx. Последнее > несколько недель по непонятным причинам постоянно растет количество > opensockets. Причем даже в ненагруженные дни рост все равно есть. Пробовал > рестартовать ngnix, но opnesockets по прежнему растет. В чем может быть > проблема? На что обратить внимание? Обратить внимание на логи, на версию nginx, на используемые сторонние модули и конфигурацию. Ошибки, приводящие к утечки сокетов, время от времени случаются и исправляются. -- Валентин Бартенев From mdounin на mdounin.ru Mon Jan 9 15:30:30 2017 From: mdounin на mdounin.ru (Maxim Dounin) Date: Mon, 9 Jan 2017 18:30:30 +0300 Subject: =?UTF-8?B?UmU6IG5naW54INC4INGB0YLQsNGC0LjRh9C10YHQutC40LkgaGxzLCDRgdGC0YA=?= =?UTF-8?B?0LDQvdC90YvQtSDQv9Cw0LTQtdC90LjRjyDRgdC60L7RgNC+0YHRgtC4?= In-Reply-To: <0c010804-f2eb-4be6-e377-f1fab5113d2a@kpi.ua> References: <0c010804-f2eb-4be6-e377-f1fab5113d2a@kpi.ua> Message-ID: <20170109153030.GB1761@mdounin.ru> Hello! On Sun, Jan 08, 2017 at 06:19:47PM +0200, Андрей Василишин wrote: > Есть странная проблема, нгинкс после определенного времени начинает > медленно отдавать сегменты hls, которые являются статикой на диске > (4хSSD Kingston SH103S3 LVM ext4) при этом резко возрастает writing и > падает waiting. > > https://i.gyazo.com/b4f7745c2fdf0ef63614684fa91177af.png > > > В логах в это время пусто, при релоаде нгинкс, все снова стает в порядке > до определенного момента, который может быть как через 5 минут, так и > через пару часов. > Что это может быть? Судя по графикам - вы в канал упираетесь. -- Maxim Dounin http://nginx.org/ From a.vasilishin на kpi.ua Mon Jan 9 16:23:06 2017 From: a.vasilishin на kpi.ua (=?UTF-8?B?0JDQvdC00YDQtdC5INCS0LDRgdC40LvQuNGI0LjQvQ==?=) Date: Mon, 9 Jan 2017 18:23:06 +0200 Subject: =?UTF-8?B?UmU6IG5naW54INC4INGB0YLQsNGC0LjRh9C10YHQutC40LkgaGxzLCDRgdGC0YA=?= =?UTF-8?B?0LDQvdC90YvQtSDQv9Cw0LTQtdC90LjRjyDRgdC60L7RgNC+0YHRgtC4?= In-Reply-To: <20170109153030.GB1761@mdounin.ru> References: <0c010804-f2eb-4be6-e377-f1fab5113d2a@kpi.ua> <20170109153030.GB1761@mdounin.ru> Message-ID: <57241bbe-667c-da73-06af-93ef6e775f16@kpi.ua> > > Судя по графикам - вы в канал упираетесь. > Та вроде как нет, во всяком случае на аплинке еще запас не менее 5 гбит/с есть и потерь не наблюдается. Но вот почему так резко обрубает и при релоаде становится все нормально? Как временный костыль - релоад нгинкс раз в 15 минут по крону. Последние сутки график уже выглядит так: https://i.gyazo.com/24f12765b1f6cc9459d0a92ba94c5bea.png From basil на vpm.net.ua Mon Jan 9 16:37:55 2017 From: basil на vpm.net.ua (Vasiliy P. Melnik) Date: Mon, 9 Jan 2017 18:37:55 +0200 Subject: =?UTF-8?B?UmU6IG5naW54INC4INGB0YLQsNGC0LjRh9C10YHQutC40LkgaGxzLCDRgdGC0YA=?= =?UTF-8?B?0LDQvdC90YvQtSDQv9Cw0LTQtdC90LjRjyDRgdC60L7RgNC+0YHRgtC4?= In-Reply-To: <20170109153030.GB1761@mdounin.ru> References: <0c010804-f2eb-4be6-e377-f1fab5113d2a@kpi.ua> <20170109153030.GB1761@mdounin.ru> Message-ID: какой кернел? 9 января 2017 г., 17:30 пользователь Maxim Dounin написал: > Hello! > > On Sun, Jan 08, 2017 at 06:19:47PM +0200, Андрей Василишин wrote: > > > Есть странная проблема, нгинкс после определенного времени начинает > > медленно отдавать сегменты hls, которые являются статикой на диске > > (4хSSD Kingston SH103S3 LVM ext4) при этом резко возрастает writing и > > падает waiting. > > > > https://i.gyazo.com/b4f7745c2fdf0ef63614684fa91177af.png > > > > > > В логах в это время пусто, при релоаде нгинкс, все снова стает в порядке > > до определенного момента, который может быть как через 5 минут, так и > > через пару часов. > > Что это может быть? > > Судя по графикам - вы в канал упираетесь. > > -- > Maxim Dounin > http://nginx.org/ > _______________________________________________ > nginx-ru mailing list > nginx-ru на nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From a.vasilishin на kpi.ua Mon Jan 9 16:42:05 2017 From: a.vasilishin на kpi.ua (=?UTF-8?B?0JDQvdC00YDQtdC5INCS0LDRgdC40LvQuNGI0LjQvQ==?=) Date: Mon, 9 Jan 2017 18:42:05 +0200 Subject: =?UTF-8?B?UmU6IG5naW54INC4INGB0YLQsNGC0LjRh9C10YHQutC40LkgaGxzLCDRgdGC0YA=?= =?UTF-8?B?0LDQvdC90YvQtSDQv9Cw0LTQtdC90LjRjyDRgdC60L7RgNC+0YHRgtC4?= In-Reply-To: References: <0c010804-f2eb-4be6-e377-f1fab5113d2a@kpi.ua> <20170109153030.GB1761@mdounin.ru> Message-ID: <090ab6fe-a0b9-bead-96f2-4e3041378e17@kpi.ua> 09.01.2017 18:37, Vasiliy P. Melnik пишет: > какой кернел? Сейчас такой # uname -a Linux host-21 3.2.0-4-amd64 #1 SMP Debian 3.2.84-1 x86_64 GNU/Linux На момент написания стартпоста было: Linux host-21 3.2.0-4-amd64 #1 SMP Debian 3.2.82-1 x86_64 From basil на vpm.net.ua Mon Jan 9 17:04:19 2017 From: basil на vpm.net.ua (Vasiliy P. Melnik) Date: Mon, 9 Jan 2017 19:04:19 +0200 Subject: =?UTF-8?B?UmU6IG5naW54INC4INGB0YLQsNGC0LjRh9C10YHQutC40LkgaGxzLCDRgdGC0YA=?= =?UTF-8?B?0LDQvdC90YvQtSDQv9Cw0LTQtdC90LjRjyDRgdC60L7RgNC+0YHRgtC4?= In-Reply-To: <090ab6fe-a0b9-bead-96f2-4e3041378e17@kpi.ua> References: <0c010804-f2eb-4be6-e377-f1fab5113d2a@kpi.ua> <20170109153030.GB1761@mdounin.ru> <090ab6fe-a0b9-bead-96f2-4e3041378e17@kpi.ua> Message-ID: у лвм на таких кернелах не работает трим - надо 3.9 минимум. Ну или уйти от лвм-а Я вышел из положения раскладкой кеша на 4 диска средствами самого нгинкса - у него есть сплиткеш. Деградация скорости в случае отсутствия трима может быть легко раз в 10. в atop-е хорошо видно 9 января 2017 г., 18:42 пользователь Андрей Василишин написал: > 09.01.2017 18:37, Vasiliy P. Melnik пишет: > > какой кернел? > > Сейчас такой > # uname -a > Linux host-21 3.2.0-4-amd64 #1 SMP Debian 3.2.84-1 x86_64 GNU/Linux > > На момент написания стартпоста было: > Linux host-21 3.2.0-4-amd64 #1 SMP Debian 3.2.82-1 x86_64 > _______________________________________________ > nginx-ru mailing list > nginx-ru на nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From a.vasilishin на kpi.ua Mon Jan 9 17:32:40 2017 From: a.vasilishin на kpi.ua (=?UTF-8?B?0JDQvdC00YDQtdC5INCS0LDRgdC40LvQuNGI0LjQvQ==?=) Date: Mon, 9 Jan 2017 19:32:40 +0200 Subject: =?UTF-8?B?UmU6IG5naW54INC4INGB0YLQsNGC0LjRh9C10YHQutC40LkgaGxzLCDRgdGC0YA=?= =?UTF-8?B?0LDQvdC90YvQtSDQv9Cw0LTQtdC90LjRjyDRgdC60L7RgNC+0YHRgtC4?= In-Reply-To: References: <0c010804-f2eb-4be6-e377-f1fab5113d2a@kpi.ua> <20170109153030.GB1761@mdounin.ru> <090ab6fe-a0b9-bead-96f2-4e3041378e17@kpi.ua> Message-ID: <9de15939-974b-d450-07be-1bc268be688e@kpi.ua> 09.01.2017 19:04, Vasiliy P. Melnik пишет: > у лвм на таких кернелах не работает трим - надо 3.9 минимум. Ну или уйти > от лвм-а > > Я вышел из положения раскладкой кеша на 4 диска средствами самого > нгинкса - у него есть сплиткеш. Деградация скорости в случае отсутствия > трима может быть легко раз в 10. в atop-е хорошо видно > Спасибо за совет, LVM вообще первый раз использую по просьбе клиента, до этого использовал диски по отдельности. Но в atop в моменты просадок нет никаких перегрузов даже и близко From basil на vpm.net.ua Mon Jan 9 17:51:25 2017 From: basil на vpm.net.ua (Vasiliy P. Melnik) Date: Mon, 9 Jan 2017 19:51:25 +0200 Subject: =?UTF-8?B?UmU6IG5naW54INC4INGB0YLQsNGC0LjRh9C10YHQutC40LkgaGxzLCDRgdGC0YA=?= =?UTF-8?B?0LDQvdC90YvQtSDQv9Cw0LTQtdC90LjRjyDRgdC60L7RgNC+0YHRgtC4?= In-Reply-To: <9de15939-974b-d450-07be-1bc268be688e@kpi.ua> References: <0c010804-f2eb-4be6-e377-f1fab5113d2a@kpi.ua> <20170109153030.GB1761@mdounin.ru> <090ab6fe-a0b9-bead-96f2-4e3041378e17@kpi.ua> <9de15939-974b-d450-07be-1bc268be688e@kpi.ua> Message-ID: > > Спасибо за совет, LVM вообще первый раз использую по просьбе клиента, до > этого использовал диски по отдельности. Но в atop в моменты просадок > нет никаких перегрузов даже и близко > если затык в диске, то скорее всего было бы видно. вообще лвм и ссд-эшники не лучший вариант, я свои диски держу заполненными на 90%, а на какой диск будет писать лвм вообще никому не известно, в итоге можно просто угробить диск очень быстро. С софтовым рейдом та же ситуация - там с кернела 4.2 кажись работает трим. это я все к тому, что вопрос трима нельзя пускать на самотек и он требует внимания - надо понимать, что делаешь и какие возможны последствия. Недавно в другой рассылке обсуждали вопрос трима - народ говорит, что скорость может упасть раз в 100 из-за отсутствия трима. ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From simplebox66 на gmail.com Wed Jan 11 07:21:32 2017 From: simplebox66 на gmail.com (=?UTF-8?B?0JjQstCw0L0g0JzQuNGI0LjQvQ==?=) Date: Wed, 11 Jan 2017 10:21:32 +0300 Subject: =?UTF-8?B?UmU6INC60L7Qu9C40YfQtdGB0YLQstC+IG9wZW4gc29ja2V0cw==?= In-Reply-To: <2071721.PtxWHHSfeL@vbart-laptop> References: <2071721.PtxWHHSfeL@vbart-laptop> Message-ID: В логах тишина, nginx самый свежий из стабильных nginx/1.10.2. Сторонние модули не использую. Как проверить что это именно утечка? И найти где эта утечка? Чтобы вы могли это исправить в будущих версиях. 9 января 2017 г., 16:32 пользователь Валентин Бартенев написал: > On Thursday 29 December 2016 09:47:53 Иван Мишин wrote: > > Есть несколько одинаковых nginx, обслуживающих около 100 хостов. На > каждом > > nginx используется кеш ramfs объемом 30Гб на каждый nginx. Последнее > > несколько недель по непонятным причинам постоянно растет количество > > opensockets. Причем даже в ненагруженные дни рост все равно есть. > Пробовал > > рестартовать ngnix, но opnesockets по прежнему растет. В чем может быть > > проблема? На что обратить внимание? > > Обратить внимание на логи, на версию nginx, на используемые сторонние > модули > и конфигурацию. Ошибки, приводящие к утечки сокетов, время от времени > случаются и исправляются. > > -- > Валентин Бартенев > _______________________________________________ > nginx-ru mailing list > nginx-ru на nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From simplebox66 на gmail.com Wed Jan 11 09:18:56 2017 From: simplebox66 на gmail.com (=?UTF-8?B?0JjQstCw0L0g0JzQuNGI0LjQvQ==?=) Date: Wed, 11 Jan 2017 12:18:56 +0300 Subject: =?UTF-8?B?UmU6INCg0LDRgdGC0LXRgiDQutC+0Lst0LLQviDQvtGC0LrRgNGL0YLRi9GFIHVk?= =?UTF-8?B?cCDRgdC+0LrQtdGC0L7Qsg==?= In-Reply-To: References: <20151113112149.GA2151@vlpc.nginx.com> <20151116093704.GB30270@vlpc.nginx.com> <20151116111050.GA28216@vlpc.nginx.com> <20151120100323.GF17764@protva.ru> Message-ID: Проблема сама ушла, но сейчас снова вернулась. nginx имеет кучу процессов в состоянии shutting down > nginx 2245 0.1 0.4 277892 170264 ? S< 2016 60:12 nginx: > worker process is shutting down > nginx 2246 0.1 0.4 277892 170268 ? S< 2016 60:04 nginx: > worker process is shutting down > nginx 2247 0.1 0.4 277892 170264 ? S< 2016 53:58 nginx: > worker process is shutting down > nginx 2248 0.1 0.4 277892 170268 ? S< 2016 61:46 nginx: > worker process is shutting down > nginx 2249 0.1 0.4 277892 170264 ? S< 2016 60:04 nginx: > worker process is shutting down > nginx 2250 0.1 0.4 277892 170264 ? S< 2016 61:02 nginx: > worker process is shutting down > root 12463 0.0 0.3 239260 117740 ? Ss 2016 0:02 nginx: > master process /usr/sbin/nginx -c /etc/nginx/nginx.conf > nginx 12466 0.1 0.3 225684 117204 ? S< 2016 63:19 nginx: > worker process is shutting down > nginx 12472 0.2 0.3 226236 117596 ? S< 2016 68:23 nginx: > worker process is shutting down > nginx 12475 0.1 0.3 226204 117592 ? S< 2016 65:29 nginx: > worker process is shutting down > root 34155 0.0 0.0 103336 916 pts/1 S+ 11:58 0:00 grep nginx > nginx 44094 1.0 0.4 280680 171700 ? S< 2016 301:38 nginx: > worker process is shutting down > nginx 44095 0.9 0.4 280680 171700 ? S< 2016 260:05 nginx: > worker process is shutting down > nginx 44096 0.9 0.4 280680 171700 ? S< 2016 280:09 nginx: > worker process is shutting down > nginx 44097 0.9 0.4 280680 171700 ? S< 2016 274:12 nginx: > worker process is shutting down > nginx 44098 1.0 0.4 280680 171700 ? S< 2016 304:19 nginx: > worker process is shutting down > nginx 44099 1.0 0.4 280680 171700 ? S< 2016 289:29 nginx: > worker process is shutting down > nginx 47185 2.0 0.4 280732 170500 ? S< Jan09 59:39 nginx: > worker process > nginx 47186 2.0 0.4 280732 170504 ? S< Jan09 58:10 nginx: > worker process > nginx 47187 1.7 0.4 280732 170504 ? S< Jan09 51:09 nginx: > worker process > nginx 47188 1.7 0.4 280732 170504 ? S< Jan09 50:46 nginx: > worker process > nginx 47189 1.8 0.4 280732 170504 ? S< Jan09 53:27 nginx: > worker process > nginx 47190 2.0 0.4 280732 170504 ? S< Jan09 59:42 nginx: > worker process > nginx 47191 0.0 0.3 239264 128296 ? S Jan09 1:04 nginx: > cache manager process > nginx 58834 0.0 0.4 277892 170248 ? S< 2016 18:34 nginx: > worker process is shutting down > nginx 58835 0.0 0.4 277892 170248 ? S< 2016 20:34 nginx: > worker process is shutting down > nginx 58836 0.0 0.4 277892 170244 ? S< 2016 19:48 nginx: > worker process is shutting down При этом netstat -nap | grep выдает например > tcp 0 0 x.x.x.x:49810 y.y.y.y:80 > ESTABLISHED 2245/nginx отправляюсь на y.y.y.y (там у меня на 80 порту nginx) и делаю service nginx stop и service nginx start. Но возвращаясь на x.x.x.x я снова вижу > При этом netstat -nap | grep выдает > например tcp 0 0 x.x.x.x:49810 y.y.y.y:80 > ESTABLISHED 2245/nginx Не пойму почему не отваливается соединение? 30 ноября 2015 г., 10:53 пользователь Aleksandr Sytar написал: > > > 30 ноября 2015 г., 10:42 пользователь Иван Мишин > написал: > >> Проблема в том что не отмирают старые процессы по несколько дней ( видел >> те которые 10 дней даже живут), они то и держат "лишние" соединения. >> >> Вот конкретно сейчас есть процессы от 23 числа.: >> nginx 46065 1.5 0.3 237188 133192 ? S< Nov23 151:19 nginx: >> worker process is shutting down >> nginx 46066 1.5 0.3 237060 133156 ? S< Nov23 144:16 nginx: >> worker process is shutting down >> nginx 46069 1.6 0.3 237008 133836 ? S< Nov23 156:25 nginx: >> worker process is shutting down >> >> Почему они за 7 дней до сих пор не умерли? >> > > Потому что к ним еще подключены клиенты. Убейте клиентов и воркеры сам > закроются > > > _______________________________________________ > nginx-ru mailing list > nginx-ru на nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru > ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From stalker на altlinux.ru Wed Jan 11 11:45:43 2017 From: stalker на altlinux.ru (Anton Gorlov) Date: Wed, 11 Jan 2017 14:45:43 +0300 Subject: =?UTF-8?B?UmU6INCg0LDRgdGC0LXRgiDQutC+0Lst0LLQviDQvtGC0LrRgNGL0YLRi9GFIHVk?= =?UTF-8?B?cCDRgdC+0LrQtdGC0L7Qsg==?= In-Reply-To: References: <20151113112149.GA2151@vlpc.nginx.com> <20151116093704.GB30270@vlpc.nginx.com> <20151116111050.GA28216@vlpc.nginx.com> <20151120100323.GF17764@protva.ru> Message-ID: <2ebd51c4-c6b4-bac1-5ba6-a01e9b986391@altlinux.ru> А Вам не шлют часом пакетики с zero windows? 11.01.2017 12:18, Иван Мишин пишет: > Проблема сама ушла, но сейчас снова вернулась. > nginx имеет кучу процессов в состоянии shutting down > > nginx 2245 0.1 0.4 277892 170264 ? S< 2016 60:12 > nginx: worker process is shutting down > nginx 2246 0.1 0.4 277892 170268 ? S< 2016 60:04 > nginx: worker process is shutting down > nginx 2247 0.1 0.4 277892 170264 ? S< 2016 53:58 > nginx: worker process is shutting down > nginx 2248 0.1 0.4 277892 170268 ? S< 2016 61:46 > nginx: worker process is shutting down > nginx 2249 0.1 0.4 277892 170264 ? S< 2016 60:04 > nginx: worker process is shutting down > nginx 2250 0.1 0.4 277892 170264 ? S< 2016 61:02 > nginx: worker process is shutting down > root 12463 0.0 0.3 239260 117740 ? Ss 2016 0:02 > nginx: master process /usr/sbin/nginx -c /etc/nginx/nginx.conf > nginx 12466 0.1 0.3 225684 117204 ? S< 2016 63:19 > nginx: worker process is shutting down > nginx 12472 0.2 0.3 226236 117596 ? S< 2016 68:23 > nginx: worker process is shutting down > nginx 12475 0.1 0.3 226204 117592 ? S< 2016 65:29 > nginx: worker process is shutting down > root 34155 0.0 0.0 103336 916 pts/1 S+ 11:58 0:00 > grep nginx > nginx 44094 1.0 0.4 280680 171700 ? S< 2016 301:38 > nginx: worker process is shutting down > nginx 44095 0.9 0.4 280680 171700 ? S< 2016 260:05 > nginx: worker process is shutting down > nginx 44096 0.9 0.4 280680 171700 ? S< 2016 280:09 > nginx: worker process is shutting down > nginx 44097 0.9 0.4 280680 171700 ? S< 2016 274:12 > nginx: worker process is shutting down > nginx 44098 1.0 0.4 280680 171700 ? S< 2016 304:19 > nginx: worker process is shutting down > nginx 44099 1.0 0.4 280680 171700 ? S< 2016 289:29 > nginx: worker process is shutting down > nginx 47185 2.0 0.4 280732 170500 ? S< Jan09 59:39 > nginx: worker process > nginx 47186 2.0 0.4 280732 170504 ? S< Jan09 58:10 > nginx: worker process > nginx 47187 1.7 0.4 280732 170504 ? S< Jan09 51:09 > nginx: worker process > nginx 47188 1.7 0.4 280732 170504 ? S< Jan09 50:46 > nginx: worker process > nginx 47189 1.8 0.4 280732 170504 ? S< Jan09 53:27 > nginx: worker process > nginx 47190 2.0 0.4 280732 170504 ? S< Jan09 59:42 > nginx: worker process > nginx 47191 0.0 0.3 239264 128296 ? S Jan09 1:04 > nginx: cache manager process > nginx 58834 0.0 0.4 277892 170248 ? S< 2016 18:34 > nginx: worker process is shutting down > nginx 58835 0.0 0.4 277892 170248 ? S< 2016 20:34 > nginx: worker process is shutting down > nginx 58836 0.0 0.4 277892 170244 ? S< 2016 19:48 > nginx: worker process is shutting down > > > При этом netstat -nap | grep > выдает например > > tcp 0 0 x.x.x.x:49810 y.y.y.y:80 > ESTABLISHED 2245/nginx > > > отправляюсь на y.y.y.y (там у меня на 80 порту nginx) и делаю service > nginx stop и service nginx start. > Но возвращаясь на x.x.x.x я снова вижу > > При этом netstat -nap | grep down> выдает например > > tcp 0 0 x.x.x.x:49810 y.y.y.y:80 > ESTABLISHED 2245/nginx > > > Не пойму почему не отваливается соединение? > > 30 ноября 2015 г., 10:53 пользователь Aleksandr Sytar > > написал: > > > > 30 ноября 2015 г., 10:42 пользователь Иван Мишин > > написал: > > Проблема в том что не отмирают старые процессы по несколько > дней ( видел те которые 10 дней даже живут), они то и держат > "лишние" соединения. > > Вот конкретно сейчас есть процессы от 23 числа.: > nginx 46065 1.5 0.3 237188 133192 ? S< Nov23 > 151:19 nginx: worker process is shutting down > nginx 46066 1.5 0.3 237060 133156 ? S< Nov23 > 144:16 nginx: worker process is shutting down > nginx 46069 1.6 0.3 237008 133836 ? S< Nov23 > 156:25 nginx: worker process is shutting down > > Почему они за 7 дней до сих пор не умерли? > > > Потому что к ним еще подключены клиенты. Убейте клиентов и воркеры > сам закроются > > > _______________________________________________ > 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From simplebox66 на gmail.com Wed Jan 11 12:07:54 2017 From: simplebox66 на gmail.com (=?UTF-8?B?0JjQstCw0L0g0JzQuNGI0LjQvQ==?=) Date: Wed, 11 Jan 2017 15:07:54 +0300 Subject: =?UTF-8?B?UmU6INCg0LDRgdGC0LXRgiDQutC+0Lst0LLQviDQvtGC0LrRgNGL0YLRi9GFIHVk?= =?UTF-8?B?cCDRgdC+0LrQtdGC0L7Qsg==?= In-Reply-To: <2ebd51c4-c6b4-bac1-5ba6-a01e9b986391@altlinux.ru> References: <20151113112149.GA2151@vlpc.nginx.com> <20151116093704.GB30270@vlpc.nginx.com> <20151116111050.GA28216@vlpc.nginx.com> <20151120100323.GF17764@protva.ru> <2ebd51c4-c6b4-bac1-5ba6-a01e9b986391@altlinux.ru> Message-ID: > > А Вам не шлют часом пакетики с zero windows? Поясните пожалуйста что это такое? ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From simplebox66 на gmail.com Wed Jan 11 13:28:26 2017 From: simplebox66 на gmail.com (=?UTF-8?B?0JjQstCw0L0g0JzQuNGI0LjQvQ==?=) Date: Wed, 11 Jan 2017 16:28:26 +0300 Subject: =?UTF-8?B?UmU6INCg0LDRgdGC0LXRgiDQutC+0Lst0LLQviDQvtGC0LrRgNGL0YLRi9GFIHVk?= =?UTF-8?B?cCDRgdC+0LrQtdGC0L7Qsg==?= In-Reply-To: References: <20151113112149.GA2151@vlpc.nginx.com> <20151116093704.GB30270@vlpc.nginx.com> <20151116111050.GA28216@vlpc.nginx.com> <20151120100323.GF17764@protva.ru> <2ebd51c4-c6b4-bac1-5ba6-a01e9b986391@altlinux.ru> Message-ID: > > А Вам не шлют часом пакетики с zero windows? Разобрался, нет не шлют. 11 января 2017 г., 15:07 пользователь Иван Мишин написал: > А Вам не шлют часом пакетики с zero windows? > > Поясните пожалуйста что это такое? > ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From vbart на nginx.com Thu Jan 12 16:32:16 2017 From: vbart на nginx.com (=?utf-8?B?0JLQsNC70LXQvdGC0LjQvSDQkdCw0YDRgtC10L3QtdCy?=) Date: Thu, 12 Jan 2017 19:32:16 +0300 Subject: =?UTF-8?B?UmU6INC60L7Qu9C40YfQtdGB0YLQstC+IG9wZW4gc29ja2V0cw==?= In-Reply-To: References: <2071721.PtxWHHSfeL@vbart-laptop> Message-ID: <6292485.5PS80I48bP@vbart-workstation> On Wednesday 11 January 2017 10:21:32 Иван Мишин wrote: > В логах тишина, nginx самый свежий из стабильных nginx/1.10.2. Сторонние > модули не использую. > Как проверить что это именно утечка? И найти где эта утечка? Чтобы вы могли > это исправить в будущих версиях. > Имеет смысл удостовериться, что проверялся именно основной лог. Об утекших соединения nginx обычно сообщает в error_log: ... open socket #12 left in connection 5 при завершении рабочего процесса. -- Валентин Бартенев From nginx-forum на forum.nginx.org Fri Jan 13 10:38:38 2017 From: nginx-forum на forum.nginx.org (liveder) Date: Fri, 13 Jan 2017 05:38:38 -0500 Subject: ignore long locked inactive cache entry In-Reply-To: References: Message-ID: <276a693dc18ffb0b13e06b615439b6be.NginxMailingListRussian@forum.nginx.org> Добрый день, Антон Решили ли вы в итоге проблему? Если да, то как? Спасибо Posted at Nginx Forum: https://forum.nginx.org/read.php?21,271068,271981#msg-271981 From nginx-forum на forum.nginx.org Sun Jan 15 08:07:01 2017 From: nginx-forum на forum.nginx.org (ProUnebit) Date: Sun, 15 Jan 2017 03:07:01 -0500 Subject: =?UTF-8?B?TmdpbnhQcm94eSAtPiBOZ2lueCArIG5neCBwYWdlc3BlZWQsINC60LDQuiDQv9GA?= =?UTF-8?B?0LDQstC40LvRjNC90L4g0L3QsNGB0YLRgNC+0LjRgtGMPw==?= Message-ID: Доброго времени суток уважаемые! Имеем: 1. Nginx, на фронте, в роли ReveseProxy, HTTP/HTTPS, он же будет выполнять роль балансировщика нагрузки 2. Несколько Nginx+PHP-FPM серверов "сзади", на некоторых установлен ngx_pagespeed (серверы могут отвечать за разные сайты/сервисы/проекты) Столкнулся с проблемой: 1. "Главный" (фронтальный) Nginx "портит" заголовки. При обращении к северу-источнику, получаем: Expires: Sat, 04 Feb 2017 08:59:15 GMT Cache-Control: max-age=2587554, public ETag: W/"PSA-aj-29OAZzvhfX" Если посмотрим с фронтального сервера: cache-control:max-age=44190 etag: W/"PSA-aj-29OAZzvhfX" expires: Thu, 05 Jan 2017 20:01:14 GMT Как мы видим, изменились заголовки cache-control, expires, иногда меняется E-Tag. Вопрос. Как отключить кэширование на фронтальном сервере (лучше совсем) и изменение заголовков с его стороны? Меня интересует исключительно функции прямого прокси, кэшируется всё что нужно пусть на источниках. Второй момент, с которым борюсь уже 2-й день - это ngx_pagespeed модуль. Который ни в какую не хочет убирать CSS-скрипт из заголовка. Я уже перепробовал все вариции фильтров которые приходили мне в голову, в том числе: extend_cache prioritize_critical_css И так далее Ни в какую не хочет работать как просит гугл: "Оставить в шапке важные CSS, остальные убрать в конец". Кому-нибудь удалось добиться подобного эффекта? Posted at Nginx Forum: https://forum.nginx.org/read.php?21,271993,271993#msg-271993 From nginx-forum на forum.nginx.org Mon Jan 16 10:51:06 2017 From: nginx-forum на forum.nginx.org (Vvedensky) Date: Mon, 16 Jan 2017 05:51:06 -0500 Subject: =?UTF-8?B?0JrQtdGI0LjRgNC+0LLQsNC90LjQtSDQvtGC0LLQtdGC0LAgcGhwLWZwbQ==?= Message-ID: <9007622078520c488810c36a8d4efbac.NginxMailingListRussian@forum.nginx.org> Здравствуйте. Периодически в лог-файлах nginx возникают подобные сообщения: 2017/01/16 12:41:54 [warn] 17173#17173: *14642 an upstream response is buffered to a temporary file /var/cache/nginx/fastcgi_temp/9/00/0000000009 while reading upstream Я понимаю это сообщение так: приходит ответ от php-fpm, но nginx в этот момент занят и ответ кешируется в файл. Так ли это? Как понять причину предупреждения? На первый взгляд ресурсы у сервера есть. Posted at Nginx Forum: https://forum.nginx.org/read.php?21,271999,271999#msg-271999 From simplebox66 на gmail.com Mon Jan 16 10:56:51 2017 From: simplebox66 на gmail.com (=?UTF-8?B?0JjQstCw0L0g0JzQuNGI0LjQvQ==?=) Date: Mon, 16 Jan 2017 13:56:51 +0300 Subject: =?UTF-8?B?UmU6INC60L7Qu9C40YfQtdGB0YLQstC+IG9wZW4gc29ja2V0cw==?= In-Reply-To: <6292485.5PS80I48bP@vbart-workstation> References: <2071721.PtxWHHSfeL@vbart-laptop> <6292485.5PS80I48bP@vbart-workstation> Message-ID: > > ... open socket #12 left in connection 5 Нет у меня таких записей в логах. 12 января 2017 г., 19:32 пользователь Валентин Бартенев написал: > On Wednesday 11 January 2017 10:21:32 Иван Мишин wrote: > > В логах тишина, nginx самый свежий из стабильных nginx/1.10.2. Сторонние > > модули не использую. > > Как проверить что это именно утечка? И найти где эта утечка? Чтобы вы > могли > > это исправить в будущих версиях. > > > > Имеет смысл удостовериться, что проверялся именно основной лог. Об утекших > соединения nginx обычно сообщает в error_log: > > ... open socket #12 left in connection 5 > > при завершении рабочего процесса. > > > -- > Валентин Бартенев > _______________________________________________ > nginx-ru mailing list > nginx-ru на nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru > ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From swood на fotofor.biz Mon Jan 16 11:07:38 2017 From: swood на fotofor.biz (Anton Kiryushkin) Date: Mon, 16 Jan 2017 11:07:38 +0000 Subject: ignore long locked inactive cache entry In-Reply-To: <276a693dc18ffb0b13e06b615439b6be.NginxMailingListRussian@forum.nginx.org> References: <276a693dc18ffb0b13e06b615439b6be.NginxMailingListRussian@forum.nginx.org> Message-ID: Спасает обновление минимум до 1.11.6. Жаль, что разработчики это никак не комментировали. пт, 13 янв. 2017 г. в 13:38, liveder : > Добрый день, Антон > > Решили ли вы в итоге проблему? Если да, то как? > > Спасибо > > Posted at Nginx Forum: > https://forum.nginx.org/read.php?21,271068,271981#msg-271981 > > _______________________________________________ > nginx-ru mailing list > nginx-ru на nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru -------------- next part -------------- An HTML attachment was scrubbed... URL: From mdounin на mdounin.ru Mon Jan 16 13:02:30 2017 From: mdounin на mdounin.ru (Maxim Dounin) Date: Mon, 16 Jan 2017 16:02:30 +0300 Subject: =?UTF-8?B?UmU6INCa0LXRiNC40YDQvtCy0LDQvdC40LUg0L7RgtCy0LXRgtCwIHBocC1mcG0=?= In-Reply-To: <9007622078520c488810c36a8d4efbac.NginxMailingListRussian@forum.nginx.org> References: <9007622078520c488810c36a8d4efbac.NginxMailingListRussian@forum.nginx.org> Message-ID: <20170116130229.GB45866@mdounin.ru> Hello! On Mon, Jan 16, 2017 at 05:51:06AM -0500, Vvedensky wrote: > Здравствуйте. > Периодически в лог-файлах nginx возникают подобные сообщения: > 2017/01/16 12:41:54 [warn] 17173#17173: *14642 an upstream response is > buffered to a temporary file /var/cache/nginx/fastcgi_temp/9/00/0000000009 > while reading upstream > Я понимаю это сообщение так: приходит ответ от php-fpm, но nginx в этот > момент занят и ответ кешируется в файл. Так ли это? Как понять причину > предупреждения? На первый взгляд ресурсы у сервера есть. Нет. Подробное описание того, что на самом деле происходит при получении ответа бекенда, есть тут: http://nginx.org/r/fastcgi_buffering/ru Приведённое сообщение выдаётся тогда, когда буфера кончились, и ответ начинает записываться во временный файл. Если сообщение появляется часто, и при этом свободной памяти много - это повод задуматься об увелчичении fastcgi_buffers. -- Maxim Dounin http://nginx.org/ From mdounin на mdounin.ru Mon Jan 16 13:16:41 2017 From: mdounin на mdounin.ru (Maxim Dounin) Date: Mon, 16 Jan 2017 16:16:41 +0300 Subject: ignore long locked inactive cache entry In-Reply-To: References: <276a693dc18ffb0b13e06b615439b6be.NginxMailingListRussian@forum.nginx.org> Message-ID: <20170116131641.GC45866@mdounin.ru> Hello! On Mon, Jan 16, 2017 at 11:07:38AM +0000, Anton Kiryushkin wrote: > Спасает обновление минимум до 1.11.6. Жаль, что разработчики это никак не > комментировали. Если спасает - значит проблема была в том, что вы со включённым кешированием пытались проксировать WebSocket'ы. Смысла в этом нет - кешировать WebSocket'ы невозможно. Но соответствующий элемент кеша оказывался заблокирован на всё время WebSocket-соединения, что могло приводить к алертам в логах, а также блокировать очистку кеша по max_size. Workaround - не включать кеширование там, где включено проксирование WebSocket'ов. Ну или периодически закрывать WebSocket-соединения. -- Maxim Dounin http://nginx.org/ From swood на fotofor.biz Mon Jan 16 13:23:44 2017 From: swood на fotofor.biz (Anton Kiryushkin) Date: Mon, 16 Jan 2017 13:23:44 +0000 Subject: ignore long locked inactive cache entry In-Reply-To: <20170116131641.GC45866@mdounin.ru> References: <276a693dc18ffb0b13e06b615439b6be.NginxMailingListRussian@forum.nginx.org> <20170116131641.GC45866@mdounin.ru> Message-ID: Максим, я вас расстрою. В моем случае речь не может идти о websocket, так как их нет как технологии в проекте. Я не могу дать абсолютно все подробности. Но смысл кэширования в том, чтобы сохранять ответы, которые генерируются бэкендом. Исключительно http/1.0. Даже не 1.1. пн, 16 янв. 2017 г. в 16:16, Maxim Dounin : > Hello! > > On Mon, Jan 16, 2017 at 11:07:38AM +0000, Anton Kiryushkin wrote: > > > Спасает обновление минимум до 1.11.6. Жаль, что разработчики это никак не > > комментировали. > > Если спасает - значит проблема была в том, что вы со включённым > кешированием пытались проксировать WebSocket'ы. Смысла в этом нет - > кешировать WebSocket'ы невозможно. Но соответствующий элемент > кеша оказывался заблокирован на всё время WebSocket-соединения, > что могло приводить к алертам в логах, а также блокировать очистку > кеша по max_size. > > Workaround - не включать кеширование там, где включено > проксирование WebSocket'ов. Ну или периодически закрывать > WebSocket-соединения. > > -- > Maxim Dounin > http://nginx.org/ > _______________________________________________ > nginx-ru mailing list > nginx-ru на nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru -------------- next part -------------- An HTML attachment was scrubbed... URL: From mdounin на mdounin.ru Mon Jan 16 13:48:04 2017 From: mdounin на mdounin.ru (Maxim Dounin) Date: Mon, 16 Jan 2017 16:48:04 +0300 Subject: ignore long locked inactive cache entry In-Reply-To: References: <276a693dc18ffb0b13e06b615439b6be.NginxMailingListRussian@forum.nginx.org> <20170116131641.GC45866@mdounin.ru> Message-ID: <20170116134804.GD45866@mdounin.ru> Hello! On Mon, Jan 16, 2017 at 01:23:44PM +0000, Anton Kiryushkin wrote: > Максим, я вас расстрою. В моем случае речь не может идти о websocket, так > как их нет как технологии в проекте. Я не могу дать абсолютно все > подробности. Но смысл кэширования в том, чтобы сохранять ответы, которые > генерируются бэкендом. Исключительно http/1.0. Даже не 1.1. Аналогичная картина могла возникать до 1.11.6, если при включённом кеше выключить буферизацию ответа (кеш при выключенной буферизации работать не может), и долго возвращать этот ответ. Собственно, возникать оно может (и должно) при любых долгих ответах, даже тех, которые честно складываются в кеш. Ну или при падениях рабочих процессов. Если падает - искать и лечить то, что падет. Если не падает - искать долгие ответы. -- Maxim Dounin http://nginx.org/ From nginx-forum на forum.nginx.org Mon Jan 16 14:46:35 2017 From: nginx-forum на forum.nginx.org (liveder) Date: Mon, 16 Jan 2017 09:46:35 -0500 Subject: ignore long locked inactive cache entry In-Reply-To: References: Message-ID: Спасибо! Попробуем! Posted at Nginx Forum: https://forum.nginx.org/read.php?21,271068,272013#msg-272013 From swood на fotofor.biz Mon Jan 16 16:49:30 2017 From: swood на fotofor.biz (Anton Kiryushkin) Date: Mon, 16 Jan 2017 19:49:30 +0300 Subject: ignore long locked inactive cache entry In-Reply-To: References: Message-ID: А как узнать, что ответ от бэкенда медленный? По моим наблюдениям, объект в кэше мог пролежать несколько дней. При этом сам бэкенд могли перезагрузить по несколько раз за это время. Объект как был в кэше и был занят nginx, так и продолжал это делать. На мой взгляд это как раз баг, который был исправлен, а не какое-то странное поведение какого-то бэкенда, на которое с определенной версии nginx перестал обращать внимание. 2017-01-16 17:46 GMT+03:00 liveder : > Спасибо! Попробуем! > > Posted at Nginx Forum: https://forum.nginx.org/read. > php?21,271068,272013#msg-272013 > > _______________________________________________ > nginx-ru mailing list > nginx-ru на nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru > -- Best regards, Anton Kiryushkin -------------- next part -------------- An HTML attachment was scrubbed... URL: From nginx-forum на forum.nginx.org Mon Jan 16 16:53:12 2017 From: nginx-forum на forum.nginx.org (liveder) Date: Mon, 16 Jan 2017 11:53:12 -0500 Subject: ignore long locked inactive cache entry In-Reply-To: References: Message-ID: <106aa367d16013741a6575fc5cee1574.NginxMailingListRussian@forum.nginx.org> Есть предположение, что у вас падают воркеры. А кеш менеджер думает, что файл еще занят им. Плюс, мы не можем зарепродюсить данную проблему на el7. Хотя на el6 без проблем - достаточно лишь kill -9 воркера Posted at Nginx Forum: https://forum.nginx.org/read.php?21,271068,272018#msg-272018 From swood на fotofor.biz Mon Jan 16 16:56:24 2017 From: swood на fotofor.biz (Anton Kiryushkin) Date: Mon, 16 Jan 2017 19:56:24 +0300 Subject: ignore long locked inactive cache entry In-Reply-To: <106aa367d16013741a6575fc5cee1574.NginxMailingListRussian@forum.nginx.org> References: <106aa367d16013741a6575fc5cee1574.NginxMailingListRussian@forum.nginx.org> Message-ID: Нет, не падают. По крайней мере о падении должно сообщаться в лог. Сообщений не было. Не было и ООМ-killer. Да, если стрельнуть в воркера сигналом, то файлы отпускаются и удаляются cache-manager. Но вместе с этим воркером мы теряем и запросы, которые этот воркер обрабатывал, а это уже обидно. 16 января 2017 г., 19:53 пользователь liveder написал: > Есть предположение, что у вас падают воркеры. А кеш менеджер думает, что > файл еще занят им. > Плюс, мы не можем зарепродюсить данную проблему на el7. Хотя на el6 без > проблем - достаточно лишь kill -9 воркера > > Posted at Nginx Forum: https://forum.nginx.org/read. > php?21,271068,272018#msg-272018 > > _______________________________________________ > nginx-ru mailing list > nginx-ru на nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru > -- Best regards, Anton Kiryushkin -------------- next part -------------- An HTML attachment was scrubbed... URL: From nginx-forum на forum.nginx.org Mon Jan 16 16:59:12 2017 From: nginx-forum на forum.nginx.org (liveder) Date: Mon, 16 Jan 2017 11:59:12 -0500 Subject: ignore long locked inactive cache entry In-Reply-To: References: Message-ID: <5283a3ec38b8762c2c240b6791a62f46.NginxMailingListRussian@forum.nginx.org> У нас файлы не удаляются, если воркера убить SIGKILL. Сразу после кила сыпятся ошибки(по ttl expire) Posted at Nginx Forum: https://forum.nginx.org/read.php?21,271068,272020#msg-272020 From nginx-forum на forum.nginx.org Tue Jan 17 11:49:07 2017 From: nginx-forum на forum.nginx.org (Vvedensky) Date: Tue, 17 Jan 2017 06:49:07 -0500 Subject: =?UTF-8?B?UmU6INCa0LXRiNC40YDQvtCy0LDQvdC40LUg0L7RgtCy0LXRgtCwIHBocC1mcG0=?= In-Reply-To: <20170116130229.GB45866@mdounin.ru> References: <20170116130229.GB45866@mdounin.ru> Message-ID: <3ab7367bfa00500f8b82b0aad85c8520.NginxMailingListRussian@forum.nginx.org> Спасибо за ответ. По указанной вами ссылке по умолчанию: fastcgi_buffers 8 4k|8k. Если я правильно понимаю, то для 32-разрядной платформы 4k, для 64-разрядной 8k. А что следует увеличивать размер одного буфера (например, до 16k) или количество буферов до 16? Сообщение появляется не часто, в основном при работе в админке сайта. На первый взгляд общий объем буферов небольшой - около 64k, размер ОЗУ сервера 1 Гб, лишней памяти не очень много, но 100...200 Кб погоды не делают. Так ли это на ваш взгляд? Posted at Nginx Forum: https://forum.nginx.org/read.php?21,271999,272023#msg-272023 From mdounin на mdounin.ru Tue Jan 17 13:12:08 2017 From: mdounin на mdounin.ru (Maxim Dounin) Date: Tue, 17 Jan 2017 16:12:08 +0300 Subject: =?UTF-8?B?UmU6INCa0LXRiNC40YDQvtCy0LDQvdC40LUg0L7RgtCy0LXRgtCwIHBocC1mcG0=?= In-Reply-To: <3ab7367bfa00500f8b82b0aad85c8520.NginxMailingListRussian@forum.nginx.org> References: <20170116130229.GB45866@mdounin.ru> <3ab7367bfa00500f8b82b0aad85c8520.NginxMailingListRussian@forum.nginx.org> Message-ID: <20170117131208.GE45866@mdounin.ru> Hello! On Tue, Jan 17, 2017 at 06:49:07AM -0500, Vvedensky wrote: > Спасибо за ответ. По указанной вами ссылке по умолчанию: fastcgi_buffers 8 > 4k|8k. > Если я правильно понимаю, то для 32-разрядной платформы 4k, для 64-разрядной > 8k. Нет, 4k или 8k определяется размером страницы памяти на конкретной платформе. Для i386 и amd64 это 4k. > А что следует увеличивать размер одного буфера (например, до 16k) или > количество буферов до 16? Общая логика какая-то такая: большие буфера могут заполняться не полностью, и соответственно память будет тратится впустую, а много буферов - лишние накладные расходы, т.к. заметная часть операций делается для каждого буфера. Истина - где-то посередине. Между 8*16k и 16*8k, IMHO, выбор совершенно не принципиален. Лично я бы - поставил 8*16k. > Сообщение появляется не часто, в основном при работе в админке сайта. На > первый взгляд общий объем буферов небольшой - около 64k, размер ОЗУ сервера > 1 Гб, лишней памяти не очень много, но 100...200 Кб погоды не делают. Так ли > это на ваш взгляд? В первую очередь надо понимать, что задаваемые буфера - для _каждого_ запроса. Т.е. 32k буферов по умолчанию - при 1000 одновременных запросов это уже может потребовать до 32 мегабайт памяти. В целом, если сообщение появляется только иногда, а не возникает на типичных ответах - серьёзного повода что-либо менять нет. Но и от увеличения размера буферов в пару раз - тоже вряд ли станет хуже. -- Maxim Dounin http://nginx.org/ From nginx-forum на forum.nginx.org Tue Jan 17 14:56:27 2017 From: nginx-forum на forum.nginx.org (Vvedensky) Date: Tue, 17 Jan 2017 09:56:27 -0500 Subject: =?UTF-8?B?UmU6INCa0LXRiNC40YDQvtCy0LDQvdC40LUg0L7RgtCy0LXRgtCwIHBocC1mcG0=?= In-Reply-To: <20170117131208.GE45866@mdounin.ru> References: <20170117131208.GE45866@mdounin.ru> Message-ID: <68fad3fd529253087d54c526e0d122e7.NginxMailingListRussian@forum.nginx.org> Спасибо за подробный ответ. Несколько уточняющих вопросов: 1. Правильно ли я вас понял. Для каждого запроса буфер не забирается сразу целиком, а кусочками по 16k (если это буфер 8*16k). Соответственно 8*16k=128k при 1000 одновременных запросах займут 128М памяти только при условии, что а) nginx не будет их отдавать, б) что буфер каждого запроса будет израсходован целиком. На самом деле такая ситуация достаточно редкая и реальный размер использованной памяти будет меньше. Так ли это? 2. Попробовал сохранить одну из страниц, попадаемых в кеш в формате html, её размер получился 911k. Значит ли это, что размер fastcgi_buffers должен быть близким к этому значению? Posted at Nginx Forum: https://forum.nginx.org/read.php?21,271999,272025#msg-272025 From mdounin на mdounin.ru Tue Jan 17 16:29:00 2017 From: mdounin на mdounin.ru (Maxim Dounin) Date: Tue, 17 Jan 2017 19:29:00 +0300 Subject: =?UTF-8?B?UmU6INCa0LXRiNC40YDQvtCy0LDQvdC40LUg0L7RgtCy0LXRgtCwIHBocC1mcG0=?= In-Reply-To: <68fad3fd529253087d54c526e0d122e7.NginxMailingListRussian@forum.nginx.org> References: <20170117131208.GE45866@mdounin.ru> <68fad3fd529253087d54c526e0d122e7.NginxMailingListRussian@forum.nginx.org> Message-ID: <20170117162900.GF45866@mdounin.ru> Hello! On Tue, Jan 17, 2017 at 09:56:27AM -0500, Vvedensky wrote: > Спасибо за подробный ответ. Несколько уточняющих вопросов: > 1. Правильно ли я вас понял. Для каждого запроса буфер не забирается сразу > целиком, а кусочками по 16k (если это буфер 8*16k). Соответственно > 8*16k=128k при 1000 одновременных запросах займут 128М памяти только при > условии, что а) nginx не будет их отдавать, б) что буфер каждого запроса > будет израсходован целиком. На самом деле такая ситуация достаточно редкая и > реальный размер использованной памяти будет меньше. Так ли это? Да, всё так. > 2. Попробовал сохранить одну из страниц, попадаемых в кеш в формате html, её > размер получился 911k. Значит ли это, что размер fastcgi_buffers должен быть > близким к этому значению? Не могу сказать, что понял, размер чего именно вы посчитали. Наиболее правильно для оценки необходимого размера буферов - смотреть на значение переменной $upstream_response_length, т.е. на размер ответа, возвращаемый бекендом. Близкое значение обычно имеет $body_bytes_sent, значение которой логгируется по умолчанию (но там могут быть сильно другие значения, если вы жмёте ответы с помощью gzip-фильтра). -- Maxim Dounin http://nginx.org/ From nginx-forum на forum.nginx.org Tue Jan 17 17:49:06 2017 From: nginx-forum на forum.nginx.org (Vvedensky) Date: Tue, 17 Jan 2017 12:49:06 -0500 Subject: =?UTF-8?B?0J7Qs9GA0LDQvdC40YfQtdC90LjQtSDRh9Cw0YHRgtGL0YUg0LfQsNC/0YDQvtGB?= =?UTF-8?B?0L7Qsg==?= Message-ID: Здравствуйте. Вот конфигурационный файл nginx: server { server_name site.ru; listen 12.345.67.890:80; charset UTF-8; disable_symlinks if_not_owner from=$root_path; index index.html index.php; root $root_path; set $root_path /var/www/site1/data/www/site.ru; include /etc/nginx/vhosts-includes/*.conf; client_max_body_size 64M; location ^~ /core/ { try_files error-404 @modx; } location ^~ /config.core.php { try_files error-404 @modx; } location ~* ^.+\.(css|js|svg|jpg|jpeg|gif|png|ico|zip|rar|doc|xls|pdf|exe|wav|bmp|rtf)$ { client_max_body_size 128M; access_log off; expires 7d; break; } location / { try_files $uri $uri/ @modx; location ~ [^/]\.ph(p\d*|tml)$ { try_files /does_not_exists @php; } } location @modx { limit_req zone=one burst=3; rewrite ^/(.*)$ /index.php?q=$1&$args; } location @php { fastcgi_index index.php; fastcgi_buffers 8 16k; fastcgi_pass unix:/var/www/php-fpm/site1.sock; fastcgi_split_path_info ^((?U).+\.ph(?:p\d*|tml))(/?.+)$; try_files $uri @modx; include fastcgi_params; } } Есть следующая проблема: при нахождении файла в корневой директории его нужно обрабатывать по правилу location @modx и затем через fastcgi (это может быть как файл с расширением php, так и файл без расширения), частые запросы нужно ограничить. Если файл находится в папках /assets, /manager, /connectors и имеет расширение php, то его также нужно пропустить через fastcgi, при этом частота запросов к нему не должна быть ограничена. Не пойму как правильно составить правила обработки. Можете ли посоветовать какой-либо вариант? Posted at Nginx Forum: https://forum.nginx.org/read.php?21,272030,272030#msg-272030 From chipitsine на gmail.com Wed Jan 18 04:58:36 2017 From: chipitsine на gmail.com (=?UTF-8?B?0JjQu9GM0Y8g0KjQuNC/0LjRhtC40L0=?=) Date: Wed, 18 Jan 2017 09:58:36 +0500 Subject: =?UTF-8?B?UmU6INC/0LDRgtGHINC00LvRjyDQvtGC0LrQu9GO0YfQtdC90LjRjyDQt9Cw0LM=?= =?UTF-8?B?0L7Qu9C+0LLQutC+0LIgIkNvbm5lY3Rpb246IGtlZXAtYWxpdmUiICjQtdGJ?= =?UTF-8?B?0LUg0YDQsNC3KQ==?= In-Reply-To: <20161219122642.GB16033@lo0.su> References: <20131210163749.GL95113@mdounin.ru> <20131210184303.GR95113@mdounin.ru> <20131211144155.GW95113@mdounin.ru> <20131211180425.GC95113@mdounin.ru> <20131214175926.GK74021@lo0.su> <20161219122642.GB16033@lo0.su> Message-ID: 19 декабря 2016 г., 17:26 пользователь Ruslan Ermilov написал: > Приветствую! > > On Sun, Dec 18, 2016 at 10:33:19PM +0500, Илья Шипицин wrote: > > Руслан, добрый день! > > > > а может быть вы сможете закомитить ту версию патча, которую допустимо > > закомитить ? > > В смысле Вы предлагаете мне закоммитить патч Максима, который явно > обозначил (даже дважды), что не хотел бы его коммитить без тщательного > тестирования? Боюсь, в таком случае я знаю, каким будет следующий > коммит. :) > > Мне видится более правильным вариант, если Вы сообщите о результатах > проведённого Вами уже видимо трёхлетнего тестирования патча, который > предлагал Максим. > Руслан, может быть такой вариант - дефолтное поведение оставить неизменным, и добавить настройку, скажем "ядреная_оптимизация_кипэлайв on", энтузиасты включат (на свой риск), протестируют, и можно будет думать о том, чтобы поменять дефолтное поведение. > > > 14 декабря 2013 г., 23:59 пользователь Ruslan Ermilov > > написал: > > > > > On Wed, Dec 11, 2013 at 10:04:25PM +0400, Maxim Dounin wrote: > > > > Да сколько угодно, я ж разве возражаю? Только тогда патч не будет > > > > закоммичен из-за стилистических проблем. ;) > > > > > > Максим, закоммить пожалуйста свою версию патча и закроем вопрос. > > > (Мне твой вариант патча нравится больше.) > _______________________________________________ > nginx-ru mailing list > nginx-ru на nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru > ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From ru на nginx.com Thu Jan 19 08:08:14 2017 From: ru на nginx.com (Ruslan Ermilov) Date: Thu, 19 Jan 2017 11:08:14 +0300 Subject: =?UTF-8?B?UmU6INC/0LDRgtGHINC00LvRjyDQvtGC0LrQu9GO0YfQtdC90LjRjyDQt9Cw0LM=?= =?UTF-8?B?0L7Qu9C+0LLQutC+0LIgIkNvbm5lY3Rpb246IGtlZXAtYWxpdmUiICjQtdGJ?= =?UTF-8?B?0LUg0YDQsNC3KQ==?= In-Reply-To: References: <20131210184303.GR95113@mdounin.ru> <20131211144155.GW95113@mdounin.ru> <20131211180425.GC95113@mdounin.ru> <20131214175926.GK74021@lo0.su> <20161219122642.GB16033@lo0.su> Message-ID: <20170119080814.GA24083@lo0.su> Илья, приветствую! On Wed, Jan 18, 2017 at 09:58:36AM +0500, Илья Шипицин wrote: > 19 декабря 2016 г., 17:26 пользователь Ruslan Ermilov > написал: > > > Приветствую! > > > > On Sun, Dec 18, 2016 at 10:33:19PM +0500, Илья Шипицин wrote: > > > Руслан, добрый день! > > > > > > а может быть вы сможете закомитить ту версию патча, которую допустимо > > > закомитить ? > > > > В смысле Вы предлагаете мне закоммитить патч Максима, который явно > > обозначил (даже дважды), что не хотел бы его коммитить без тщательного > > тестирования? Боюсь, в таком случае я знаю, каким будет следующий > > коммит. :) > > > > Мне видится более правильным вариант, если Вы сообщите о результатах > > проведённого Вами уже видимо трёхлетнего тестирования патча, который > > предлагал Максим. > > > > Руслан, может быть такой вариант - дефолтное поведение оставить неизменным, > и добавить настройку, скажем "ядреная_оптимизация_кипэлайв on", энтузиасты > включат (на свой риск), протестируют, и можно будет думать о том, чтобы > поменять дефолтное поведение. Лично я в такой ручке вижу мало смысла. Есть готовый патч. Желающие могут его протестировать и сообщить о рез-тах тестирования. После чего патч будет скорее всего закоммичен. From chipitsine на gmail.com Thu Jan 19 08:40:08 2017 From: chipitsine на gmail.com (=?UTF-8?B?0JjQu9GM0Y8g0KjQuNC/0LjRhtC40L0=?=) Date: Thu, 19 Jan 2017 13:40:08 +0500 Subject: =?UTF-8?B?UmU6INC/0LDRgtGHINC00LvRjyDQvtGC0LrQu9GO0YfQtdC90LjRjyDQt9Cw0LM=?= =?UTF-8?B?0L7Qu9C+0LLQutC+0LIgIkNvbm5lY3Rpb246IGtlZXAtYWxpdmUiICjQtdGJ?= =?UTF-8?B?0LUg0YDQsNC3KQ==?= In-Reply-To: <20170119080814.GA24083@lo0.su> References: <20131210184303.GR95113@mdounin.ru> <20131211144155.GW95113@mdounin.ru> <20131211180425.GC95113@mdounin.ru> <20131214175926.GK74021@lo0.su> <20161219122642.GB16033@lo0.su> <20170119080814.GA24083@lo0.su> Message-ID: 19 января 2017 г., 13:08 пользователь Ruslan Ermilov написал: > Илья, приветствую! > > On Wed, Jan 18, 2017 at 09:58:36AM +0500, Илья Шипицин wrote: > > 19 декабря 2016 г., 17:26 пользователь Ruslan Ermilov > > написал: > > > > > Приветствую! > > > > > > On Sun, Dec 18, 2016 at 10:33:19PM +0500, Илья Шипицин wrote: > > > > Руслан, добрый день! > > > > > > > > а может быть вы сможете закомитить ту версию патча, которую допустимо > > > > закомитить ? > > > > > > В смысле Вы предлагаете мне закоммитить патч Максима, который явно > > > обозначил (даже дважды), что не хотел бы его коммитить без тщательного > > > тестирования? Боюсь, в таком случае я знаю, каким будет следующий > > > коммит. :) > > > > > > Мне видится более правильным вариант, если Вы сообщите о результатах > > > проведённого Вами уже видимо трёхлетнего тестирования патча, который > > > предлагал Максим. > > > > > > > Руслан, может быть такой вариант - дефолтное поведение оставить > неизменным, > > и добавить настройку, скажем "ядреная_оптимизация_кипэлайв on", > энтузиасты > > включат (на свой риск), протестируют, и можно будет думать о том, чтобы > > поменять дефолтное поведение. > > Лично я в такой ручке вижу мало смысла. Есть готовый патч. Желающие > могут его протестировать и сообщить о рез-тах тестирования. После > чего патч будет скорее всего закоммичен. > мы протестировали, у нас все хорошо > _______________________________________________ > nginx-ru mailing list > nginx-ru на nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru > ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From chipitsine на gmail.com Thu Jan 19 09:17:22 2017 From: chipitsine на gmail.com (=?UTF-8?B?0JjQu9GM0Y8g0KjQuNC/0LjRhtC40L0=?=) Date: Thu, 19 Jan 2017 14:17:22 +0500 Subject: =?UTF-8?B?UmU6INC/0LDRgtGHINC00LvRjyDQvtGC0LrQu9GO0YfQtdC90LjRjyDQt9Cw0LM=?= =?UTF-8?B?0L7Qu9C+0LLQutC+0LIgIkNvbm5lY3Rpb246IGtlZXAtYWxpdmUiICjQtdGJ?= =?UTF-8?B?0LUg0YDQsNC3KQ==?= In-Reply-To: <20170119080814.GA24083@lo0.su> References: <20131210184303.GR95113@mdounin.ru> <20131211144155.GW95113@mdounin.ru> <20131211180425.GC95113@mdounin.ru> <20131214175926.GK74021@lo0.su> <20161219122642.GB16033@lo0.su> <20170119080814.GA24083@lo0.su> Message-ID: 19 января 2017 г., 13:08 пользователь Ruslan Ermilov написал: > Илья, приветствую! > > On Wed, Jan 18, 2017 at 09:58:36AM +0500, Илья Шипицин wrote: > > 19 декабря 2016 г., 17:26 пользователь Ruslan Ermilov > > написал: > > > > > Приветствую! > > > > > > On Sun, Dec 18, 2016 at 10:33:19PM +0500, Илья Шипицин wrote: > > > > Руслан, добрый день! > > > > > > > > а может быть вы сможете закомитить ту версию патча, которую допустимо > > > > закомитить ? > > > > > > В смысле Вы предлагаете мне закоммитить патч Максима, который явно > > > обозначил (даже дважды), что не хотел бы его коммитить без тщательного > > > тестирования? Боюсь, в таком случае я знаю, каким будет следующий > > > коммит. :) > > > > > > Мне видится более правильным вариант, если Вы сообщите о результатах > > > проведённого Вами уже видимо трёхлетнего тестирования патча, который > > > предлагал Максим. > > > > > > > Руслан, может быть такой вариант - дефолтное поведение оставить > неизменным, > > и добавить настройку, скажем "ядреная_оптимизация_кипэлайв on", > энтузиасты > > включат (на свой риск), протестируют, и можно будет думать о том, чтобы > > поменять дефолтное поведение. > > Лично я в такой ручке вижу мало смысла. Есть готовый патч. Желающие > могут его протестировать и сообщить о рез-тах тестирования. После > чего патч будет скорее всего закоммичен. > кажется, тут может возникнуть двусмысленность. тестировали мы мою версию патча. вариант Максима я вижу менее логичным (ему хочется сравнивать версии протокола http аналогичным образом, как это делается для версий библиотеки openssl), функционально это одно и то же, но насчет тестирования патча Максима предлагаю вопросы задавать ему. и по прежнему, если вопрос в тестировании, предлагаю рассмотреть вариант с "рубильником" > _______________________________________________ > nginx-ru mailing list > nginx-ru на nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru > ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From nginx-forum на forum.nginx.org Fri Jan 20 16:34:55 2017 From: nginx-forum на forum.nginx.org (vitcool) Date: Fri, 20 Jan 2017 11:34:55 -0500 Subject: =?UTF-8?B?0J7Qv9GP0YLRjCDQv9GA0L4g0LrQtdGI0LjRgNC+0LLQsNC90LjQtQ==?= Message-ID: <05370d054939f234b047d31c98e637a0.NginxMailingListRussian@forum.nginx.org> кто нибудь исследовал тему, на каком минимальном времени кэширования его эффективность сходит на "нет"? допустим у нас 50..75 одновременных запросов к тяжелым динамическим страницам (чистый html) ставим nginx на фронт, настраиваем кэш этого локейшена допустим на 1 минуту насколько это решение рабочее? Posted at Nginx Forum: https://forum.nginx.org/read.php?21,272077,272077#msg-272077 From nginx на mva.name Fri Jan 20 16:57:12 2017 From: nginx на mva.name (Vadim A. Misbakh-Soloviov) Date: Fri, 20 Jan 2017 23:57:12 +0700 Subject: =?UTF-8?B?UmU6INCe0L/Rj9GC0Ywg0L/RgNC+INC60LXRiNC40YDQvtCy0LDQvdC40LU=?= In-Reply-To: <05370d054939f234b047d31c98e637a0.NginxMailingListRussian@forum.nginx.org> References: <05370d054939f234b047d31c98e637a0.NginxMailingListRussian@forum.nginx.org> Message-ID: <2383728.ZQ03Idca3G@note> > тяжелым динамическим страницам > чистый html 1) это как? Динамика, всё-таки, или статика? > чистый html > настраиваем кэш 2) Если всё же статика, то не проще было бы просто в tmpfs класть? From nginx-forum на forum.nginx.org Fri Jan 20 17:03:39 2017 From: nginx-forum на forum.nginx.org (vitcool) Date: Fri, 20 Jan 2017 12:03:39 -0500 Subject: =?UTF-8?B?UmU6INCe0L/Rj9GC0Ywg0L/RgNC+INC60LXRiNC40YDQvtCy0LDQvdC40LU=?= In-Reply-To: <2383728.ZQ03Idca3G@note> References: <2383728.ZQ03Idca3G@note> Message-ID: <28f2ee948f0bf223949f00139540138a.NginxMailingListRussian@forum.nginx.org> Vadim A. Misbakh-Soloviov Wrote: ------------------------------------------------------- > > тяжелым динамическим страницам > > чистый html > > 1) это как? Динамика, всё-таки, или статика? Динамика. Страница собирается иногда очень долго, каждые 10..15 минут обновление данных из которых она собирается. Таких страниц 2+ млн. Свое серверное кэширование на бекенде есть, так как он сейчас в роли фронтенда (там есть свой вебсервер). Posted at Nginx Forum: https://forum.nginx.org/read.php?21,272077,272079#msg-272079 From vbart на nginx.com Fri Jan 20 18:22:14 2017 From: vbart на nginx.com (=?utf-8?B?0JLQsNC70LXQvdGC0LjQvSDQkdCw0YDRgtC10L3QtdCy?=) Date: Fri, 20 Jan 2017 21:22:14 +0300 Subject: =?UTF-8?B?UmU6INCe0L/Rj9GC0Ywg0L/RgNC+INC60LXRiNC40YDQvtCy0LDQvdC40LU=?= In-Reply-To: <2383728.ZQ03Idca3G@note> References: <05370d054939f234b047d31c98e637a0.NginxMailingListRussian@forum.nginx.org> <2383728.ZQ03Idca3G@note> Message-ID: <4005910.TtcxxYkmmO@vbart-workstation> On Friday 20 January 2017 23:57:12 Vadim A. Misbakh-Soloviov wrote: > > тяжелым динамическим страницам > > чистый html > > 1) это как? Динамика, всё-таки, или статика? > > > чистый html > > настраиваем кэш > > 2) Если всё же статика, то не проще было бы просто в tmpfs класть? [..] Смысла хранения статики в tmpfs чаще всего нет никакого. Кэш страниц операционной системы работает не хуже. -- Валентин Бартенев From annulen на yandex.ru Fri Jan 20 18:43:16 2017 From: annulen на yandex.ru (Konstantin Tokarev) Date: Fri, 20 Jan 2017 21:43:16 +0300 Subject: =?UTF-8?B?UmU6INCe0L/Rj9GC0Ywg0L/RgNC+INC60LXRiNC40YDQvtCy0LDQvdC40LU=?= In-Reply-To: <4005910.TtcxxYkmmO@vbart-workstation> References: <05370d054939f234b047d31c98e637a0.NginxMailingListRussian@forum.nginx.org> <2383728.ZQ03Idca3G@note> <4005910.TtcxxYkmmO@vbart-workstation> Message-ID: <5723361484937796@web7m.yandex.ru> 20.01.2017, 21:22, "Валентин Бартенев" : > On Friday 20 January 2017 23:57:12 Vadim A. Misbakh-Soloviov wrote: >>  > тяжелым динамическим страницам >>  > чистый html >> >>  1) это как? Динамика, всё-таки, или статика? >> >>  > чистый html >>  > настраиваем кэш >> >>  2) Если всё же статика, то не проще было бы просто в tmpfs класть? > > [..] > > Смысла хранения статики в tmpfs чаще всего нет никакого. Кэш страниц > операционной системы работает не хуже. По факту tmpfs (по крайней мере, в Linux) - это файловая система, хранящая данные непосредственно в этом кэше. > > -- > Валентин Бартенев > _______________________________________________ > nginx-ru mailing list > nginx-ru на nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru -- Regards, Konstantin From kohaner на gmail.com Fri Jan 20 20:35:37 2017 From: kohaner на gmail.com (DK) Date: Sat, 21 Jan 2017 02:35:37 +0600 Subject: invalid parameter max_conns Message-ID: Добрый день, Согласно документации и change логу, начиная с версии 1.11.5 в комьюнити версии стал доступен параметр max_conns в модуле upstream Установил официальный бинарный пакет nginx/1.11.8 , centos6, i386. При попытке написать что-то вида upstream as_img_backend { server 127.0.0.1:80 max_conns=96; } получаю ошибку 2017/01/21 01:59:51 [emerg] 26498#26498: invalid parameter "max_conns=96" in /etc/nginx/conf.d/13_site.ru.conf:4 при этом configtest никаких ошибок не находит? В чем может быть ошибка? ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From vbart на nginx.com Sat Jan 21 05:32:30 2017 From: vbart на nginx.com (=?utf-8?B?0JLQsNC70LXQvdGC0LjQvSDQkdCw0YDRgtC10L3QtdCy?=) Date: Sat, 21 Jan 2017 08:32:30 +0300 Subject: invalid parameter max_conns In-Reply-To: References: Message-ID: <2120399.jl02x7djVA@vbart-laptop> On Saturday 21 January 2017 02:35:37 DK wrote: > Добрый день, > > Согласно документации и change логу, начиная с версии 1.11.5 в комьюнити > версии стал доступен параметр max_conns в модуле upstream > > Установил официальный бинарный пакет nginx/1.11.8 , centos6, i386. > > При попытке написать что-то вида > > upstream as_img_backend { > server 127.0.0.1:80 max_conns=96; > } > > получаю ошибку > > 2017/01/21 01:59:51 [emerg] 26498#26498: invalid parameter "max_conns=96" > in /etc/nginx/conf.d/13_site.ru.conf:4 > > при этом configtest никаких ошибок не находит? > > В чем может быть ошибка? В том, что запустить вы пытаетесь какую-то другую версию nginx, а не ту, что только что установили. -- Валентин Бартенев From laa на laa.zp.ua Sat Jan 21 09:32:10 2017 From: laa на laa.zp.ua (Lystopad Aleksandr) Date: Sat, 21 Jan 2017 11:32:10 +0200 Subject: =?UTF-8?B?UmU6INCe0L/Rj9GC0Ywg0L/RgNC+INC60LXRiNC40YDQvtCy0LDQvdC40LU=?= In-Reply-To: <4005910.TtcxxYkmmO@vbart-workstation> References: <05370d054939f234b047d31c98e637a0.NginxMailingListRussian@forum.nginx.org> <2383728.ZQ03Idca3G@note> <4005910.TtcxxYkmmO@vbart-workstation> Message-ID: <20170121093210.GB1234@laa.zp.ua> Hello, Валентин Бартенев! On Fri, Jan 20, 2017 at 09:22:14PM +0300 vbart на nginx.com wrote about "Re: Опять про кеширование": > On Friday 20 January 2017 23:57:12 Vadim A. Misbakh-Soloviov wrote: > > > тяжелым динамическим страницам > > > чистый html > > > > 1) это как? Динамика, всё-таки, или статика? > > > > > чистый html > > > настраиваем кэш > > > > 2) Если всё же статика, то не проще было бы просто в tmpfs класть? > [..] > > Смысла хранения статики в tmpfs чаще всего нет никакого. Кэш страниц > операционной системы работает не хуже. Валентин, спасибо за информацию. А вот, если взять виртуальную машину с nginx, скажем ec2. К ней идет поток зпросов на статический контент. Как разгрузить бэкенд? Оставить чтение с диска или настроить proxy_cache в tmpfs. Для двух случаев: back-end на этом же инстансе и на отдельном. Ну и сразу тот же вопрос, но относительно fastcgi_cache. ;) Заранее благодарю за ответы. From basil на vpm.net.ua Sat Jan 21 20:18:06 2017 From: basil на vpm.net.ua (Vasiliy P. Melnik) Date: Sat, 21 Jan 2017 22:18:06 +0200 Subject: =?UTF-8?B?UmU6INCe0L/Rj9GC0Ywg0L/RgNC+INC60LXRiNC40YDQvtCy0LDQvdC40LU=?= In-Reply-To: <20170121093210.GB1234@laa.zp.ua> References: <05370d054939f234b047d31c98e637a0.NginxMailingListRussian@forum.nginx.org> <2383728.ZQ03Idca3G@note> <4005910.TtcxxYkmmO@vbart-workstation> <20170121093210.GB1234@laa.zp.ua> Message-ID: > > Как разгрузить бэкенд? Оставить чтение с диска или настроить > proxy_cache в tmpfs. Для двух случаев: back-end на этом же > инстансе и на отдельном. > странный вопрос - если у вас данные статические и там лежат всегда, то тогда зачем их еще и кешировать. У меня, например, картинки генерятся: сначала складывали в статику средствами нжинкса - через try_files и запуск скрипта, если файла не оказывалось. Но после того, как пришлось такой кеш почистить - отдали кеширование нжинксу, во-первых он сам чистит кеш от старых файлов, во вторых - он не дергает директорию на наличие файла и плюс у него есть индексы по кешу. ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From vbart на nginx.com Sat Jan 21 23:52:46 2017 From: vbart на nginx.com (=?utf-8?B?0JLQsNC70LXQvdGC0LjQvSDQkdCw0YDRgtC10L3QtdCy?=) Date: Sun, 22 Jan 2017 02:52:46 +0300 Subject: =?UTF-8?B?UmU6INCe0L/Rj9GC0Ywg0L/RgNC+INC60LXRiNC40YDQvtCy0LDQvdC40LU=?= In-Reply-To: <20170121093210.GB1234@laa.zp.ua> References: <05370d054939f234b047d31c98e637a0.NginxMailingListRussian@forum.nginx.org> <4005910.TtcxxYkmmO@vbart-workstation> <20170121093210.GB1234@laa.zp.ua> Message-ID: <2269270.MfiX7xeQEp@vbart-laptop> On Saturday 21 January 2017 11:32:10 Lystopad Aleksandr wrote: > Hello, Валентин Бартенев! > > On Fri, Jan 20, 2017 at 09:22:14PM +0300 > vbart на nginx.com wrote about "Re: Опять про кеширование": > > On Friday 20 January 2017 23:57:12 Vadim A. Misbakh-Soloviov wrote: > > > > тяжелым динамическим страницам > > > > чистый html > > > > > > 1) это как? Динамика, всё-таки, или статика? > > > > > > > чистый html > > > > настраиваем кэш > > > > > > 2) Если всё же статика, то не проще было бы просто в tmpfs класть? > > [..] > > > > Смысла хранения статики в tmpfs чаще всего нет никакого. Кэш страниц > > операционной системы работает не хуже. > > Валентин, спасибо за информацию. > А вот, если взять виртуальную машину с nginx, скажем ec2. > К ней идет поток зпросов на статический контент. > Как разгрузить бэкенд? Оставить чтение с диска или настроить > proxy_cache в tmpfs. Для двух случаев: back-end на этом же > инстансе и на отдельном. > > Ну и сразу тот же вопрос, но относительно fastcgi_cache. ;) > > Заранее благодарю за ответы. [..] Кэш в nginx служит в первую очередь для кэширования динамического контента. Если статика у вас на где-то на бекенде лежит, то перенесите её на фронтенд тем же rsync-ом например. -- Валентин Бартенев From laa на laa.zp.ua Sun Jan 22 05:03:45 2017 From: laa на laa.zp.ua (Lystopad Aleksandr) Date: Sun, 22 Jan 2017 07:03:45 +0200 Subject: =?UTF-8?B?UmU6INCe0L/Rj9GC0Ywg0L/RgNC+INC60LXRiNC40YDQvtCy0LDQvdC40LU=?= In-Reply-To: References: <05370d054939f234b047d31c98e637a0.NginxMailingListRussian@forum.nginx.org> <2383728.ZQ03Idca3G@note> <4005910.TtcxxYkmmO@vbart-workstation> <20170121093210.GB1234@laa.zp.ua> Message-ID: <20170122050345.GC1234@laa.zp.ua> Hello, Vasiliy P. Melnik! On Sat, Jan 21, 2017 at 10:18:06PM +0200 basil на vpm.net.ua wrote about "Re: Опять про кеширование": > > > > Как разгрузить бэкенд? Оставить чтение с диска или настроить > > proxy_cache в tmpfs. Для двух случаев: back-end на этом же > > инстансе и на отдельном. > > > > странный вопрос - если у вас данные статические и там лежат всегда, то > тогда зачем их еще и кешировать. Спасибо за ответ! Отвечу, например, если у меня ec2 инстанс с каким-то небольшим лимитом IOPS. То отдавать статику из RAM или из disk может по-разному влиять на работу инстанса. > У меня, например, картинки генерятся: > сначала складывали в статику средствами нжинкса - через try_files и запуск > скрипта, если файла не оказывалось. Но после того, как пришлось такой кеш > почистить - отдали кеширование нжинксу, во-первых он сам чистит кеш от > старых файлов, во вторых - он не дергает директорию на наличие файла и плюс > у него есть индексы по кешу. From laa на laa.zp.ua Sun Jan 22 05:05:30 2017 From: laa на laa.zp.ua (Lystopad Aleksandr) Date: Sun, 22 Jan 2017 07:05:30 +0200 Subject: =?UTF-8?B?UmU6INCe0L/Rj9GC0Ywg0L/RgNC+INC60LXRiNC40YDQvtCy0LDQvdC40LU=?= In-Reply-To: <2269270.MfiX7xeQEp@vbart-laptop> References: <05370d054939f234b047d31c98e637a0.NginxMailingListRussian@forum.nginx.org> <4005910.TtcxxYkmmO@vbart-workstation> <20170121093210.GB1234@laa.zp.ua> <2269270.MfiX7xeQEp@vbart-laptop> Message-ID: <20170122050530.GD1234@laa.zp.ua> Hello, Валентин Бартенев! > > Валентин, спасибо за информацию. > > А вот, если взять виртуальную машину с nginx, скажем ec2. > > К ней идет поток зпросов на статический контент. > > Как разгрузить бэкенд? Оставить чтение с диска или настроить > > proxy_cache в tmpfs. Для двух случаев: back-end на этом же > > инстансе и на отдельном. > > > > Ну и сразу тот же вопрос, но относительно fastcgi_cache. ;) > > > > Заранее благодарю за ответы. > [..] > > Кэш в nginx служит в первую очередь для кэширования динамического контента. > Если статика у вас на где-то на бекенде лежит, то перенесите её на фронтенд > тем же rsync-ом например. Валентин, благодарю за ответ. Но, в этом случае это будет на front-end создавать IOPS, верно? В случае ec2-instance это может быть болезненно. From nginx-forum на forum.nginx.org Sun Jan 22 05:39:51 2017 From: nginx-forum на forum.nginx.org (ozz) Date: Sun, 22 Jan 2017 00:39:51 -0500 Subject: =?UTF-8?B?0JrQvtC90YHRgtCw0L3RgtCwIHJhbmQoKSBtb2QgcGVybA==?= Message-ID: Приветствую! Можно ли и как данную инструкцию вызвать один раз при запуске/перезапуске рабочего процесса? perl_set $c 'sub { return int(rand(99));}'; Posted at Nginx Forum: https://forum.nginx.org/read.php?21,272098,272098#msg-272098 From nginx-forum на forum.nginx.org Sun Jan 22 09:27:46 2017 From: nginx-forum на forum.nginx.org (S.A.N) Date: Sun, 22 Jan 2017 04:27:46 -0500 Subject: Best practices - url versioning static cache Message-ID: <2a1b430104df08537a3add72c1eba7d1.NginxMailingListRussian@forum.nginx.org> Здравствуйте. Для статичных файлов, есть старая добрая практика, добавлять в url, некий номер версии этого файла, клиентам отдавать в заготовках максимальное время кеширования, как-то так: expires max;