Причиной периодически пониженной скорости чтения с диска является сама ОС?

Согласно странице руководства:

   -t     Perform timings of device reads  for  benchmark  and  comparison
          purposes.   For  meaningful  results,  this  operation should be
          repeated 2-3 times on an otherwise  inactive  system  (no  other
          active  processes)  with  at least a couple of megabytes of free
          memory.  

Итак, да, другие процессы могут повлиять на эти результаты.

Могу ли я провести еще какие-то области или тесты?

Один из способов узнать, используют ли эти диски другие процессы, - это загрузить sysstat с главной страницы Вот. Sysstat, конечно, уже доступен из репо, но, к сожалению, он не включает pidstat команда, которая необходима, чтобы проверить это.

Ядра EL5 переносят учетные записи диска в ядро, начиная с EL5.4, без предоставления интерфейса для его использования, но pidstat будет работать, как только вы это сделаете.

Затем запустите pidstat -d команда для генерации полезных показателей дискового ввода-вывода, в частности, что другие процессы делают с диском. Вы также можете использовать pidstat -d <interval> <count> чтобы получить более точную метрику конкуренции на используемом диске.

Может ли какое-либо повреждение виртуальной машины / ОС вызвать такое поведение?

Повреждение ОС маловероятно (я думаю, системные вызовы как-то облажались). hdparm не использует файловую систему для выполнения своих тестов, что устраняет любое замедление в этой области, включая проблемы с деградацией. Если вы используете LVM, существует риск того, что вы будете читать из фрагментированных экстентов. Однако ваши примеры этого не показывают.

Коррупция виртуальной машины, ну и всякая игра, я думаю, и это сводится к ряду факторов, которые я могу придумать, но, вероятно, будет включать больше:

• В каком формате образа находится диск.
• Как эти данные распределяются в базовом механизме хранения (это сам логический том с экстентами?)
• Если внутри контроллера диска происходит перестройка рейда или какое-либо другое обслуживание уровня блока. Т.е., если контроллер на самом деле является SAN, выполняющим некоторую форму ребалансировки рейда.
• Сбой диска в рейде, принудительный расчет четности.
• Считываются ли данные в реальности «быстрым» кешем, таким как FusionIO, кешем данных, присутствующим в SAN, или рейд-картами с резервным питанием от батареи.
• Распределяет ли как-то базовый носитель ваше хранилище.
• Конфликт диска со стороны гипервизора, из-за которого ваши запросы ввода-вывода дольше помещаются в очередь.
• Конфликт за диск со стороны SAN, из-за которого запросы ввода-вывода дольше помещаются в очередь (очень часто виртуальные машины находятся в общем хранилище).
• Тома с тонким предоставлением ресурсов представляют собой высокий риск фрагментации. То, как это повлияет на ваш тест, полностью зависит от того, сколько блоков вы выделите для экстента с тонкой подготовкой. Например, при тонком выделении LVM в Linux размер экстента по умолчанию равен 32 МБ, поэтому передача маркера 32 МБ на вашем диске может вызвать дополнительный поиск, который испортит ваши тайминги.

Помогло бы восстановление / замена виртуальной машины?

Я думаю, удача в горшке, лучше или хуже. См. Приведенные выше факторы окружающей среды, которые могут помочь / помешать.

В конце концов, если вы используете программное обеспечение для управления томами или программное обеспечение тонкого выделения ресурсов в любой точке потока данных, записываемых на носитель (на вашем хосте, на уровне вашей виртуальной машины, на уровне SAN / контроллера), вы можете иметь нет надежных ожиданий что последовательное чтение, которое вы выполняете, действительно является последовательным или что носитель, на который вы записываете, согласован (если это быстрый диск или данные были перемещены на медленный диск).

Виртуализация настолько мощна, потому что добавляет хосту уровень логической абстракции. Но из-за этого уровня абстракции выполнение на них надежного управления мощностью может быть потенциально ужасным.