From izorkin на gmail.com Tue Jan 4 09:19:59 2022 From: izorkin на gmail.com (izorkin на gmail.com) Date: Tue, 4 Jan 2022 12:19:59 +0300 Subject: =?UTF-8?B?bmdpbnhRVUlDOiDQvdC1INGA0LDQsdC+0YLQsNC10YIg0YHQsNC50YIg0L/QvtGB?= =?UTF-8?B?0LvQtSDQutC+0LzQvNC40YLQsCA2Y2NmMzg2Nzk1OWE=?= Message-ID: <15897882.20220104121959@gmail.com> Здравствуйте. После последнего обновления nginxQUIC перестал открываться сайт на PeerTube - отображается пустая страница. Проверил разные сборки, перестал работать после этого коммита - 6ccf3867959a - QUIC: refactored ngx_quic_order_bufs() and ngx_quic_split_bufs(). Debug лог не влезает по размерам на pastebin.com? занимает 1 МБ. -- С уважением, Izorkin mailto:izorkin на gmail.com From nginx-forum на forum.nginx.org Tue Jan 4 10:49:34 2022 From: nginx-forum на forum.nginx.org (Vladislavik) Date: Tue, 04 Jan 2022 05:49:34 -0500 Subject: =?UTF-8?B?bmdpbnggcHJveHkgY2FjaGUg0LHQuNGC0YvQtSDRhNCw0LnQu9GL?= Message-ID: Добрый день, nginx проксирует запросы к удаленному бэкэнду. Удаленный nginx бэкэнд сжимает динамические ответы brotli и отдает через HTTP1.1 chunked_transfer_encoding. Иногда в кэше появляются не полные части файлов. Вопрос: nginx при наступлении proxy_cache_min_uses должен сохранить ответ, НО если ответ был не полным то nginx его все равно сохранит или перезапросит или отложит сохранение до следующего запроса? При разборе кэш файла из proxy_cache директории видно, что он был сжат и отправлялся по chunked_transfer_encoding без указания Content-Lenght. Nginx же по идее должен перед сохранением в кэш удостовериться, что файл получен полностью, с случае если Content-Lenght указан смотреть на полученный размер, если не указан, то ожидать чанка с содержимым "0" Posted at Nginx Forum: https://forum.nginx.org/read.php?21,293246,293246#msg-293246 From mdounin на mdounin.ru Wed Jan 5 12:35:53 2022 From: mdounin на mdounin.ru (Maxim Dounin) Date: Wed, 5 Jan 2022 15:35:53 +0300 Subject: =?UTF-8?B?UmU6IG5naW54IHByb3h5IGNhY2hlINCx0LjRgtGL0LUg0YTQsNC50LvRiw==?= In-Reply-To: References: Message-ID: Hello! On Tue, Jan 04, 2022 at 05:49:34AM -0500, Vladislavik wrote: > Добрый день, nginx проксирует запросы к удаленному бэкэнду. Удаленный nginx > бэкэнд сжимает динамические ответы brotli и отдает через HTTP1.1 > chunked_transfer_encoding. > > Иногда в кэше появляются не полные части файлов. Вопрос: nginx при > наступлении proxy_cache_min_uses должен сохранить ответ, НО если ответ был > не полным то nginx его все равно сохранит или перезапросит или отложит > сохранение до следующего запроса? > > При разборе кэш файла из proxy_cache директории видно, что он был сжат и > отправлялся по chunked_transfer_encoding без указания Content-Lenght. Nginx > же по идее должен перед сохранением в кэш удостовериться, что файл получен > полностью, с случае если Content-Lenght указан смотреть на полученный > размер, если не указан, то ожидать чанка с содержимым "0" Неполные ответы nginx не сохраняет. Однако есть нюанс: по умолчанию при работе с бэкендами nginx использует HTTP/1.0 (http://nginx.org/r/proxy_http_version), а значит "Transfer-Encoding: chunked" использоваться не будет, и соответственно для ответов без длины может быть невозможно установить, полный он или не полный. -- Maxim Dounin http://mdounin.ru/ From gmm на csdoc.com Wed Jan 5 12:59:46 2022 From: gmm на csdoc.com (Gena Makhomed) Date: Wed, 5 Jan 2022 14:59:46 +0200 Subject: =?UTF-8?B?UmU6IG5naW54IHByb3h5IGNhY2hlINCx0LjRgtGL0LUg0YTQsNC50LvRiw==?= In-Reply-To: References: Message-ID: On 05.01.2022 14:35, Maxim Dounin wrote: > Неполные ответы nginx не сохраняет. Однако есть нюанс: по > умолчанию при работе с бэкендами nginx использует HTTP/1.0 > (http://nginx.org/r/proxy_http_version), а значит > "Transfer-Encoding: chunked" использоваться не будет, и > соответственно для ответов без длины может быть невозможно > установить, полный он или не полный. А какой смысл по умолчанию при работе с бэкендами использовать HTTP/1.0 ? Ведь это же явно разложенные грабли (subj), на которые практически все рано или поздно наступают. Может быть имеет смысл изменить значение по умлолчанию, чтобы при работе с бэкендами использовался протокол HTTP/1.1 ? Преимуществ HTTP/1.0 не дает никаких, одни только проблемы. И ответа на этот вопрос в документации нет, почему так сделано. -- Best regards, Gena From chipitsine на gmail.com Wed Jan 5 13:19:45 2022 From: chipitsine на gmail.com (=?UTF-8?B?0JjQu9GM0Y8g0KjQuNC/0LjRhtC40L0=?=) Date: Wed, 5 Jan 2022 18:19:45 +0500 Subject: =?UTF-8?B?UmU6IG5naW54IHByb3h5IGNhY2hlINCx0LjRgtGL0LUg0YTQsNC50LvRiw==?= In-Reply-To: References: Message-ID: по соображениям обратной совместимости, вероятно. все, для кого важно, включили 1.1 ср, 5 янв. 2022 г. в 18:00, Gena Makhomed : > On 05.01.2022 14:35, Maxim Dounin wrote: > > > Неполные ответы nginx не сохраняет. Однако есть нюанс: по > > умолчанию при работе с бэкендами nginx использует HTTP/1.0 > > (http://nginx.org/r/proxy_http_version), а значит > > "Transfer-Encoding: chunked" использоваться не будет, и > > соответственно для ответов без длины может быть невозможно > > установить, полный он или не полный. > > А какой смысл по умолчанию при работе > с бэкендами использовать HTTP/1.0 ? > > Ведь это же явно разложенные грабли (subj), > на которые практически все рано или поздно наступают. > > Может быть имеет смысл изменить значение по умлолчанию, > чтобы при работе с бэкендами использовался протокол HTTP/1.1 ? > > Преимуществ HTTP/1.0 не дает никаких, одни только проблемы. > И ответа на этот вопрос в документации нет, почему так сделано. > > -- > Best regards, > Gena > _______________________________________________ > nginx-ru mailing list > nginx-ru на nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru ----------- следующая часть ----------- Вложение в формате HTML было извлечено… URL: From chipitsine на gmail.com Wed Jan 5 13:22:12 2022 From: chipitsine на gmail.com (=?UTF-8?B?0JjQu9GM0Y8g0KjQuNC/0LjRhtC40L0=?=) Date: Wed, 5 Jan 2022 18:22:12 +0500 Subject: =?UTF-8?B?UmU6IG5naW54IHByb3h5IGNhY2hlINCx0LjRgtGL0LUg0YTQsNC50LvRiw==?= In-Reply-To: References: Message-ID: я не адвокатирую HTTP/1.0 однако, гипотетически могут возникнуть грабли такого свойства - на http/1.0 не поддерживается gzip. из-за этого ваш бекенд всегда будет игнорировать компрессию. допустим, вы включили 1.1, бекенд отдал с компрессией, вы положили ответ в кеш. пришел клиент (без компрессии), вы ему отдали сжатое из кеша. маловероятно, что такое может быть (пример надуманный), но у клиента все сломается. ср, 5 янв. 2022 г. в 18:00, Gena Makhomed : > On 05.01.2022 14:35, Maxim Dounin wrote: > > > Неполные ответы nginx не сохраняет. Однако есть нюанс: по > > умолчанию при работе с бэкендами nginx использует HTTP/1.0 > > (http://nginx.org/r/proxy_http_version), а значит > > "Transfer-Encoding: chunked" использоваться не будет, и > > соответственно для ответов без длины может быть невозможно > > установить, полный он или не полный. > > А какой смысл по умолчанию при работе > с бэкендами использовать HTTP/1.0 ? > > Ведь это же явно разложенные грабли (subj), > на которые практически все рано или поздно наступают. > > Может быть имеет смысл изменить значение по умлолчанию, > чтобы при работе с бэкендами использовался протокол HTTP/1.1 ? > > Преимуществ HTTP/1.0 не дает никаких, одни только проблемы. > И ответа на этот вопрос в документации нет, почему так сделано. > > -- > Best regards, > Gena > _______________________________________________ > nginx-ru mailing list > nginx-ru на nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru ----------- следующая часть ----------- Вложение в формате HTML было извлечено… URL: From drug на qwarta.ru Mon Jan 10 14:40:44 2022 From: drug на qwarta.ru (=?windows-1251?B?xPPj6O0g0eXw4+Xp?=) Date: Mon, 10 Jan 2022 17:40:44 +0300 Subject: =?UTF-8?B?bmdpbngg0LXRgdGC0Ywg0LTQtdGB0Y/RgtC60Lgg0LPQuNCz0LDQsdCw0YIg0L8=?= =?UTF-8?B?0LDQvNGP0YLQuCDQuCDRgdC10YDQstC10YAg0YPRhdC+0LTQuNGCINCyIHN3?= =?UTF-8?B?YXA=?= Message-ID: <365132381.20220110174044@qwarta.ru> Здравствуйте, Nginx-ru. Помогите nginx в течении часа после запуска начинает жрать порядка 60-70 гигобайт памяти и дальше растет не хвтает свапа и сервер перегружать приходится если вовремя не килнуть и не перезапустить nginx Скриншот прилагаю. Была более старая версия, таже была проблема. В логе ошибок error_log /var/log/nginx/error.log warn; Ошибок нет Меня смущает только такие параметры в nginx: server_names_hash_max_size 131070; server_names_hash_bucket_size 128; Но если делать меньше nginx не запускается, так как порядка 2000 доменов в конфиге прописано. Подбирал эти числа на практике. Но даже с ними не понятно почему пару процессов nginx отжирают по 30 гиг RAM Больше идей нет, есть у кого-нибудь мысли как можно починить ситуацию? nginx version: nginx/1.20.2 built by gcc 4.8.5 20150623 (Red Hat 4.8.5-39) (GCC) built with OpenSSL 1.0.2k-fips 26 Jan 2017 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-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='-O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector-strong --param=ssp-buffer-size=4 -grecord-gcc-switches -m64 -mtune=generic -fPIC' --with-ld-opt='-Wl,-z,relro -Wl,-z,now -pie' cat /etc/os-release NAME="CloudLinux" VERSION="7.9 (Boris Yegorov)" ID="cloudlinux" Linux 3.10.0-962.3.2.lve1.5.42.el7.x86_64 #1 SMP Mon Nov 9 08:11:18 EST 2020 x86_64 x86_64 x86_64 GNU/Linux top - 17:33:50 up 12:18, 1 user, load average: 13.88, 13.09, 12.50 Tasks: 909 total, 7 running, 901 sleeping, 0 stopped, 1 zombie %Cpu(s): 12.1 us, 4.8 sy, 0.1 ni, 82.2 id, 0.3 wa, 0.0 hi, 0.6 si, 0.0 st KiB Mem : 13182188+total, 4598376 free, 75250656 used, 51972864 buff/cache KiB Swap: 10077298+total, 96888000 free, 3884988 used. 44158760 avail Mem PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 12785 root 20 0 35.0g 34.0g 2440 S 28.0 27.1 10:43.40 nginx 12807 root 20 0 14.4g 13.4g 2448 S 29.6 10.6 4:22.15 nginx 12805 root 20 0 2904776 1.8g 2588 S 3.0 1.4 1:10.02 nginx 12802 root 20 0 2880556 1.8g 2432 S 2.0 1.4 0:52.17 nginx 12799 root 20 0 2859616 1.8g 2452 S 1.6 1.4 0:31.47 nginx 12795 root 20 0 2844724 1.7g 2436 S 1.0 1.4 0:23.12 nginx 12793 root 20 0 2838340 1.7g 2548 S 0.3 1.4 0:19.55 nginx 12791 root 20 0 2831640 1.7g 2432 S 0.7 1.4 0:17.34 nginx 12779 root 20 0 2823876 1.7g 2404 S 0.3 1.4 0:12.40 nginx 12778 root 20 0 2821256 1.7g 2352 S 0.0 1.4 0:10.86 nginx 12777 root 20 0 2819208 1.7g 2392 S 0.7 1.4 0:09.13 nginx 12774 root 20 0 2816544 1.7g 2364 S 0.3 1.4 0:08.00 nginx 12771 root 20 0 2815748 1.7g 2392 S 0.7 1.4 0:07.82 nginx 12767 root 20 0 2813880 1.7g 2324 S 0.3 1.4 0:06.81 nginx 12763 root 20 0 2813828 1.7g 2348 S 0.0 1.4 0:06.76 nginx 12761 root 20 0 2813480 1.7g 2360 S 0.7 1.4 0:06.26 nginx 12760 root 20 0 2812952 1.7g 2376 S 0.0 1.4 0:05.89 nginx 12757 root 20 0 2812084 1.7g 2364 S 0.0 1.4 0:05.78 nginx 12707 root 20 0 2811584 1.7g 2304 S 0.3 1.4 0:02.55 nginx 12759 root 20 0 2811772 1.7g 2312 S 0.3 1.4 0:05.61 nginx 12694 root 20 0 2811380 1.7g 2288 S 0.3 1.4 0:02.06 nginx 12711 root 20 0 2811416 1.7g 2300 S 0.0 1.4 0:02.54 nginx 12686 root 20 0 2811228 1.7g 2288 S 0.0 1.4 0:01.14 nginx 12710 root 20 0 2811108 1.7g 2288 S 0.0 1.4 0:02.52 nginx 12752 root 20 0 2811060 1.7g 2316 S 0.3 1.4 0:04.99 nginx 12748 root 20 0 2811024 1.7g 2296 S 0.3 1.4 0:05.05 nginx 12745 root 20 0 2811144 1.7g 2288 S 0.3 1.4 0:04.58 nginx 12699 root 20 0 2811012 1.7g 2280 S 0.0 1.4 0:02.20 nginx 12728 root 20 0 2811028 1.7g 2276 S 0.0 1.4 0:03.09 nginx 12690 root 20 0 2811196 1.7g 2280 S 0.3 1.4 0:01.93 nginx 12754 root 20 0 2810868 1.7g 2272 S 0.0 1.4 0:04.98 nginx 12688 root 20 0 2810928 1.7g 2312 S 0.0 1.4 0:01.72 nginx 12732 root 20 0 2810948 1.7g 2276 S 0.0 1.4 0:03.34 nginx 12687 root 20 0 2810944 1.7g 2284 S 0.0 1.4 0:01.50 nginx 12703 root 20 0 2810852 1.7g 2292 S 0.3 1.4 0:02.23 nginx 12739 root 20 0 2810884 1.7g 2280 S 0.0 1.4 0:04.25 nginx 12738 root 20 0 2810916 1.7g 2296 S 0.3 1.4 0:04.03 nginx 12717 root 20 0 2810788 1.7g 2316 S 0.0 1.4 0:02.82 nginx 12742 root 20 0 2810768 1.7g 2276 S 0.0 1.4 0:04.38 nginx 12684 root 20 0 2810760 1.7g 2296 S 0.0 1.4 0:01.01 nginx 12682 root 20 0 2810676 1.7g 2280 S 0.0 1.4 0:00.88 nginx 12715 root 20 0 2810624 1.7g 2280 S 0.0 1.4 0:02.72 nginx 12734 root 20 0 2810600 1.7g 2280 S 0.0 1.4 0:03.49 nginx 12736 root 20 0 2810504 1.7g 2284 S 0.0 1.4 0:03.65 nginx 12731 root 20 0 2810480 1.7g 2280 S 0.0 1.4 0:03.14 nginx 12723 root 20 0 2810496 1.7g 2268 S 0.0 1.4 0:02.87 nginx 12737 root 20 0 2810660 1.7g 2280 S 0.3 1.4 0:03.89 nginx 12741 root 20 0 2810560 1.7g 2272 S 0.3 1.4 0:04.13 nginx 12681 root 20 0 2795668 1.7g 144 S 0.0 1.4 0:01.80 nginx -- С уважением, Дугин Сергей mailto:drug на qwarta.ru QWARTA From chipitsine на gmail.com Mon Jan 10 14:48:47 2022 From: chipitsine на gmail.com (=?UTF-8?B?0JjQu9GM0Y8g0KjQuNC/0LjRhtC40L0=?=) Date: Mon, 10 Jan 2022 17:48:47 +0300 Subject: =?UTF-8?B?UmU6IG5naW54INC10YHRgtGMINC00LXRgdGP0YLQutC4INCz0LjQs9Cw0LHQsNGC?= =?UTF-8?B?INC/0LDQvNGP0YLQuCDQuCDRgdC10YDQstC10YAg0YPRhdC+0LTQuNGCINCy?= =?UTF-8?B?IHN3YXA=?= In-Reply-To: <365132381.20220110174044@qwarta.ru> References: <365132381.20220110174044@qwarta.ru> Message-ID: reload делаете ? количество процессов-воркеров мониторите ? пн, 10 янв. 2022 г. в 17:41, Дугин Сергей : > Здравствуйте, Nginx-ru. > > Помогите nginx в течении часа после запуска начинает жрать порядка 60-70 > гигобайт памяти и дальше растет > не хвтает свапа и сервер перегружать приходится если вовремя не килнуть и > не перезапустить nginx > Скриншот прилагаю. > Была более старая версия, таже была проблема. > > В логе ошибок > error_log /var/log/nginx/error.log warn; > Ошибок нет > > Меня смущает только такие параметры в nginx: > server_names_hash_max_size 131070; > server_names_hash_bucket_size 128; > > Но если делать меньше nginx не запускается, так как порядка 2000 доменов в > конфиге прописано. Подбирал эти числа на практике. > Но даже с ними не понятно почему пару процессов nginx отжирают по 30 гиг > RAM > > Больше идей нет, есть у кого-нибудь мысли как можно починить ситуацию? > > nginx version: nginx/1.20.2 > > built by gcc 4.8.5 20150623 (Red Hat 4.8.5-39) (GCC) > built with OpenSSL 1.0.2k-fips 26 Jan 2017 > 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-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='-O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions > -fstack-protector-strong --param=ssp-buffer-size=4 -grecord-gcc-switches > -m64 -mtune=generic -fPIC' --with-ld-opt='-Wl,-z,relro -Wl,-z,now -pie' > > cat /etc/os-release > NAME="CloudLinux" > VERSION="7.9 (Boris Yegorov)" > ID="cloudlinux" > > Linux 3.10.0-962.3.2.lve1.5.42.el7.x86_64 #1 SMP Mon Nov 9 08:11:18 EST > 2020 x86_64 x86_64 x86_64 GNU/Linux > > > top - 17:33:50 up 12:18, 1 user, load average: 13.88, 13.09, 12.50 > Tasks: 909 total, 7 running, 901 sleeping, 0 stopped, 1 zombie > %Cpu(s): 12.1 us, 4.8 sy, 0.1 ni, 82.2 id, 0.3 wa, 0.0 hi, 0.6 si, > 0.0 st > KiB Mem : 13182188+total, 4598376 free, 75250656 used, 51972864 buff/cache > KiB Swap: 10077298+total, 96888000 free, 3884988 used. 44158760 avail Mem > > PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND > 12785 root 20 0 35.0g 34.0g 2440 S 28.0 27.1 10:43.40 nginx > 12807 root 20 0 14.4g 13.4g 2448 S 29.6 10.6 4:22.15 nginx > 12805 root 20 0 2904776 1.8g 2588 S 3.0 1.4 1:10.02 nginx > 12802 root 20 0 2880556 1.8g 2432 S 2.0 1.4 0:52.17 nginx > 12799 root 20 0 2859616 1.8g 2452 S 1.6 1.4 0:31.47 nginx > 12795 root 20 0 2844724 1.7g 2436 S 1.0 1.4 0:23.12 nginx > 12793 root 20 0 2838340 1.7g 2548 S 0.3 1.4 0:19.55 nginx > 12791 root 20 0 2831640 1.7g 2432 S 0.7 1.4 0:17.34 nginx > 12779 root 20 0 2823876 1.7g 2404 S 0.3 1.4 0:12.40 nginx > 12778 root 20 0 2821256 1.7g 2352 S 0.0 1.4 0:10.86 nginx > 12777 root 20 0 2819208 1.7g 2392 S 0.7 1.4 0:09.13 nginx > 12774 root 20 0 2816544 1.7g 2364 S 0.3 1.4 0:08.00 nginx > 12771 root 20 0 2815748 1.7g 2392 S 0.7 1.4 0:07.82 nginx > 12767 root 20 0 2813880 1.7g 2324 S 0.3 1.4 0:06.81 nginx > 12763 root 20 0 2813828 1.7g 2348 S 0.0 1.4 0:06.76 nginx > 12761 root 20 0 2813480 1.7g 2360 S 0.7 1.4 0:06.26 nginx > 12760 root 20 0 2812952 1.7g 2376 S 0.0 1.4 0:05.89 nginx > 12757 root 20 0 2812084 1.7g 2364 S 0.0 1.4 0:05.78 nginx > 12707 root 20 0 2811584 1.7g 2304 S 0.3 1.4 0:02.55 nginx > 12759 root 20 0 2811772 1.7g 2312 S 0.3 1.4 0:05.61 nginx > 12694 root 20 0 2811380 1.7g 2288 S 0.3 1.4 0:02.06 nginx > 12711 root 20 0 2811416 1.7g 2300 S 0.0 1.4 0:02.54 nginx > 12686 root 20 0 2811228 1.7g 2288 S 0.0 1.4 0:01.14 nginx > 12710 root 20 0 2811108 1.7g 2288 S 0.0 1.4 0:02.52 nginx > 12752 root 20 0 2811060 1.7g 2316 S 0.3 1.4 0:04.99 nginx > 12748 root 20 0 2811024 1.7g 2296 S 0.3 1.4 0:05.05 nginx > 12745 root 20 0 2811144 1.7g 2288 S 0.3 1.4 0:04.58 nginx > 12699 root 20 0 2811012 1.7g 2280 S 0.0 1.4 0:02.20 nginx > 12728 root 20 0 2811028 1.7g 2276 S 0.0 1.4 0:03.09 nginx > 12690 root 20 0 2811196 1.7g 2280 S 0.3 1.4 0:01.93 nginx > 12754 root 20 0 2810868 1.7g 2272 S 0.0 1.4 0:04.98 nginx > 12688 root 20 0 2810928 1.7g 2312 S 0.0 1.4 0:01.72 nginx > 12732 root 20 0 2810948 1.7g 2276 S 0.0 1.4 0:03.34 nginx > 12687 root 20 0 2810944 1.7g 2284 S 0.0 1.4 0:01.50 nginx > 12703 root 20 0 2810852 1.7g 2292 S 0.3 1.4 0:02.23 nginx > 12739 root 20 0 2810884 1.7g 2280 S 0.0 1.4 0:04.25 nginx > 12738 root 20 0 2810916 1.7g 2296 S 0.3 1.4 0:04.03 nginx > 12717 root 20 0 2810788 1.7g 2316 S 0.0 1.4 0:02.82 nginx > 12742 root 20 0 2810768 1.7g 2276 S 0.0 1.4 0:04.38 nginx > 12684 root 20 0 2810760 1.7g 2296 S 0.0 1.4 0:01.01 nginx > 12682 root 20 0 2810676 1.7g 2280 S 0.0 1.4 0:00.88 nginx > 12715 root 20 0 2810624 1.7g 2280 S 0.0 1.4 0:02.72 nginx > 12734 root 20 0 2810600 1.7g 2280 S 0.0 1.4 0:03.49 nginx > 12736 root 20 0 2810504 1.7g 2284 S 0.0 1.4 0:03.65 nginx > 12731 root 20 0 2810480 1.7g 2280 S 0.0 1.4 0:03.14 nginx > 12723 root 20 0 2810496 1.7g 2268 S 0.0 1.4 0:02.87 nginx > 12737 root 20 0 2810660 1.7g 2280 S 0.3 1.4 0:03.89 nginx > 12741 root 20 0 2810560 1.7g 2272 S 0.3 1.4 0:04.13 nginx > 12681 root 20 0 2795668 1.7g 144 S 0.0 1.4 0:01.80 nginx > > > -- > С уважением, > Дугин Сергей mailto:drug на qwarta.ru > QWARTA > > _______________________________________________ > nginx-ru mailing list > nginx-ru на nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru ----------- следующая часть ----------- Вложение в формате HTML было извлечено… URL: From drug на qwarta.ru Mon Jan 10 17:43:18 2022 From: drug на qwarta.ru (=?utf-8?B?0JTRg9Cz0LjQvSDQodC10YDQs9C10Lk=?=) Date: Mon, 10 Jan 2022 20:43:18 +0300 Subject: =?UTF-8?B?UmU6IG5naW54INC10YHRgtGMINC00LXRgdGP0YLQutC4INCz0LjQs9Cw0LHQsNGC?= =?UTF-8?B?INC/0LDQvNGP0YLQuCDQuCDRgdC10YDQstC10YAg0YPRhdC+0LTQuNGCINCy?= =?UTF-8?B?IHN3YXA=?= In-Reply-To: References: <365132381.20220110174044@qwarta.ru> Message-ID: <808904007.20220110204318@qwarta.ru> Здравствуйте, Илья. Да reload делал не помогает и через killall-9 nginx делал, воркеров пробовал и так worker_processes auto; и так worker_processes 6; Памяти на сервере 128 гиг 48 ядер и из 128 гиг более 80 гиг кушает nginx Вы писали 10 января 2022 г., 17:48:47: > reload делаете ? количество процессов-воркеров мониторите ? > пн, 10 янв. 2022 г. в 17:41, Дугин Сергей : >> Здравствуйте, Nginx-ru. >> >> Помогите nginx в течении часа после запуска начинает жрать порядка 60-70 >> гигобайт памяти и дальше растет >> не хвтает свапа и сервер перегружать приходится если вовремя не килнуть и >> не перезапустить nginx >> Скриншот прилагаю. >> Была более старая версия, таже была проблема. >> >> В логе ошибок >> error_log /var/log/nginx/error.log warn; >> Ошибок нет >> >> Меня смущает только такие параметры в nginx: >> server_names_hash_max_size 131070; >> server_names_hash_bucket_size 128; >> >> Но если делать меньше nginx не запускается, так как порядка 2000 доменов в >> конфиге прописано. Подбирал эти числа на практике. >> Но даже с ними не понятно почему пару процессов nginx отжирают по 30 гиг >> RAM >> >> Больше идей нет, есть у кого-нибудь мысли как можно починить ситуацию? >> >> nginx version: nginx/1.20.2 >> >> built by gcc 4.8.5 20150623 (Red Hat 4.8.5-39) (GCC) >> built with OpenSSL 1.0.2k-fips 26 Jan 2017 >> 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-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='-O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions >> -fstack-protector-strong --param=ssp-buffer-size=4 -grecord-gcc-switches >> -m64 -mtune=generic -fPIC' --with-ld-opt='-Wl,-z,relro -Wl,-z,now -pie' >> >> cat /etc/os-release >> NAME="CloudLinux" >> VERSION="7.9 (Boris Yegorov)" >> ID="cloudlinux" >> >> Linux 3.10.0-962.3.2.lve1.5.42.el7.x86_64 #1 SMP Mon Nov 9 08:11:18 EST >> 2020 x86_64 x86_64 x86_64 GNU/Linux >> >> >> top - 17:33:50 up 12:18, 1 user, load average: 13.88, 13.09, 12.50 >> Tasks: 909 total, 7 running, 901 sleeping, 0 stopped, 1 zombie >> %Cpu(s): 12.1 us, 4.8 sy, 0.1 ni, 82.2 id, 0.3 wa, 0.0 hi, 0.6 si, >> 0.0 st >> KiB Mem : 13182188+total, 4598376 free, 75250656 used, 51972864 buff/cache >> KiB Swap: 10077298+total, 96888000 free, 3884988 used. 44158760 avail Mem >> >> PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND >> 12785 root 20 0 35.0g 34.0g 2440 S 28.0 27.1 10:43.40 nginx >> 12807 root 20 0 14.4g 13.4g 2448 S 29.6 10.6 4:22.15 nginx >> 12805 root 20 0 2904776 1.8g 2588 S 3.0 1.4 1:10.02 nginx >> 12802 root 20 0 2880556 1.8g 2432 S 2.0 1.4 0:52.17 nginx >> 12799 root 20 0 2859616 1.8g 2452 S 1.6 1.4 0:31.47 nginx >> 12795 root 20 0 2844724 1.7g 2436 S 1.0 1.4 0:23.12 nginx >> 12793 root 20 0 2838340 1.7g 2548 S 0.3 1.4 0:19.55 nginx >> 12791 root 20 0 2831640 1.7g 2432 S 0.7 1.4 0:17.34 nginx >> 12779 root 20 0 2823876 1.7g 2404 S 0.3 1.4 0:12.40 nginx >> 12778 root 20 0 2821256 1.7g 2352 S 0.0 1.4 0:10.86 nginx >> 12777 root 20 0 2819208 1.7g 2392 S 0.7 1.4 0:09.13 nginx >> 12774 root 20 0 2816544 1.7g 2364 S 0.3 1.4 0:08.00 nginx >> 12771 root 20 0 2815748 1.7g 2392 S 0.7 1.4 0:07.82 nginx >> 12767 root 20 0 2813880 1.7g 2324 S 0.3 1.4 0:06.81 nginx >> 12763 root 20 0 2813828 1.7g 2348 S 0.0 1.4 0:06.76 nginx >> 12761 root 20 0 2813480 1.7g 2360 S 0.7 1.4 0:06.26 nginx >> 12760 root 20 0 2812952 1.7g 2376 S 0.0 1.4 0:05.89 nginx >> 12757 root 20 0 2812084 1.7g 2364 S 0.0 1.4 0:05.78 nginx >> 12707 root 20 0 2811584 1.7g 2304 S 0.3 1.4 0:02.55 nginx >> 12759 root 20 0 2811772 1.7g 2312 S 0.3 1.4 0:05.61 nginx >> 12694 root 20 0 2811380 1.7g 2288 S 0.3 1.4 0:02.06 nginx >> 12711 root 20 0 2811416 1.7g 2300 S 0.0 1.4 0:02.54 nginx >> 12686 root 20 0 2811228 1.7g 2288 S 0.0 1.4 0:01.14 nginx >> 12710 root 20 0 2811108 1.7g 2288 S 0.0 1.4 0:02.52 nginx >> 12752 root 20 0 2811060 1.7g 2316 S 0.3 1.4 0:04.99 nginx >> 12748 root 20 0 2811024 1.7g 2296 S 0.3 1.4 0:05.05 nginx >> 12745 root 20 0 2811144 1.7g 2288 S 0.3 1.4 0:04.58 nginx >> 12699 root 20 0 2811012 1.7g 2280 S 0.0 1.4 0:02.20 nginx >> 12728 root 20 0 2811028 1.7g 2276 S 0.0 1.4 0:03.09 nginx >> 12690 root 20 0 2811196 1.7g 2280 S 0.3 1.4 0:01.93 nginx >> 12754 root 20 0 2810868 1.7g 2272 S 0.0 1.4 0:04.98 nginx >> 12688 root 20 0 2810928 1.7g 2312 S 0.0 1.4 0:01.72 nginx >> 12732 root 20 0 2810948 1.7g 2276 S 0.0 1.4 0:03.34 nginx >> 12687 root 20 0 2810944 1.7g 2284 S 0.0 1.4 0:01.50 nginx >> 12703 root 20 0 2810852 1.7g 2292 S 0.3 1.4 0:02.23 nginx >> 12739 root 20 0 2810884 1.7g 2280 S 0.0 1.4 0:04.25 nginx >> 12738 root 20 0 2810916 1.7g 2296 S 0.3 1.4 0:04.03 nginx >> 12717 root 20 0 2810788 1.7g 2316 S 0.0 1.4 0:02.82 nginx >> 12742 root 20 0 2810768 1.7g 2276 S 0.0 1.4 0:04.38 nginx >> 12684 root 20 0 2810760 1.7g 2296 S 0.0 1.4 0:01.01 nginx >> 12682 root 20 0 2810676 1.7g 2280 S 0.0 1.4 0:00.88 nginx >> 12715 root 20 0 2810624 1.7g 2280 S 0.0 1.4 0:02.72 nginx >> 12734 root 20 0 2810600 1.7g 2280 S 0.0 1.4 0:03.49 nginx >> 12736 root 20 0 2810504 1.7g 2284 S 0.0 1.4 0:03.65 nginx >> 12731 root 20 0 2810480 1.7g 2280 S 0.0 1.4 0:03.14 nginx >> 12723 root 20 0 2810496 1.7g 2268 S 0.0 1.4 0:02.87 nginx >> 12737 root 20 0 2810660 1.7g 2280 S 0.3 1.4 0:03.89 nginx >> 12741 root 20 0 2810560 1.7g 2272 S 0.3 1.4 0:04.13 nginx >> 12681 root 20 0 2795668 1.7g 144 S 0.0 1.4 0:01.80 nginx >> >> >> -- >> С уважением, >> Дугин Сергей mailto:drug на qwarta.ru >> QWARTA >> >> _______________________________________________ >> nginx-ru mailing list >> nginx-ru на nginx.org >> http://mailman.nginx.org/mailman/listinfo/nginx-ru -- С уважением, Дугин Сергей mailto:drug на qwarta.ru QWARTA From chipitsine на gmail.com Mon Jan 10 18:43:07 2022 From: chipitsine на gmail.com (=?UTF-8?B?0JjQu9GM0Y8g0KjQuNC/0LjRhtC40L0=?=) Date: Mon, 10 Jan 2022 21:43:07 +0300 Subject: =?UTF-8?B?UmU6IG5naW54INC10YHRgtGMINC00LXRgdGP0YLQutC4INCz0LjQs9Cw0LHQsNGC?= =?UTF-8?B?INC/0LDQvNGP0YLQuCDQuCDRgdC10YDQstC10YAg0YPRhdC+0LTQuNGCINCy?= =?UTF-8?B?IHN3YXA=?= In-Reply-To: <808904007.20220110204318@qwarta.ru> References: <365132381.20220110174044@qwarta.ru> <808904007.20220110204318@qwarta.ru> Message-ID: При релоаде у вас запускаются новые воркеры, а старые остаются запущенными (при правильной настройке они будут завершены). Я имею в виду, мониьорите ли вы количество воркеров On Mon, Jan 10, 2022, 8:43 PM Дугин Сергей wrote: > Здравствуйте, Илья. > > Да reload делал не помогает и через killall-9 nginx делал, > воркеров пробовал и так > worker_processes auto; > и так > worker_processes 6; > > Памяти на сервере 128 гиг > 48 ядер > и из 128 гиг более 80 гиг кушает nginx > > > Вы писали 10 января 2022 г., 17:48:47: > > > reload делаете ? количество процессов-воркеров мониторите ? > > > пн, 10 янв. 2022 г. в 17:41, Дугин Сергей : > > >> Здравствуйте, Nginx-ru. > >> > >> Помогите nginx в течении часа после запуска начинает жрать порядка 60-70 > >> гигобайт памяти и дальше растет > >> не хвтает свапа и сервер перегружать приходится если вовремя не килнуть > и > >> не перезапустить nginx > >> Скриншот прилагаю. > >> Была более старая версия, таже была проблема. > >> > >> В логе ошибок > >> error_log /var/log/nginx/error.log warn; > >> Ошибок нет > >> > >> Меня смущает только такие параметры в nginx: > >> server_names_hash_max_size 131070; > >> server_names_hash_bucket_size 128; > >> > >> Но если делать меньше nginx не запускается, так как порядка 2000 > доменов в > >> конфиге прописано. Подбирал эти числа на практике. > >> Но даже с ними не понятно почему пару процессов nginx отжирают по 30 гиг > >> RAM > >> > >> Больше идей нет, есть у кого-нибудь мысли как можно починить ситуацию? > >> > >> nginx version: nginx/1.20.2 > >> > >> built by gcc 4.8.5 20150623 (Red Hat 4.8.5-39) (GCC) > >> built with OpenSSL 1.0.2k-fips 26 Jan 2017 > >> 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-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='-O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions > >> -fstack-protector-strong --param=ssp-buffer-size=4 -grecord-gcc-switches > >> -m64 -mtune=generic -fPIC' --with-ld-opt='-Wl,-z,relro -Wl,-z,now -pie' > >> > >> cat /etc/os-release > >> NAME="CloudLinux" > >> VERSION="7.9 (Boris Yegorov)" > >> ID="cloudlinux" > >> > >> Linux 3.10.0-962.3.2.lve1.5.42.el7.x86_64 #1 SMP Mon Nov 9 08:11:18 EST > >> 2020 x86_64 x86_64 x86_64 GNU/Linux > >> > >> > >> top - 17:33:50 up 12:18, 1 user, load average: 13.88, 13.09, 12.50 > >> Tasks: 909 total, 7 running, 901 sleeping, 0 stopped, 1 zombie > >> %Cpu(s): 12.1 us, 4.8 sy, 0.1 ni, 82.2 id, 0.3 wa, 0.0 hi, 0.6 si, > >> 0.0 st > >> KiB Mem : 13182188+total, 4598376 free, 75250656 used, 51972864 > buff/cache > >> KiB Swap: 10077298+total, 96888000 free, 3884988 used. 44158760 avail > Mem > >> > >> PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ > COMMAND > >> 12785 root 20 0 35.0g 34.0g 2440 S 28.0 27.1 10:43.40 > nginx > >> 12807 root 20 0 14.4g 13.4g 2448 S 29.6 10.6 4:22.15 > nginx > >> 12805 root 20 0 2904776 1.8g 2588 S 3.0 1.4 1:10.02 > nginx > >> 12802 root 20 0 2880556 1.8g 2432 S 2.0 1.4 0:52.17 > nginx > >> 12799 root 20 0 2859616 1.8g 2452 S 1.6 1.4 0:31.47 > nginx > >> 12795 root 20 0 2844724 1.7g 2436 S 1.0 1.4 0:23.12 > nginx > >> 12793 root 20 0 2838340 1.7g 2548 S 0.3 1.4 0:19.55 > nginx > >> 12791 root 20 0 2831640 1.7g 2432 S 0.7 1.4 0:17.34 > nginx > >> 12779 root 20 0 2823876 1.7g 2404 S 0.3 1.4 0:12.40 > nginx > >> 12778 root 20 0 2821256 1.7g 2352 S 0.0 1.4 0:10.86 > nginx > >> 12777 root 20 0 2819208 1.7g 2392 S 0.7 1.4 0:09.13 > nginx > >> 12774 root 20 0 2816544 1.7g 2364 S 0.3 1.4 0:08.00 > nginx > >> 12771 root 20 0 2815748 1.7g 2392 S 0.7 1.4 0:07.82 > nginx > >> 12767 root 20 0 2813880 1.7g 2324 S 0.3 1.4 0:06.81 > nginx > >> 12763 root 20 0 2813828 1.7g 2348 S 0.0 1.4 0:06.76 > nginx > >> 12761 root 20 0 2813480 1.7g 2360 S 0.7 1.4 0:06.26 > nginx > >> 12760 root 20 0 2812952 1.7g 2376 S 0.0 1.4 0:05.89 > nginx > >> 12757 root 20 0 2812084 1.7g 2364 S 0.0 1.4 0:05.78 > nginx > >> 12707 root 20 0 2811584 1.7g 2304 S 0.3 1.4 0:02.55 > nginx > >> 12759 root 20 0 2811772 1.7g 2312 S 0.3 1.4 0:05.61 > nginx > >> 12694 root 20 0 2811380 1.7g 2288 S 0.3 1.4 0:02.06 > nginx > >> 12711 root 20 0 2811416 1.7g 2300 S 0.0 1.4 0:02.54 > nginx > >> 12686 root 20 0 2811228 1.7g 2288 S 0.0 1.4 0:01.14 > nginx > >> 12710 root 20 0 2811108 1.7g 2288 S 0.0 1.4 0:02.52 > nginx > >> 12752 root 20 0 2811060 1.7g 2316 S 0.3 1.4 0:04.99 > nginx > >> 12748 root 20 0 2811024 1.7g 2296 S 0.3 1.4 0:05.05 > nginx > >> 12745 root 20 0 2811144 1.7g 2288 S 0.3 1.4 0:04.58 > nginx > >> 12699 root 20 0 2811012 1.7g 2280 S 0.0 1.4 0:02.20 > nginx > >> 12728 root 20 0 2811028 1.7g 2276 S 0.0 1.4 0:03.09 > nginx > >> 12690 root 20 0 2811196 1.7g 2280 S 0.3 1.4 0:01.93 > nginx > >> 12754 root 20 0 2810868 1.7g 2272 S 0.0 1.4 0:04.98 > nginx > >> 12688 root 20 0 2810928 1.7g 2312 S 0.0 1.4 0:01.72 > nginx > >> 12732 root 20 0 2810948 1.7g 2276 S 0.0 1.4 0:03.34 > nginx > >> 12687 root 20 0 2810944 1.7g 2284 S 0.0 1.4 0:01.50 > nginx > >> 12703 root 20 0 2810852 1.7g 2292 S 0.3 1.4 0:02.23 > nginx > >> 12739 root 20 0 2810884 1.7g 2280 S 0.0 1.4 0:04.25 > nginx > >> 12738 root 20 0 2810916 1.7g 2296 S 0.3 1.4 0:04.03 > nginx > >> 12717 root 20 0 2810788 1.7g 2316 S 0.0 1.4 0:02.82 > nginx > >> 12742 root 20 0 2810768 1.7g 2276 S 0.0 1.4 0:04.38 > nginx > >> 12684 root 20 0 2810760 1.7g 2296 S 0.0 1.4 0:01.01 > nginx > >> 12682 root 20 0 2810676 1.7g 2280 S 0.0 1.4 0:00.88 > nginx > >> 12715 root 20 0 2810624 1.7g 2280 S 0.0 1.4 0:02.72 > nginx > >> 12734 root 20 0 2810600 1.7g 2280 S 0.0 1.4 0:03.49 > nginx > >> 12736 root 20 0 2810504 1.7g 2284 S 0.0 1.4 0:03.65 > nginx > >> 12731 root 20 0 2810480 1.7g 2280 S 0.0 1.4 0:03.14 > nginx > >> 12723 root 20 0 2810496 1.7g 2268 S 0.0 1.4 0:02.87 > nginx > >> 12737 root 20 0 2810660 1.7g 2280 S 0.3 1.4 0:03.89 > nginx > >> 12741 root 20 0 2810560 1.7g 2272 S 0.3 1.4 0:04.13 > nginx > >> 12681 root 20 0 2795668 1.7g 144 S 0.0 1.4 0:01.80 > nginx > >> > >> > >> -- > >> С уважением, > >> Дугин Сергей mailto:drug на qwarta.ru > >> QWARTA > >> > >> _______________________________________________ > >> nginx-ru mailing list > >> nginx-ru на nginx.org > >> http://mailman.nginx.org/mailman/listinfo/nginx-ru > > > > -- > С уважением, > Дугин Сергей mailto:drug на qwarta.ru > QWARTA > > _______________________________________________ > nginx-ru mailing list > nginx-ru на nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru ----------- следующая часть ----------- Вложение в формате HTML было извлечено… URL: From mdounin на mdounin.ru Mon Jan 10 19:07:16 2022 From: mdounin на mdounin.ru (Maxim Dounin) Date: Mon, 10 Jan 2022 22:07:16 +0300 Subject: =?UTF-8?B?UmU6IG5naW54INC10YHRgtGMINC00LXRgdGP0YLQutC4INCz0LjQs9Cw0LHQsNGC?= =?UTF-8?B?INC/0LDQvNGP0YLQuCDQuCDRgdC10YDQstC10YAg0YPRhdC+0LTQuNGCINCy?= =?UTF-8?B?IHN3YXA=?= In-Reply-To: <365132381.20220110174044@qwarta.ru> References: <365132381.20220110174044@qwarta.ru> Message-ID: Hello! On Mon, Jan 10, 2022 at 05:40:44PM +0300, Дугин Сергей wrote: > Помогите nginx в течении часа после запуска начинает жрать порядка 60-70 гигобайт памяти и дальше растет > не хвтает свапа и сервер перегружать приходится если вовремя не килнуть и не перезапустить nginx > Скриншот прилагаю. > Была более старая версия, таже была проблема. > > В логе ошибок > error_log /var/log/nginx/error.log warn; > Ошибок нет > > Меня смущает только такие параметры в nginx: > server_names_hash_max_size 131070; > server_names_hash_bucket_size 128; > > Но если делать меньше nginx не запускается, так как порядка 2000 доменов в конфиге прописано. Подбирал эти числа на практике. > Но даже с ними не понятно почему пару процессов nginx отжирают по 30 гиг RAM Эти параметры точно ни при чём: хэши строятся один раз при чтении конфига, и не могут приводить к последующему росту потребления памяти отдельными рабочими процессами. > Больше идей нет, есть у кого-нибудь мысли как можно починить ситуацию? А что при этом в конфиге? В частности, worker_connections и всевозможные буфера (client_header_buffer_size, large_client_header_buffers, client_body_buffer_size, proxy_buffer_size, proxy_buffers, output_buffers и так далее)? Если включён HTTP/2 - то ещё и http2_max_concurrent_streams. Отдельно интересно нет ли в конфиге сторонних модулей. А если есть, то воспроизводится ли проблема без них. [...] > cat /etc/os-release > NAME="CloudLinux" > VERSION="7.9 (Boris Yegorov)" > ID="cloudlinux" > > Linux 3.10.0-962.3.2.lve1.5.42.el7.x86_64 #1 SMP Mon Nov 9 08:11:18 EST 2020 x86_64 x86_64 x86_64 GNU/Linux > > > top - 17:33:50 up 12:18, 1 user, load average: 13.88, 13.09, 12.50 > Tasks: 909 total, 7 running, 901 sleeping, 0 stopped, 1 zombie > %Cpu(s): 12.1 us, 4.8 sy, 0.1 ni, 82.2 id, 0.3 wa, 0.0 hi, 0.6 si, 0.0 st > KiB Mem : 13182188+total, 4598376 free, 75250656 used, 51972864 buff/cache > KiB Swap: 10077298+total, 96888000 free, 3884988 used. 44158760 avail Mem > > PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND > 12785 root 20 0 35.0g 34.0g 2440 S 28.0 27.1 10:43.40 nginx > 12807 root 20 0 14.4g 13.4g 2448 S 29.6 10.6 4:22.15 nginx > 12805 root 20 0 2904776 1.8g 2588 S 3.0 1.4 1:10.02 nginx > 12802 root 20 0 2880556 1.8g 2432 S 2.0 1.4 0:52.17 nginx > 12799 root 20 0 2859616 1.8g 2452 S 1.6 1.4 0:31.47 nginx Судя по всему, растут те процессы, которые собственно занимаются обработкой соединений: на современных линуксах распределение соединений между рабочими процессами может быть сильно неравномерным, лечить проще всего включением accept_mutex'а (https://trac.nginx.org/nginx/ticket/2285). Почему растут - отдельный вопрос. Для начала, наверное, стоит посмотреть, до какого размера процессы могут расти по памяти в соответствии с текущими настройками. Грубая оценка максимального потребления памяти одним рабочим процессом - worker_connections * <сумма всех буферов>. Если она не превышена - то вопрос, скорее, в настройках, не соответствующих имеющемуся объёму памяти. Если превышена - то имеет смысл разбираться дальше. -- Maxim Dounin http://mdounin.ru/ From drug на qwarta.ru Tue Jan 11 02:27:57 2022 From: drug на qwarta.ru (=?utf-8?B?0JTRg9Cz0LjQvSDQodC10YDQs9C10Lk=?=) Date: Tue, 11 Jan 2022 05:27:57 +0300 Subject: =?UTF-8?B?UmU6IG5naW54INC10YHRgtGMINC00LXRgdGP0YLQutC4INCz0LjQs9Cw0LHQsNGC?= =?UTF-8?B?INC/0LDQvNGP0YLQuCDQuCDRgdC10YDQstC10YAg0YPRhdC+0LTQuNGCINCy?= =?UTF-8?B?IHN3YXA=?= In-Reply-To: References: <365132381.20220110174044@qwarta.ru> <808904007.20220110204318@qwarta.ru> Message-ID: <1432168869.20220111052757@qwarta.ru> Здравствуйте, Илья. Вы писали 10 января 2022 г., 21:43:07: > При релоаде у вас запускаются новые воркеры, а старые остаются запущенными > (при правильной настройке они будут завершены). Я имею в виду, мониьорите > ли вы количество воркеров да, их контролирую. > On Mon, Jan 10, 2022, 8:43 PM Дугин Сергей wrote: >> Здравствуйте, Илья. >> >> Да reload делал не помогает и через killall-9 nginx делал, >> воркеров пробовал и так >> worker_processes auto; >> и так >> worker_processes 6; >> >> Памяти на сервере 128 гиг >> 48 ядер >> и из 128 гиг более 80 гиг кушает nginx >> >> >> Вы писали 10 января 2022 г., 17:48:47: >> >> > reload делаете ? количество процессов-воркеров мониторите ? >> >> > пн, 10 янв. 2022 г. в 17:41, Дугин Сергей : >> >> >> Здравствуйте, Nginx-ru. >> >> >> >> Помогите nginx в течении часа после запуска начинает жрать порядка 60-70 >> >> гигобайт памяти и дальше растет >> >> не хвтает свапа и сервер перегружать приходится если вовремя не килнуть >> и >> >> не перезапустить nginx >> >> Скриншот прилагаю. >> >> Была более старая версия, таже была проблема. >> >> >> >> В логе ошибок >> >> error_log /var/log/nginx/error.log warn; >> >> Ошибок нет >> >> >> >> Меня смущает только такие параметры в nginx: >> >> server_names_hash_max_size 131070; >> >> server_names_hash_bucket_size 128; >> >> >> >> Но если делать меньше nginx не запускается, так как порядка 2000 >> доменов в >> >> конфиге прописано. Подбирал эти числа на практике. >> >> Но даже с ними не понятно почему пару процессов nginx отжирают по 30 гиг >> >> RAM >> >> >> >> Больше идей нет, есть у кого-нибудь мысли как можно починить ситуацию? >> >> >> >> nginx version: nginx/1.20.2 >> >> >> >> built by gcc 4.8.5 20150623 (Red Hat 4.8.5-39) (GCC) >> >> built with OpenSSL 1.0.2k-fips 26 Jan 2017 >> >> 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-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='-O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions >> >> -fstack-protector-strong --param=ssp-buffer-size=4 -grecord-gcc-switches >> >> -m64 -mtune=generic -fPIC' --with-ld-opt='-Wl,-z,relro -Wl,-z,now -pie' >> >> >> >> cat /etc/os-release >> >> NAME="CloudLinux" >> >> VERSION="7.9 (Boris Yegorov)" >> >> ID="cloudlinux" >> >> >> >> Linux 3.10.0-962.3.2.lve1.5.42.el7.x86_64 #1 SMP Mon Nov 9 08:11:18 EST >> >> 2020 x86_64 x86_64 x86_64 GNU/Linux >> >> >> >> >> >> top - 17:33:50 up 12:18, 1 user, load average: 13.88, 13.09, 12.50 >> >> Tasks: 909 total, 7 running, 901 sleeping, 0 stopped, 1 zombie >> >> %Cpu(s): 12.1 us, 4.8 sy, 0.1 ni, 82.2 id, 0.3 wa, 0.0 hi, 0.6 si, >> >> 0.0 st >> >> KiB Mem : 13182188+total, 4598376 free, 75250656 used, 51972864 >> buff/cache >> >> KiB Swap: 10077298+total, 96888000 free, 3884988 used. 44158760 avail >> Mem >> >> >> >> PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ >> COMMAND >> >> 12785 root 20 0 35.0g 34.0g 2440 S 28.0 27.1 10:43.40 >> nginx >> >> 12807 root 20 0 14.4g 13.4g 2448 S 29.6 10.6 4:22.15 >> nginx >> >> 12805 root 20 0 2904776 1.8g 2588 S 3.0 1.4 1:10.02 >> nginx >> >> 12802 root 20 0 2880556 1.8g 2432 S 2.0 1.4 0:52.17 >> nginx >> >> 12799 root 20 0 2859616 1.8g 2452 S 1.6 1.4 0:31.47 >> nginx >> >> 12795 root 20 0 2844724 1.7g 2436 S 1.0 1.4 0:23.12 >> nginx >> >> 12793 root 20 0 2838340 1.7g 2548 S 0.3 1.4 0:19.55 >> nginx >> >> 12791 root 20 0 2831640 1.7g 2432 S 0.7 1.4 0:17.34 >> nginx >> >> 12779 root 20 0 2823876 1.7g 2404 S 0.3 1.4 0:12.40 >> nginx >> >> 12778 root 20 0 2821256 1.7g 2352 S 0.0 1.4 0:10.86 >> nginx >> >> 12777 root 20 0 2819208 1.7g 2392 S 0.7 1.4 0:09.13 >> nginx >> >> 12774 root 20 0 2816544 1.7g 2364 S 0.3 1.4 0:08.00 >> nginx >> >> 12771 root 20 0 2815748 1.7g 2392 S 0.7 1.4 0:07.82 >> nginx >> >> 12767 root 20 0 2813880 1.7g 2324 S 0.3 1.4 0:06.81 >> nginx >> >> 12763 root 20 0 2813828 1.7g 2348 S 0.0 1.4 0:06.76 >> nginx >> >> 12761 root 20 0 2813480 1.7g 2360 S 0.7 1.4 0:06.26 >> nginx >> >> 12760 root 20 0 2812952 1.7g 2376 S 0.0 1.4 0:05.89 >> nginx >> >> 12757 root 20 0 2812084 1.7g 2364 S 0.0 1.4 0:05.78 >> nginx >> >> 12707 root 20 0 2811584 1.7g 2304 S 0.3 1.4 0:02.55 >> nginx >> >> 12759 root 20 0 2811772 1.7g 2312 S 0.3 1.4 0:05.61 >> nginx >> >> 12694 root 20 0 2811380 1.7g 2288 S 0.3 1.4 0:02.06 >> nginx >> >> 12711 root 20 0 2811416 1.7g 2300 S 0.0 1.4 0:02.54 >> nginx >> >> 12686 root 20 0 2811228 1.7g 2288 S 0.0 1.4 0:01.14 >> nginx >> >> 12710 root 20 0 2811108 1.7g 2288 S 0.0 1.4 0:02.52 >> nginx >> >> 12752 root 20 0 2811060 1.7g 2316 S 0.3 1.4 0:04.99 >> nginx >> >> 12748 root 20 0 2811024 1.7g 2296 S 0.3 1.4 0:05.05 >> nginx >> >> 12745 root 20 0 2811144 1.7g 2288 S 0.3 1.4 0:04.58 >> nginx >> >> 12699 root 20 0 2811012 1.7g 2280 S 0.0 1.4 0:02.20 >> nginx >> >> 12728 root 20 0 2811028 1.7g 2276 S 0.0 1.4 0:03.09 >> nginx >> >> 12690 root 20 0 2811196 1.7g 2280 S 0.3 1.4 0:01.93 >> nginx >> >> 12754 root 20 0 2810868 1.7g 2272 S 0.0 1.4 0:04.98 >> nginx >> >> 12688 root 20 0 2810928 1.7g 2312 S 0.0 1.4 0:01.72 >> nginx >> >> 12732 root 20 0 2810948 1.7g 2276 S 0.0 1.4 0:03.34 >> nginx >> >> 12687 root 20 0 2810944 1.7g 2284 S 0.0 1.4 0:01.50 >> nginx >> >> 12703 root 20 0 2810852 1.7g 2292 S 0.3 1.4 0:02.23 >> nginx >> >> 12739 root 20 0 2810884 1.7g 2280 S 0.0 1.4 0:04.25 >> nginx >> >> 12738 root 20 0 2810916 1.7g 2296 S 0.3 1.4 0:04.03 >> nginx >> >> 12717 root 20 0 2810788 1.7g 2316 S 0.0 1.4 0:02.82 >> nginx >> >> 12742 root 20 0 2810768 1.7g 2276 S 0.0 1.4 0:04.38 >> nginx >> >> 12684 root 20 0 2810760 1.7g 2296 S 0.0 1.4 0:01.01 >> nginx >> >> 12682 root 20 0 2810676 1.7g 2280 S 0.0 1.4 0:00.88 >> nginx >> >> 12715 root 20 0 2810624 1.7g 2280 S 0.0 1.4 0:02.72 >> nginx >> >> 12734 root 20 0 2810600 1.7g 2280 S 0.0 1.4 0:03.49 >> nginx >> >> 12736 root 20 0 2810504 1.7g 2284 S 0.0 1.4 0:03.65 >> nginx >> >> 12731 root 20 0 2810480 1.7g 2280 S 0.0 1.4 0:03.14 >> nginx >> >> 12723 root 20 0 2810496 1.7g 2268 S 0.0 1.4 0:02.87 >> nginx >> >> 12737 root 20 0 2810660 1.7g 2280 S 0.3 1.4 0:03.89 >> nginx >> >> 12741 root 20 0 2810560 1.7g 2272 S 0.3 1.4 0:04.13 >> nginx >> >> 12681 root 20 0 2795668 1.7g 144 S 0.0 1.4 0:01.80 >> nginx >> >> >> >> >> >> -- >> >> С уважением, >> >> Дугин Сергей mailto:drug на qwarta.ru >> >> QWARTA >> >> >> >> _______________________________________________ >> >> nginx-ru mailing list >> >> nginx-ru на nginx.org >> >> http://mailman.nginx.org/mailman/listinfo/nginx-ru >> >> >> >> -- >> С уважением, >> Дугин Сергей mailto:drug на qwarta.ru >> QWARTA >> >> _______________________________________________ >> nginx-ru mailing list >> nginx-ru на nginx.org >> http://mailman.nginx.org/mailman/listinfo/nginx-ru -- С уважением, Дугин Сергей mailto:drug на qwarta.ru QWARTA From drug на qwarta.ru Tue Jan 11 02:54:36 2022 From: drug на qwarta.ru (=?utf-8?B?0JTRg9Cz0LjQvSDQodC10YDQs9C10Lk=?=) Date: Tue, 11 Jan 2022 05:54:36 +0300 Subject: =?UTF-8?B?UmU6IG5naW54INC10YHRgtGMINC00LXRgdGP0YLQutC4INCz0LjQs9Cw0LHQsNGC?= =?UTF-8?B?INC/0LDQvNGP0YLQuCDQuCDRgdC10YDQstC10YAg0YPRhdC+0LTQuNGCINCy?= =?UTF-8?B?IHN3YXA=?= In-Reply-To: References: <365132381.20220110174044@qwarta.ru> Message-ID: <1745739219.20220111055436@qwarta.ru> Здравствуйте, Maxim. Вы писали 10 января 2022 г., 22:07:16: > А что при этом в конфиге? В частности, worker_connections и > всевозможные буфера (client_header_buffer_size, > large_client_header_buffers, client_body_buffer_size, > proxy_buffer_size, proxy_buffers, output_buffers и так далее)? > Если включён HTTP/2 - то ещё и http2_max_concurrent_streams. Эти параметры все по дефолту. HTTP/2 - нет http2_max_concurrent_streams - тоже нет > Отдельно интересно нет ли в конфиге сторонних модулей. А если > есть, то воспроизводится ли проблема без них. Сторонних модулей нет и не ставил в папке /usr/lib64/nginx/modules/ нет ничего > [...] >> cat /etc/os-release >> NAME="CloudLinux" >> VERSION="7.9 (Boris Yegorov)" >> ID="cloudlinux" >> >> Linux 3.10.0-962.3.2.lve1.5.42.el7.x86_64 #1 SMP Mon Nov 9 08:11:18 EST 2020 x86_64 x86_64 x86_64 GNU/Linux >> >> >> top - 17:33:50 up 12:18, 1 user, load average: 13.88, 13.09, 12.50 >> Tasks: 909 total, 7 running, 901 sleeping, 0 stopped, 1 zombie >> %Cpu(s): 12.1 us, 4.8 sy, 0.1 ni, 82.2 id, 0.3 wa, 0.0 hi, 0.6 si, 0.0 st >> KiB Mem : 13182188+total, 4598376 free, 75250656 used, 51972864 buff/cache >> KiB Swap: 10077298+total, 96888000 free, 3884988 used. 44158760 avail Mem >> >> PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND >> 12785 root 20 0 35.0g 34.0g 2440 S 28.0 27.1 10:43.40 nginx >> 12807 root 20 0 14.4g 13.4g 2448 S 29.6 10.6 4:22.15 nginx >> 12805 root 20 0 2904776 1.8g 2588 S 3.0 1.4 1:10.02 nginx >> 12802 root 20 0 2880556 1.8g 2432 S 2.0 1.4 0:52.17 nginx >> 12799 root 20 0 2859616 1.8g 2452 S 1.6 1.4 0:31.47 nginx > Судя по всему, растут те процессы, которые собственно занимаются > обработкой соединений: на современных линуксах распределение > соединений между рабочими процессами может быть сильно > неравномерным, лечить проще всего включением accept_mutex'а > (https://trac.nginx.org/nginx/ticket/2285). Сделал worker_processes auto; форкеров стало ровно столько сколько ядер и теперь все форкеры кушают примерно одинаково: 6310 root 20 0 4494660 3.3g 2456 S 0.0 2.6 0:01.82 nginx 15109 root 20 0 4494660 3.3g 2452 S 2.3 2.6 0:01.32 nginx 15133 root 20 0 4494660 3.3g 2444 S 0.3 2.6 0:00.89 nginx 6216 root 20 0 4494660 3.3g 2420 S 0.0 2.6 0:00.65 nginx 6267 root 20 0 4494660 3.3g 2412 S 0.0 2.6 0:00.99 nginx 15085 root 20 0 4494660 3.3g 2344 S 1.6 2.6 0:00.94 nginx 6297 root 20 0 4494660 3.3g 2336 S 0.0 2.6 0:01.53 nginx 15097 root 20 0 4494660 3.3g 2332 S 2.3 2.6 0:01.09 nginx 14858 root 20 0 4494660 3.3g 2256 S 0.0 2.6 0:00.40 nginx 15045 root 20 0 4494660 3.3g 2300 S 0.7 2.6 0:00.54 nginx 15026 root 20 0 4494660 3.3g 2288 S 0.7 2.6 0:00.55 nginx и так далее При запуске писало 1.7g, сейчас уже 3.3g то есть при запуске потребляет 48*1.1=81,6g памяти, а сейчас уже 158,4G и сервер уже очень бодро свапится. > Почему растут - отдельный вопрос. Для начала, наверное, стоит > посмотреть, до какого размера процессы могут расти по памяти в > соответствии с текущими настройками. Грубая оценка максимального > потребления памяти одним рабочим процессом - worker_connections * > <сумма всех буферов>. Если она не превышена - то вопрос, скорее, > в настройках, не соответствующих имеющемуся объёму памяти. Если > превышена - то имеет смысл разбираться дальше. worker_connections поставил по дефолту буфера тоже все по дефолту worker_processes сделал 6 перезапустил вижу по top такое: USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND root 15962 4.3 2.6 4477008 3467940 ? S 05:42 0:01 nginx: worker process root 15954 1.6 2.6 4477008 3467916 ? S 05:42 0:00 nginx: worker process root 15972 1.4 2.6 4477008 3467876 ? S 05:42 0:00 nginx: worker process root 15982 0.4 2.6 4477008 3467720 ? S 05:42 0:00 nginx: worker process root 15993 0.2 2.6 4477008 3467588 ? S 05:42 0:00 nginx: worker process root 44803 15.8 2.6 4477004 3467200 ? Ss 05:39 0:30 nginx: master process /usr/sbin/nginx -c /etc/nginx/nginx.conf root 16005 0.1 2.6 4477008 3465784 ? S 05:42 0:00 nginx: worker process В итоге 6 процессов кушают 3467940*6 около 20 гиг памяти при старте. Еще есть вот этот параметр client_max_body_size 128m; -- С уважением, Дугин Сергей mailto:drug на qwarta.ru QWARTA From mdounin на mdounin.ru Tue Jan 11 13:09:07 2022 From: mdounin на mdounin.ru (Maxim Dounin) Date: Tue, 11 Jan 2022 16:09:07 +0300 Subject: =?UTF-8?B?UmU6IG5naW54INC10YHRgtGMINC00LXRgdGP0YLQutC4INCz0LjQs9Cw0LHQsNGC?= =?UTF-8?B?INC/0LDQvNGP0YLQuCDQuCDRgdC10YDQstC10YAg0YPRhdC+0LTQuNGCINCy?= =?UTF-8?B?IHN3YXA=?= In-Reply-To: <1745739219.20220111055436@qwarta.ru> References: <365132381.20220110174044@qwarta.ru> <1745739219.20220111055436@qwarta.ru> Message-ID: Hello! On Tue, Jan 11, 2022 at 05:54:36AM +0300, Дугин Сергей wrote: > Здравствуйте, Maxim. > > Вы писали 10 января 2022 г., 22:07:16: > > > А что при этом в конфиге? В частности, worker_connections и > > всевозможные буфера (client_header_buffer_size, > > large_client_header_buffers, client_body_buffer_size, > > proxy_buffer_size, proxy_buffers, output_buffers и так далее)? > > Если включён HTTP/2 - то ещё и http2_max_concurrent_streams. > Эти параметры все по дефолту. > HTTP/2 - нет > http2_max_concurrent_streams - тоже нет > > > Отдельно интересно нет ли в конфиге сторонних модулей. А если > > есть, то воспроизводится ли проблема без них. > Сторонних модулей нет и не ставил > в папке /usr/lib64/nginx/modules/ > нет ничего [...] > > Судя по всему, растут те процессы, которые собственно занимаются > > обработкой соединений: на современных линуксах распределение > > соединений между рабочими процессами может быть сильно > > неравномерным, лечить проще всего включением accept_mutex'а > > (https://trac.nginx.org/nginx/ticket/2285). > Сделал worker_processes auto; > форкеров стало ровно столько сколько ядер и теперь все форкеры кушают примерно одинаково: > 6310 root 20 0 4494660 3.3g 2456 S 0.0 2.6 0:01.82 nginx > 15109 root 20 0 4494660 3.3g 2452 S 2.3 2.6 0:01.32 nginx > 15133 root 20 0 4494660 3.3g 2444 S 0.3 2.6 0:00.89 nginx > 6216 root 20 0 4494660 3.3g 2420 S 0.0 2.6 0:00.65 nginx > 6267 root 20 0 4494660 3.3g 2412 S 0.0 2.6 0:00.99 nginx > 15085 root 20 0 4494660 3.3g 2344 S 1.6 2.6 0:00.94 nginx > 6297 root 20 0 4494660 3.3g 2336 S 0.0 2.6 0:01.53 nginx > 15097 root 20 0 4494660 3.3g 2332 S 2.3 2.6 0:01.09 nginx > 14858 root 20 0 4494660 3.3g 2256 S 0.0 2.6 0:00.40 nginx > 15045 root 20 0 4494660 3.3g 2300 S 0.7 2.6 0:00.54 nginx > 15026 root 20 0 4494660 3.3g 2288 S 0.7 2.6 0:00.55 nginx > и так далее В смысле - после включения accept_mutex'а? > При запуске писало 1.7g, сейчас уже 3.3g > то есть при запуске потребляет 48*1.1=81,6g памяти, > а сейчас уже 158,4G и сервер уже очень бодро свапится. > > > > Почему растут - отдельный вопрос. Для начала, наверное, стоит > > посмотреть, до какого размера процессы могут расти по памяти в > > соответствии с текущими настройками. Грубая оценка максимального > > потребления памяти одним рабочим процессом - worker_connections * > > <сумма всех буферов>. Если она не превышена - то вопрос, скорее, > > в настройках, не соответствующих имеющемуся объёму памяти. Если > > превышена - то имеет смысл разбираться дальше. > > worker_connections поставил по дефолту > буфера тоже все по дефолту > worker_processes сделал 6 > > перезапустил вижу по top такое: > USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND > root 15962 4.3 2.6 4477008 3467940 ? S 05:42 0:01 nginx: worker process > root 15954 1.6 2.6 4477008 3467916 ? S 05:42 0:00 nginx: worker process > root 15972 1.4 2.6 4477008 3467876 ? S 05:42 0:00 nginx: worker process > root 15982 0.4 2.6 4477008 3467720 ? S 05:42 0:00 nginx: worker process > root 15993 0.2 2.6 4477008 3467588 ? S 05:42 0:00 nginx: worker process > root 44803 15.8 2.6 4477004 3467200 ? Ss 05:39 0:30 nginx: master process /usr/sbin/nginx -c /etc/nginx/nginx.conf > root 16005 0.1 2.6 4477008 3465784 ? S 05:42 0:00 nginx: worker process > > В итоге 6 процессов кушают 3467940*6 около 20 гиг памяти при старте. Занятно. А можно посмотреть конфиг полностью? В идеале - сразу вывод "nginx -T", но можно выкинуть/отфильтровать имена серверов и прочую приватную информацию. -- Maxim Dounin http://mdounin.ru/ From drug на qwarta.ru Tue Jan 11 15:10:43 2022 From: drug на qwarta.ru (=?utf-8?B?0JTRg9Cz0LjQvSDQodC10YDQs9C10Lk=?=) Date: Tue, 11 Jan 2022 18:10:43 +0300 Subject: =?UTF-8?B?UmU6IG5naW54INC10YHRgtGMINC00LXRgdGP0YLQutC4INCz0LjQs9Cw0LHQsNGC?= =?UTF-8?B?INC/0LDQvNGP0YLQuCDQuCDRgdC10YDQstC10YAg0YPRhdC+0LTQuNGCINCy?= =?UTF-8?B?IHN3YXA=?= In-Reply-To: References: <365132381.20220110174044@qwarta.ru> <1745739219.20220111055436@qwarta.ru> Message-ID: <16810421528.20220111181043@qwarta.ru> Здравствуйте, Maxim. Вы писали 11 января 2022 г., 16:09:07: > Hello! > On Tue, Jan 11, 2022 at 05:54:36AM +0300, Дугин Сергей wrote: >> Здравствуйте, Maxim. >> >> Вы писали 10 января 2022 г., 22:07:16: >> >> > А что при этом в конфиге? В частности, worker_connections и >> > всевозможные буфера (client_header_buffer_size, >> > large_client_header_buffers, client_body_buffer_size, >> > proxy_buffer_size, proxy_buffers, output_buffers и так далее)? >> > Если включён HTTP/2 - то ещё и http2_max_concurrent_streams. >> Эти параметры все по дефолту. >> HTTP/2 - нет >> http2_max_concurrent_streams - тоже нет >> >> > Отдельно интересно нет ли в конфиге сторонних модулей. А если >> > есть, то воспроизводится ли проблема без них. >> Сторонних модулей нет и не ставил >> в папке /usr/lib64/nginx/modules/ >> нет ничего > [...] >> > Судя по всему, растут те процессы, которые собственно занимаются >> > обработкой соединений: на современных линуксах распределение >> > соединений между рабочими процессами может быть сильно >> > неравномерным, лечить проще всего включением accept_mutex'а >> > (https://trac.nginx.org/nginx/ticket/2285). >> Сделал worker_processes auto; >> форкеров стало ровно столько сколько ядер и теперь все форкеры кушают примерно одинаково: >> 6310 root 20 0 4494660 3.3g 2456 S 0.0 2.6 0:01.82 nginx >> 15109 root 20 0 4494660 3.3g 2452 S 2.3 2.6 0:01.32 nginx >> 15133 root 20 0 4494660 3.3g 2444 S 0.3 2.6 0:00.89 nginx >> 6216 root 20 0 4494660 3.3g 2420 S 0.0 2.6 0:00.65 nginx >> 6267 root 20 0 4494660 3.3g 2412 S 0.0 2.6 0:00.99 nginx >> 15085 root 20 0 4494660 3.3g 2344 S 1.6 2.6 0:00.94 nginx >> 6297 root 20 0 4494660 3.3g 2336 S 0.0 2.6 0:01.53 nginx >> 15097 root 20 0 4494660 3.3g 2332 S 2.3 2.6 0:01.09 nginx >> 14858 root 20 0 4494660 3.3g 2256 S 0.0 2.6 0:00.40 nginx >> 15045 root 20 0 4494660 3.3g 2300 S 0.7 2.6 0:00.54 nginx >> 15026 root 20 0 4494660 3.3g 2288 S 0.7 2.6 0:00.55 nginx >> и так далее > В смысле - после включения accept_mutex'а? Сделал так: events { accept_mutex on; } и так worker_processes auto; потребление процессами вроде равномерно. Но ночью сделал worker_processes 6; и было так: PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 9477 root 20 0 101.9g 86.7g 2172 S 1.0 69.0 82:54.87 nginx 9467 root 20 0 5078884 275248 2204 S 1.0 0.2 9:18.31 nginx 9472 root 20 0 3510260 267848 2176 S 3.9 0.2 5:51.72 nginx 9475 root 20 0 3510260 258752 2252 S 1.0 0.2 8:01.37 nginx 9463 root 20 0 3510260 257088 2240 S 1.3 0.2 6:41.24 nginx 9480 root 20 0 3510260 224516 2256 S 0.3 0.2 7:15.55 nginx 9750 root 20 0 3510256 20856 1104 S 0.0 0.0 0:20.91 nginx То есть accept_mutex on не помогло при малом числе процессов, но возможно и при worker_processes auto так же будет на более длинном промежутке >> При запуске писало 1.7g, сейчас уже 3.3g >> то есть при запуске потребляет 48*1.1=81,6g памяти, >> а сейчас уже 158,4G и сервер уже очень бодро свапится. >> >> >> > Почему растут - отдельный вопрос. Для начала, наверное, стоит >> > посмотреть, до какого размера процессы могут расти по памяти в >> > соответствии с текущими настройками. Грубая оценка максимального >> > потребления памяти одним рабочим процессом - worker_connections * >> > <сумма всех буферов>. Если она не превышена - то вопрос, скорее, >> > в настройках, не соответствующих имеющемуся объёму памяти. Если >> > превышена - то имеет смысл разбираться дальше. >> >> worker_connections поставил по дефолту >> буфера тоже все по дефолту >> worker_processes сделал 6 >> >> перезапустил вижу по top такое: >> USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND >> root 15962 4.3 2.6 4477008 3467940 ? S 05:42 0:01 nginx: worker process >> root 15954 1.6 2.6 4477008 3467916 ? S 05:42 0:00 nginx: worker process >> root 15972 1.4 2.6 4477008 3467876 ? S 05:42 0:00 nginx: worker process >> root 15982 0.4 2.6 4477008 3467720 ? S 05:42 0:00 nginx: worker process >> root 15993 0.2 2.6 4477008 3467588 ? S 05:42 0:00 nginx: worker process >> root 44803 15.8 2.6 4477004 3467200 ? Ss 05:39 0:30 nginx: master process /usr/sbin/nginx -c /etc/nginx/nginx.conf >> root 16005 0.1 2.6 4477008 3465784 ? S 05:42 0:00 nginx: worker process >> >> В итоге 6 процессов кушают 3467940*6 около 20 гиг памяти при старте. > Занятно. А можно посмотреть конфиг полностью? В идеале - сразу > вывод "nginx -T", но можно выкинуть/отфильтровать имена серверов и > прочую приватную информацию. сделал так nginx -T | grep -v "server_name\|include\|access_log\|error_log\|\/var\/www\/\|^#\|ssl_certificate" > nginx.conf.1.txt IP заменил так же. Если удобнее могу архивнуть папку /etc/nginx/ и скинуть на личную почту. -- С уважением, Дугин Сергей mailto:drug на qwarta.ru QWARTA ----------- следующая часть ----------- Вложение не в текстовом формате было извлечено… Имя: nginx.conf.tar.gz Тип: application/x-gzip Размер: 97824 байтов Описание: отсутствует URL: From mdounin на mdounin.ru Tue Jan 11 21:28:36 2022 From: mdounin на mdounin.ru (Maxim Dounin) Date: Wed, 12 Jan 2022 00:28:36 +0300 Subject: =?UTF-8?B?UmU6IG5naW54INC10YHRgtGMINC00LXRgdGP0YLQutC4INCz0LjQs9Cw0LHQsNGC?= =?UTF-8?B?INC/0LDQvNGP0YLQuCDQuCDRgdC10YDQstC10YAg0YPRhdC+0LTQuNGCINCy?= =?UTF-8?B?IHN3YXA=?= In-Reply-To: <16810421528.20220111181043@qwarta.ru> References: <365132381.20220110174044@qwarta.ru> <1745739219.20220111055436@qwarta.ru> <16810421528.20220111181043@qwarta.ru> Message-ID: Hello! On Tue, Jan 11, 2022 at 06:10:43PM +0300, Дугин Сергей wrote: > Здравствуйте, Maxim. > > Вы писали 11 января 2022 г., 16:09:07: > > > Hello! > > > On Tue, Jan 11, 2022 at 05:54:36AM +0300, Дугин Сергей wrote: > > >> Здравствуйте, Maxim. > >> > >> Вы писали 10 января 2022 г., 22:07:16: > >> > >> > А что при этом в конфиге? В частности, worker_connections и > >> > всевозможные буфера (client_header_buffer_size, > >> > large_client_header_buffers, client_body_buffer_size, > >> > proxy_buffer_size, proxy_buffers, output_buffers и так далее)? > >> > Если включён HTTP/2 - то ещё и http2_max_concurrent_streams. > >> Эти параметры все по дефолту. > >> HTTP/2 - нет > >> http2_max_concurrent_streams - тоже нет > >> > >> > Отдельно интересно нет ли в конфиге сторонних модулей. А если > >> > есть, то воспроизводится ли проблема без них. > >> Сторонних модулей нет и не ставил > >> в папке /usr/lib64/nginx/modules/ > >> нет ничего > > > [...] > > >> > Судя по всему, растут те процессы, которые собственно занимаются > >> > обработкой соединений: на современных линуксах распределение > >> > соединений между рабочими процессами может быть сильно > >> > неравномерным, лечить проще всего включением accept_mutex'а > >> > (https://trac.nginx.org/nginx/ticket/2285). > >> Сделал worker_processes auto; > >> форкеров стало ровно столько сколько ядер и теперь все форкеры кушают примерно одинаково: > >> 6310 root 20 0 4494660 3.3g 2456 S 0.0 2.6 0:01.82 nginx > >> 15109 root 20 0 4494660 3.3g 2452 S 2.3 2.6 0:01.32 nginx > >> 15133 root 20 0 4494660 3.3g 2444 S 0.3 2.6 0:00.89 nginx > >> 6216 root 20 0 4494660 3.3g 2420 S 0.0 2.6 0:00.65 nginx > >> 6267 root 20 0 4494660 3.3g 2412 S 0.0 2.6 0:00.99 nginx > >> 15085 root 20 0 4494660 3.3g 2344 S 1.6 2.6 0:00.94 nginx > >> 6297 root 20 0 4494660 3.3g 2336 S 0.0 2.6 0:01.53 nginx > >> 15097 root 20 0 4494660 3.3g 2332 S 2.3 2.6 0:01.09 nginx > >> 14858 root 20 0 4494660 3.3g 2256 S 0.0 2.6 0:00.40 nginx > >> 15045 root 20 0 4494660 3.3g 2300 S 0.7 2.6 0:00.54 nginx > >> 15026 root 20 0 4494660 3.3g 2288 S 0.7 2.6 0:00.55 nginx > >> и так далее > > > В смысле - после включения accept_mutex'а? > > Сделал так: > events { > accept_mutex on; > } > и так > worker_processes auto; > > потребление процессами вроде равномерно. > > Но ночью сделал > worker_processes 6; > и было так: > PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND > 9477 root 20 0 101.9g 86.7g 2172 S 1.0 69.0 82:54.87 nginx > 9467 root 20 0 5078884 275248 2204 S 1.0 0.2 9:18.31 nginx > 9472 root 20 0 3510260 267848 2176 S 3.9 0.2 5:51.72 nginx > 9475 root 20 0 3510260 258752 2252 S 1.0 0.2 8:01.37 nginx > 9463 root 20 0 3510260 257088 2240 S 1.3 0.2 6:41.24 nginx > 9480 root 20 0 3510260 224516 2256 S 0.3 0.2 7:15.55 nginx > 9750 root 20 0 3510256 20856 1104 S 0.0 0.0 0:20.91 nginx > То есть > accept_mutex on не помогло при малом числе процессов, но возможно и при worker_processes auto так же будет на более длинном промежутке Судя по цифрам - accept_mutex скорее помог, и соединения разбалансировались между рабочими процессами. Но, похоже, проблема скорее в том, что делается в рамках некоторых редких запросов, и эти запросы и приводят к росту потребляемой памяти. Это согласуется с тем, что видно в конфиге, см. ниже. > >> При запуске писало 1.7g, сейчас уже 3.3g > >> то есть при запуске потребляет 48*1.1=81,6g памяти, > >> а сейчас уже 158,4G и сервер уже очень бодро свапится. > >> > >> > >> > Почему растут - отдельный вопрос. Для начала, наверное, стоит > >> > посмотреть, до какого размера процессы могут расти по памяти в > >> > соответствии с текущими настройками. Грубая оценка максимального > >> > потребления памяти одним рабочим процессом - worker_connections * > >> > <сумма всех буферов>. Если она не превышена - то вопрос, скорее, > >> > в настройках, не соответствующих имеющемуся объёму памяти. Если > >> > превышена - то имеет смысл разбираться дальше. > >> > >> worker_connections поставил по дефолту > >> буфера тоже все по дефолту > >> worker_processes сделал 6 > >> > >> перезапустил вижу по top такое: > >> USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND > >> root 15962 4.3 2.6 4477008 3467940 ? S 05:42 0:01 nginx: worker process > >> root 15954 1.6 2.6 4477008 3467916 ? S 05:42 0:00 nginx: worker process > >> root 15972 1.4 2.6 4477008 3467876 ? S 05:42 0:00 nginx: worker process > >> root 15982 0.4 2.6 4477008 3467720 ? S 05:42 0:00 nginx: worker process > >> root 15993 0.2 2.6 4477008 3467588 ? S 05:42 0:00 nginx: worker process > >> root 44803 15.8 2.6 4477004 3467200 ? Ss 05:39 0:30 nginx: master process /usr/sbin/nginx -c /etc/nginx/nginx.conf > >> root 16005 0.1 2.6 4477008 3465784 ? S 05:42 0:00 nginx: worker process > >> > >> В итоге 6 процессов кушают 3467940*6 около 20 гиг памяти при старте. > > > Занятно. А можно посмотреть конфиг полностью? В идеале - сразу > > вывод "nginx -T", но можно выкинуть/отфильтровать имена серверов и > > прочую приватную информацию. > > сделал так > nginx -T | grep -v "server_name\|include\|access_log\|error_log\|\/var\/www\/\|^#\|ssl_certificate" > nginx.conf.1.txt > IP заменил так же. > > Если удобнее могу архивнуть папку /etc/nginx/ и скинуть на личную почту. Из наиболее подозрительного - вижу разрешённый SSI в некоторых серверах. Возможно, проблема в том, что в каких-то ситуациях создаётся очень много SSI-подзапросов, и они и потребляют память. Из наименее интрузивного - проще всего включить логгирование подзапросов (https://nginx.org/r/log_subrequest) и посмотреть, что вылезет в логах (но в общем случае может быть непросто отличить обычные запросы от подзапросов). Ну или просто выключить SSI и посмотреть, уйдёт ли проблема. -- Maxim Dounin http://mdounin.ru/ From sb на nginx.com Thu Jan 13 11:52:40 2022 From: sb на nginx.com (Sergey Budnevitch) Date: Thu, 13 Jan 2022 14:52:40 +0300 Subject: Mailing list migration to mailman3 Message-ID: <52378D2C-52D4-482C-8A95-8021AE4B9132@nginx.com> Добрый день, Как вы могли заметить по web-интерфейсу, рассылка переведена на mailman3. Он сильно отличается от mailman2, который использовался ранее. Пожалуйста, обратите внимание на несколько существенных отличий: * Mailman3 не добавляет заголовок X-BeenThere в сообщения, если вы использовали этот заголовок для сортировки, пожалуйста, поменяйте его в правилах на List-Id или List-Post * Старый архив по прежнему доступен на https://mailman.nginx.org/pipermail/nginx-ru/, новый ведется с 1-ого января 2020 и его можно найти по ссылке https://mailman.nginx.org/archives/list/nginx-ru на nginx.org/ * Возможность подписаться/отписаться, используя почтовый интерфейс, работает как прежде. Однако web-интерфейс это отдельная часть mailman'а со своей авторизацией, и для того чтобы получить к нему доступ надо зарегистрироваться с текущим email'ом - восстановление пароля не сработает, так как пользователя в web-интерфейсе еще не существует. From gmm на csdoc.com Tue Jan 18 20:15:05 2022 From: gmm на csdoc.com (Gena Makhomed) Date: Tue, 18 Jan 2022 22:15:05 +0200 Subject: =?UTF-8?B?0JjQs9C+0YDRjCDQodGL0YHQvtC10LIg0YPRiNGR0Lsg0LjQtyDQutC+?= =?UTF-8?B?0LzQv9Cw0L3QuNC5IEY1IE5ldHdvcmsg0Lgg0L/QvtC60LjQvdGD0Lsg0L/RgNC+?= =?UTF-8?B?0LXQutGCIE5HSU5Y?= Message-ID: <39cd7e7e-552c-bfda-46de-439fdb2d4eac@csdoc.com> https://www.opennet.ru/opennews/art.shtml?num=56535 Игорь Сысоев ушёл из компаний F5 Network и покинул проект NGINX Игорь Сысоев, создатель высокопроизводительного HTTP-сервера NGINX, уволился из компании F5 Network, в которой после продажи компании NGINX Inc находился в числе технических руководителей проекта NGINX. Отмечается, что уход обусловлен желанием проводить больше времени в семье и заниматься личными проектами. В компании F5 Игорь занимал должность главного архитектора. Руководство разработкой NGINX теперь сосредоточится в руках Максима Коновалова, занимающего пост вице-президента по инжинирингу группы продуктов NGINX. Игорь основал NGINX в 2002 году и до создания компании NGINX Inc в 2011 году практически в одиночку занимался всей разработкой. С 2012 года Игорь отстранился от рутинного написания кода NGINX и основную работу по сопровождению кодовой базы подхватили Максим Дунин, Валентин Бартенев и Роман Арутюнян. После 2012 года участие Игоря в разработке было сосредоточено на сервере приложений NGINX Unit и движке njs. Отмечается, что после ухода Игоря из проекта, созданные при его участии культура и подход к разработке останутся неизменными, как не изменится и отношение к сообществу, прозрачности процессов, инновациям и открытому коду. Оставшаяся команда разработчиков постарается соответствовать той высокой планке, которую задал Игорь. -- Best regards, Gena From vitaliy.okulov на gmail.com Wed Jan 19 12:57:44 2022 From: vitaliy.okulov на gmail.com (Vitaliy Okulov) Date: Wed, 19 Jan 2022 15:57:44 +0300 Subject: =?UTF-8?B?UmU6INCY0LPQvtGA0Ywg0KHRi9GB0L7QtdCyINGD0YjRkdC7INC40Lcg0LrQvtC80L/QsA==?= =?UTF-8?B?0L3QuNC5IEY1IE5ldHdvcmsg0Lgg0L/QvtC60LjQvdGD0Lsg0L/RgNC+0LXQutGCIE5HSU5Y?= In-Reply-To: <39cd7e7e-552c-bfda-46de-439fdb2d4eac@csdoc.com> References: <39cd7e7e-552c-bfda-46de-439fdb2d4eac@csdoc.com> Message-ID: Прошла эпоха, надеюсь Игорь хорошо вышел из компании. вт, 18 янв. 2022 г. в 23:15, Gena Makhomed : > > https://www.opennet.ru/opennews/art.shtml?num=56535 > > Игорь Сысоев ушёл из компаний F5 Network и покинул проект NGINX > > Игорь Сысоев, создатель высокопроизводительного HTTP-сервера NGINX, > уволился из компании F5 Network, в которой после продажи компании NGINX > Inc находился в числе технических руководителей проекта NGINX. > Отмечается, что уход обусловлен желанием проводить больше времени в > семье и заниматься личными проектами. В компании F5 Игорь занимал > должность главного архитектора. Руководство разработкой NGINX теперь > сосредоточится в руках Максима Коновалова, занимающего пост > вице-президента по инжинирингу группы продуктов NGINX. > > Игорь основал NGINX в 2002 году и до создания компании NGINX Inc в 2011 > году практически в одиночку занимался всей разработкой. С 2012 года > Игорь отстранился от рутинного написания кода NGINX и основную работу по > сопровождению кодовой базы подхватили Максим Дунин, Валентин Бартенев и > Роман Арутюнян. После 2012 года участие Игоря в разработке было > сосредоточено на сервере приложений NGINX Unit и движке njs. > > Отмечается, что после ухода Игоря из проекта, созданные при его участии > культура и подход к разработке останутся неизменными, как не изменится и > отношение к сообществу, прозрачности процессов, инновациям и открытому > коду. Оставшаяся команда разработчиков постарается соответствовать той > высокой планке, которую задал Игорь. > > > -- > Best regards, > Gena > _______________________________________________ > nginx-ru mailing list -- nginx-ru на nginx.org > To unsubscribe send an email to nginx-ru-leave на nginx.org > ----------- следующая часть ----------- Вложение в формате HTML было извлечено… URL: From 440hz на mail.ru Wed Jan 19 12:59:43 2022 From: 440hz на mail.ru (=?UTF-8?B?0JDQvdC00YDQtdC5INCT0L7Qu9GD0LHQtdCy?=) Date: Wed, 19 Jan 2022 15:59:43 +0300 Subject: =?UTF-8?B?UmU6INCY0LPQvtGA0Ywg0KHRi9GB0L7QtdCyINGD0YjRkdC7INC40Lcg0Lo=?= =?UTF-8?B?0L7QvNC/0LDQvdC40LkgRjUgTmV0d29yayDQuCDQv9C+0LrQuNC90YPQuyA=?= =?UTF-8?B?0L/RgNC+0LXQutGCIE5HSU5Y?= In-Reply-To: <39cd7e7e-552c-bfda-46de-439fdb2d4eac@csdoc.com> References: <39cd7e7e-552c-bfda-46de-439fdb2d4eac@csdoc.com> Message-ID: <1642597183.957577180@f311.i.mail.ru> Игорю всего хорошего!   >Вторник, 18 января 2022, 23:15 +03:00 от Gena Makhomed : >  > >https://www.opennet.ru/opennews/art.shtml?num=56535 > >Игорь Сысоев ушёл из компаний F5 Network и покинул проект NGINX > >Игорь Сысоев, создатель высокопроизводительного HTTP-сервера NGINX, >уволился из компании F5 Network, в которой после продажи компании NGINX >Inc находился в числе технических руководителей проекта NGINX. >Отмечается, что уход обусловлен желанием проводить больше времени в >семье и заниматься личными проектами. В компании F5 Игорь занимал >должность главного архитектора. Руководство разработкой NGINX теперь >сосредоточится в руках Максима Коновалова, занимающего пост >вице-президента по инжинирингу группы продуктов NGINX. > >Игорь основал NGINX в 2002 году и до создания компании NGINX Inc в 2011 >году практически в одиночку занимался всей разработкой. С 2012 года >Игорь отстранился от рутинного написания кода NGINX и основную работу по >сопровождению кодовой базы подхватили Максим Дунин, Валентин Бартенев и >Роман Арутюнян. После 2012 года участие Игоря в разработке было >сосредоточено на сервере приложений NGINX Unit и движке njs. > >Отмечается, что после ухода Игоря из проекта, созданные при его участии >культура и подход к разработке останутся неизменными, как не изменится и >отношение к сообществу, прозрачности процессов, инновациям и открытому >коду. Оставшаяся команда разработчиков постарается соответствовать той >высокой планке, которую задал Игорь. > > >-- >Best regards, >  Gena >_______________________________________________ >nginx-ru mailing list -- nginx-ru на nginx.org >To unsubscribe send an email to nginx-ru-leave на nginx.org     С уважением, Андрей Голубев 440hz на mail.ru   ----------- следующая часть ----------- Вложение в формате HTML было извлечено… URL: From igor на sysoev.ru Wed Jan 19 14:07:16 2022 From: igor на sysoev.ru (Igor Sysoev) Date: Wed, 19 Jan 2022 15:07:16 +0100 Subject: =?utf-8?B?UmU6INCY0LPQvtGA0Ywg0KHRi9GB0L7QtdCyINGD0YjRkdC7INC4?= =?utf-8?B?0Lcg0LrQvtC80L/QsNC90LjQuSBGNSBOZXR3b3JrINC4INC/0L7QutC40L0=?= =?utf-8?B?0YPQuyDQv9GA0L7QtdC60YIgTkdJTlg=?= In-Reply-To: References: <39cd7e7e-552c-bfda-46de-439fdb2d4eac@csdoc.com> Message-ID: Да, всё когда-то заканчивается. У меня всё хорошо. У nginx и F5, надеюсь, тоже будет всё хорошо. -- Igor Sysoev > On 19 Jan 2022, at 13:57, Vitaliy Okulov wrote: > > Прошла эпоха, надеюсь Игорь хорошо вышел из компании. > > вт, 18 янв. 2022 г. в 23:15, Gena Makhomed : > > https://www.opennet.ru/opennews/art.shtml?num=56535 > > Игорь Сысоев ушёл из компаний F5 Network и покинул проект NGINX > > Игорь Сысоев, создатель высокопроизводительного HTTP-сервера NGINX, > уволился из компании F5 Network, в которой после продажи компании NGINX > Inc находился в числе технических руководителей проекта NGINX. > Отмечается, что уход обусловлен желанием проводить больше времени в > семье и заниматься личными проектами. В компании F5 Игорь занимал > должность главного архитектора. Руководство разработкой NGINX теперь > сосредоточится в руках Максима Коновалова, занимающего пост > вице-президента по инжинирингу группы продуктов NGINX. > > Игорь основал NGINX в 2002 году и до создания компании NGINX Inc в 2011 > году практически в одиночку занимался всей разработкой. С 2012 года > Игорь отстранился от рутинного написания кода NGINX и основную работу по > сопровождению кодовой базы подхватили Максим Дунин, Валентин Бартенев и > Роман Арутюнян. После 2012 года участие Игоря в разработке было > сосредоточено на сервере приложений NGINX Unit и движке njs. > > Отмечается, что после ухода Игоря из проекта, созданные при его участии > культура и подход к разработке останутся неизменными, как не изменится и > отношение к сообществу, прозрачности процессов, инновациям и открытому > коду. Оставшаяся команда разработчиков постарается соответствовать той > высокой планке, которую задал Игорь. > > > -- > Best regards, > Gena > _______________________________________________ > nginx-ru mailing list -- nginx-ru на nginx.org > To unsubscribe send an email to nginx-ru-leave на nginx.org > _______________________________________________ > nginx-ru mailing list -- nginx-ru на nginx.org > To unsubscribe send an email to nginx-ru-leave на nginx.org From pnz.stalker на mail.ru Wed Jan 19 18:59:24 2022 From: pnz.stalker на mail.ru (=?UTF-8?B?0JDQvdGC0L7QvSDQk9C+0YDQu9C+0LI=?=) Date: Wed, 19 Jan 2022 21:59:24 +0300 Subject: =?UTF-8?B?UmU6INCY0LPQvtGA0Ywg0KHRi9GB0L7QtdCyINGD0YjRkdC7INC40Lcg?= =?UTF-8?B?0LrQvtC80L/QsNC90LjQuSBGNSBOZXR3b3JrINC4INC/0L7QutC40L3Rg9C7INC/?= =?UTF-8?B?0YDQvtC10LrRgiBOR0lOWA==?= In-Reply-To: References: <39cd7e7e-552c-bfda-46de-439fdb2d4eac@csdoc.com> Message-ID: Игорь - благодарим Вас за Ваши труды! Удачи Вам во всём! 19.01.2022 17:07, Igor Sysoev пишет: > Да, всё когда-то заканчивается. > У меня всё хорошо. > У nginx и F5, надеюсь, тоже будет всё хорошо. > > From chipitsine на gmail.com Wed Jan 19 19:20:32 2022 From: chipitsine на gmail.com (=?UTF-8?B?0JjQu9GM0Y8g0KjQuNC/0LjRhtC40L0=?=) Date: Thu, 20 Jan 2022 00:20:32 +0500 Subject: =?UTF-8?B?UmU6INCY0LPQvtGA0Ywg0KHRi9GB0L7QtdCyINGD0YjRkdC7INC40Lcg0LrQvtC80L/QsA==?= =?UTF-8?B?0L3QuNC5IEY1IE5ldHdvcmsg0Lgg0L/QvtC60LjQvdGD0Lsg0L/RgNC+0LXQutGCIE5HSU5Y?= In-Reply-To: References: <39cd7e7e-552c-bfda-46de-439fdb2d4eac@csdoc.com> Message-ID: Какие планы, если не секрет? On Wed, Jan 19, 2022, 7:08 PM Igor Sysoev wrote: > Да, всё когда-то заканчивается. > У меня всё хорошо. > У nginx и F5, надеюсь, тоже будет всё хорошо. > > > -- > Igor Sysoev > > > On 19 Jan 2022, at 13:57, Vitaliy Okulov > wrote: > > > > Прошла эпоха, надеюсь Игорь хорошо вышел из компании. > > > > вт, 18 янв. 2022 г. в 23:15, Gena Makhomed : > > > > https://www.opennet.ru/opennews/art.shtml?num=56535 > > > > Игорь Сысоев ушёл из компаний F5 Network и покинул проект NGINX > > > > Игорь Сысоев, создатель высокопроизводительного HTTP-сервера NGINX, > > уволился из компании F5 Network, в которой после продажи компании NGINX > > Inc находился в числе технических руководителей проекта NGINX. > > Отмечается, что уход обусловлен желанием проводить больше времени в > > семье и заниматься личными проектами. В компании F5 Игорь занимал > > должность главного архитектора. Руководство разработкой NGINX теперь > > сосредоточится в руках Максима Коновалова, занимающего пост > > вице-президента по инжинирингу группы продуктов NGINX. > > > > Игорь основал NGINX в 2002 году и до создания компании NGINX Inc в 2011 > > году практически в одиночку занимался всей разработкой. С 2012 года > > Игорь отстранился от рутинного написания кода NGINX и основную работу по > > сопровождению кодовой базы подхватили Максим Дунин, Валентин Бартенев и > > Роман Арутюнян. После 2012 года участие Игоря в разработке было > > сосредоточено на сервере приложений NGINX Unit и движке njs. > > > > Отмечается, что после ухода Игоря из проекта, созданные при его участии > > культура и подход к разработке останутся неизменными, как не изменится и > > отношение к сообществу, прозрачности процессов, инновациям и открытому > > коду. Оставшаяся команда разработчиков постарается соответствовать той > > высокой планке, которую задал Игорь. > > > > > > -- > > Best regards, > > Gena > > _______________________________________________ > > nginx-ru mailing list -- nginx-ru на nginx.org > > To unsubscribe send an email to nginx-ru-leave на nginx.org > > _______________________________________________ > > nginx-ru mailing list -- nginx-ru на nginx.org > > To unsubscribe send an email to nginx-ru-leave на nginx.org > > _______________________________________________ > nginx-ru mailing list -- nginx-ru на nginx.org > To unsubscribe send an email to nginx-ru-leave на nginx.org > ----------- следующая часть ----------- Вложение в формате HTML было извлечено… URL: From vitaliy.okulov на gmail.com Thu Jan 20 09:01:01 2022 From: vitaliy.okulov на gmail.com (Vitaliy Okulov) Date: Thu, 20 Jan 2022 12:01:01 +0300 Subject: =?UTF-8?B?UmU6INCY0LPQvtGA0Ywg0KHRi9GB0L7QtdCyINGD0YjRkdC7INC40Lcg0LrQvtC80L/QsA==?= =?UTF-8?B?0L3QuNC5IEY1IE5ldHdvcmsg0Lgg0L/QvtC60LjQvdGD0Lsg0L/RgNC+0LXQutGCIE5HSU5Y?= In-Reply-To: References: <39cd7e7e-552c-bfda-46de-439fdb2d4eac@csdoc.com> Message-ID: Игорь, спасибо за отличный веб сервер. Удачи вам в новых начинаниях, проектах, все что происходит - все к лучшему. ср, 19 янв. 2022 г. в 17:08, Igor Sysoev : > Да, всё когда-то заканчивается. > У меня всё хорошо. > У nginx и F5, надеюсь, тоже будет всё хорошо. > > > -- > Igor Sysoev > > > On 19 Jan 2022, at 13:57, Vitaliy Okulov > wrote: > > > > Прошла эпоха, надеюсь Игорь хорошо вышел из компании. > > > > вт, 18 янв. 2022 г. в 23:15, Gena Makhomed : > > > > https://www.opennet.ru/opennews/art.shtml?num=56535 > > > > Игорь Сысоев ушёл из компаний F5 Network и покинул проект NGINX > > > > Игорь Сысоев, создатель высокопроизводительного HTTP-сервера NGINX, > > уволился из компании F5 Network, в которой после продажи компании NGINX > > Inc находился в числе технических руководителей проекта NGINX. > > Отмечается, что уход обусловлен желанием проводить больше времени в > > семье и заниматься личными проектами. В компании F5 Игорь занимал > > должность главного архитектора. Руководство разработкой NGINX теперь > > сосредоточится в руках Максима Коновалова, занимающего пост > > вице-президента по инжинирингу группы продуктов NGINX. > > > > Игорь основал NGINX в 2002 году и до создания компании NGINX Inc в 2011 > > году практически в одиночку занимался всей разработкой. С 2012 года > > Игорь отстранился от рутинного написания кода NGINX и основную работу по > > сопровождению кодовой базы подхватили Максим Дунин, Валентин Бартенев и > > Роман Арутюнян. После 2012 года участие Игоря в разработке было > > сосредоточено на сервере приложений NGINX Unit и движке njs. > > > > Отмечается, что после ухода Игоря из проекта, созданные при его участии > > культура и подход к разработке останутся неизменными, как не изменится и > > отношение к сообществу, прозрачности процессов, инновациям и открытому > > коду. Оставшаяся команда разработчиков постарается соответствовать той > > высокой планке, которую задал Игорь. > > > > > > -- > > Best regards, > > Gena > > _______________________________________________ > > nginx-ru mailing list -- nginx-ru на nginx.org > > To unsubscribe send an email to nginx-ru-leave на nginx.org > > _______________________________________________ > > nginx-ru mailing list -- nginx-ru на nginx.org > > To unsubscribe send an email to nginx-ru-leave на nginx.org > > _______________________________________________ > nginx-ru mailing list -- nginx-ru на nginx.org > To unsubscribe send an email to nginx-ru-leave на nginx.org > ----------- следующая часть ----------- Вложение в формате HTML было извлечено… URL: From constantine на mellodesign.ru Thu Jan 20 10:09:51 2022 From: constantine на mellodesign.ru (=?utf-8?B?0JrQvtC90YHRgtCw0L3RgtC40L0g0KLQutCw0YfQtdC90LrQvg==?=) Date: Thu, 20 Jan 2022 13:09:51 +0300 Subject: =?utf-8?B?UmU6INCY0LPQvtGA0Ywg0KHRi9GB0L7QtdCyINGD0YjRkdC7INC4?= =?utf-8?B?0Lcg0LrQvtC80L/QsNC90LjQuSBGNSBOZXR3b3JrINC4INC/0L7QutC40L0=?= =?utf-8?B?0YPQuyDQv9GA0L7QtdC60YIgTkdJTlg=?= In-Reply-To: References: <39cd7e7e-552c-bfda-46de-439fdb2d4eac@csdoc.com> Message-ID: <264500F8-BF5E-4C9F-9C50-70A7A52F258D@mellodesign.ru> Спасибо за великолепные разработки. Успехов в дальнейшем! > 19 янв. 2022 г., в 17:07, Igor Sysoev написал(а): > > Да, всё когда-то заканчивается. > У меня всё хорошо. > У nginx и F5, надеюсь, тоже будет всё хорошо. > > > -- > Igor Sysoev > >> On 19 Jan 2022, at 13:57, Vitaliy Okulov wrote: >> >> Прошла эпоха, надеюсь Игорь хорошо вышел из компании. >> >> вт, 18 янв. 2022 г. в 23:15, Gena Makhomed : >> >> https://www.opennet.ru/opennews/art.shtml?num=56535 >> >> Игорь Сысоев ушёл из компаний F5 Network и покинул проект NGINX >> >> Игорь Сысоев, создатель высокопроизводительного HTTP-сервера NGINX, >> уволился из компании F5 Network, в которой после продажи компании NGINX >> Inc находился в числе технических руководителей проекта NGINX. >> Отмечается, что уход обусловлен желанием проводить больше времени в >> семье и заниматься личными проектами. В компании F5 Игорь занимал >> должность главного архитектора. Руководство разработкой NGINX теперь >> сосредоточится в руках Максима Коновалова, занимающего пост >> вице-президента по инжинирингу группы продуктов NGINX. >> >> Игорь основал NGINX в 2002 году и до создания компании NGINX Inc в 2011 >> году практически в одиночку занимался всей разработкой. С 2012 года >> Игорь отстранился от рутинного написания кода NGINX и основную работу по >> сопровождению кодовой базы подхватили Максим Дунин, Валентин Бартенев и >> Роман Арутюнян. После 2012 года участие Игоря в разработке было >> сосредоточено на сервере приложений NGINX Unit и движке njs. >> >> Отмечается, что после ухода Игоря из проекта, созданные при его участии >> культура и подход к разработке останутся неизменными, как не изменится и >> отношение к сообществу, прозрачности процессов, инновациям и открытому >> коду. Оставшаяся команда разработчиков постарается соответствовать той >> высокой планке, которую задал Игорь. >> >> >> -- >> Best regards, >> Gena >> _______________________________________________ >> nginx-ru mailing list -- nginx-ru на nginx.org >> To unsubscribe send an email to nginx-ru-leave на nginx.org >> _______________________________________________ >> nginx-ru mailing list -- nginx-ru на nginx.org >> To unsubscribe send an email to nginx-ru-leave на nginx.org > > _______________________________________________ > nginx-ru mailing list -- nginx-ru на nginx.org > To unsubscribe send an email to nginx-ru-leave на nginx.org From igor на sysoev.ru Thu Jan 20 12:00:06 2022 From: igor на sysoev.ru (Igor Sysoev) Date: Thu, 20 Jan 2022 13:00:06 +0100 Subject: =?utf-8?B?UmU6INCY0LPQvtGA0Ywg0KHRi9GB0L7QtdCyINGD0YjRkdC7INC4?= =?utf-8?B?0Lcg0LrQvtC80L/QsNC90LjQuSBGNSBOZXR3b3JrINC4INC/0L7QutC40L0=?= =?utf-8?B?0YPQuyDQv9GA0L7QtdC60YIgTkdJTlg=?= In-Reply-To: References: <39cd7e7e-552c-bfda-46de-439fdb2d4eac@csdoc.com> Message-ID: <04649347-D762-4AEE-AAF7-D3830E1F1EA0@sysoev.ru> На данный момент - никаких. -- Igor Sysoev > On 19 Jan 2022, at 20:20, Илья Шипицин wrote: > > Какие планы, если не секрет? > > On Wed, Jan 19, 2022, 7:08 PM Igor Sysoev wrote: > Да, всё когда-то заканчивается. > У меня всё хорошо. > У nginx и F5, надеюсь, тоже будет всё хорошо. > > > -- > Igor Sysoev > > > On 19 Jan 2022, at 13:57, Vitaliy Okulov wrote: > > > > Прошла эпоха, надеюсь Игорь хорошо вышел из компании. > > > > вт, 18 янв. 2022 г. в 23:15, Gena Makhomed : > > > > https://www.opennet.ru/opennews/art.shtml?num=56535 > > > > Игорь Сысоев ушёл из компаний F5 Network и покинул проект NGINX > > > > Игорь Сысоев, создатель высокопроизводительного HTTP-сервера NGINX, > > уволился из компании F5 Network, в которой после продажи компании NGINX > > Inc находился в числе технических руководителей проекта NGINX. > > Отмечается, что уход обусловлен желанием проводить больше времени в > > семье и заниматься личными проектами. В компании F5 Игорь занимал > > должность главного архитектора. Руководство разработкой NGINX теперь > > сосредоточится в руках Максима Коновалова, занимающего пост > > вице-президента по инжинирингу группы продуктов NGINX. > > > > Игорь основал NGINX в 2002 году и до создания компании NGINX Inc в 2011 > > году практически в одиночку занимался всей разработкой. С 2012 года > > Игорь отстранился от рутинного написания кода NGINX и основную работу по > > сопровождению кодовой базы подхватили Максим Дунин, Валентин Бартенев и > > Роман Арутюнян. После 2012 года участие Игоря в разработке было > > сосредоточено на сервере приложений NGINX Unit и движке njs. > > > > Отмечается, что после ухода Игоря из проекта, созданные при его участии > > культура и подход к разработке останутся неизменными, как не изменится и > > отношение к сообществу, прозрачности процессов, инновациям и открытому > > коду. Оставшаяся команда разработчиков постарается соответствовать той > > высокой планке, которую задал Игорь. > > > > > > -- > > Best regards, > > Gena > > _______________________________________________ > > nginx-ru mailing list -- nginx-ru на nginx.org > > To unsubscribe send an email to nginx-ru-leave на nginx.org > > _______________________________________________ > > nginx-ru mailing list -- nginx-ru на nginx.org > > To unsubscribe send an email to nginx-ru-leave на nginx.org > > _______________________________________________ > nginx-ru mailing list -- nginx-ru на nginx.org > To unsubscribe send an email to nginx-ru-leave на nginx.org > _______________________________________________ > nginx-ru mailing list -- nginx-ru на nginx.org > To unsubscribe send an email to nginx-ru-leave на nginx.org From arut на nginx.com Thu Jan 20 12:26:02 2022 From: arut на nginx.com (Roman Arutyunyan) Date: Thu, 20 Jan 2022 15:26:02 +0300 Subject: nginxQUIC: =?utf-8?B?0L3QtSDRgNCw0LHQvtGC0LDQtdGCINGB0LDQudGC?= =?utf-8?B?INC/0L7RgdC70LUg0LrQvtC80LzQuNGC0LA=?= 6ccf3867959a In-Reply-To: <15897882.20220104121959@gmail.com> References: <15897882.20220104121959@gmail.com> Message-ID: <20220120122602.p7ljmvygteuu7kch@Romans-MacBook-Pro.local> Добрый день, On Tue, Jan 04, 2022 at 12:19:59PM +0300, izorkin на gmail.com wrote: > Здравствуйте. > После последнего обновления nginxQUIC перестал открываться сайт на PeerTube - отображается пустая страница. > Проверил разные сборки, перестал работать после этого коммита - 6ccf3867959a - QUIC: refactored ngx_quic_order_bufs() and ngx_quic_split_bufs(). > Debug лог не влезает по размерам на pastebin.com? занимает 1 МБ. Попробуйте обновить код, После этого коммита должно заработать: https://hg.nginx.org/nginx-quic/rev/5acd0d89d8c2 -- Roman Arutyunyan From nginx-forum на forum.nginx.org Tue Jan 25 08:21:08 2022 From: nginx-forum на forum.nginx.org (Ilya Evseev) Date: Tue, 25 Jan 2022 03:21:08 -0500 Subject: =?UTF-8?Q?=D0=9F=D0=BE=D1=87=D0=B5=D0=BC=D1=83=20=D0=B7=D0=B0=D0=BF?= =?UTF-8?Q?=D0=B8=D1=81=D0=B8=20=D0=B2=20access.log=20=D0=BC=D0=BE=D0?= =?UTF-8?Q?=B3=D1=83=D1=82=20=D1=81=D0=BE=D0=B4=D0=B5=D1=80=D0=B6=D0?= =?UTF-8?Q?=B0=D1=82=D1=8C=20=D0=BF=D1=83=D1=81=D1=82=D0=BE=D0=B9=20rem?= =?UTF-8?Q?ote_addr=20=3F?= Message-ID: <25b4e8c9875894a70ded1ece41d6d8e7.NginxMailingListRussian@forum.nginx.org> Дано: nginx 1.18.0-0ubuntu1.2 и access_log по умолчанию. Проблема: некоторые записи в access.log содержат пустой IP клиента. Примеры (обе строки начинаются с пробела, фактические запросы заменил на "..."): - - [25/Jan/2022:07:56:46 +0300] "GET /... HTTP/1.1" 410 198 "-" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/97.0.4692.99 Safari/537.36" - - [25/Jan/2022:08:01:14 +0300] "GET /... HTTP/1.1" 101 2 "-" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/97.0.4692.71 Safari/537.36" Как такое может быть? remote_addr в настройках не переопределяется, set_real_ip_from не используется. Posted at Nginx Forum: https://forum.nginx.org/read.php?21,293434,293434#msg-293434 From mdounin на mdounin.ru Tue Jan 25 15:24:03 2022 From: mdounin на mdounin.ru (Maxim Dounin) Date: Tue, 25 Jan 2022 18:24:03 +0300 Subject: nginx-1.21.6 Message-ID: Изменения в nginx 1.21.6 25.01.2022 *) Исправление: при использование EPOLLEXCLUSIVE на Linux распределение клиентских соединений между рабочими процессами было неравномерным. *) Исправление: во время плавного завершения старых рабочих процессов nginx возвращал в ответах строку заголовка "Connection: keep-alive". *) Исправление: в директиве ssl_session_ticket_key при использовании TLSv1.3. -- Maxim Dounin http://nginx.org/ From nginx на kinetiksoft.com Tue Jan 25 15:39:51 2022 From: nginx на kinetiksoft.com (=?UTF-8?B?0JjQstCw0L0=?=) Date: Tue, 25 Jan 2022 18:39:51 +0300 Subject: =?UTF-8?B?UmU6INCf0L7Rh9C10LzRgyDQt9Cw0L/QuNGB0Lgg0LIgYWNjZXNzLmxv?= =?UTF-8?B?ZyDQvNC+0LPRg9GCINGB0L7QtNC10YDQttCw0YLRjCDQv9GD0YHRgtC+0LkgcmVt?= =?UTF-8?Q?ote_addr_=3f?= In-Reply-To: <25b4e8c9875894a70ded1ece41d6d8e7.NginxMailingListRussian@forum.nginx.org> References: <25b4e8c9875894a70ded1ece41d6d8e7.NginxMailingListRussian@forum.nginx.org> Message-ID: <28420986-1d04-01c3-4ea7-0809c11cff93@kinetiksoft.com> Здравствуйте! Сходу, если идея, то IP адреса может не быть, если запрос приходит в nginx через unix-сокет. Проверьте все ваши listen'ы или дайте nginx -T. С уважением, Иван. 25.01.2022 11:21, Ilya Evseev пишет: > Дано: nginx 1.18.0-0ubuntu1.2 и access_log по умолчанию. > > Проблема: некоторые записи в access.log содержат пустой IP клиента. > > Примеры (обе строки начинаются с пробела, фактические запросы заменил на > "..."): > > - - [25/Jan/2022:07:56:46 +0300] "GET /... HTTP/1.1" 410 198 "-" > "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like > Gecko) Chrome/97.0.4692.99 Safari/537.36" > - - [25/Jan/2022:08:01:14 +0300] "GET /... HTTP/1.1" 101 2 "-" "Mozilla/5.0 > (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) > Chrome/97.0.4692.71 Safari/537.36" > > Как такое может быть? > remote_addr в настройках не переопределяется, set_real_ip_from не > используется. > > Posted at Nginx Forum: https://forum.nginx.org/read.php?21,293434,293434#msg-293434 > > _______________________________________________ > nginx-ru mailing list -- nginx-ru на nginx.org > To unsubscribe send an email to nginx-ru-leave на nginx.org From mdounin на mdounin.ru Wed Jan 26 02:32:17 2022 From: mdounin на mdounin.ru (Maxim Dounin) Date: Wed, 26 Jan 2022 05:32:17 +0300 Subject: =?koi8-r?B?8M/exc3VINrB0MnTySDXIGFj?= =?koi8-r?B?Y2Vzcy5sb2cgzc/H1dQg08/ExdLWwdTYINDV09TPyg==?= remote addr ? In-Reply-To: <28420986-1d04-01c3-4ea7-0809c11cff93@kinetiksoft.com> References: <25b4e8c9875894a70ded1ece41d6d8e7.NginxMailingListRussian@forum.nginx.org> <28420986-1d04-01c3-4ea7-0809c11cff93@kinetiksoft.com> Message-ID: Hello! On Tue, Jan 25, 2022 at 06:39:51PM +0300, Иван wrote: > Сходу, если идея, то IP адреса может не быть, если запрос приходит в > nginx через unix-сокет. Проверьте все ваши listen'ы или дайте nginx -T. Для unix-сокетов будет строка "unix:" (и путь, если клиентский сокет забинжен). > 25.01.2022 11:21, Ilya Evseev пишет: > > Дано: nginx 1.18.0-0ubuntu1.2 и access_log по умолчанию. > > > > Проблема: некоторые записи в access.log содержат пустой IP клиента. > > > > Примеры (обе строки начинаются с пробела, фактические запросы заменил на > > "..."): > > > > - - [25/Jan/2022:07:56:46 +0300] "GET /... HTTP/1.1" 410 198 "-" > > "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like > > Gecko) Chrome/97.0.4692.99 Safari/537.36" > > - - [25/Jan/2022:08:01:14 +0300] "GET /... HTTP/1.1" 101 2 "-" "Mozilla/5.0 > > (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) > > Chrome/97.0.4692.71 Safari/537.36" > > > > Как такое может быть? > > remote_addr в настройках не переопределяется, set_real_ip_from не > > используется. Как можно получить пробел - лично я не представляю. Для начала я бы внимательно посмотрел на то, как именно сконфигурировано логгирование (читай: действительно ли по умолчанию, или есть нюансы), и нет ли сторонних модулей (практика показывает, что там может быть что угодно, и любые спецэффекты в произвольных местах как следствие). -- Maxim Dounin http://mdounin.ru/ From nginx-forum на forum.nginx.org Wed Jan 26 08:31:29 2022 From: nginx-forum на forum.nginx.org (Ilya Evseev) Date: Wed, 26 Jan 2022 03:31:29 -0500 Subject: =?UTF-8?Q?Re:=20=D0=9F=D0=BE=D1=87=D0=B5=D0=BC=D1=83=20=D0=B7=D0=B0?= =?UTF-8?Q?=D0=BF=D0=B8=D1=81=D0=B8=20=D0=B2=20access.log=20=D0=BC=D0?= =?UTF-8?Q?=BE=D0=B3=D1=83=D1=82=20=D1=81=D0=BE=D0=B4=D0=B5=D1=80=D0?= =?UTF-8?Q?=B6=D0=B0=D1=82=D1=8C=20=D0=BF=D1=83=D1=81=D1=82=D0=BE=D0?= =?UTF-8?Q?=B9=20remote=20addr=20=3F?= In-Reply-To: References: Message-ID: Проверил: nginx -T | grep listen -- только TCP-порты nginx -T | grep unix: -- только fastcgi_pass ss -nlp | grep -w nginx -- только TCP-порты nginx -T | grep access_log -- только стандартный и combined Единственный сторонний модуль - nchan Возможно, дело действительно в нём, потому что пустой remote_addr только в записях для тех запросов, которые обрабатывает nchan. Posted at Nginx Forum: https://forum.nginx.org/read.php?21,293451,293461#msg-293461 From gmm на csdoc.com Fri Jan 28 08:57:10 2022 From: gmm на csdoc.com (Gena Makhomed) Date: Fri, 28 Jan 2022 10:57:10 +0200 Subject: js_import Message-ID: <09e2195c-7770-d588-41e0-0fda5a243996@csdoc.com> Здравствуйте, All! Ошибка в русской документации к директиве js_import: http://nginx.org/ru/docs/http/ngx_http_js_module.html#js_import Синтаксис: js_import модуль.js | имя_экспорта из модуль.js; http://nginx.org/en/docs/http/ngx_http_js_module.html#js_import Syntax: js_import module.js | export_name from module.js; from - это же ключевое слово, и оно не должно переводиться на русский? Вместо: Синтаксис: js_import модуль.js | имя_экспорта из модуль.js; Должно быть: Синтаксис: js_import модуль.js | имя_экспорта from модуль.js; -- Best regards, Gena From xeioex на nginx.com Fri Jan 28 09:19:16 2022 From: xeioex на nginx.com (Dmitry Volyntsev) Date: Fri, 28 Jan 2022 12:19:16 +0300 Subject: js_import In-Reply-To: <09e2195c-7770-d588-41e0-0fda5a243996@csdoc.com> References: <09e2195c-7770-d588-41e0-0fda5a243996@csdoc.com> Message-ID: <08c99de4-11b2-ea9e-4ea0-bffc00c6f44d@nginx.com> On 28.01.2022 11:57, Gena Makhomed wrote: > Здравствуйте, All! > > Ошибка в русской документации к директиве js_import: > > http://nginx.org/ru/docs/http/ngx_http_js_module.html#js_import > > Синтаксис: js_import модуль.js | имя_экспорта из модуль.js; > > http://nginx.org/en/docs/http/ngx_http_js_module.html#js_import > > Syntax:    js_import module.js | export_name from module.js; > > from - это же ключевое слово, и оно не должно переводиться на русский? > > Вместо: > > Синтаксис: js_import модуль.js | имя_экспорта из модуль.js; > > Должно быть: > > Синтаксис: js_import модуль.js | имя_экспорта from модуль.js; > > да, это ошибка. Исправим. From nginx-forum на forum.nginx.org Mon Jan 31 12:45:19 2022 From: nginx-forum на forum.nginx.org (alex123456) Date: Mon, 31 Jan 2022 07:45:19 -0500 Subject: =?UTF-8?Q?=D0=B2=D1=8B=D0=B4=D0=B0=D1=82=D1=8C=20406=20=D0=BE=D1=88?= =?UTF-8?Q?=D0=B8=D0=B1=D0=BA=D1=83,=20=D0=B5=D1=81=D0=BB=D0=B8=20=D0?= =?UTF-8?Q?=B7=D0=B0=D0=B3=D0=BE=D0=BB=D0=BE=D0=B2=D0=BE=D0=BA=20=D0?= =?UTF-8?Q?=BD=D0=B5=20=D1=82=D0=BE=D1=82?= Message-ID: <36a640e997cc8da5a7d4dbcc89cce4fa.NginxMailingListRussian@forum.nginx.org> Добрый день. Есть задача на уровне nginx провалидировать клиентские заголовки если Content-Type != application/vnd.api+json то выдать 406 Как это можно сделать средаствами nginx? Posted at Nginx Forum: https://forum.nginx.org/read.php?21,293547,293547#msg-293547 From chipitsine на gmail.com Mon Jan 31 13:09:21 2022 From: chipitsine на gmail.com (=?UTF-8?B?0JjQu9GM0Y8g0KjQuNC/0LjRhtC40L0=?=) Date: Mon, 31 Jan 2022 18:09:21 +0500 Subject: =?UTF-8?B?UmU6INCy0YvQtNCw0YLRjCA0MDYg0L7RiNC40LHQutGDLCDQtdGB0LvQuCDQt9Cw0LPQvg==?= =?UTF-8?B?0LvQvtCy0L7QuiDQvdC1INGC0L7Rgg==?= In-Reply-To: <36a640e997cc8da5a7d4dbcc89cce4fa.NginxMailingListRussian@forum.nginx.org> References: <36a640e997cc8da5a7d4dbcc89cce4fa.NginxMailingListRussian@forum.nginx.org> Message-ID: кажется, должно сработать вот так map $http_content_type $is_header_not_ok { default "1"; application/vnd.api+json "0"; } if ($is_header_not_ok) { return 406; } пн, 31 янв. 2022 г. в 17:46, alex123456 : > Добрый день. > Есть задача на уровне nginx провалидировать клиентские заголовки > если Content-Type != application/vnd.api+json > то выдать 406 > Как это можно сделать средаствами nginx? > > Posted at Nginx Forum: > https://forum.nginx.org/read.php?21,293547,293547#msg-293547 > > _______________________________________________ > nginx-ru mailing list -- nginx-ru на nginx.org > To unsubscribe send an email to nginx-ru-leave на nginx.org > ----------- следующая часть ----------- Вложение в формате HTML было извлечено… URL: From nginx-forum на forum.nginx.org Mon Jan 31 14:19:44 2022 From: nginx-forum на forum.nginx.org (alex123456) Date: Mon, 31 Jan 2022 09:19:44 -0500 Subject: =?UTF-8?Q?Re:=20=D0=B2=D1=8B=D0=B4=D0=B0=D1=82=D1=8C=20406=20=D0=BE?= =?UTF-8?Q?=D1=88=D0=B8=D0=B1=D0=BA=D1=83,=20=D0=B5=D1=81=D0=BB=D0=B8?= =?UTF-8?Q?=20=D0=B7=D0=B0=D0=B3=D0=BE=D0=BB=D0=BE=D0=B2=D0=BE=D0=BA?= =?UTF-8?Q?=20=D0=BD=D0=B5=20=D1=82=D0=BE=D1=82?= In-Reply-To: References: Message-ID: <361afef7f144a11bf2fa08ade7289100.NginxMailingListRussian@forum.nginx.org> да. работает. спасибо! Posted at Nginx Forum: https://forum.nginx.org/read.php?21,293547,293549#msg-293549