Kafka на Kubernetes: cgroup v2 съедает page cache

Для Kafka дисковые чтения — это не просто деталь хранилища. При нормальной работе, когда потребители (consumers) находятся близко к голове лога и у брокеров достаточно памяти, горячие данные должны обычно отдаваться из кэша страниц (page cache), а не с диска.

Когда чтения начинают проваливаться до хранилища, симптомы становятся трудно игнорируемыми:

Именно поэтому это сразу бросилось в глаза. Мы наблюдали не безобидное расхождение в метриках, а активацию пути обработки данных, который не должен был срабатывать так часто.

В этой статье рассказывается, как мы расследовали проблему и что обнаружили. Хотя именно Kafka обнажила её, первопричина оказалась шире: взаимодействие между Kubernetes, cgroup v2, поведением ядра Linux при освобождении памяти (reclaim) и рабочими нагрузками с активным обращением к диску.

К концу статьи у вас должна сложиться более чёткая картина:

После миграции первого кластера Kafka на Kubernetes с помощью Strimzi мы сразу заметили кое-что необычное: брокеры выполняли постоянные и ощутимые чтения с диска. Для нашей нагрузки это был тревожный сигнал, поскольку эти кластеры обрабатывают очень высокий трафик, и даже небольшие регрессии задержки быстро проявляются в производительности брокеров.

График имел значение, потому что это был не изолированный всплеск и не событие восстановления. Это была стабильная активность чтения при штатной работе на железе, которое должно было вести себя аналогично нашему развёртыванию на EC2.

Kafka в значительной мере полагается на кэш страниц операционной системы, а не реализует собственный буферный слой. В здоровом кластере, когда потребители читают близко к голове лога и на узле достаточно доступной памяти, большинство горячих чтений должны обслуживаться из памяти, а не с диска.

Именно поэтому эти чтения сразу привлекли наше внимание:

Ключевая мысль была простой: для нашей нагрузки дисковые чтения — это не просто метрика хранилища. Это сигнал задержки.

Первым подозреваемым стало отставание потребителей (consumer lag). Это было бы самым простым объяснением: если потребители читают старые смещения (offsets), соответствующие данные могут уже не находиться в кэше страниц, и ядро вынуждено загружать их с диска.

Мы проверили отставание потребителей с помощью наших экспортёров и дашбордов мониторинга и не обнаружили ничего существенного. Потребители читали близко к голове лога, так что одно лишь отставание не могло объяснить постоянные чтения.

Вывод: чтения были реальными, но причиной служило не отставание потребителей.

Исключив отставание, мы задали следующий очевидный вопрос: что изменилось между старым и новым окружением?

Мы сравнили очевидных кандидатов:

Всё это фактически не изменилось. Значимые различия находились глубже в стеке:

Это сузило расследование до поведения памяти на уровне операционной системы, а не самой Kafka.

Чтобы понять, что делает ядро, мы использовали writeback.bt — скрипт bpftrace, показывающий, почему страницы записываются обратно на диск (writeback). Это было полезно, поскольку позволяет различать обычный фоновый writeback и writeback, вызванный давлением памяти (reclaim-driven writeback).

На новой машине многие события writeback были помечены как vmscan:

На старой машине writeback преобладал в режиме фоновых и периодических событий:

Это различие стало первым сильным сигналом на уровне ядра. Новая установка выполняла значительно больше writeback, вызванного освобождением памяти, что означало давление на кэш страниц.

vmscan — часть пути освобождения памяти (reclaim path) в ядре. Когда он появляется в трассировках writeback, это обычно означает, что ядро активно освобождает память, а не выполняет плановую фоновую запись.

На практике это означало, что система платила штраф за освобождение памяти, которого мы не ожидали на эквивалентном железе. В этот момент вопрос сместился с «почему Kafka читает с диска?» на «почему ядро так агрессивно вытесняет кэш страниц в этом окружении?»

Это привело нас к поведению памяти в cgroup v2, и в частности к memory.high. В cgroup v2, как только рабочая нагрузка пересекает высокое пороговое значение памяти (high memory threshold), ядро может начать применять давление освобождения памяти внутри этой cgroup, даже если на узле ещё есть свободная память.

Это плохо сочетается с Kafka и аналогичными системами, работающими с диском:

Иными словами, проблема была не в том, что у узла недостаточно RAM в абсолютном выражении. Проблема в том, что поведение освобождения памяти изменилось под Kubernetes с cgroup v2.

Поначалу мы попробовали очевидные Kafka-специфичные ручки тюнинга: vm.dirty_ratio и vm.dirty_background_ratio. Эти настройки влияют на то, сколько «грязных» данных ядро допускает накопить перед принудительным writeback.

Они помогли управлять поведением writeback, но не решили реальную проблему. Writeback, вызванный освобождением памяти, сохранялся, а дисковые чтения оставались выше прежнего базового уровня.

Вывод: тюнинга dirty-страниц было недостаточно, поскольку основная проблема заключалась в давлении reclaim, а не в обычной записи на диск.

Первым значимым исправлением стал отказ от установки лимитов памяти для подов Kafka с переходом к использованию requests и выделенных узлов. Это позволило избежать срабатывания давления освобождения памяти на уровне пода через механизмы управления памятью cgroup, пока хост ещё располагал свободной памятью.

В нашем случае это сработало по следующим причинам:

Это изменение дало Kafka больше свободы использовать кэш страниц хоста, вместо того чтобы быть ограниченной искусственной границей освобождения памяти.

Второе исправление — настройка vm.min_free_kbytes. Этот параметр влияет на водяные знаки ядра (kernel watermarks), которые определяют, когда kswapd просыпается и начинает освобождать память.

На наших узлах значение по умолчанию составляло:

Мы постепенно увеличивали его и наблюдали:

Для нашего железа лучший результат дало:

Это значение специфично для конкретной нагрузки, поэтому я не стал бы представлять его как универсальную рекомендацию. Важен сам механизм: повышение водяных знаков помогло ядру освобождать память раньше и плавнее, вместо того чтобы скатываться в более жёсткое поведение reclaim позже.

После применения обоих изменений разница была очевидна:

При той же нагрузке количество байт, читаемых с диска, упало почти до нуля, а нормализованный средний уровень нагрузки (load average) снизился примерно на 50%.

Если вы устраняете подобное поведение в Kafka или другом disk-heavy сервисе на Kubernetes, я бы начал отсюда:

Если хотите глубже разобраться в идеях, лежащих в основе этого расследования, следующие ресурсы заслуживают внимания:

Если вы сталкивались с похожим поведением кэша страниц, освобождения памяти или cgroup v2 в Kafka или других stateful-нагрузках на Kubernetes — буду рад сравнить наблюдения.