Uso anormal da CPU durante as operações de gravação de disco

Question

Eu tenho um host decente dedicado do CentOS 6.5 (CentOS 6.5 / E3-1230 Quad Core de 3.2 GHz + HT / 16GB / Software Raid 1 SATA II / WD2503ABYX / ext4) com o kernel padrão do CentOS e" elevator = deadline "no grub.

Operações de gravação de E / S causam um grande aumento no uso da CPU. As leituras estão funcionando bem. Por exemplo,

dd if=/dev/zero of=test bs=1048576 count=2048

faz com que a utilização da CPU do host atinja acima de 3 ou 4. Sob operação normal, ela permanece abaixo de 0,40, mas quando há uma operação de E / S mais intensa, tudo fica paralisado.

mpstat 1 durante esses testes dd mostra io wait em 20-25%.

Aqui está o layout do disco:

Disk /dev/sda: 251.1 GB, 251059544064 bytes
255 heads, 63 sectors/track, 30522 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x000c6673

   Device Boot      Start         End      Blocks   Id  System
/dev/sda1   *           1          26      204800   fd  Linux raid autodetect
Partition 1 does not end on cylinder boundary.
/dev/sda2              26         548     4194304   fd  Linux raid autodetect
Partition 2 does not end on cylinder boundary.
/dev/sda3             548       30523   240775168   fd  Linux raid autodetect

Disk /dev/sdb: 251.1 GB, 251059544064 bytes
255 heads, 63 sectors/track, 30522 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x00095c99

   Device Boot      Start         End      Blocks   Id  System
/dev/sdb1   *           1          26      204800   fd  Linux raid autodetect
Partition 1 does not end on cylinder boundary.
/dev/sdb2              26         548     4194304   fd  Linux raid autodetect
Partition 2 does not end on cylinder boundary.
/dev/sdb3             548       30523   240775168   fd  Linux raid autodetect

Disk /dev/md2: 246.6 GB, 246552588288 bytes
2 heads, 4 sectors/track, 60193503 cylinders
Units = cylinders of 8 * 512 = 4096 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x00000000


Disk /dev/md1: 4293 MB, 4293910528 bytes
2 heads, 4 sectors/track, 1048318 cylinders
Units = cylinders of 8 * 512 = 4096 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x00000000


Disk /dev/mapper/vg_main-LogVol00: 246.5 GB, 246549577728 bytes
255 heads, 63 sectors/track, 29974 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x00000000


Disk /dev/md0: 209 MB, 209702912 bytes
2 heads, 4 sectors/track, 51197 cylinders
Units = cylinders of 8 * 512 = 4096 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x00000000

O problema (alto uso da CPU) começou a acontecer no final de dezembro do ano passado, o que me leva a acreditar que está relacionado a software (o sistema de arquivos do disco foi verificado pelo pessoal do DC).

Quais testes devo executar ao lado para tentar isolar o problema?

PS: Não estou procurando dicas de maximização de desempenho. O servidor está subutilizado. Eu só estou olhando para reduzir a carga da CPU durante gravações em disco.

UPDATE: pergunta reformulada para melhor descrever o problema.

UPDATE: ENCONTREI UMA SOLUÇÃO Eu finalmente descobri qual era o problema quando me deparei com este post .

root> modprobe vhost_net root> echo vhost_net > /etc/modules

Por algum motivo, as interfaces do virtio não estavam carregando o driver antes. Tudo está bem agora.

    

Answer 1

No CentOS, o dirty_ratio está definido para 20%.

O que isto significa é que escrever um arquivo fora

dd if=/dev/zero of=test bs=1048576 count=2048

Na verdade, grava os dados na memória como writeback (até 3.2GB) e não grava-os no disco.

É mais lento (mas não um benchmark de desempenho realista) na VM porque você provavelmente atribuiu uma atribuição de memória muito menor à própria VM (digamos 2G) e isso leva a dirty_writeback fornecendo apenas ~ 400MB de write-back antes isso forçará o conteúdo para o disco.

Se você executar esse comando, execute sync , você perceberá que a sincronização demora muito para retornar.

Você precisa executar o comando fazendo o seguinte, para ter uma ideia melhor da taxa de transferência real.

dd if=/dev/zero of=test oflag=sync bs=1048576 count=2048