Назад | Перейти на главную страницу

ubuntu kvm disk io замедление после некоторого времени

Хост-система:

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

Гостевая система:

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

через некоторое время скорость записи падает до 1 МБ / с, но хост-система не загружена, и тест dd показывает те же 30-40 МБ / с, загрузка процессора 10%. На время помогает гостевая перезагрузка. Нет ошибок / сбоев / нет mdadm rebuild или resync.

Понятия не имею, где проблема и где копать.


Похоже, это помогает гостю: sync && echo 3> / proc / sys / vm / drop_caches


Аналогичная проблема В системе с памятью 64 ГБ буфер Linux заполнен при копировании с помощью dd в dev null, а io останавливается до ручного drop_caches

Я думаю, что начальная производительность 30-40 МБ / с связана с кешированием ядра Linux (и любым другим кешированием, которое может происходить на аппаратном уровне). Как только это кэширование "израсходовано", начинается реальный доступ к диску, и производительность падает.

Кроме того, чтобы дд чтобы иметь лучшую производительность, установите bs = аргумент в пользу достаточно большого размера. Лично мне нравится устанавливать его примерно на 1 / 3-1 / 2 доступного плунжера. Ваша настройка 1M не является оптимальной и является основной причиной низких показателей производительности. Но даже при оптимальном bs = установки вы увидите падение производительности в какой-то момент, как описано выше.