Почему виртуальная машина Linux в vSphere ESXi 5.5 показывает резко увеличенную задержку ввода-вывода диска?

Я в тупике и надеюсь, что кто-то еще распознает симптомы этой проблемы.

Аппаратное обеспечение: новый Dell T110 II, двухъядерный Pentium G850 2,9 ГГц, встроенный контроллер SATA, один новый жесткий диск на 500 ГБ 7200 об / мин с кабелем внутри коробки, другие диски внутри, но еще не смонтированы. Никакого RAID. Программное обеспечение: свежая виртуальная машина CentOS 6.5 под VMware ESXi 5.5.0 (сборка 1746018) + клиент vSphere. Выделено 2,5 ГБ ОЗУ. Диск - это то, как CentOS предложила его настроить, а именно как том внутри группы томов LVM, за исключением того, что я пропустил отдельный / home и просто использовал / и / boot. CentOS исправлен, ESXi исправлен, на виртуальной машине установлены новейшие инструменты VMware. В системе нет пользователей, не запущены службы, нет файлов на диске, кроме установки ОС. Я взаимодействую с виртуальной машиной через виртуальную консоль виртуальной машины в vSphere Client.

Прежде чем идти дальше, я хотел проверить, что я настроил более или менее разумно. Я выполнил следующую команду от имени пользователя root в оболочке виртуальной машины:

for i in 1 2 3 4 5 6 7 8 9 10; do
  dd if=/dev/zero of=/test.img bs=8k count=256k conv=fdatasync
done

То есть, просто повторите команду dd 10 раз, что приведет к печати скорости передачи каждый раз. Результаты вызывают тревогу. Все начинается хорошо:

262144+0 records in
262144+0 records out
2147483648 bytes (2.1 GB) copied, 20.451 s, 105 MB/s
262144+0 records in
262144+0 records out
2147483648 bytes (2.1 GB) copied, 20.4202 s, 105 MB/s
...

но после 7-8 из них он печатает

262144+0 records in
262144+0 records out
2147483648 bytes (2.1 GG) copied, 82.9779 s, 25.9 MB/s
262144+0 records in
262144+0 records out
2147483648 bytes (2.1 GB) copied, 84.0396 s, 25.6 MB/s
262144+0 records in
262144+0 records out
2147483648 bytes (2.1 GB) copied, 103.42 s, 20.8 MB/s

Если я жду значительное время, скажем, 30-45 минут, и запускаю его снова, он снова возвращается к 105 МБ / с, а после нескольких раундов (иногда несколько, иногда 10+) он падает до ~ 20- Опять 25 МБ / с.

На основе предварительного поиска возможных причин, в частности VMware KB 2011861, Я изменил планировщик ввода-вывода Linux на "noop"вместо значения по умолчанию. cat /sys/block/sda/queue/scheduler показывает, что это действует. Однако я не вижу, чтобы это повлияло на это поведение.

График задержки диска в интерфейсе vSphere показывает периоды высокой задержки диска, достигающие 1,2–1,5 секунды в то время, когда dd сообщает о низкой пропускной способности. (И да, пока это происходит, все перестает отвечать.)

Что может быть причиной этого?

Мне удобно, что это не из-за отказа диска, потому что я также настроил два других диска как дополнительный том в той же системе. Сначала я подумал, что сделал что-то не так с этим томом, но после того, как закомментировал том из / etc / fstab, перезагрузился и попробовал тесты на /, как показано выше, стало ясно, что проблема в другом месте. Вероятно, это проблема конфигурации ESXi, но я не очень разбираюсь в ESXi. Вероятно, это что-то глупое, но после нескольких часов попыток понять это в течение нескольких дней я не могу найти проблему, поэтому я надеюсь, что кто-то сможет указать мне правильное направление.

