Почему виртуальная машина 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 Client. 2,5 ГБ ОЗУ выделено. Диск - это то, как CentOS предложил настроить его, а именно как том внутри группы томов LVM, за исключением того, что я пропустил отдельную / home и просто установил / и / boot. Исправлено CentOS, исправлено ESXi, на VM установлены последние инструменты 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 МБ / с, когда дела идут на юг.

ADDENDUM # 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 (). Это библиотечная процедура, которая выполняет буферизованные и заблокированные операции чтения. Буфер находится в адресном пространстве пользователя. Если бы приложение считывало передачи очень маленького размера, то функции буферизованного и заблокированного ввода-вывода функции fread () могут повысить производительность приложения за счет уменьшения количества фактических вызовов операционной системы и увеличения размера передач в операционной системе. звонки сделаны.

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

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

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

Можете ли вы дать точный номер сборки ESXi? Пожалуйста , попробуйте еще раз тесты с специально построенной производительностью диска инструментом анализа , как МСН или IOzone получить реальный базовый уровень. Использование ddне очень продуктивно для этого.

В общем, стандартный планировщик ввода / вывода в EL6 не так уж и хорош. Вы должны подумать о переходе к крайнему сроку или ноль лифтов ввода-вывода или, что еще лучше, об установке настроенного фреймворка .

Попробуйте: yum install tuned tuned-utilsи tuned-adm profile virtual-guestзатем проверьте снова.

Я столкнулся с той же проблемой и заметил очень низкую производительность диска в виртуальных машинах. Я использую ESXi 5.5 на Seagate ST33000650NS.

Следуя этой статье, я изменил Disk.DiskMaxIOSizeразмер блока моих дисков. В моем случае 4096.

Замечание VMware об этом очень приятно, так как вы можете просто протестировать его.

Примечание. Это изменение можно внести без перезагрузки хоста ESX / ESXi или без перевода хоста ESX / ESXi в режим обслуживания.

Я знаю, что этот вопрос очень старый, но Мхука вложил в свой пост столько энергии и информации, что мне пришлось ответить.

Правка № 1: После использования 4096 в течение дня я вернулся к старому значению 32767. Тестирование ввода-вывода и все еще кажется стабильным. Я предполагаю, что запуск ESXi на обычном жестком диске с Disk.DiskMaxIOSizeустановленным значением 32767будет работать нормально в течение нескольких часов или, возможно, дней. Возможно, требуется некоторая нагрузка от виртуальных машин, чтобы постепенно снизить производительность.

Я пытаюсь расследовать и вернуться позже ...

Постарайтесь выяснить, где в вашем стеке хранения возникают большие задержки:

Источник: Устранение неполадок производительности системы хранения в vSphere. Часть 1. Основы