Кафка производитель плохая производительность - PullRequest
0 голосов
/ 13 октября 2018

У меня проблема с производителем кафки.На самом деле я использую Spring Kafka, и отправка сообщений через KafkaTemplate следующим образом:

DefaultKafkaProducerFactory<K, V> defaultKafkaProducerFactory = new DefaultKafkaProducerFactory<>(producerParams);
KafkaTemplate kafkaTemplate = new KafkaTemplate<>(defaultKafkaProducerFactory);
RecordMetadata recordMetadata = kafkaTemplate.send(record).get().getRecordMetadata();

Проблема в том, что иногда отправка сообщения занимает 4-20 сек.Там много сообщений, на отправку которых уходит 100 мс.Поэтому у меня есть несколько вопросов:

  1. Есть ли какая-либо связь между размером сообщения и пропускной способностью, какова связь?

  2. Что я должен проверить в первую очередь, может быть, я не выполнил настройку в любом направлении?

Ответы [ 2 ]

0 голосов
/ 03 апреля 2019

Если у вас огромное количество данных, тогда производитель Kafka требует Performance Tunning.В этом случае лучше настроить batch.size , linger.ms & buffer.memory .Обычно в kafka конфигурация batch.size по умолчанию составляет 16 Кбайт.Чтобы повысить производительность, просто увеличьте размер batch.size.

props.put(ProducerConfig.BATCH_SIZE_CONFIG, 16_384 * 4);
    // Send with little bit buffering
    props.put(ProducerConfig.LINGER_MS_CONFIG, 200);    
  //Use Snappy compression for batch compression.
    props.put(ProducerConfig.COMPRESSION_TYPE_CONFIG, "snappy");

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

Kafka Performance

0 голосов
/ 14 октября 2018

Хорошо, на самом деле проблема была в машинах, процессор был слишком высок, в диспетчере Cloudera были журналы

Обнаружена пауза в JVM или хост-машине (например, остановка мира GC или JVM не запланированы): приостановлено приблизительно 4332 мсек: ГХ не обнаружены.

Обнаружена пауза в JVM или хост-машине (например, остановка мира GC или JVM не запланирована): приостановлена ​​приблизительно 10827 мсек: коллекция GC "ConcurrentMarkSweep" имела коллекцию (ы)): count = 1 раз = 11107мс

Когда я запускаю то же самое на машине с 8 ядрами - проблема исчезла.еще одна вещь, которая была рекомендована, это увеличение размера кучи Java брокера

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...