Kafka Broker ReplicaFetcherThread использует 100% CPU - PullRequest
1 голос
/ 02 февраля 2020

У нас есть 6 брокеров, работающих на AWS EC2 (i3.large с 4vcpu), и каждому из них назначено около 1000 разделов. Если мы заменим посредника (с тем же идентификатором посредника) с нулевыми данными - и репликация начнется - независимо от того, сколько num.replica.fetchers мы установим (попробовали 1-5) - потоки средства извлечения всегда нагружают ЦП. В настоящее время мы находимся на Confluent 5.3.2 с открытым исходным кодом.

broker.rack=$(curl -s http://169.254.169.254/latest/meta-data/placement/availability-zone)
broker.id=$KB_BROKER_ID
listeners=PLAINTEXT://$KB_ENIIP:9092
advertised.listeners=PLAINTEXT://$KB_ENIIP:9092
auto.create.topics.enable=false
default.replication.factor=3
inter.broker.protocol.version=2.3
log.dirs=$KB_LOGDIRDATA
log.message.format.version=2.3
log.roll.hours=24
log.retention.hours=48
log.segment.bytes=100000000
min.insync.replicas=1
num.recovery.threads.per.data.dir=4
offsets.retention.minutes=10080
num.network.threads=16
num.io.threads=20
socket.send.buffer.bytes=-1
socket.receive.buffer.bytes=-1
group.initial.rebalance.delay.ms=10000
num.partitions=6
transaction.state.log.replication.factor=3
zookeeper.connection.timeout.ms=1000000
zookeeper.connect=$ZK_CONN
zookeeper.session.timeout.ms=10000
message.max.bytes=5242880
replica.fetch.max.bytes=5242880
replica.fetch.response.max.bytes=5242880
replica.socket.receive.buffer.bytes=5242880
num.replica.fetchers=2
confluent.support.metrics.enable=false




      PID USER      PR  NI    VIRT    RES    SHR S %CPU %MEM     TIME+ COMMAND
 6913 kafka     20   0   66.2g   5.3g  64128 R 87.5 17.7  13:11.24 ReplicaFetcherT
 6916 kafka     20   0   66.2g   5.3g  64128 R 81.2 17.7   8:34.31 ReplicaFetcherT
 6929 kafka     20   0   66.2g   5.3g  64128 R 81.2 17.7   8:55.83 ReplicaFetcherT
 6930 kafka     20   0   66.2g   5.3g  64128 R 68.8 17.7   8:04.13 ReplicaFetcherT
 6918 kafka     20   0   66.2g   5.3g  64128 S 12.5 17.7   0:41.58 ReplicaFetcherT
 6919 kafka     20   0   66.2g   5.3g  64128 S 12.5 17.7   3:13.76 ReplicaFetcherT
 6927 kafka     20   0   66.2g   5.3g  64128 S 12.5 17.7   5:05.56 ReplicaFetcherT
 6931 kafka     20   0   66.2g   5.3g  64128 R  6.2 17.7   7:30.61 ReplicaFetcherT
 6777 kafka     20   0   66.2g   5.3g  64128 S  0.0 17.7   0:00.00 java
 6807 kafka     20   0   66.2g   5.3g  64128 S  0.0 17.7   0:02.69 java
  1. Кто-нибудь знает, почему это может происходить? (это по замыслу?)
  2. Можно ли ограничить использование ЦП для репликатных потоков?
  3. Является ли единственно возможным решением увеличить нагрузку на ЦП? Я проверил экземпляр с 8vcpu, однако потоки считывателя все еще хотели использовать весь процессор.
  4. Может ли установка большего количества num.io.threads и num.network.threads фактически увеличить загрузку процессора?
Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...