Início / computer / Perguntas / 1819721
Accepted
King David
Asked: 2023-12-07 16:53:50 +0800 CST

o utilitário de disco é muito alto + quais etapas proativas podemos tomar para minimizá-lo

  • 772

Nosso cluster Kafka inclui 12 máquinas VM RHEL 7.6.

detalhes das especificações da máquina:

  1. CPU(s):14

  2. O disco Kafka é um disco VMDK. (disco sdb)

  3. RAM 48G

Quando o cluster Kafka está trabalhando duro (quando injeta dados em discos Kafka e leitura intensiva do disco), podemos ver no sarrelatório que a utilização dos discos VMDK é muito alta, quase 100% E o iowait da CPU também atingiu cerca de ~ 40%

quando não há gravação/leitura no disco Kafka ( sdb ), a utilização do disco fica em torno de 1-3% e tudo bem

aqui está um exemplo da primeira máquina Kafka, este exemplo é semelhante a outras máquinas no cluster

sar -p -d 5 15 | grep sdb

                  DEV       tps  rd_sec/s  wr_sec/s  avgrq-sz  avgqu-sz     await     svctm     %util
11:45:44 AM       sdb    667.60  50776.00 114753.80    247.95    145.06    210.63      1.50    100.00
11:45:49 AM       sdb    484.60  40296.00 142994.40    378.23    145.80    343.71      2.06    100.00
11:45:54 AM       sdb    355.40  12758.40 170463.40    515.54    285.86    724.10      2.81    100.00
11:45:59 AM       sdb    477.40  26828.80 142663.20    355.03    219.43    419.59      2.10    100.02
11:46:04 AM       sdb    526.40  30964.80 116515.60    280.17    219.52    495.00      1.90     99.98
11:46:09 AM       sdb    387.20  26939.20 142214.60    436.86    192.80    405.45      2.58    100.00
11:46:14 AM       sdb    403.00  18192.00 130434.80    368.80    286.71    681.59      2.48    100.00
11:46:19 AM       sdb    608.00  50153.60  96733.40    241.59    163.63    336.13      1.65    100.04
11:46:24 AM       sdb    188.40   8406.40  87474.80    508.92    196.47    657.40      5.31     99.98
11:46:29 AM       sdb    749.40  54948.80 167797.40    297.23    207.97    388.29      1.33    100.02
11:46:34 AM       sdb    419.20  57480.00 110545.60    400.82    143.63    305.59      2.39    100.00
11:46:39 AM       sdb    549.60  34772.80 149058.60    334.48    144.77    286.05      1.82     99.98
11:46:44 AM       sdb    468.26  40547.70 130706.99    365.72    146.39    318.22      2.13     99.90
11:46:49 AM       sdb    412.40  21929.60 186562.40    505.56    144.34    363.23      2.42     99.98
11:46:54 AM       sdb    574.60  36830.40 177053.60    372.23    149.73    245.82      1.74    100.00
Average:          sdb    484.76  34122.49 137730.57    354.51    186.13    385.28      2.06     99.99

E da perspectiva do relatório da CPU

sar  5 15

12:12:45 PM     CPU     %user     %nice   %system   %iowait    %steal     %idle
12:12:50 PM     all      8.21      0.00      9.87     10.26      0.00     71.67
12:12:55 PM     all      6.50      0.00      7.65      7.78      0.00     78.07
12:13:00 PM     all      7.90      0.00      9.40     10.53      0.00     72.16
12:13:05 PM     all     11.83      0.00     13.24     26.62      0.00     48.31
12:13:10 PM     all     11.66      0.00     12.84     19.00      0.00     56.50
12:13:15 PM     all      8.23      0.00      9.98      9.52      0.00     72.26
12:13:20 PM     all      7.74      0.00      8.87     10.95      0.00     72.44
12:13:25 PM     all      6.70      0.00      7.92      9.10      0.00     76.27
12:13:30 PM     all      7.15      0.00      8.32      8.05      0.00     76.49
12:13:35 PM     all     12.84      0.00     14.12     15.17      0.00     57.87
12:13:40 PM     all      7.91      0.00      9.04     35.44      0.00     47.62
12:13:45 PM     all      9.20      0.00     10.63     11.09      0.00     69.09
12:13:50 PM     all      9.57      0.00     10.98      8.15      0.00     71.30
12:13:55 PM     all     10.85      0.00     12.61      7.39      0.00     69.15
12:14:00 PM     all     10.88      0.00     12.44      9.54      0.00     67.15
Average:        all      9.14      0.00     10.52     13.23      0.00     67.11

