Я в тупике, и я надеюсь, что кто-то еще узнает симптомы этой проблемы.
Аппаратное обеспечение: новый 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графиков.
iostatи он показал загрузку ~ 90% как до, так и после. Но я не эксперт в оценке этих вещей - возможно, где-то происходит насыщение. Я обновляю свой вопрос, чтобы показать iostatвывод в случае, если он полезен.