(PS: да, я знаю, что эта комбинация оборудования не выиграет никаких наград за скорость в качестве сервера, и у меня есть причины использовать это оборудование низкого уровня и запускать одну виртуальную машину, но я думаю, что это не относится к этому вопросу [если только на самом деле это проблема оборудования].

ПРИЛОЖЕНИЕ №1: Чтение других ответов, например вот этот заставил меня попробовать добавить oflag=direct к dd. Однако это не имеет значения в структуре результатов: сначала цифры выше для многих раундов, затем они падают до 20-25 МБ / с. (Первоначальные абсолютные числа находятся в диапазоне 50 МБ / с.)

ПРИЛОЖЕНИЕ №2: Добавление sync ; echo 3 > /proc/sys/vm/drop_caches в цикл вообще не имеет значения.

ПРИЛОЖЕНИЕ №3: Чтобы извлечь дополнительные переменные, я запускаю dd таким образом, что размер создаваемого файла превышает объем оперативной памяти в системе. Новая команда dd if=/dev/zero of=/test.img bs=16k count=256k conv=fdatasync oflag=direct. Начальные значения пропускной способности для этой версии команды составляют ~ 50 МБ / с. Когда дела идут плохо, они падают до 20-25 МБ / с.

ПРИЛОЖЕНИЕ №4: Вот результат iostat -d -m -x 1 работает в другом окне терминала, когда производительность "хорошая", а затем снова, когда она "плохая". (Пока это происходит, я бегу dd if=/dev/zero of=/test.img bs=16k count=256k conv=fdatasync oflag=direct.) Во-первых, когда все «хорошо», это показывает следующее:

Когда дела идут "плохо", iostat -d -m -x 1 показывает это:

ПРИЛОЖЕНИЕ №5: По предложению @ewwhite я попытался использовать tuned с разными профилями и тоже пробовал iozone. В этом дополнении я сообщаю о результатах экспериментов с разными tuned профили оказали какое-либо влияние на dd поведение, описанное выше. Я пробовал сменить профиль на virtual-guest, latency-performance и throughput-performance, сохраняя все остальное, перезагружаясь после каждого изменения, а затем каждый раз выполняя dd if=/dev/zero of=/test.img bs=16k count=256k conv=fdatasync oflag=direct. Это не повлияло на поведение: как и раньше, все начинается хорошо, и многие повторные запуски dd показывают такую ​​же производительность, но потом в какой-то момент после 10-40 запусков производительность падает вдвое. Далее я использовал iozone. Эти результаты более обширны, поэтому я помещаю их в приложение №6 ниже.

ПРИЛОЖЕНИЕ №6: По предложению @ewwhite я установил и использовал iozone для проверки производительности. Я запускал это под разными tuned профилей и использовал очень большой параметр максимального размера файла (4G) для iozone. (На виртуальной машине выделено 2,5 ГБ ОЗУ, а на хосте всего 4 ГБ.) Эти тестовые прогоны заняли довольно много времени. FWIW, файлы необработанных данных доступны по ссылкам ниже. Во всех случаях для создания файлов использовалась команда iozone -g 4G -Rab filename.

• Профиль latency-performance:
  • необработанные результаты: http://cl.ly/0o043W442W2r
  • Электронная таблица Excel (версия OSX) с графиками: http://cl.ly/2M3r0U2z3b22
• Профиль enterprise-storage:
  • необработанные результаты: http://cl.ly/333U002p2R1n
  • Электронная таблица Excel (версия OSX) с графиками: http://cl.ly/3j0T2B1l0P46

Ниже приводится мое резюме.

В некоторых случаях я перезагружался после предыдущего запуска, в других случаях я не делал этого и просто запускал iozone снова после изменения профиля с помощью tuned. Это не оказало очевидного влияния на общие результаты.

Разные tuned профили не казались (на мой, по общему признанию, неопытными глазами) влияющими на широкий о поведении сообщил iozone, хотя профили повлияли на некоторые детали. Во-первых, неудивительно, что некоторые профили изменили порог, при котором производительность упала для записи очень больших файлов: iozone результатов, вы можете увидеть отвесный обрыв в 0,5 ГБ для профиля latency-performance но это падение проявляется на 1 Гб под профиль enterprise-storage. Во-вторых, хотя все профили демонстрируют странную изменчивость для комбинаций небольших размеров файлов и небольших размеров записи, точная картина изменчивости различалась между профилями. Другими словами, на графиках, показанных ниже, скалистый узор с левой стороны существует для всех профилей, но расположение ямок и их глубина различны для разных профилей. (Однако я не повторял прогоны одних и тех же профилей, чтобы увидеть, заметно ли меняется картина изменчивости между прогонами iozone под тем же профилем, так что это возможно что то, что выглядит как различия между профилями, на самом деле просто случайная изменчивость.)

Ниже приведены поверхностные графики различных iozone тесты для tuned профиль latency-performance. Описание тестов скопировано из документации для iozone.

Прочитать тест: Этот тест измеряет производительность чтения существующего файла.

Написать тест: Этот тест измеряет производительность записи нового файла.

Случайное чтение: Этот тест измеряет производительность чтения файла при доступе к случайным местам внутри файла.

Случайная запись: Этот тест измеряет производительность записи файла при доступе к случайным местам внутри файла.

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

Напишите: Этот тест измеряет производительность записи файла с помощью библиотечной функции fwrite (). Это библиотечная процедура, которая выполняет операции буферизованной записи. Буфер находится в адресном пространстве пользователя. Если приложение должно было записывать передачи очень небольшого размера, то функция буферизованного и заблокированного ввода-вывода fwrite () может повысить производительность приложения за счет уменьшения количества фактических вызовов операционной системы и увеличения размера передачи, когда операционная система звонки сделаны. Этот тест записывает новый файл, поэтому в измерение снова включены накладные расходы на метаданные.

Наконец, за то время, когда iozone делал свое дело, я также исследовал графики производительности виртуальной машины в клиентском интерфейсе vSphere 5. Я переключался между графиками виртуального диска и хранилища данных в реальном времени. Доступные параметры построения графика для хранилища данных были больше, чем для виртуального диска, а графики производительности хранилища данных, казалось, отражали то, что делали графики диска и виртуального диска, поэтому здесь я прилагаю только моментальный снимок графика хранилища данных, сделанный после iozone закончено (под tuned профиль latency-performance). Цвета трудночитаемы, но, пожалуй, наиболее примечательны резкие вертикальные всплески читать задержка (например, в 4:25, затем снова немного через 4:30 и снова между 4: 50-4: 55). Примечание: график не читается, когда он встроен сюда, поэтому я также загрузил его в http://cl.ly/image/0w2m1z2T1z2b

Признаюсь, я не знаю, что со всем этим делать. Я особенно не понимаю странных профилей выбоин в областях малого размера записи / небольшого размера файла iozone сюжеты.