do ponto de vista da memória RAM, não vejo problema, mas não tenho certeza de qual é o gargalo aqui e por que o utilitário de disco é muito alto

uma direção é aumentar a CPU de 14 núcleos para 48 núcleos, mas talvez o fato de obtermos valores altos de CPU %IOWAIT seja resultado de alta utilização do disco.

o tráfego proveniente dos produtores que está enviando para um cluster é persistido no disco. Portanto, a taxa de transferência subjacente do volume de armazenamento pode se tornar o gargalo do cluster.

Neste caso, faz sentido adicionar outras máquinas kafka ao cluster. ou talvez adicione alguns discos adicionais a cada máquina Kafka (como discos JBOD) para equilibrar a escrita/leitura intensiva.

agradeço receber qualquer sugestão que possa melhorar a utilização do disco Kafka

Detalhes do disco VMware (do cliente vSphere nas configurações de edição)

SATA controller 0     AHCI
VM storage policy     VxRail RAID5 Default 
Sharing               No SHaring
Disk File             VxRail-VSAN_Datastore 
Disk mode             Dependent 
Virtual Device Node   SCSI controller 0

os resultados do vmstat quando o cluster é carregado

vmstat 1 20
procs -----------memory---------- ---swap-- -----io---- -system-- ------cpu-----
 r  b   swpd   free   buff  cache   si   so    bi    bo   in   cs us sy id wa st
18 13   1024 379388      0 54566428    0    0  1888  5137    0    0  4  4 47 45  0
 0 19   1024 328408      0 54606020    0    0     0  6853 11700 7288  2  2 12 85  0
 0 15   1024 330204      0 54618088    0    0 12004 56708 16881 8254  3  3 16 78  0
 0 13   1024 345284      0 54601404    0    0  3492 104672 5135 3067  0  1 43 56  0
 0 17   1024 324864      0 54620400    0    0   248 66547 16615 8477  2  4 31 63  0
 0 18   1024 367468      0 54577640    0    0     0 84404 13020 6995  2  3  6 90  0
 0 21   1024 327480      0 54611036    0    0  8536 125999 29355 37872  4  7 18 71  0
 0 19   1024 362180      0 54581692    0    0  7692 66464 4167 2717  0  0 33 66  0
 0 19   1024 419264      0 54523248    0    0     0 46409 1799 1825  0  0 27 73  0
 0 14   1024 356708      0 54586004    0    0     4 78656 17169 9841  3  4 23 70  0
 0 14   1024 407352      0 54539976    0    0     0 136732 4554 4673  0  1 20 79  0
 0 12   1024 389672      0 54557752    0    0  5832 59124 9619 5537  1  2 25 71  0
 0 14   1024 431880      0 54513164    0    0   948 94160 14272 7229  2  3 30 65  0
 0 15   1024 440300      0 54502784    0    0  9140 136328 10626 5296  1  1 38 60  0
 0 13   1024 441708      0 54501948    0    0  7652 62132 4663 2756  0  1 33 66  0
 0 14   1024 449396      0 54492664    0    0   416 64790 1955 1757  0  0 33 66  0
 0 17   1024 424028      0 54520452    0    0   484 114372 16674 7946  2  3 25 70  0
 0 18   1024 441912      0 54499924    0    0     0 82027 2752 2100  0  0 22 78  0
 0 14   1024 473604      0 54468560    0    0     0 60188 2021 2212  0  0 22 78  0
 1 14   1024 420224      0 54525684    0    0  8576 128225 21739 9684  9  4 27 60  0
hard-drive

1 respostas

  1. Best Answer

    Pelo que vejo em vmstat(quando a máquina está carregada), você tem uma grande quantidade de operações de E/S, uma grande quantidade de interrupções (geralmente para operações de E/S novamente) e uma perda significativa de tempo de processo no estado de espera (que geralmente espera por recursos, com operações de E/S de alta probabilidade).

    Então, minha opinião é que você deve adicionar discos e fazer com que o Kafka distribua a carga por todos os discos. Como você está em um ambiente virtualizado, você deve adicionar discos de diferentes datastores. Será muito melhor se os datastores tiverem HDDs próprios (não compartilhados), ainda melhor se esses HDDs do datastore usarem controladores (SATA/SAS) diferentes (ou interfaces FC/Ethernet se você usar SAN/NAS) do armazenamento de dados usado atualmente.

    Resumindo – adicione mais armazenamento, acessível através de diferentes canais de comunicação.

    • 1

relate perguntas