Сколько RAM нужно для Apache Kafka

MAATRIX

Если вы считаете память под Kafka так же, как под обычный веб-сервис — по формуле «сколько ест процесс» — то почти наверняка возьмёте либо слишком мало, либо в разы больше, чем нужно. Брокер Kafka сам по себе съедает скромный кусок RAM под JVM-heap, а вот всё остальное — это page cache операционной системы, и именно от него зависит, будет кластер летать или задыхаться под нагрузкой. Разберём, сколько реально нужно памяти под брокер, ZooKeeper или KRaft, и как не переплатить за сервер, который всё равно упрётся не в RAM, а в диск.

Почему Kafka считает память не так, как обычные сервисы

Kafka спроектирована вокруг простой идеи: диск быстрый, если писать и читать последовательно, а операционная система уже умеет кэшировать файлы в памяти лучше, чем любое приложение поверх неё. Поэтому брокер Kafka сознательно не держит данные сообщений в heap JVM — он пишет их на диск в виде сегментов лога и полагается на page cache Linux, чтобы читать их обратно быстро, без похода на физический накопитель.

Из этого следует главный вывод: RAM, выделенная под heap JVM, и RAM, которая реально разгоняет throughput кластера — это две разные и почти не пересекающиеся категории. Можно дать брокеру 4 ГБ heap и 64 ГБ сервера — и это будет куда быстрее, чем 32 ГБ heap на той же машине. Большой heap не ускоряет Kafka, он только увеличивает паузы сборщика мусора.

Отсюда и практическое правило sizing'а: считать нужно не «сколько нужно Kafka», а «сколько нужно heap-у Kafka» плюс «сколько нужно page cache под ваш рабочий набор данных (working set)» плюс запас под ОС и соседние процессы (мониторинг, log-shipping, при необходимости — ZooKeeper). Тот же принцип «heap отдельно, кэш ОС отдельно» работает и для других JVM-систем — например, для Elasticsearch расчёт RAM устроен похоже.

Сколько выделять JVM-heap брокеру

Официальная и подтверждённая практикой рекомендация — держать heap брокера Kafka в диапазоне 6-8 ГБ, даже на серверах с большим объёмом RAM. Увеличение heap выше этого порога почти никогда не даёт прироста производительности, зато ощутимо повышает риск долгих пауз GC, особенно на старых сборщиках мусора.

Задаётся heap через переменные окружения перед запуском kafka-server-start.sh:

export KAFKA_HEAP_OPTS="-Xms6g -Xmx6g"
export KAFKA_JVM_PERFORMANCE_OPTS="-server -XX:+UseG1GC -XX:MaxGCPauseMillis=20 \
  -XX:InitiatingHeapOccupancyPercent=35 -XX:+ExplicitGCInvokesConcurrent \
  -XX:MaxInlineLevel=15 -Djava.awt.headless=true"

Ключевые моменты:

• -Xms и -Xmx лучше делать равными — так JVM не тратит время на динамическое расширение heap под нагрузкой.
• G1GC — стандартный выбор для Kafka начиная со старых версий, он даёт предсказуемые паузы на больших heap лучше, чем CMS.
• Для небольших нагрузок (тест, staging, до нескольких сотен сообщений в секунду) достаточно 2-3 ГБ heap — переплачивать смысла нет.
• Для production-кластера с десятками партиций на брокер и высоким throughput 6 ГБ — комфортный стандарт, 8 ГБ — верхняя разумная граница.

