Мы наблюдаем плохие результаты ввода-вывода при чтении файлов, которые мы хотели бы лучше понять. Мы можем использовать фио для записи 100 файлов с устойчивой совокупной пропускной способностью ~ 700 МБ / с. Когда мы переключаем тест на чтение вместо записи, совокупная пропускная способность составляет всего ~ 55 МБ / с. Падение, похоже, связано с количеством файлов, поскольку пропускная способность для чтения и записи сопоставима для одного файла, а затем пропорционально расходится по мере увеличения количества файлов.
Тестовый сервер имеет 24 ядра ЦП, 48 ГБ памяти и работает под управлением CentOS 6.0. Дисковое оборудование представляет собой массив RAID 6 с 12 дисками и контроллером Dell H800. Это устройство разбито на ext4 с использованием настроек по умолчанию.
Увеличение опережения чтения (использование Blockdev) значительно увеличивает скорость чтения, но по-прежнему не соответствует скорости записи. Например, увеличение времени опережения чтения со 128 КБ до 1 МБ улучшило скорость чтения до ~ 145 МБ / с.
Ниже приведены результаты iostat для случая чтения:
$ iostat -mx 2
avg-cpu: %user %nice %system %iowait %steal %idle
0.06 0.00 0.15 4.06 0.00 95.73
Device: rrqm/s wrqm/s r/s w/s rMB/s wMB/s avgrq-sz avgqu-sz await svctm %util
sda 0.00 0.00 524.00 0.00 73.12 0.00 285.77 27.07 51.70 1.90 99.70
и напишите case:
$ iostat -mx 2
avg-cpu: %user %nice %system %iowait %steal %idle
0.73 0.00 4.98 2.92 0.00 91.37
Device: rrqm/s wrqm/s r/s w/s rMB/s wMB/s avgrq-sz avgqu-sz await svctm %util
sda 0.00 195040.50 0.00 3613.00 0.00 776.79 440.32 137.23 37.88 0.28 100.00
Одна странность заключается в том, что rrqm / s для случая чтения составляет 0,0.
Это известная проблема производительности в нашей конфигурации ОС / диска / файловой системы? Если да, то как мы можем сказать? Если нет, то какие инструменты или тесты мы можем использовать для дальнейшего выявления проблемы?
Спасибо.
Это определенно связано с поиском головы, даже если каждый файл читается и записывается последовательно, одновременная работа означает, что головка диска должна постоянно переключаться между каждым файлом.
В iostat вывод ясно показывает эту картинку:
У большинства накопителей среднее время поиска составляет от 8 до 11 мс, при распределении по массиву из 12 дисков вы получите в лучшем случае около 1-2 мсек, что соответствует 1,90. svctm фигура.
Таким образом, чтение ~ 2 мс дает ~ 500 чтений / сек. Если каждое чтение составляет 128 КБ, вы получаете ~ 64 МБ / с. Чем больше чтения, тем выше вы можете оказаться, но в вашем iostat это показывает avgrq-sz всего 285 КБ / чтение. Очевидно, планировщик ввода-вывода должен уменьшить размер запроса, чтобы другие операции чтения не ожидали слишком долго. Я думаю, вы используете deadline планировщик, поскольку он имеет именно такой приоритет: не заставлять процесс ждать слишком долго.
Производительность записи остается высокой, потому что при достаточном объеме ОЗУ планировщик ввода-вывода может агрегировать достаточно данных для каждого потока, что приближает его к последовательному доступу. В avgrq-sz всего в два раза больше, но avgqu-sz означает, что в очереди стоит в пять раз больше операций, что обеспечивает в десять раз большую пропускную способность.
Теперь, как сделать чтение лучше (более последовательным)? Очевидный способ (и единственный гарантированный, ИМХО) - уменьшить количество одновременных файлов. Вы также можете попробовать другие планировщики; Я не знаю, если cfq предпочел бы пропускную способность задержке, возможно, noop один будет работать лучше, но при этом остальная система может перестать отвечать. Наконец, есть несколько параметров для настройки любого планировщика, вы можете поиграть с ними, пока не найдете свою идеальную настройку.