У нас есть 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
- Кто-нибудь знает, почему это может происходить? (это по замыслу?)
- Можно ли ограничить использование ЦП для репликатных потоков?
- Является ли единственно возможным решением увеличить нагрузку на ЦП? Я проверил экземпляр с 8vcpu, однако потоки считывателя все еще хотели использовать весь процессор.
- Может ли установка большего количества num.io.threads и num.network.threads фактически увеличить загрузку процессора?