Re: nginx 1.18.0 ест всю память и swap на Ubuntu Server 20.04.1 LTS
Alexey Galygin
mif на me.com
Пн Авг 31 11:38:21 UTC 2020
стандартная сборка из docker hub nginx:1.18.0
docker exec nginx nginx -V
TLS SNI support enabled
configure arguments: --prefix=/etc/nginx --sbin-path=/usr/sbin/nginx --modules-path=/usr/lib/nginx/modules --conf-path=/etc/nginx/nginx.conf --error-log-path=/var/log/nginx/error.log --http-log-path=/var/log/nginx/access.log --pid-path=/var/run/nginx.pid --lock-path=/var/run/nginx.lock --http-client-body-temp-path=/var/cache/nginx/client_temp --http-proxy-temp-path=/var/cache/nginx/proxy_temp --http-fastcgi-temp-path=/var/cache/nginx/fastcgi_temp --http-uwsgi-temp-path=/var/cache/nginx/uwsgi_temp --http-scgi-temp-path=/var/cache/nginx/scgi_temp --user=nginx --group=nginx --with-compat --with-file-aio --with-threads --with-http_addition_module --with-http_auth_request_module --with-http_dav_module --with-http_flv_module --with-http_gunzip_module --with-http_gzip_static_module --with-http_mp4_module --with-http_random_index_module --with-http_realip_module --with-http_secure_link_module --with-http_slice_module --with-http_ssl_module --with-http_stub_status_module --with-http_sub_module --with-http_v2_module --with-mail --with-mail_ssl_module --with-stream --with-stream_realip_module --with-stream_ssl_module --with-stream_ssl_preread_module --with-cc-opt='-g -O2 -fdebug-prefix-map=/data/builder/debuild/nginx-1.18.0/debian/debuild-base/nginx-1.18.0=. -fstack-protector-strong -Wformat -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -fPIC' --with-ld-opt='-Wl,-z,relro -Wl,-z,now -Wl,--as-needed -pie’
тестировать можем только по ночам, днём пользователи работают
поэтому посмотреть рост воркеров сейчас не представляется возможным + требуется именно получить нагрузку (пока сервер не трогают там штиль и спокойствие)
хочу собрать идеи, что крутить ночью
возможно дело и не в количестве воркеров: по скриншоту видно, что всего 5-10 воркеров набрали всю память
конфиг большой, светить бы его прод версию не хотелось
могу точечно надёргать:
worker_processes auto;
events {
worker_connections 4096;
multi_accept on;
use epoll;
}
worker_rlimit_nofile 10240;
http {
client_max_body_size 2000m;
sendfile on;
tcp_nopush on;
tcp_nodelay on;
server_tokens off;
keepalive_timeout 60;
reset_timedout_connection on;
if_modified_since before;
proxy_buffer_size 128k;
proxy_buffers 24 32k;
proxy_busy_buffers_size 256k;
proxy_temp_file_write_size 4m;
client_header_buffer_size 8k;
large_client_header_buffers 8 128k;
client_body_buffer_size 256K;
server_names_hash_max_size 4096;
server_names_hash_bucket_size 128;
map_hash_max_size 8500;
proxy_headers_hash_bucket_size 128;
gzip on;
gzip_types text/plain text/css text/xml application/xml application/x-javascript application/javascript application/json application/rss+xml application/rss application/x-rss+xml;
gzip_http_version 1.1;
gzip_min_length 900;
gzip_comp_level 7;
gzip_proxied any;
gzip_buffers 32 8k;
gzip_disable msie6;
proxy_cache_path /var/lib/nginx/cache levels=1:2 keys_zone=C1:20m inactive=24h max_size=20000m;
proxy_cache_use_stale updating error timeout invalid_header http_500 http_502 http_503 http_504;
proxy_cache_background_update on;
proxy_temp_path /var/run/nginx/proxy;
proxy_cache_lock on;
proxy_cache_lock_timeout 25s;
proxy_cache_methods GET HEAD;
proxy_cache_valid 404 1m;
open_file_cache max=1024 inactive=30s;
open_file_cache_valid 60s;
open_file_cache_min_uses 2;
open_file_cache_errors on;
open_log_file_cache max=100 inactive=30s valid=1m min_uses=2;
}
к слову, на новом стенде cache выел всего 300 Мб из 10-20 Гб разрешённых (а на рабочем старом стенде вообще пишется в RAM /var/run — и всё там ок)
нюанс в том, что эта конфигурация отлично работает на старом сервере рядом, где только Ubuntu более старая
> On 31 Aug 2020, at 14:19, Илья Шипицин <chipitsine на gmail.com> wrote:
>
> Посмотрите, не увеличивается ли у вас число воркеров.
>
> Ещё поможет вывод nginx -V
>
> И поможет конфиг
>
> On Mon, Aug 31, 2020, 1:51 PM Alexey Galygin <mif на me.com <mailto:mif на me.com>> wrote:
> привет всем
>
> случилось странное, переехали на сервера по параметрам в разы большие, чем сейчас (с нескромными 256 Гб RAM+ 100 Гб swap (из всех параметров влияния на штатные параметры sysctl осталось отключение ipv6 и swapness выставленный в 10%))
>
> через 5 минут после старта nginx ест всю память и весь swap! (см. https://prnt.sc/u8nia0 <https://prnt.sc/u8nia0>)
> в итоге сервер умирает, никогда такого не видели, это же кэширующий прокси, а не БД!…
>
> пускаем на Ubuntu 20.04 Server LTS (5.4.0-42-generic #46-Ubuntu SMP Fri Jul 10 00:24:02 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux)
> нагруженный nginx 1.18 (пробовали из официальных репок ставить на хост nginx/stable 1.18.0-1~focal amd64 и в контейнер из официального докера nginx:1.18.0)
>
> из особенностей используются ngx_http_js_module.so — для исторического escape/unescape URI и ngx_http_image_filter_module.so — для подрезки изображений
>
> исключили уже всё — и zfs, который переформатировали в ext4 с отключенным atime
> и из docker вынесли nginx в хост
>
> и внутренние системы исключили…
>
> меняли конфиги, отключали sendfile, кэши open-файлов, включали aio…
>
> упорно кончается вся память через 5 минут, все 256 Гб и своп
>
> идей практически не осталось, куда можно ещё копать?
> _______________________________________________
> nginx-ru mailing list
> nginx-ru на nginx.org <mailto:nginx-ru на nginx.org>
> http://mailman.nginx.org/mailman/listinfo/nginx-ru <http://mailman.nginx.org/mailman/listinfo/nginx-ru>_______________________________________________
> nginx-ru mailing list
> nginx-ru на nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx-ru
----------- следущая часть -----------
Вложение в формате HTML было извлечено…
URL: <http://mailman.nginx.org/pipermail/nginx-ru/attachments/20200831/aff2df26/attachment-0001.htm>
Подробная информация о списке рассылки nginx-ru