Hello!

On Mon, Aug 31, 2020 at 04:48:36PM +0300, Alexey Galygin wrote:

> мы запросили у организации, которая занимается DDoS Protection
> список всех запросов за интервал теста
>
> пытаемся по этим ссылкам ходить скриптом…
>
> на штатный resize пришлось не более 800 запросов за всё время эксперимента, вряд ли бы это забило всю память
> (файлики jpg они маленькие, ну допустим текло по 1 Мб на запрос, ну утёк бы 1 Гб за 5 минут, а не 300…)
>
> ну и точно такой же nginx 1.18.0 на эталонном сервере так не утекает
>
> изменилось в стенде только — Ubuntu — была 16.04 стала 20.04 (тут я подозреваю, сменился аллокатор памяти, что-то с FS подкрутили, может дескрипторы если не утекают, то кэш избыточный накапливается в ОЗУ)
> память — было 192 — стало 256
> FS как была ext4 так и осталась ext4…
> ЦОД — было нормальное железо — стала платформа VMWare Cloud Director… на вид работает даже шустрее

Это называется "сменилось примерно всё".
Я бы начал с простого:

0. Внимательно изучил конфигурацию.

Простая оценка максимального потребления памяти рабочим процессом:
worker_connections * (сумма всех буферов в конфиге). Стандартные
размеры буферов невелики, и сумму всех можно смело считать как
"меньше одного мегабайта", если в конфиге задано что-то иное -
соответственно прибавлять. Относительно большие размерыы буферов
встречаются только в image-фильтре (image_filter_buffer 1m) и mp4
(mp4_max_buffer_size 10m).

Нюанс: простая оценка не работает, если используются подзапросы
(SSI, cache background update, и так далее - каждый подзапрос
может иметь свои буфера, соответственно надо умножать на
количество подзапросов в одном соединении) и/или HTTP/2 (умножать
на http2_max_concurrent_streams + http2_max_concurrent_pushes).

Если результат больше или сравним с наблюдаемым потреблением
памяти - то чинить конфигурацию, если заметно больше - то искать
дальше.

Если я правильно помню приведённые фрагменты конфига, то там 4096
worker_connections, буферов мегабайта на 2 минимум, используется
background update. Если HTTP/2 не используется, то общее
потребление памяти в пределе будет 4096 * 2m * 2 == 16 гигабайт.
Это меньше, чем наблюдается, но не сильно. Что уже наводит на
всяческие мысли. Если же ещё и HTTP/2 используется - то один
рабочий процесс может занимать до пары терабайт, что явно не
соответствует возможностям машины.

То есть в принципе все наблюдаемые эффекты могут просто
объясняться конфигурацией и характером нагрузки, без всяких
утечек. Можно попробовать отключить HTTP/2, если вдруг
используется, и/или покрутить размеры буферов вниз. Ну и
количество рабочих процессов тоже.

Отдельный вопрос - почему не наблюдаются такие же или близкие
размеры рабочих процессов на старом сервере. Если конфигурации
полностью совпадают - возможно, причина в несколько другом
характере нагрузки, в частности - из-за смены ядра и платформы.
Меня, в частности, сильно смущает, что все рабочие процессы в
состоянии "D", смотреть стоит на дисковую подсистему.

1. Если есть какие-то сторонние модули - исключил их из конфига
(или сборки, если они собраны статически), и убедился, что
проблема воспроизводится. Если модули очень нужны - то можно
попробовать переписать конфиг так, чтобы вынести их в отдельный
инстанс nginx'а.

2. Если в конфиге используется скриптовый код - perl, njs,
whatever - то этот код может потреблять произвольный объём памяти,
даже если код кажется простым. Опять же, лучше всего попробовать
воспроизвести проблему без этого кода.

Ну и логи таки имеет смысл почитать, дабы точно понимать, что
происходит, а не строить предположения.

[...]

--
Maxim Dounin
http://mdounin.ru/
_______________________________________________
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru