Хабр Курсы для всех
РЕКЛАМА
Большая витрина: от крупнейших школ до частных авторов. Сравнивайте по цене, длительности, формату и выбирайте самый подходящий курс!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 17
В частности в RAID- контроллерах Adaptec эта технология называется maxCache и текущая ее версия 4.0 реализована в моделях ASR-8885Q и ASR-81605ZQ.
8-ая серия = MaxCache 3.0
серия 3100 (новая) = MaxCache 4.0. Отличается, прежде всего, возможностью нарезать кэш нужными кусками под определённые кэшируемые тома.
В качестве SSD-накопителей для тома maxCache выступали две пары устройств: два Samsung 850 EVO второго поколения
Для приблизительной оценки производительности годится, но в production десктопные накопители под SSD-кэш с Write-Back ставить нельзя. Во-первых, у них отсутствует встроенная защита RAM-кэша, во-вторых — стабильность производительности (QoS задержки) никто не обещает, особенно на запись.
Отметим, что с массивом RAID60 из 36-ти дисков… Отрицательная сторона такого варианта – дополнительные расходы на объем, поскольку «теряется» не два диска на том, а два на каждую группу.
RAID-60 служит не только для преодоления ограничений на размер простой RAID-группы. Основная цель — уменьшить т.н. fault domain, делая на больших nearline дисках составные массивы не более чем из 8–12 дисков в подмассиве. Большие объёмы современных HDD в сочетании с UER на уровне 10^-15 означают долгий ребилд и большую вероятность побить данные во время ребилда.
Опишите подробнее методологию тестирования: параметры fio (randrepeat, ioengine, direct, norandommap, refill_buffers), размер тестируемой области, время тестирования. У Вас есть основной том размером 36 ТБ и кэш размером 1 ТБ или 400 ГБ. Если Вы просто будете запускать тесты с разной глубиной очереди произвольной длительности на весь размер тома, то получите низкий и нестабильный процент попадания в кэш. Но SSD-кэш нужен для тех случаев, когда есть некая нагрузка на случайный доступ, суммарный размер которой более-менее сопоставим с размером кэша. Раз уж у нас всё равно синтетика, то интересно было бы узнать потолок производительности для идеальной нагрузки, которая на 100% умещается в кэш, т.е. задать область тестирования, например, в 50 ГБ и перед тестами добиться заполнения кэша. Могу заранее сказать, что при этом вы упрётесь в производительность SSD минус 10–20%. Поведение в реальных приложениях может сильно отличаться. Помню, как в ранних реализациях SSD-кэша от конкурента Adaptec он поначалу не умел фильтровать последовательный доступ.
Спасибо за комментарий, поправил про версию. Новая серия контроллеров использует другой стек и не очень удобна, если нужна переносимость существующих томов с данными. На 6-7-8 проблем с переносом не было ни в одну ни в другую сторону.
Да, конечно данные SATA накопители чисто десктопные. Но не всегда есть возможность заплатить в два-три раза больше. Так что для сравнения вполне подойдут. Более существенно то, что в такой конфигурации нет TRIM и они уже сильно «использованные». В итоге чистая последовательная запись (на момент проведения тестирования) — около 90 МБ/с на том же оборудовании, что уже медленнее винчестеров (чтение — около 300 МБ/с).
И про RAID60 конечно так и есть. Но в данной статье речь преимущественно о скорости работы.
Тест запускался так:
fio --rw=test --bs=blocksize --ioengine=libaio --iodepth=iodepth --direct=1 --group_reporting --name=test --numjobs=1 --runtime=runtime --filename=device
С синтетикой проверять кэширование непросто, о чем и было сказано в статье. Зато она может показать «самый сложный» сценарий. Лучше бы конечно реальные приложения, но их не всегда удобно масштабировать, повторять и т.п.
Да, конечно данные SATA накопители чисто десктопные. Но не всегда есть возможность заплатить в два-три раза больше. Так что для сравнения вполне подойдут. Более существенно то, что в такой конфигурации нет TRIM и они уже сильно «использованные». В итоге чистая последовательная запись (на момент проведения тестирования) — около 90 МБ/с на том же оборудовании, что уже медленнее винчестеров (чтение — около 300 МБ/с).
И про RAID60 конечно так и есть. Но в данной статье речь преимущественно о скорости работы.
Тест запускался так:
fio --rw=test --bs=blocksize --ioengine=libaio --iodepth=iodepth --direct=1 --group_reporting --name=test --numjobs=1 --runtime=runtime --filename=device
С синтетикой проверять кэширование непросто, о чем и было сказано в статье. Зато она может показать «самый сложный» сценарий. Лучше бы конечно реальные приложения, но их не всегда удобно масштабировать, повторять и т.п.
За послдение пару лет на нескольких десятках серверов 90% железных проблем — это геморрой с платами адаптека. Каких только чудес не насмотрелись. Может нам фатально не везло, конечно… но вернёмся к кэшу, ага. Если я не ошибаюсь, то есть еще один нюанс — возможность юзать ssd кэширование является платной опцией. Да, там относительно недорого, что-то в районе 100-200$, однако, учитывая общее качество реализации всего у этой компании, есть большие опасения. В итоге была взята программная линуксовая реализация — bcache ( www.kernel.org/doc/Documentation/bcache.txt ). Да, увы, она требует свежего ядра, поэтому RHEL и CentOs — давай досвиданья. Однако, к bcache доверия больше. Все нужные фичи есть, плюс куча метрик, которые можно смотреть даже без консоли на JAVA и лишней пары гигов RAM (разработчики адаптек мне, конечно, в этом не поверят, но вы — верьте =).
Серьезных нагрузочных тестов погонять, увы, не успелось, но пока 4 хоста по 55Тб в raid60 с bcache'ем на 1тб вполне себе шуршат…
Если у кого есть продолжительный опыт с bcache — будет интересно.
Серьезных нагрузочных тестов погонять, увы, не успелось, но пока 4 хоста по 55Тб в raid60 с bcache'ем на 1тб вполне себе шуршат…
Если у кого есть продолжительный опыт с bcache — будет интересно.
> Есть ещё много вариантов. Например, что вы банально «не умеете их готовить».
Безусловно, друг мой, такое вполне может быть! Но тогда мы не умеем их готовить вместе с саппортом адаптека, которые самое лучше, что могли советовать — это обновить прошивку (как обычно — без гарантии сохранности данных).
> Нет никаких «платных опций». Оно идет в старших линейках контроллеров, в которых помимо этого и памяти больше, и BBU, и пр.
Сознаюсь — я соврал! Эта фича платная у LSI, который вроде поадекватнее. 274$ стоит — специально нашел в почте.
> Как вообще можно опцию аппаратного рейда сравнивать с какой-то линуксовой реализацией уровня «побаловаться на домашнем NAS»
Ничего сложного в сравнении не вижу. Обоснуете про «поиграться» или тут как с Пастернаком?
> И это в эпоху, когда всё виртуализировано, крутится под гипервизорами и знать не знает о физическом железе. Прям mdadm какой-то.
Вы таки виртуализируете файловые стораджи? Не, ну если мне бы надо было освоить бюджет среднего города РФ, то я бы безусловно обратился в VMWare и виртуализировал бы всё и вся, но некоторым приходится деньги считать.
И вы таки будете смеяться, но в паре мест мы правда переключились на mdadm с АДаптека. Потому что — а ну зачем нужен контроллер, который:
а) спонтанно зависает несколько раз в год
б) может сделать зеркало неработоспособным при вылете одного(!) диска
в) может превратить массив в тыкву при обновлении фирмвари
г) внезапно может сказать, что the target logical device cannot be larger than the maximum possible size 3720Gb, при том, что Current size: 5700 Gb. И что вообще за 3720Gb?
Это я только так слёту вспомнил. Но это, конечно, мы может и сами виноваты. Что выбрали адаптек.
Безусловно, друг мой, такое вполне может быть! Но тогда мы не умеем их готовить вместе с саппортом адаптека, которые самое лучше, что могли советовать — это обновить прошивку (как обычно — без гарантии сохранности данных).
> Нет никаких «платных опций». Оно идет в старших линейках контроллеров, в которых помимо этого и памяти больше, и BBU, и пр.
Сознаюсь — я соврал! Эта фича платная у LSI, который вроде поадекватнее. 274$ стоит — специально нашел в почте.
> Как вообще можно опцию аппаратного рейда сравнивать с какой-то линуксовой реализацией уровня «побаловаться на домашнем NAS»
Ничего сложного в сравнении не вижу. Обоснуете про «поиграться» или тут как с Пастернаком?
> И это в эпоху, когда всё виртуализировано, крутится под гипервизорами и знать не знает о физическом железе. Прям mdadm какой-то.
Вы таки виртуализируете файловые стораджи? Не, ну если мне бы надо было освоить бюджет среднего города РФ, то я бы безусловно обратился в VMWare и виртуализировал бы всё и вся, но некоторым приходится деньги считать.
И вы таки будете смеяться, но в паре мест мы правда переключились на mdadm с АДаптека. Потому что — а ну зачем нужен контроллер, который:
а) спонтанно зависает несколько раз в год
б) может сделать зеркало неработоспособным при вылете одного(!) диска
в) может превратить массив в тыкву при обновлении фирмвари
г) внезапно может сказать, что the target logical device cannot be larger than the maximum possible size 3720Gb, при том, что Current size: 5700 Gb. И что вообще за 3720Gb?
Это я только так слёту вспомнил. Но это, конечно, мы может и сами виноваты. Что выбрали адаптек.
С переносимостью (по крайней мере, у Adaptec не последнего поколения) особых проблем нет. Думаю что с восстановлением тоже (была неприятная история недавно из-за ошибки пользователя, но все хорошо закончилось).
У mdadm тоже встречаются «истории» (недавно в зеркале пропал диск, часть софта делала вид, что он есть и пыталась использовать с жуткими записями в логах, а после пересканирования шины диск поменял букву...).
С другой стороны, ошибки могут быть везде и всегда. Вопрос их «глубины», цены, отношения производителя/разработчика и т.п.
У mdadm тоже встречаются «истории» (недавно в зеркале пропал диск, часть софта делала вид, что он есть и пыталась использовать с жуткими записями в логах, а после пересканирования шины диск поменял букву...).
С другой стороны, ошибки могут быть везде и всегда. Вопрос их «глубины», цены, отношения производителя/разработчика и т.п.
Была только одна проблема с Adaptec, да и то с чужих слов и в сценарии «еж + уж» (6-я серия и 12 Гбит/с бекплейны).
На указанных контроллерах опция кэширование идет в комплекте.
Есть аналогичные тесты bcache и dm_cache. Если интересно, могу сделать материал. enchanceio «не взлетел», flashcache вызывал падение ОС при попытке его протестировать :). btier — это немного другая история.
На указанных контроллерах опция кэширование идет в комплекте.
Есть аналогичные тесты bcache и dm_cache. Если интересно, могу сделать материал. enchanceio «не взлетел», flashcache вызывал падение ОС при попытке его протестировать :). btier — это немного другая история.
Стандартная поправка по любым бенчмаркам чего-либо, имеющего SSD.
Надо:
1) Учитывать max latency для записи. По моим наблюдениям SSD хуже, чем HDD по этому параметру.
2) обязательно делать бенчмарк поверх файловой системы с включенным fsync'ом (опция fio fsync=1), если делать его поверх блочного устройства, то не сработает.
По наблюдениям у хороших устройств fsync-тест на 20-30% ниже обычного, у плохих — в разы, а иногда и в десятки раз. В частности, samsung'овые EVO совершенно катастрофически себя ведут под такой нагрузкой.
В реальной жизни мы имеем fsync после каждой транзакции в базе данных и после каждой операции системы управления системными пакетами (apt, yum, и даже виндовый апдейт), т.е. производительность в условиях fsync максимально приближена к OLTP/системным апдейтам.
Надо:
1) Учитывать max latency для записи. По моим наблюдениям SSD хуже, чем HDD по этому параметру.
2) обязательно делать бенчмарк поверх файловой системы с включенным fsync'ом (опция fio fsync=1), если делать его поверх блочного устройства, то не сработает.
По наблюдениям у хороших устройств fsync-тест на 20-30% ниже обычного, у плохих — в разы, а иногда и в десятки раз. В частности, samsung'овые EVO совершенно катастрофически себя ведут под такой нагрузкой.
В реальной жизни мы имеем fsync после каждой транзакции в базе данных и после каждой операции системы управления системными пакетами (apt, yum, и даже виндовый апдейт), т.е. производительность в условиях fsync максимально приближена к OLTP/системным апдейтам.
Тестирование поверх файловой системы — совсем другая история. Хотя конечно это более полезный с практической точки зрения вариант для подавляющего числа пользователей.
Не говоря уже о выборе самой этой файловой системы, ее настроек и тестов. Например, btrfs с настройками по умолчанию шикарно ведет себя на случайной записи из-за COW, но вот потом последовательное чтение этого файла становится по факту случайным.
Не говоря уже о выборе самой этой файловой системы, ее настроек и тестов. Например, btrfs с настройками по умолчанию шикарно ведет себя на случайной записи из-за COW, но вот потом последовательное чтение этого файла становится по факту случайным.
Тут вопрос не в файловой системе и не в особенностях её работы, а в том, чтобы тест отправлял flush в устройство после каждой записи. Многие устройства делают агрессивный writeback, и только flush'ем можно заставить их всё сохранять.
В статье проверяется блочное устройство. Так что fsync не получится использовать. А тестировать fio поверх файловой системы, на мой взгляд, не очень корректно/полезно.
Что касается max latency правильнее иметь большой массив данных после теста и его уже анализировать. Не факт, что тот же fio полезную цифру выдаст.
С винчестерами (см. первые графике в статье) конечно все стабильнее.
Что касается max latency правильнее иметь большой массив данных после теста и его уже анализировать. Не факт, что тот же fio полезную цифру выдаст.
С винчестерами (см. первые графике в статье) конечно все стабильнее.
На блочное устройство можно отправлять (если это scsi) команды SYNCHRONIZE CACHE(10) или SYNCHRONIZE CACHE(10), которые заставляют устройство скидывать кеш. Самый простой с практической стороны метод — писать внутрь одного файла на файловой системе с fsync'ами.
Бенчмаркать блочное устройство только на чтение и запись без учёта flush'ей — это всё равно, что dd гонять без oflags=direct. Циферку видишь, а интерпретировать в IRL производительность не можешь.
Бенчмаркать блочное устройство только на чтение и запись без учёта flush'ей — это всё равно, что dd гонять без oflags=direct. Циферку видишь, а интерпретировать в IRL производительность не можешь.
А почему это касается только тестов с SSD?
Безусловно для некоторых задач важен flush. Но он сам по себе несколько противоречит идее кэширования. Кроме того, мы в данном случае тестируем аппаратный контроллер. И если уж «идти до конца», то там, кроме кэша на SSD, будет еще кэш в оперативной памяти контроллера и кэши на жестких дисках (если не выключили).
Так что все зависит от постановки задач — сколько соломинок требуется подстелить (тех же двойных блоков питания, двух контроллеров, бекплейна с парой экспандеров, трех ИБП, нескольких линий подачи питания и т.п. до уже совсем другой истории).
На мой взгляд, для протестированных конфигураций больше интересна скорость без fsync, чем с ним. Иначе получится что с одной стороны мы хотим кэшировать, а с другой — обеспечить синхронизацию каждой операции записи.
А dd гонять вообще очень странное занятие, если хочется оценить скорость. О чем и на этом сайте немало написано.
Безусловно для некоторых задач важен flush. Но он сам по себе несколько противоречит идее кэширования. Кроме того, мы в данном случае тестируем аппаратный контроллер. И если уж «идти до конца», то там, кроме кэша на SSD, будет еще кэш в оперативной памяти контроллера и кэши на жестких дисках (если не выключили).
Так что все зависит от постановки задач — сколько соломинок требуется подстелить (тех же двойных блоков питания, двух контроллеров, бекплейна с парой экспандеров, трех ИБП, нескольких линий подачи питания и т.п. до уже совсем другой истории).
На мой взгляд, для протестированных конфигураций больше интересна скорость без fsync, чем с ним. Иначе получится что с одной стороны мы хотим кэшировать, а с другой — обеспечить синхронизацию каждой операции записи.
А dd гонять вообще очень странное занятие, если хочется оценить скорость. О чем и на этом сайте немало написано.
SSD это касается потому, что жёсткие диски обычно ничего особо не writeback'чат. Чуть-чуть может быть, но в целом что сказали, то записали.
А flush надо учитывать, потому что редко кто применяет блочное устройство без чего-либо, делающего транзакции (где-то вверху по стеку). Даже если это субд, которая самолично управляет блочным устройством, она всё равно flush'ит.
А для чего вы хоте ли бы использовать блочное устройство без файловой системы?
А flush надо учитывать, потому что редко кто применяет блочное устройство без чего-либо, делающего транзакции (где-то вверху по стеку). Даже если это субд, которая самолично управляет блочным устройством, она всё равно flush'ит.
А для чего вы хоте ли бы использовать блочное устройство без файловой системы?
Так тестировались же не «чистые» SSD, а не самые простые массивы. Проверка варианта с файловой системой — это уже другой тест.
Для примера сравнил опцию в «сложносочиненной» схеме — fio на файле по 10 Гбит/с сети через NFS с сервера с массивом RAID, для которого используется кэш writeback — разницы нет никакой. Правда не забываем, что используется и directio=1.
Так что вопрос в итоге сводится к частоте подачи команды flush. Что, на мой взгляд, определяется требованиями решаемых задач.
Для примера сравнил опцию в «сложносочиненной» схеме — fio на файле по 10 Гбит/с сети через NFS с сервера с массивом RAID, для которого используется кэш writeback — разницы нет никакой. Правда не забываем, что используется и directio=1.
Так что вопрос в итоге сводится к частоте подачи команды flush. Что, на мой взгляд, определяется требованиями решаемых задач.
как ни кручу настройки не получается даже близко приблизиться к таким iops как у автора. Need help!
Контроллер: Adaptec ASR8885Q
MaxCache RAID: 1E из четырех SSD по 900 Гб
OS RAID: 5 из двух SSD
Storage RAID: 50 из 14 SAS по 14 Тб
Что может быть не так?
Контроллер: Adaptec ASR8885Q
MaxCache RAID: 1E из четырех SSD по 900 Гб
OS RAID: 5 из двух SSD
Storage RAID: 50 из 14 SAS по 14 Тб
Тест без кэша
root@storage-ix:~# fio testdisk.ini
readtest: (g=0): rw=randread, bs=4K-4K/4K-4K/4K-4K, ioengine=libaio, iodepth=4
writetest: (g=0): rw=randwrite, bs=4K-4K/4K-4K/4K-4K, ioengine=libaio, iodepth=4
fio-2.16
Starting 2 processes
fio: file /dev/sdb exceeds 32-bit tausworthe random generator.
fio: Switching to tausworthe64. Use the random_generator= option to get rid of this warning.
fio: file /dev/sdb exceeds 32-bit tausworthe random generator.
fio: Switching to tausworthe64. Use the random_generator= option to get rid of this warning.
^Cbs: 2 (f=2): [r(1),w(1)] [0.0% done] [36KB/3744KB/0KB /s] [9/936/0 iops] [eta 39155d:04h:56m:18s]
fio: terminating on signal 2
Jobs: 1 (f=1): [r(1),_(1)] [0.0% done] [20KB/2160KB/0KB /s] [5/540/0 iops] [eta 39160d:20h:56m:11s]
readtest: (groupid=0, jobs=1): err= 0: pid=135177: Fri Apr 10 19:26:17 2020
read: io=196824KB, bw=49642B/s, iops=12, runt=4059954msec
slat (usec): min=5, max=95, avg=35.93, stdev= 4.01
clat (usec): min=535, max=5194.4K, avg=329927.55, stdev=506721.89
lat (usec): min=575, max=5194.4K, avg=329964.22, stdev=506721.95
clat percentiles (msec):
| 1.00th=[ 9], 5.00th=[ 15], 10.00th=[ 18], 20.00th=[ 25],
| 30.00th=[ 35], 40.00th=[ 56], 50.00th=[ 100], 60.00th=[ 184],
| 70.00th=[ 318], 80.00th=[ 537], 90.00th=[ 971], 95.00th=[ 1434],
| 99.00th=[ 2409], 99.50th=[ 2671], 99.90th=[ 3326], 99.95th=[ 3556],
| 99.99th=[ 4146]
lat (usec): 750=0.01%, 1000=0.01%
lat (msec): 2=0.06%, 4=0.15%, 10=1.39%, 20=11.86%, 50=24.66%
lat (msec): 100=11.86%, 250=15.75%, 500=12.99%, 750=7.19%, 1000=4.49%
lat (msec): 2000=7.45%, >=2000=2.14%
cpu: usr=0.03%, sys=0.05%, ctx=49453, majf=0, minf=13
IO depths: 1=0.1%, 2=0.1%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, >=64=0.0%
submit: 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.0%, >=64=0.0%
complete: 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.0%, >=64=0.0%
issued: total=r=49206/w=0/d=0, short=r=0/w=0/d=0, drop=r=0/w=0/d=0
latency: target=0, window=0, percentile=100.00%, depth=4
writetest: (groupid=0, jobs=1): err= 0: pid=135178: Fri Apr 10 19:26:17 2020
write: io=13514MB, bw=3409.3KB/s, iops=852, runt=4059188msec
slat (usec): min=3, max=182, avg=15.05, stdev=10.34
clat (usec): min=35, max=1216.1K, avg=4673.97, stdev=4252.08
lat (usec): min=44, max=1216.2K, avg=4689.37, stdev=4251.51
clat percentiles (usec):
| 1.00th=[ 326], 5.00th=[ 1096], 10.00th=[ 1608], 20.00th=[ 2320],
| 30.00th=[ 2896], 40.00th=[ 3472], 50.00th=[ 4080], 60.00th=[ 4704],
| 70.00th=[ 5536], 80.00th=[ 6560], 90.00th=[ 8256], 95.00th=[10176],
| 99.00th=[14784], 99.50th=[17024], 99.90th=[24448], 99.95th=[29056],
| 99.99th=[52992]
lat (usec): 50=0.03%, 100=0.10%, 250=0.66%, 500=0.81%, 750=1.05%
lat (usec): 1000=1.60%
lat (msec): 2=11.03%, 4=33.58%, 10=45.87%, 20=5.03%, 50=0.23%
lat (msec): 100=0.01%, 250=0.01%, 500=0.01%, 750=0.01%, 1000=0.01%
lat (msec): 2000=0.01%
cpu: usr=0.59%, sys=1.58%, ctx=976798, majf=0, minf=9
IO depths: 1=0.1%, 2=0.1%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, >=64=0.0%
submit: 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.0%, >=64=0.0%
complete: 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.0%, >=64=0.0%
issued: total=r=0/w=3459470/d=0, short=r=0/w=0/d=0, drop=r=0/w=0/d=0
latency: target=0, window=0, percentile=100.00%, depth=4
Run status group 0 (all jobs):
READ: io=196824KB, aggrb=48KB/s, minb=48KB/s, maxb=48KB/s, mint=4059954msec, maxt=4059954msec
WRITE: io=13514MB, aggrb=3409KB/s, minb=3409KB/s, maxb=3409KB/s, mint=4059188msec, maxt=4059188msec
Disk stats (read/write):
sdb: ios=49254/3459470, merge=0/0, ticks=16225180/15962664, in_queue=32188164, util=99.93%
readtest: (g=0): rw=randread, bs=4K-4K/4K-4K/4K-4K, ioengine=libaio, iodepth=4
writetest: (g=0): rw=randwrite, bs=4K-4K/4K-4K/4K-4K, ioengine=libaio, iodepth=4
fio-2.16
Starting 2 processes
fio: file /dev/sdb exceeds 32-bit tausworthe random generator.
fio: Switching to tausworthe64. Use the random_generator= option to get rid of this warning.
fio: file /dev/sdb exceeds 32-bit tausworthe random generator.
fio: Switching to tausworthe64. Use the random_generator= option to get rid of this warning.
^Cbs: 2 (f=2): [r(1),w(1)] [0.0% done] [36KB/3744KB/0KB /s] [9/936/0 iops] [eta 39155d:04h:56m:18s]
fio: terminating on signal 2
Jobs: 1 (f=1): [r(1),_(1)] [0.0% done] [20KB/2160KB/0KB /s] [5/540/0 iops] [eta 39160d:20h:56m:11s]
readtest: (groupid=0, jobs=1): err= 0: pid=135177: Fri Apr 10 19:26:17 2020
read: io=196824KB, bw=49642B/s, iops=12, runt=4059954msec
slat (usec): min=5, max=95, avg=35.93, stdev= 4.01
clat (usec): min=535, max=5194.4K, avg=329927.55, stdev=506721.89
lat (usec): min=575, max=5194.4K, avg=329964.22, stdev=506721.95
clat percentiles (msec):
| 1.00th=[ 9], 5.00th=[ 15], 10.00th=[ 18], 20.00th=[ 25],
| 30.00th=[ 35], 40.00th=[ 56], 50.00th=[ 100], 60.00th=[ 184],
| 70.00th=[ 318], 80.00th=[ 537], 90.00th=[ 971], 95.00th=[ 1434],
| 99.00th=[ 2409], 99.50th=[ 2671], 99.90th=[ 3326], 99.95th=[ 3556],
| 99.99th=[ 4146]
lat (usec): 750=0.01%, 1000=0.01%
lat (msec): 2=0.06%, 4=0.15%, 10=1.39%, 20=11.86%, 50=24.66%
lat (msec): 100=11.86%, 250=15.75%, 500=12.99%, 750=7.19%, 1000=4.49%
lat (msec): 2000=7.45%, >=2000=2.14%
cpu: usr=0.03%, sys=0.05%, ctx=49453, majf=0, minf=13
IO depths: 1=0.1%, 2=0.1%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, >=64=0.0%
submit: 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.0%, >=64=0.0%
complete: 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.0%, >=64=0.0%
issued: total=r=49206/w=0/d=0, short=r=0/w=0/d=0, drop=r=0/w=0/d=0
latency: target=0, window=0, percentile=100.00%, depth=4
writetest: (groupid=0, jobs=1): err= 0: pid=135178: Fri Apr 10 19:26:17 2020
write: io=13514MB, bw=3409.3KB/s, iops=852, runt=4059188msec
slat (usec): min=3, max=182, avg=15.05, stdev=10.34
clat (usec): min=35, max=1216.1K, avg=4673.97, stdev=4252.08
lat (usec): min=44, max=1216.2K, avg=4689.37, stdev=4251.51
clat percentiles (usec):
| 1.00th=[ 326], 5.00th=[ 1096], 10.00th=[ 1608], 20.00th=[ 2320],
| 30.00th=[ 2896], 40.00th=[ 3472], 50.00th=[ 4080], 60.00th=[ 4704],
| 70.00th=[ 5536], 80.00th=[ 6560], 90.00th=[ 8256], 95.00th=[10176],
| 99.00th=[14784], 99.50th=[17024], 99.90th=[24448], 99.95th=[29056],
| 99.99th=[52992]
lat (usec): 50=0.03%, 100=0.10%, 250=0.66%, 500=0.81%, 750=1.05%
lat (usec): 1000=1.60%
lat (msec): 2=11.03%, 4=33.58%, 10=45.87%, 20=5.03%, 50=0.23%
lat (msec): 100=0.01%, 250=0.01%, 500=0.01%, 750=0.01%, 1000=0.01%
lat (msec): 2000=0.01%
cpu: usr=0.59%, sys=1.58%, ctx=976798, majf=0, minf=9
IO depths: 1=0.1%, 2=0.1%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, >=64=0.0%
submit: 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.0%, >=64=0.0%
complete: 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.0%, >=64=0.0%
issued: total=r=0/w=3459470/d=0, short=r=0/w=0/d=0, drop=r=0/w=0/d=0
latency: target=0, window=0, percentile=100.00%, depth=4
Run status group 0 (all jobs):
READ: io=196824KB, aggrb=48KB/s, minb=48KB/s, maxb=48KB/s, mint=4059954msec, maxt=4059954msec
WRITE: io=13514MB, aggrb=3409KB/s, minb=3409KB/s, maxb=3409KB/s, mint=4059188msec, maxt=4059188msec
Disk stats (read/write):
sdb: ios=49254/3459470, merge=0/0, ticks=16225180/15962664, in_queue=32188164, util=99.93%
Тест с кэшем
Read — Enabled
Write — Instant Write-Back
root@storage-ix:~# fio testdisk.ini
readtest: (g=0): rw=randread, bs=4K-4K/4K-4K/4K-4K, ioengine=libaio, iodepth=32
writetest: (g=0): rw=randwrite, bs=4K-4K/4K-4K/4K-4K, ioengine=libaio, iodepth=32
fio-2.16
Starting 2 processes
fio: file /dev/sdb exceeds 32-bit tausworthe random generator.
fio: Switching to tausworthe64. Use the random_generator= option to get rid of this warning.
fio: file /dev/sdb exceeds 32-bit tausworthe random generator.
fio: Switching to tausworthe64. Use the random_generator= option to get rid of this warning.
^Cbs: 2 (f=2): [r(1),w(1)] [0.0% done] [56KB/4464KB/0KB /s] [14/1116/0 iops] [eta 19578d:03h:55m:15s] 49s]
fio: terminating on signal 2
readtest: (groupid=0, jobs=1): err= 0: pid=119128: Fri Apr 10 14:53:46 2020
read: io=91952KB, bw=99458B/s, iops=24, runt=946717msec
slat (usec): min=3, max=143, avg=21.64, stdev= 4.06
clat (usec): min=276, max=6986.8K, avg=1316779.75, stdev=963039.96
lat (usec): min=291, max=6986.8K, avg=1316802.00, stdev=963040.24
clat percentiles (usec):
| 1.00th=[ 438], 5.00th=[55552], 10.00th=[242688], 20.00th=[411648],
| 30.00th=[618496], 40.00th=[856064], 50.00th=[1122304], 60.00th=[1433600],
| 70.00th=[1794048], 80.00th=[2179072], 90.00th=[2703360], 95.00th=[3096576],
| 99.00th=[3817472], 99.50th=[4112384], 99.90th=[4751360], 99.95th=[5210112],
| 99.99th=[5734400]
lat (usec): 500=1.58%, 750=0.22%, 1000=0.08%
lat (msec): 2=0.02%, 4=0.02%, 10=0.03%, 20=0.47%, 50=2.34%
lat (msec): 100=1.12%, 250=4.50%, 500=13.97%, 750=11.24%, 1000=9.90%
lat (msec): 2000=30.02%, >=2000=24.47%
cpu: usr=0.12%, sys=0.09%, ctx=22427, majf=0, minf=42
IO depths: 1=0.1%, 2=0.1%, 4=0.1%, 8=0.1%, 16=0.1%, 32=99.9%, >=64=0.0%
submit: 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.0%, >=64=0.0%
complete: 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.1%, 64=0.0%, >=64=0.0%
issued: total=r=22988/w=0/d=0, short=r=0/w=0/d=0, drop=r=0/w=0/d=0
latency: target=0, window=0, percentile=100.00%, depth=32
writetest: (groupid=0, jobs=1): err= 0: pid=119129: Fri Apr 10 14:53:46 2020
write: io=3325.8MB, bw=3598.6KB/s, iops=899, runt=946370msec
slat (usec): min=2, max=254, avg= 9.38, stdev= 6.30
clat (usec): min=99, max=2166.7K, avg=35533.69, stdev=84533.56
lat (usec): min=119, max=2166.7K, avg=35543.31, stdev=84534.42
clat percentiles (usec):
| 1.00th=[ 478], 5.00th=[ 628], 10.00th=[ 836], 20.00th=[ 1256],
| 30.00th=[ 1704], 40.00th=[ 2160], 50.00th=[ 2672], 60.00th=[ 9024],
| 70.00th=[20608], 80.00th=[34048], 90.00th=[89600], 95.00th=[228352],
| 99.00th=[374784], 99.50th=[440320], 99.90th=[675840], 99.95th=[872448],
| 99.99th=[1712128]
lat (usec): 100=0.01%, 250=0.09%, 500=1.71%, 750=6.19%, 1000=5.82%
lat (msec): 2=22.60%, 4=20.21%, 10=4.21%, 20=8.57%, 50=17.35%
lat (msec): 100=3.31%, 250=5.89%, 500=3.76%, 750=0.21%, 1000=0.04%
lat (msec): 2000=0.03%, >=2000=0.01%
cpu: usr=0.60%, sys=1.40%, ctx=604154, majf=0, minf=9
IO depths: 1=0.1%, 2=0.1%, 4=0.1%, 8=0.1%, 16=0.1%, 32=100.0%, >=64=0.0%
submit: 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.0%, >=64=0.0%
complete: 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.1%, 64=0.0%, >=64=0.0%
issued: total=r=0/w=851386/d=0, short=r=0/w=0/d=0, drop=r=0/w=0/d=0
latency: target=0, window=0, percentile=100.00%, depth=32
Run status group 0 (all jobs):
READ: io=91952KB, aggrb=97KB/s, minb=97KB/s, maxb=97KB/s, mint=946717msec, maxt=946717msec
WRITE: io=3325.8MB, aggrb=3598KB/s, minb=3598KB/s, maxb=3598KB/s, mint=946370msec, maxt=946370msec
Disk stats (read/write):
sdb: ios=23033/851386, merge=0/0, ticks=30243240/30212112, in_queue=60458144, util=99.70%
readtest: (g=0): rw=randread, bs=4K-4K/4K-4K/4K-4K, ioengine=libaio, iodepth=4
writetest: (g=0): rw=randwrite, bs=4K-4K/4K-4K/4K-4K, ioengine=libaio, iodepth=4
fio-2.16
Starting 2 processes
fio: file /dev/sdb exceeds 32-bit tausworthe random generator.
fio: Switching to tausworthe64. Use the random_generator= option to get rid of this warning.
fio: file /dev/sdb exceeds 32-bit tausworthe random generator.
fio: Switching to tausworthe64. Use the random_generator= option to get rid of this warning.
^Cbs: 2 (f=2): [r(1),w(1)] [0.0% done] [44KB/3128KB/0KB /s] [11/782/0 iops] [eta 36987d:14h:32m:35s] :50s]
fio: terminating on signal 2
Jobs: 1 (f=0): [f(1),_(1)] [100.0% done] [36KB/1008KB/0KB /s] [9/252/0 iops] [eta 00m:00s]
readtest: (groupid=0, jobs=1): err= 0: pid=129208: Fri Apr 10 17:40:29 2020
read: io=134300KB, bw=52552B/s, iops=12, runt=2616875msec
slat (usec): min=2, max=84, avg=35.09, stdev= 6.52
clat (usec): min=95, max=4144.6K, avg=311629.79, stdev=494456.53
lat (usec): min=112, max=4144.7K, avg=311665.57, stdev=494456.95
clat percentiles (usec):
| 1.00th=[ 143], 5.00th=[ 5728], 10.00th=[10432], 20.00th=[16320],
| 30.00th=[23936], 40.00th=[43264], 50.00th=[84480], 60.00th=[162816],
| 70.00th=[296960], 80.00th=[509952], 90.00th=[946176], 95.00th=[1384448],
| 99.00th=[2310144], 99.50th=[2637824], 99.90th=[3358720], 99.95th=[3653632],
| 99.99th=[4079616]
lat (usec): 100=0.01%, 250=3.80%, 500=0.51%, 750=0.01%, 1000=0.01%
lat (msec): 2=0.01%, 4=0.14%, 10=4.86%, 20=16.44%, 50=16.42%
lat (msec): 100=10.27%, 250=14.55%, 500=12.57%, 750=6.70%, 1000=4.48%
lat (msec): 2000=7.39%, >=2000=1.83%
cpu: usr=0.04%, sys=0.06%, ctx=33476, majf=0, minf=14
IO depths: 1=0.1%, 2=0.1%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, >=64=0.0%
submit: 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.0%, >=64=0.0%
complete: 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.0%, >=64=0.0%
issued: total=r=33575/w=0/d=0, short=r=0/w=0/d=0, drop=r=0/w=0/d=0
latency: target=0, window=0, percentile=100.00%, depth=4
writetest: (groupid=0, jobs=1): err= 0: pid=129209: Fri Apr 10 17:40:29 2020
write: io=8751.7MB, bw=3425.4KB/s, iops=856, runt=2616298msec
slat (usec): min=3, max=178, avg=14.99, stdev=10.25
clat (usec): min=34, max=954202, avg=4651.04, stdev=3734.02
lat (usec): min=46, max=954210, avg=4666.39, stdev=3733.43
clat percentiles (usec):
| 1.00th=[ 294], 5.00th=[ 1064], 10.00th=[ 1592], 20.00th=[ 2288],
| 30.00th=[ 2896], 40.00th=[ 3472], 50.00th=[ 4048], 60.00th=[ 4704],
| 70.00th=[ 5536], 80.00th=[ 6560], 90.00th=[ 8256], 95.00th=[10048],
| 99.00th=[14656], 99.50th=[17024], 99.90th=[24704], 99.95th=[29824],
| 99.99th=[57600]
lat (usec): 50=0.04%, 100=0.10%, 250=0.73%, 500=0.85%, 750=1.10%
lat (usec): 1000=1.65%
lat (msec): 2=11.10%, 4=33.54%, 10=45.68%, 20=4.96%, 50=0.23%
lat (msec): 100=0.01%, 250=0.01%, 500=0.01%, 750=0.01%, 1000=0.01%
cpu: usr=0.62%, sys=1.59%, ctx=631152, majf=0, minf=11
IO depths: 1=0.1%, 2=0.1%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, >=64=0.0%
submit: 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.0%, >=64=0.0%
complete: 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.0%, >=64=0.0%
issued: total=r=0/w=2240428/d=0, short=r=0/w=0/d=0, drop=r=0/w=0/d=0
latency: target=0, window=0, percentile=100.00%, depth=4
Run status group 0 (all jobs):
READ: io=134300KB, aggrb=51KB/s, minb=51KB/s, maxb=51KB/s, mint=2616875msec, maxt=2616875msec
WRITE: io=8751.7MB, aggrb=3425KB/s, minb=3425KB/s, maxb=3425KB/s, mint=2616298msec, maxt=2616298msec
Disk stats (read/write):
sdb: ios=33638/2240428, merge=0/0, ticks=10456604/10286276, in_queue=20742956, util=99.89%
Write — Instant Write-Back
root@storage-ix:~# fio testdisk.ini
readtest: (g=0): rw=randread, bs=4K-4K/4K-4K/4K-4K, ioengine=libaio, iodepth=32
writetest: (g=0): rw=randwrite, bs=4K-4K/4K-4K/4K-4K, ioengine=libaio, iodepth=32
fio-2.16
Starting 2 processes
fio: file /dev/sdb exceeds 32-bit tausworthe random generator.
fio: Switching to tausworthe64. Use the random_generator= option to get rid of this warning.
fio: file /dev/sdb exceeds 32-bit tausworthe random generator.
fio: Switching to tausworthe64. Use the random_generator= option to get rid of this warning.
^Cbs: 2 (f=2): [r(1),w(1)] [0.0% done] [56KB/4464KB/0KB /s] [14/1116/0 iops] [eta 19578d:03h:55m:15s] 49s]
fio: terminating on signal 2
readtest: (groupid=0, jobs=1): err= 0: pid=119128: Fri Apr 10 14:53:46 2020
read: io=91952KB, bw=99458B/s, iops=24, runt=946717msec
slat (usec): min=3, max=143, avg=21.64, stdev= 4.06
clat (usec): min=276, max=6986.8K, avg=1316779.75, stdev=963039.96
lat (usec): min=291, max=6986.8K, avg=1316802.00, stdev=963040.24
clat percentiles (usec):
| 1.00th=[ 438], 5.00th=[55552], 10.00th=[242688], 20.00th=[411648],
| 30.00th=[618496], 40.00th=[856064], 50.00th=[1122304], 60.00th=[1433600],
| 70.00th=[1794048], 80.00th=[2179072], 90.00th=[2703360], 95.00th=[3096576],
| 99.00th=[3817472], 99.50th=[4112384], 99.90th=[4751360], 99.95th=[5210112],
| 99.99th=[5734400]
lat (usec): 500=1.58%, 750=0.22%, 1000=0.08%
lat (msec): 2=0.02%, 4=0.02%, 10=0.03%, 20=0.47%, 50=2.34%
lat (msec): 100=1.12%, 250=4.50%, 500=13.97%, 750=11.24%, 1000=9.90%
lat (msec): 2000=30.02%, >=2000=24.47%
cpu: usr=0.12%, sys=0.09%, ctx=22427, majf=0, minf=42
IO depths: 1=0.1%, 2=0.1%, 4=0.1%, 8=0.1%, 16=0.1%, 32=99.9%, >=64=0.0%
submit: 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.0%, >=64=0.0%
complete: 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.1%, 64=0.0%, >=64=0.0%
issued: total=r=22988/w=0/d=0, short=r=0/w=0/d=0, drop=r=0/w=0/d=0
latency: target=0, window=0, percentile=100.00%, depth=32
writetest: (groupid=0, jobs=1): err= 0: pid=119129: Fri Apr 10 14:53:46 2020
write: io=3325.8MB, bw=3598.6KB/s, iops=899, runt=946370msec
slat (usec): min=2, max=254, avg= 9.38, stdev= 6.30
clat (usec): min=99, max=2166.7K, avg=35533.69, stdev=84533.56
lat (usec): min=119, max=2166.7K, avg=35543.31, stdev=84534.42
clat percentiles (usec):
| 1.00th=[ 478], 5.00th=[ 628], 10.00th=[ 836], 20.00th=[ 1256],
| 30.00th=[ 1704], 40.00th=[ 2160], 50.00th=[ 2672], 60.00th=[ 9024],
| 70.00th=[20608], 80.00th=[34048], 90.00th=[89600], 95.00th=[228352],
| 99.00th=[374784], 99.50th=[440320], 99.90th=[675840], 99.95th=[872448],
| 99.99th=[1712128]
lat (usec): 100=0.01%, 250=0.09%, 500=1.71%, 750=6.19%, 1000=5.82%
lat (msec): 2=22.60%, 4=20.21%, 10=4.21%, 20=8.57%, 50=17.35%
lat (msec): 100=3.31%, 250=5.89%, 500=3.76%, 750=0.21%, 1000=0.04%
lat (msec): 2000=0.03%, >=2000=0.01%
cpu: usr=0.60%, sys=1.40%, ctx=604154, majf=0, minf=9
IO depths: 1=0.1%, 2=0.1%, 4=0.1%, 8=0.1%, 16=0.1%, 32=100.0%, >=64=0.0%
submit: 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.0%, >=64=0.0%
complete: 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.1%, 64=0.0%, >=64=0.0%
issued: total=r=0/w=851386/d=0, short=r=0/w=0/d=0, drop=r=0/w=0/d=0
latency: target=0, window=0, percentile=100.00%, depth=32
Run status group 0 (all jobs):
READ: io=91952KB, aggrb=97KB/s, minb=97KB/s, maxb=97KB/s, mint=946717msec, maxt=946717msec
WRITE: io=3325.8MB, aggrb=3598KB/s, minb=3598KB/s, maxb=3598KB/s, mint=946370msec, maxt=946370msec
Disk stats (read/write):
sdb: ios=23033/851386, merge=0/0, ticks=30243240/30212112, in_queue=60458144, util=99.70%
readtest: (g=0): rw=randread, bs=4K-4K/4K-4K/4K-4K, ioengine=libaio, iodepth=4
writetest: (g=0): rw=randwrite, bs=4K-4K/4K-4K/4K-4K, ioengine=libaio, iodepth=4
fio-2.16
Starting 2 processes
fio: file /dev/sdb exceeds 32-bit tausworthe random generator.
fio: Switching to tausworthe64. Use the random_generator= option to get rid of this warning.
fio: file /dev/sdb exceeds 32-bit tausworthe random generator.
fio: Switching to tausworthe64. Use the random_generator= option to get rid of this warning.
^Cbs: 2 (f=2): [r(1),w(1)] [0.0% done] [44KB/3128KB/0KB /s] [11/782/0 iops] [eta 36987d:14h:32m:35s] :50s]
fio: terminating on signal 2
Jobs: 1 (f=0): [f(1),_(1)] [100.0% done] [36KB/1008KB/0KB /s] [9/252/0 iops] [eta 00m:00s]
readtest: (groupid=0, jobs=1): err= 0: pid=129208: Fri Apr 10 17:40:29 2020
read: io=134300KB, bw=52552B/s, iops=12, runt=2616875msec
slat (usec): min=2, max=84, avg=35.09, stdev= 6.52
clat (usec): min=95, max=4144.6K, avg=311629.79, stdev=494456.53
lat (usec): min=112, max=4144.7K, avg=311665.57, stdev=494456.95
clat percentiles (usec):
| 1.00th=[ 143], 5.00th=[ 5728], 10.00th=[10432], 20.00th=[16320],
| 30.00th=[23936], 40.00th=[43264], 50.00th=[84480], 60.00th=[162816],
| 70.00th=[296960], 80.00th=[509952], 90.00th=[946176], 95.00th=[1384448],
| 99.00th=[2310144], 99.50th=[2637824], 99.90th=[3358720], 99.95th=[3653632],
| 99.99th=[4079616]
lat (usec): 100=0.01%, 250=3.80%, 500=0.51%, 750=0.01%, 1000=0.01%
lat (msec): 2=0.01%, 4=0.14%, 10=4.86%, 20=16.44%, 50=16.42%
lat (msec): 100=10.27%, 250=14.55%, 500=12.57%, 750=6.70%, 1000=4.48%
lat (msec): 2000=7.39%, >=2000=1.83%
cpu: usr=0.04%, sys=0.06%, ctx=33476, majf=0, minf=14
IO depths: 1=0.1%, 2=0.1%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, >=64=0.0%
submit: 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.0%, >=64=0.0%
complete: 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.0%, >=64=0.0%
issued: total=r=33575/w=0/d=0, short=r=0/w=0/d=0, drop=r=0/w=0/d=0
latency: target=0, window=0, percentile=100.00%, depth=4
writetest: (groupid=0, jobs=1): err= 0: pid=129209: Fri Apr 10 17:40:29 2020
write: io=8751.7MB, bw=3425.4KB/s, iops=856, runt=2616298msec
slat (usec): min=3, max=178, avg=14.99, stdev=10.25
clat (usec): min=34, max=954202, avg=4651.04, stdev=3734.02
lat (usec): min=46, max=954210, avg=4666.39, stdev=3733.43
clat percentiles (usec):
| 1.00th=[ 294], 5.00th=[ 1064], 10.00th=[ 1592], 20.00th=[ 2288],
| 30.00th=[ 2896], 40.00th=[ 3472], 50.00th=[ 4048], 60.00th=[ 4704],
| 70.00th=[ 5536], 80.00th=[ 6560], 90.00th=[ 8256], 95.00th=[10048],
| 99.00th=[14656], 99.50th=[17024], 99.90th=[24704], 99.95th=[29824],
| 99.99th=[57600]
lat (usec): 50=0.04%, 100=0.10%, 250=0.73%, 500=0.85%, 750=1.10%
lat (usec): 1000=1.65%
lat (msec): 2=11.10%, 4=33.54%, 10=45.68%, 20=4.96%, 50=0.23%
lat (msec): 100=0.01%, 250=0.01%, 500=0.01%, 750=0.01%, 1000=0.01%
cpu: usr=0.62%, sys=1.59%, ctx=631152, majf=0, minf=11
IO depths: 1=0.1%, 2=0.1%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, >=64=0.0%
submit: 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.0%, >=64=0.0%
complete: 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.0%, >=64=0.0%
issued: total=r=0/w=2240428/d=0, short=r=0/w=0/d=0, drop=r=0/w=0/d=0
latency: target=0, window=0, percentile=100.00%, depth=4
Run status group 0 (all jobs):
READ: io=134300KB, aggrb=51KB/s, minb=51KB/s, maxb=51KB/s, mint=2616875msec, maxt=2616875msec
WRITE: io=8751.7MB, aggrb=3425KB/s, minb=3425KB/s, maxb=3425KB/s, mint=2616298msec, maxt=2616298msec
Disk stats (read/write):
sdb: ios=33638/2240428, merge=0/0, ticks=10456604/10286276, in_queue=20742956, util=99.89%
Что может быть не так?
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Тестирование технологии кэширования RAID–массивов Adaptec