Я видел во многих местах, что throughput = bs * iops должно быть истинным. Например, запись с размером блока 128 КБ на диск SAS, который может поддерживать 190 операций ввода-вывода в секунду, должна дать пропускную способность ~ 23 МБ / с - 23.75(MBs) = 128(BS)*190(SAS-15 IOPS)/1024.
Теперь, когда я протестировал его на виртуальной машине против монстра-фильтрующего устройства NetApp, я получил следующие результаты:
# dd if=/dev/zero of=/tmp/dd.out bs=4k count=2097152
8589934592 bytes (8.6 GB) copied, 61.5996 seconds, 139 MB/s
Чтобы просмотреть скорость ввода-вывода виртуальной машины, я использовал iostat и esxtop, и оба они показали около 250 операций ввода-вывода в секунду.
Итак, насколько я понимаю, пропускная способность должна была быть ~ 1000 КБ: 1000(KBs) = 4(BS)*250(IOPS).
dd из 8 ГБ, конечно, вдвое больше размера ОЗУ, поэтому кеширования страниц здесь нет.
Что мне не хватает?
Спасибо!
Вам не хватает контекста. IOPS является ПОЛНОСТЬЮ СЛУЧАЙНЫМ. Копия не случайная, а последовательная. Жесткие диски замедляются при перемещении головки - IOPS в основном предполагает правильно измеренное количество операций ввода-вывода, которое случайным образом распределяется по всей пластине диска (или, по крайней мере, по большей его части).
Да, вы намного быстрее копируете диск. К сожалению, это совершенно не имеет значения, если только вы не используете копирование ТОЛЬКО ОДНИМ ПОЛЬЗОВАТЕЛЕМ ЗА РАЗ.
Это похоже на измерение максимальной скорости автомобиля Формулы 1 и последующее предположение, что это средняя скорость во время гонки - плохие мяуканья, трассы Формулы 1 имеют повороты, машины в основном едут намного медленнее.
Итак, если вы не выполняете полностью вырожденные шаблоны (в техническом смысле), то есть выполняете только одну операцию копирования за раз, тогда ввод-вывод будет случайным (особенно виртуальные машины - одна может быть последовательной, 20 попаданий на один и тот же диск случайны. ) и голова тратит большую часть времени на перемещение, не выполняя операций ввода-вывода.
dd из 8 ГБ - это вдвое больше ОЗУ
Это все еще жалко, не правда ли? Насколько велик диск? (gb - это лишь небольшая часть, поэтому «случайная» часть - это очень мало движений (измеряемых по длине) по сравнению с реальным сценарием;) На самом деле никакого случайного движения, когда вы копируете из нулевого источника, так что это только пишет, а не движется голова. ПЛОХОЙ ;)
НАВЕРХУ:
против монстра-филлера NetApp
ЛЮБАЯ идея, насколько эти большие элементы SAN могут оптимизировать ваш ввод-вывод? Сколько у него кеша? Фильтр-монстр будет одной из лучших моделей, у которой есть память объемом 16+ гигабайт для использования в собственном кэше. Если на самом деле чудовище, то ваш файл жалкий - википедия читает верхнюю строчку 2010 (!) С памятью 192 ГБ;) Даже не осознает при буферизации 8 ГБ. А дедупликация (происходит ли это в реальном времени?) Может устранить практически все операции записи. Вы уверены, что даже измеряли IOPS на дисках?
Есть приложение под названием SQLIO, не беспокойтесь о названии, оно на самом деле не имеет ничего общего с SQL, оно было только что написано командой SQL Server в Microsoft, что позволит вам протестировать свой диск со случайным вводом-выводом (чтение или запись) и увидеть какова нагрузка на диски. Вы можете скачать его с сайта Microsoft.
Если вы собираетесь использовать throughput = block size * IOPS, вы должны использовать размер блока операций ввода-вывода, которые вы подсчитываете, а не размер блока файловой системы или размер блока блочного устройства.
139 МБ / с, вероятно, немного выше, чем у вас на самом деле, потому что ввод-вывод, вероятно, продолжался, когда измерение остановилось. Кеш блоков, вероятно, все еще очищался. Кажется, наиболее логичным объяснением является то, что размер базовых операций ввода-вывода, которые вы подсчитываете, составляет 512 КБ.
Размер блока операций ввода-вывода должен быть кратным размеру блока блочного устройства. Я полагаю, вы сказали, что это 128 КБ. Так что операции с 512 КБ (4 блока), безусловно, возможны.
512 * 250 = 128 МБ / с