Kafka производитель огромное использование памяти (утечка?) - PullRequest
0 голосов
/ 18 сентября 2018

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

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

**org.apache.kafka.common.network.Selector -**

occupies 352,519,104 (24.96%) bytes. The memory is accumulated in one instance of "byte[]" loaded by "<system class loader>".

**org.apache.kafka.common.network.KafkaChannel -**

occupies 352,527,424 (24.96%) bytes. The memory is accumulated in one instance of "byte[]" loaded by "<system class loader>"

Оба из них занимали около 352 МБ пространства.3 таких случая, поэтому они потребляли около 1,2 ГБ памяти.

Теперь об использовании производителей.В кластер Kafka отправляется не так много журналов.Это около 200 мсг / сек.Только один объект-производитель используется во всем приложении.Используется асинхронная функция отправки.

Что может быть причиной такого огромного использования памяти?Это какая-то утечка памяти в этой конкретной версии Kafka?

Вот конфигурация Kafka Producer, используемая в работе.

kafka.bootstrap.servers=x.x.x.x:9092,x.x.x.x:9092,x.x.x.x:9092
kafka.acks=0
kafka.key.serializer=org.apache.kafka.common.serialization.StringSerializer
kafka.value.serializer=org.apache.kafka.common.serialization.StringSerializer
kafka.max.block.ms=1000
kafka.request.timeout.ms=1000
kafka.max.in.flight.requests.per.connection=1
kafka.retries=0
kafka.compression.type=gzip
kafka.security.protocol=SSL
kafka.ssl.truststore.location=/data/kafka/kafka-server-truststore.jks
kafka.ssl.truststore.password=XXXXXX
kafka.linger.ms=300
logger.level=INFO

Вот раздел из журнала GC, показывающий распределение потоков сети Kafka

<allocation-stats totalBytes="3636833992" >
  <allocated-bytes non-tlh="3525405200" tlh="111428792" />
  <largest-consumer threadName="kafka-producer-network-thread | producer-1" threadId="0000000033A26700" bytes="3525287448" />
</allocation-stats>
<gc-op id="591417" type="scavenge" timems="21.255" contextid="591414" timestamp="2018-09-19T17:55:32.938">
  <scavenger-info tenureage="14" tenuremask="4000" tiltratio="89" />
  <memory-copied type="nursery" objects="61155" bytes="6304384" bytesdiscarded="3968416" />
  <memory-copied type="tenure" objects="1199" bytes="230312" bytesdiscarded="38656" />
  <finalization candidates="461" enqueued="316" />
  <ownableSynchronizers candidates="18" cleared="5" />
  <references type="soft" candidates="231" cleared="0" enqueued="0" dynamicThreshold="23" maxThreshold="32" />
  <references type="weak" candidates="20" cleared="2" enqueued="1" />
  <references type="phantom" candidates="2" cleared="0" enqueued="0" />
</gc-op>
<gc-end id="591418" type="scavenge" contextid="591414" durationms="21.715" usertimems="11.640" systemtimems="0.125" timestamp="2018-09-19T17:55:32.939" activeThreads="64">
  <mem-info id="591419" free="4226106664" total="6049234944" percent="69">
    <mem type="nursery" free="3855164752" total="4294967296" percent="89">
      <mem type="allocate" free="3855164752" total="3865444352" percent="99" />
      <mem type="survivor" free="0" total="429522944" percent="0" />
    </mem>
    <mem type="tenure" free="370941912" total="1754267648" percent="21">
      <mem type="soa" free="362646600" total="1740233728" percent="20" />
      <mem type="loa" free="8295312" total="14033920" percent="59" />
    </mem>
    <pending-finalizers system="315" default="1" reference="1" classloader="0" />
    <remembered-set count="4110" />
  </mem-info>
</gc-end>
<cycle-end id="591420" type="scavenge" contextid="591414" timestamp="2018-09-19T17:55:32.940" />
<allocation-satisfied id="591421" threadId="0000000033A26700" bytesRequested="352518920" />
<af-end id="591422" timestamp="2018-09-19T17:55:32.962" />
<exclusive-end id="591423" timestamp="2018-09-19T17:55:32.962" durationms="45.987" />

1 Ответ

0 голосов
/ 18 сентября 2018

Причин может быть много. Но если вам нужно оптимизировать, вы можете попробовать следующие вещи:

  1. replica.fetch.max.bytes - размер буфера каждого раздела. Количество разделов, умноженное на размерсамого большого сообщения не превышает доступной памяти.То же самое относится и к потребителям - fetch.message.max.bytes, max.partition.fetch.bytes -Максимальный объем данных на раздел, который сервер вернет.Проверить указание отсутствующих данных можно с помощью - replica.high.watermark.checkpoint.interval.ms, который настроит пропускную способность.

2. batch.size (не должен превышать доступную память) и linger.ms (устанавливает максимумвремя буферизации данных, если оно асинхронное)

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