Varnish использует значительно больше памяти, чем кэш?
Я использую лак в качестве веб-кеша. Я использую RHEL 9.2. Мой кэш имеет размер 1 ГБ. Мой процесс лакирования использует память 3,7 ГБ.
$ ps -p 1163 -o %mem,rss
%MEM RSS
15.7 3886108
Я запускаю лак с аргументом -s malloc,1024M, который должен установить размер кэша 1 ГБ. Полная команда, вызываемая systemd, выглядит так:
/usr/sbin/varnishd -a 127.6.6.6:7480 -f /etc/varnish/default.vcl -S /etc/varnish/secret -s malloc,1024M -P /var/run/varnish.pid -T 127.6.6.6:62
Кажется, это работает, я вижу с помощью varnishstat:
$ varnishstat -1 | grep s0.g
SMA.s0.g_alloc 22573 . Allocations outstanding
SMA.s0.g_bytes 1073105012 . Bytes outstanding
SMA.s0.g_space 636812 . Bytes available
Мне трудно поверить, что для кэша объемом 1 ГБ требуются 2,7 ГБ накладных расходов. Что мне здесь не хватает?
Перезапуск с помощью systemctl restart varnish временно снижает использование (поскольку при этом очищается кеш, но также исчезает некэш-память), но постепенно оно снова увеличивается и достигает 3,7 ГБ.
Это тестовая система под довольно большой нагрузкой. Возможно ли, что эта память действительно используется для обслуживания запросов? Я вижу это в переходном пространстве, на мой взгляд это выглядело неинтересно, но после прочтения некоторых других тем, возможно, так оно и есть.
SMA.Transient.c_req 9720800 7.90 Allocator requests
SMA.Transient.c_fail 0 0.00 Allocator failures
SMA.Transient.c_bytes 324751584558 263852.57 Bytes allocated
SMA.Transient.c_freed 324751584558 263852.57 Bytes freed
SMA.Transient.g_alloc 0 . Allocations outstanding
SMA.Transient.g_bytes 0 . Bytes outstanding
SMA.Transient.g_space 0 . Bytes available
Я также видел несколько предположений, что лак предназначен для использования с jemalloc, у меня не установлен jemalloc, похоже, что лак использует malloc glibc.
РЕДАКТИРОВАНИЕ: Полный вывод лакстата -1 можно найти здесь: https://pastebin.com/3uZ1kpy6 , а лакадм param.show здесь: https://pastebin.com/7jrLKdMx. На момент создания дампа статистики использование памяти составляло 3 ГБ.
ps -p 917285 -o %mem,vsz,rss
%MEM VSZ RSS
12.8 7278920 3136620
Ответы 1
malloc Хранение кэша представляет собой лишь часть потребления памяти Varnish.
Временное хранение
Как вы упомянули в своем вопросе, временное хранилище также может потреблять память. Временное хранилище предназначено для буферизации или потоковой передачи некэшируемого и недолговечного контента. Он не ограничен, что означает, что в случае пиков может возникнуть ошибка OOM.
К вашему сведению: параметр времени выполнения shortlived определяет, что такое кратковременный контент, и по умолчанию равен 10 секундам.
Потоки
Существует также стоимость использования Varnish. Для каждого потока происходит некоторое распределение памяти.
Количество потоков ограничено параметрами времени выполнения thread_pool_min и thread_pool_max для каждого пула потоков. По умолчанию эти значения составляют минимум 100 и максимум 5000 на пул потоков.
Поскольку существует 2 пула потоков (как определено thread_pools), оно будет находиться в диапазоне от 200 до 1000, если вы полагаетесь на значения по умолчанию.
Параметр времени выполнения workspace_thread определяет начальный объем памяти, потребляемый каждым потоком. Значение по умолчанию — 2 КБ.
Потребляется больше памяти рабочей области
Помимо workspace_thread потребления памяти на поток, существует дополнительное потребление памяти для каждого потока в зависимости от типа рабочей нагрузки, которую он обрабатывает.
Если поток используется для управления сеансом TCP, и по умолчанию потребляется дополнительно 0,75 КБ памяти, как определено параметром времени выполнения workspace_session.
Если поток используется для обработки HTTP-запроса, по умолчанию используется 96 КБ памяти, как определено параметром времени выполнения workspace_client.
А для серверных запросов потребление памяти определяется параметром времени выполнения workspace_backend, который по умолчанию также равен 96 КБ.
Тюнинг
Если вы изменили какой-либо из упомянутых мной параметров времени выполнения, это повлияет на общее потребление памяти.
Вы можете настраивать эти параметры соответствующим образом, и это во многом балансирует между обеспечением достаточного количества потоков для обработки всех входящих запросов и внутренних запросов.
Но также иметь достаточно памяти для обработки всей логики, указанной вами в файле VCL.
Альтернативным решением является Massive Storage Engine , который является частью Varnish Enterprise, коммерческой версии Varnish. Он имеет функцию под названием Регулятор памяти, которая позволяет ограничивать общее потребление памяти Varnish и автоматически масштабировать размер кэша в зависимости от требуемой памяти во время выполнения.
Я также должен отметить, что после обновления с 4.0.5 до 6.6.2 ситуация кардинально изменилась. Перед обновлением мы использовали в общей сложности около 1,3 ГБ для поддержки кэша объемом 1 ГБ.
@ Алекс 200, у тебя очень мало потоков. Я не вижу причин, по которым varnishd потреблял бы так много памяти. Не могли бы вы прикрепить полный вывод varnishstat -1 к своему вопросу и полному файлу VCL? Конечно, вам нужно собирать статистику, когда происходит высокое потребление памяти. Пожалуйста, также прикрепите выходные данные varnishadm param.show, чтобы увидеть, какие параметры времени выполнения вы используете. Я хотел бы получить полную картину.
Я обновил исходное сообщение, добавив полный вывод лакстата и команду лакаадм. Большое спасибо за ваши постоянные советы.
@Алекс, я только что разговаривал с нашими разработчиками, и они посоветовали бы тебе отключить «прозрачные огромные страницы» в ядре Linux. Дополнительную информацию см. на странице docs.varnish-software.com/varnish-enterprise/installation/…. jemalloc тоже может быть связано. Какую версию Варниша вы используете?
Я использую лак-6.6.2, установленный через RPM прямо из ISO-образа RHEL9. Я перезагрузил одну из наших систем после отключения прозрачных огромных страниц, которые выглядели многообещающе, однако, к сожалению, использование памяти осталось неизменным. Кажется (согласно: bugzilla.redhat.com/show_bug.cgi?id=1656034), что версия лака для RHEL компилируется без jemalloc. Возможно, мне стоит попробовать пересобрать с помощью jemalloc?
@Alex Пожалуйста, установите Varnish из packagecloud.io/varnishcache. Имейте в виду, что версия 6.6 — это EOL. Либо используйте 6.0 LTS, либо 7.5. Я не уверен, что это включает поддержку jemalloc из коробки, но попробовать стоит.
Спасибо за предложение. Я установил версию 6.0.13 и jemalloc (подозреваю, что это было необходимо, ldd показывает, что он связан с лаком). Использование памяти для кэша объемом 1 ГБ снизилось с ~3,7 ГБ до ~2 ГБ. Это потрясающее улучшение, мне действительно интересно, что происходит с версией RHEL9. Скорее всего, я подниму с ними заявку в службу поддержки. Большое спасибо за вашу помощь в этом.
@Алекс, несколько заключительных советов: если можете, попробуйте установить Varnish Cache 7.5 и посмотреть, есть ли еще улучшения. Синтаксис VCL и поведение Varnish должны быть совместимы.
Спасибо за подробности. Хотя я не уверен, что это объясняет то, что я вижу. Чтобы предоставить дополнительную информацию, у меня 200 тем. «varnishstat», как показано выше, показывает, что я использую 1 ГБ в кеше malloc и 0 во временном пространстве. Так откуда же взялись эти дополнительные 2,7 ГБ? Я заметил, что когда я снял нагрузку, использование памяти также остается высоким. Такое ощущение, что у меня какие-то неправильные настройки конфигурации.