☰

ubuntu kvm disk io desaceleração depois de algum tempo

tag-icon • tag-icon linux virtualization kvm-virtualization io
ubuntu kvm disk io desaceleração depois de algum tempo

Sistema hospedeiro:

Ubuntu Server x64 12.04 
mdadm raid 1 (/dev/sda /dev/sdb)
no lvm
dd bs=1M count=256 if=/dev/zero of=filename conv=fdatasync
avarage ~ 40 MB/s

NCQ on disks is disabled
WriteCache is disables

Sistema convidado:

Ubuntu server i386 12.04
with lvm2 /10Gb /200Gb /200Gb disks all on lv-root (LV)
  --- Physical volume ---
  PV Name               /dev/vda5
  VG Name               root-vg
  PV Size               9.76 GiB / not usable 2.00 MiB
  Allocatable           yes (but full)
  PE Size               4.00 MiB
  Total PE              2498
  Free PE               0
  Allocated PE          2498

  --- Physical volume ---
  PV Name               /dev/vdb
  VG Name               root-vg
  PV Size               195.31 GiB / not usable 4.00 MiB
  Allocatable           yes (but full)
  PE Size               4.00 MiB
  Total PE              49999
  Free PE               0
  Allocated PE          49999

  --- Physical volume ---
  PV Name               /dev/vdc
  VG Name               root-vg
  PV Size               195.31 GiB / not usable 4.00 MiB
  Allocatable           yes (but full)
  PE Size               4.00 MiB
  Total PE              49999
  Free PE               0
  Allocated PE          49999

 dd bs=1M count=256 if=/dev/zero of=filename conv=fdatasync
    avarage ~ 30 MB/s
all disks in guest are RAWformat /VirtioBUS / No cache / IOmode=native

depois de algum tempo, a velocidade de gravação cai para 1 MB/s, mas o sistema host não está carregado e o teste dd mostra os mesmos 30-40 MB/s, uso da CPU de 10%. A reinicialização do convidado ajuda por um tempo. Não há erros/falhas/sem reconstrução ou ressincronização do mdadm.

Não tenho ideia de onde está o problema ou onde cavar.

Parece que isso ajuda no convidado: sync && echo 3 > /proc/sys/vm/drop_caches

Problema semelhanteEm um sistema com 64 GB de mem, o buffer do Linux é executado completamente enquanto copia com dd para dev null e io para até drop_caches manuais

Responder1

Eu acho que o que acontece é que o desempenho inicial de 30-40 MB/s é devido ao cache do kernel do Linux (e qualquer outro cache que possa estar acontecendo no nível do hardware). Uma vez que o cache tenha sido "esgotado", o acesso real ao disco começa a entrar em ação e o desempenho cai.

Além disso paraddpara ter melhor desempenho defina obesteira=argumento para um tamanho razoavelmente grande. Pessoalmente, gosto de configurá-lo para cerca de 1/3-1/2 da memória RAM disponível. Sua configuração de 1M está abaixo do ideal e é a principal razão para os baixos números de desempenho. Mas mesmo com ótimobesteira=configuração, você veria uma queda de desempenho em algum momento, conforme explicado acima.

informação relacionada