Re: nginx 1.18.0 ест всю память и swap на Ubuntu Server 20.04.1 LTS
Влад Т
tolmachev.vlad на gmail.com
Пн Авг 31 16:08:08 UTC 2020
Такая же проблема есть, когда диски проседают при наплыве клиентов, nginx
начинает жрать до 100% памяти, подтверждаю, раздается статика.
пн, 31 авг. 2020 г., 19:02 Илья Шипицин <chipitsine на gmail.com>:
>
>
> пн, 31 авг. 2020 г. в 20:11, Alexey Galygin <mif на me.com>:
>
>> на тестовом запуске мы словили примерно 200 запросов к статике в секунду
>> в среднем (иногда больше, иногда меньше)
>> в общем-то это не так уж и много (картинки, стили, документы
>>
>> может быть такое, что если дисковая система стала медленнее (а судя по
>> косвенным замерам, которые я провёл, она медленнее в разы)
>> то прежняя конфигурация nginx просто не успевает раздавать статику?
>>
>> скорость сети больше чем скорость дисков
>> запросов от клиентов приходит масса
>> ком нарастает
>>
>
> а отключите буферизацию ?
>
> proxy_buffering off;
> proxy_request_buffering off;
>
> у вас статика раздается непосредственно с этого сервера или проксируете на
> другие ?
>
>
>
>> процессы висят в статусе “D", медленно считывают и копят это в память
>>
>> если отключить sendfile, включить aio, добавить ограничений, это поможет?
>>
>> или уменьшить worker_connections 4096?
>>
>> или уменьшить open_file_cache?
>>
>> или это всё фантазия и медленный диск не мог стать причиной пожирания
>> всей памяти?
>>
>>
>> On 31 Aug 2020, at 14:38, Alexey Galygin <mif на me.com> wrote:
>>
>> стандартная сборка из docker hub nginx:1.18.0
>>
>>
>> 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> wrote:
>>
>>> привет всем
>>>
>>> случилось странное, переехали на сервера по параметрам в разы большие,
>>> чем сейчас (с нескромными 256 Гб RAM+ 100 Гб swap (из всех параметров
>>> влияния на штатные параметры sysctl осталось отключение ipv6 и swapness выставленный
>>> в 10%))
>>>
>>> через 5 минут после старта nginx ест всю память и весь swap! (см.
>>> 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
>>> http://mailman.nginx.org/mailman/listinfo/nginx-ru
>>
>> _______________________________________________
>> nginx-ru mailing list
>> nginx-ru на nginx.org
>> http://mailman.nginx.org/mailman/listinfo/nginx-ru
>>
>>
>>
>> _______________________________________________
>> nginx-ru mailing list
>> nginx-ru на nginx.org
>> http://mailman.nginx.org/mailman/listinfo/nginx-ru
>
> _______________________________________________
> 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/611dcafd/attachment-0001.htm>
Подробная информация о списке рассылки nginx-ru