Высокая загрузка ЦП для брокеров Kafka

Question

Мы используем Apache версию Kafka 2.2 с 5 брокерами. Мы получаем 50 миллионов событий в день, но мы достигли высокого уровня использования ЦП kafka. Мы используем настройки производителя / потребителя / брокера по умолчанию.

У меня есть вопросы по производительности;

У нас есть разные приложения kafka-streams, которые выполняют агрегирование или операции соединения для передачи расширенных сообщений. Все наши приложения kafka-streams состоят из следующих настроек:

• точно один раз: true
• min-in-syn c реплик: 3
• репликация фактор: 3
• topi c раздел: ~ 50- ~ 100 (отличается по топологии)

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

Однако, помимо оптимизации топологии, можем ли мы что-то сделать с настройками по умолчанию?

Помимо kafka- streams мы используем производитель / потребитель spring-kafka. Но, как я уже сказал, мы используем настройки по умолчанию. Например, мы создаем события одно за другим на стороне производителя.

Наша пропускная способность недостаточно высока, и у нас много ЦП. Если мы закроем некоторые из наших приложений kafka-streams, нагрузка на брокеров уменьшится. Итак, мой вопрос:

Прилагает ли синхронизированные c -репликации с истинным значением exatly-once и коэффициентом репликации 3 слишком большую нагрузку на брокеров? Я не хочу терять или дедуплицировать свои сообщения в среде prod, поэтому мои потоковые приложения должны состоять из exaclty-once true, но приложения Spring хорошо работают без kafka-streams.

Я хочу уменьшить общую загрузку процессора использование брокера в нашей системе.

Если я использую пакетный производитель на стороне производителя, уменьшите min-in-syn c реплик для моих отказоустойчивых рабочих, уменьшится ли использование моего процессора?

Я не могу придумать дополнительный способ. Любая идея может помочь мне, почему загрузка ЦП моих брокеров очень высока, например, около% 80-90 в дневное время.

Что может вызвать высокую загрузку ЦП на брокерах?

Answer 1

Вам необходимо предоставить более подробную информацию о вашей топологии / кластере. Например;

• вы видите скачок ЦП у всех ваших брокеров или у некоторых? Это может легко привести вас к основной проблеме.
• включено ли шифрование? Основной причиной высокой загрузки ЦП обычно является шифрование. Может быть, некоторые из ваших приложений используют зашифрованные каналы, а некоторые нет?.
• Изучите топологии ваших потоковых приложений. Неправильное использование ключа может привести к чрезмерному перераспределению, которое использует темы переразбивки в Kafka и может привести к высокой загрузке ЦП как на стороне брокера, так и на стороне вашего приложения. вакансии в пределах max.poll.interval.ms? если это так, они будут часто перебалансироваться, и у брокеров действительно есть работа по перебалансировке, хотя и небольшая, которая может значительно увеличиться, если у вас много групп, которые постоянно перебалансируют.
• Если вы не используете синхронный send с производителями (что значительно влияет на пропускную способность), они группируются и отправляются вместе. но вы можете попробовать поиграть с конфигурацией linger.ms. Это может повлиять на пропускную способность вашего производителя.

Я не думаю, что конфигурации replication.factor и min.insyn c .replicas играют важную роль, но я не могу сказать что-либо наверняка, не зная всех переменные.

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