Вам необходимо предоставить более подробную информацию о вашем сценарии использования, например, средний размер сообщений и т. Д., Но в любом случае вот мои 2 цента:
Документация Confluent может пролить некоторый свет:
Процессоры
Большинство развертываний Kafka, как правило, довольно незначительны в отношении требований к процессору.Таким образом, точная настройка процессора имеет меньшее значение, чем другие ресурсы.Обратите внимание, что если SSL включен, требования к процессору могут быть значительно выше (точные детали зависят от типа процессора и реализации JVM).
Вы должны выбрать современный процессор с несколькими ядрами.Обычные кластеры используют 24 ядра.
Если вам нужно выбрать между более быстрыми ЦП или несколькими ядрами, выберите больше ядер.Дополнительный параллелизм, предлагаемый несколькими ядрами, намного перевесит немного более высокую тактовую частоту.
Как рассчитать пропускную способность
Это также может быть полезновычислить пропускную способность.Например, если у вас 800 сообщений в секунду, по 500 байт каждый, тогда ваша пропускная способность составляет 800*500/(1024*1024) = ~0.4MB/s.Теперь, если ваша тема разбита на разделы, и у вас есть 3 брокера, которые работают с 3 репликами, это приведет к 0.4/3*3=0.4MB/s на брокера.
Более подробную информацию о вашей архитектуре можно найти в официальном документе Confluent Apache Kafka и Confluent Reference Architecture .Вот раздел использования памяти:
ZooKeeper использует кучу JVM, и обычно достаточно 4 ГБ ОЗУ.Слишком маленькая куча приведет к высокой загрузке ЦП из-за постоянной сборки мусора, а слишком большая куча может привести к длительным паузах сбора мусора и потере подключения в кластере ZooKeeper.
Брокеры Kafka использованиеи кучи JVM и кеш страницы ОС.Куча JVM используется для репликации разделов между брокерами и для сжатия журналов.Для репликации требуется 1 МБ (по умолчанию replica.max.fetch.size) для каждого раздела посредника.В Apache Kafka 0.10.1 (Confluent Platform 3.1) мы добавили новую конфигурацию (replica.fetch.response.max.bytes), которая ограничивает общий объем оперативной памяти, используемой для репликации, до 10 МБ, чтобы избежать проблем с памятью и сборкой мусора при количестверазделов у брокера высокий.Для сжатия журнала вычисление требуемой памяти является более сложным, и мы рекомендуем обратиться к документации Kafka, если вы используете эту функцию.Для развертываний малого и среднего размера обычно достаточно размера кучи 4 ГБ.Кроме того, настоятельно рекомендуется, чтобы потребители всегда читали из памяти, то есть из данных, которые были записаны в Kafka и все еще хранятся в кеше страницы ОС.Требуемый объем памяти зависит от скорости записи этих данных и того, насколько далеко от вас ожидают потребители.Если вы пишете 20 ГБ в час на каждого брокера и позволяете брокерам отставать на 3 часа в обычном сценарии, вам нужно зарезервировать 60 ГБ для кэша страниц ОС.В тех случаях, когда потребители вынуждены читать с диска, производительность значительно снижается
Kafka Connect сама не использует много памяти, но некоторые разъемы для эффективности буферизуют данные.Если вы используете несколько коннекторов, использующих буферизацию, вы захотите увеличить размер кучи JVM до 1 ГБ или выше.
Потребители используют по крайней мере 2 МБ на пользователя и до 64 МБ в случае большихответы от брокеров (типично для бурного трафика). Производители будут иметь буфер по 64 МБ каждый.Начните с выделения 1 ГБ ОЗУ и добавьте 64 МБ для каждого производителя и 16 МБ для каждого планируемого потребителя.
Существует множество различных факторов, которые необходимо учитывать при настройке конфигурации вашей архитектуры.Я бы предложил просмотреть вышеупомянутую документацию, проконтролировать существующий кластер и ресурсы и, наконец, настроить их соответствующим образом.