Если видите в логах брокера частые Full GC длительностью больше секунды — это почти всегда сигнал не «добавить heap», а «разобраться, что там происходит» (слишком много партиций, утечка в кастомных interceptor'ах, старая версия JVM).

Page cache: главный потребитель RAM в Kafka

Вот где на самом деле должна лежать основная часть RAM сервера. Когда продюсер пишет сообщение, оно попадает в page cache и на диск практически одновременно (Linux буферизует запись). Когда консьюмер читает — если данные ещё в page cache, чтение идёт из памяти со скоростью, близкой к RAM, без единой операции ввода-вывода на диске. Это и есть причина, по которой Kafka способна прокачивать гигабиты в секунду на обычных серверах: она превращает диск в почти линейную запись и читает горячие данные из памяти ОС.

Отсюда практический ориентир: чем ближе объём RAM (за вычетом heap и ОС) к вашему «горячему» рабочему набору, тем стабильнее throughput. Горячий набор — это не весь объём данных за весь retention, а тот объём, который реально читают консьюмеры прямо сейчас: обычно это последние часы или сутки данных, а не недели хранения.

Пример расчёта: если в топик пишется 50 МБ/с и консьюмеры читают данные с задержкой не больше 2 часов от записи, горячий набор — это примерно 50 МБ/с × 3600 с × 2 = 360 ГБ. Столько page cache вы вряд ли себе позволите, и это нормально: часть чтений всё равно уйдёт на диск. Важно, чтобы хотя бы данные за последние минуты-десятки минут помещались в кэш — именно их читают consumer group'ы, которые не отстают от продюсеров.

Проверить, насколько активно используется page cache под данные Kafka, можно так:

free -h
# смотрим колонку buff/cache — это и есть память под page cache

# доля физических чтений с диска vs из кэша по конкретному разделу
iostat -x 5 /dev/sdb

Если %util на диске с логами Kafka стабильно высокий, а buff/cache в free -h близок к общему объёму RAM — вы уже упёрлись в page cache, и следующий шаг это либо больше RAM, либо более быстрый диск (NVMe вместо SATA SSD), либо сокращение retention.

ZooKeeper vs KRaft — разница в требованиях к памяти

До версии 3.3 (и как production-ready режим — начиная примерно с 3.5-3.6) Kafka требовала отдельный кластер ZooKeeper для хранения метаданных: списка топиков, партиций, ACL, конфигурации брокеров. С переходом на KRaft (Kafka Raft metadata mode) ZooKeeper больше не нужен — метаданные хранятся прямо в самой Kafka через выделенные controller-узлы.

С точки зрения RAM разница ощутимая:

Для нового кластера в 2026 году имеет смысл сразу разворачивать KRaft — Apache Kafka официально объявила ZooKeeper устаревшим режимом, и новые версии постепенно убирают поддержку. Если вы поднимаете кластер с нуля на пробу, комбинированный режим (controller + broker в одном процессе) на 1-3 узлах экономит и RAM, и количество серверов, которые нужно администрировать.

Если у вас уже есть legacy-кластер с ZooKeeper — закладывайте отдельные лёгкие серверы под него (2-4 ГБ RAM на узел вполне достаточно для метаданных, если только у вас не десятки тысяч партиций).

Сколько RAM нужно на практике: таблица по нагрузке

Ориентировочные цифры ниже — это отправная точка, а не гарантия: реальное потребление зависит от количества партиций на брокер, размера сообщений, числа consumer group'ов и retention. Указана RAM на один брокер, без учёта ZooKeeper/controller.

Отдельно стоит сказать про количество партиций: каждая партиция — это открытый файловый дескриптор, индекс и метаданные в памяти брокера. При тысячах партиций на брокер накладные расходы на саму структуру данных Kafka (не на heap, а на файловые буферы и метаданные) начинают заметно расти — это ещё один аргумент не размазывать кластер на тысячи мелких топиков без необходимости.

Если вы разворачиваете тестовый или небольшой продакшн-кластер, для старта на VPS с 8-16 ГБ RAM обычно достаточно, чтобы получить честное представление о поведении Kafka под вашей нагрузкой, прежде чем закладывать бюджет на выделенный сервер.

Настройка ОС и JVM под Kafka

Помимо heap, есть несколько настроек уровня Linux, которые напрямую влияют на то, как эффективно используется оставшаяся RAM.

Swappiness — Kafka крайне не любит, когда её процесс уходит в своп: это моментально превращается в задержки записи и таймауты на стороне продюсеров. Снижаем склонность ядра свопить (подробнее о логике свопа на VPS — в статье про правильный размер swap):

sudo sysctl -w vm.swappiness=1
echo "vm.swappiness=1" | sudo tee -a /etc/sysctl.conf

Dirty pages — Kafka активно пишет на диск, и стандартные настройки vm.dirty_ratio могут привести к резким «залпам» записи, когда ядро внезапно сбрасывает накопленные грязные страницы на диск. Для серверов с Kafka стоит снизить пороги, чтобы запись шла более равномерно:

sudo sysctl -w vm.dirty_background_ratio=5
sudo sysctl -w vm.dirty_ratio=60

Лимиты файловых дескрипторов — при большом числе партиций и соединений от клиентов стандартный лимит 1024 кончится быстро:

# /etc/security/limits.conf
kafka soft nofile 100000
kafka hard nofile 100000

Размер сегментов лога — влияет на то, как часто пересоздаются индексы и, косвенно, на давление на page cache. В server.properties:

log.segment.bytes=1073741824
log.retention.hours=168
log.retention.check.interval.ms=300000
num.io.threads=8
num.network.threads=3

Число IO- и network-тредов стоит соотносить с числом ядер CPU сервера, а не задавать наугад — избыточные треды только увеличивают contention без пользы для throughput.

Если планируете держать Kafka в Docker или docker-compose для разработки, помните, что контейнер по умолчанию не ограничивает потребление page cache — это остаётся на уровне хоста, и «RAM контейнера» в docker stats не покажет вам реальной картины использования памяти под page cache.

Частые вопросы