Если смотреть только на «задержки-очередь», то конечно почти везде все линейно. Но на «скорость-очередь» разница между 16 и 256 обычно заметна. Можно было бы ограничиться скажем 128, но все-таки удобнее иметь дополнительные точки для более четкого понимания, что «полка» точно наступила.
В описанной задаче речь не идет про СУБД. Хотя конечно Intel Optane с базами данных смотрелся бы скорее всего отлично.
«Диск» — именно жесткий диск или накопитель в общем смысле этого слова? Причин попробовать 256 несколько — на реальной нагрузке (файловый сервер) видел 150 и более, некоторые конфигурации и на этом значении не упираются в свой предел, часто интересно смотреть до какого значения можно увеличивать очередь с сохранением задержек ниже заданных.
Да, формально 1 и 1,5 — разница в полтора раза. Но найти приложение, которое это заметит, непросто.
Читал несколько статей о выборе scheduler для «не жестких дисков». Результаты тестов, на мой взгляд, неоднозначные. Для конкретной задачи (например, базы данных) можно подобрать оптимальный, если сначала определиться с критериями. Для синтетических тестов это менее интересно/полезно.
А NVMe — это уже другая история и там обычные scheduler не используются.
Вопрос стоял не в «получить максимальные результаты на данном железе настройкой ПО и выбором опций/параметров/режимов». Хотя конечно решение этой задачи очень даже интересно и полезно на практике.
Это отдельная история. Добавлять еще один параметр в эту статью не стал. Иначе бы история существенно занянулась. Так что все «из коробки».
Почему для последовательной записи использовали именно 256К блоки?
Так исторически сложилось. Не стояло задачи «выжать все», а так конечно можно было бы еще много разных параметров накрутить. Обычно можно использовать «блок достаточно большого размера». Так что увеличение, скажем до 512 КБ или 1024 КБ, мало что изменит.
P.s. Обычно используют опции sync, direct чтобы не мерить кэш.
Для самого fio конечно direct=1. Но все-таки «что б не мерить кэш» — это неоднозначный вопрос.
P.P.s. Тесты проводились в один поток, а это обычно не свойственно виртуализации. Было бы интереснее увидеть (iops\BW\lat) / threads.
Тесты проводились с изменением параметра iodepth от 1 до 256. Возможно стоило еще обратить внимание на numjobs. Надо будет попробовать и сравнить результаты.
Про показатели разных типов дисков написано тут вагон и маленькая тележка, при чём уже довольно давно, но с тех пор ничего не изменилось.
Не очень понятен выбор материала для сравнения. Да и как минимум цифры разные. Так что вероятно все-таки что-то изменилось. Например, условия тестирования.
На каком объёме данных проходили тесты то? Диски предварительно заполнялись или нет? Какое время тестирования для флеша?
Тесты проводились на блочных устройствах без ограничения объема. В случае виртуальных дисков на lvm и в формате raw диски имели объем 64 ГБ, как и указано в тексте. Диски предварительно не заполнялись. Время тестирования для каждого шаблона — пять минут.
ВОзьмите ради интереса хайпер-в или вмваре
Мне был интересен Proxmox. В принципе, можно попробовать повторить на vmware.
Так тестировались же не «чистые» SSD, а не самые простые массивы. Проверка варианта с файловой системой — это уже другой тест.
Для примера сравнил опцию в «сложносочиненной» схеме — fio на файле по 10 Гбит/с сети через NFS с сервера с массивом RAID, для которого используется кэш writeback — разницы нет никакой. Правда не забываем, что используется и directio=1.
Так что вопрос в итоге сводится к частоте подачи команды flush. Что, на мой взгляд, определяется требованиями решаемых задач.
А почему это касается только тестов с SSD?
Безусловно для некоторых задач важен flush. Но он сам по себе несколько противоречит идее кэширования. Кроме того, мы в данном случае тестируем аппаратный контроллер. И если уж «идти до конца», то там, кроме кэша на SSD, будет еще кэш в оперативной памяти контроллера и кэши на жестких дисках (если не выключили).
Так что все зависит от постановки задач — сколько соломинок требуется подстелить (тех же двойных блоков питания, двух контроллеров, бекплейна с парой экспандеров, трех ИБП, нескольких линий подачи питания и т.п. до уже совсем другой истории).
На мой взгляд, для протестированных конфигураций больше интересна скорость без fsync, чем с ним. Иначе получится что с одной стороны мы хотим кэшировать, а с другой — обеспечить синхронизацию каждой операции записи.
А dd гонять вообще очень странное занятие, если хочется оценить скорость. О чем и на этом сайте немало написано.
С переносимостью (по крайней мере, у Adaptec не последнего поколения) особых проблем нет. Думаю что с восстановлением тоже (была неприятная история недавно из-за ошибки пользователя, но все хорошо закончилось).
У mdadm тоже встречаются «истории» (недавно в зеркале пропал диск, часть софта делала вид, что он есть и пыталась использовать с жуткими записями в логах, а после пересканирования шины диск поменял букву...).
С другой стороны, ошибки могут быть везде и всегда. Вопрос их «глубины», цены, отношения производителя/разработчика и т.п.
В статье проверяется блочное устройство. Так что fsync не получится использовать. А тестировать fio поверх файловой системы, на мой взгляд, не очень корректно/полезно.
Что касается max latency правильнее иметь большой массив данных после теста и его уже анализировать. Не факт, что тот же fio полезную цифру выдаст.
С винчестерами (см. первые графике в статье) конечно все стабильнее.
Тестирование поверх файловой системы — совсем другая история. Хотя конечно это более полезный с практической точки зрения вариант для подавляющего числа пользователей.
Не говоря уже о выборе самой этой файловой системы, ее настроек и тестов. Например, btrfs с настройками по умолчанию шикарно ведет себя на случайной записи из-за COW, но вот потом последовательное чтение этого файла становится по факту случайным.
Была только одна проблема с Adaptec, да и то с чужих слов и в сценарии «еж + уж» (6-я серия и 12 Гбит/с бекплейны).
На указанных контроллерах опция кэширование идет в комплекте.
Есть аналогичные тесты bcache и dm_cache. Если интересно, могу сделать материал. enchanceio «не взлетел», flashcache вызывал падение ОС при попытке его протестировать :). btier — это немного другая история.
Спасибо за комментарий, поправил про версию. Новая серия контроллеров использует другой стек и не очень удобна, если нужна переносимость существующих томов с данными. На 6-7-8 проблем с переносом не было ни в одну ни в другую сторону.
Да, конечно данные SATA накопители чисто десктопные. Но не всегда есть возможность заплатить в два-три раза больше. Так что для сравнения вполне подойдут. Более существенно то, что в такой конфигурации нет TRIM и они уже сильно «использованные». В итоге чистая последовательная запись (на момент проведения тестирования) — около 90 МБ/с на том же оборудовании, что уже медленнее винчестеров (чтение — около 300 МБ/с).
И про RAID60 конечно так и есть. Но в данной статье речь преимущественно о скорости работы.
С синтетикой проверять кэширование непросто, о чем и было сказано в статье. Зато она может показать «самый сложный» сценарий. Лучше бы конечно реальные приложения, но их не всегда удобно масштабировать, повторять и т.п.
В описанной задаче речь не идет про СУБД. Хотя конечно Intel Optane с базами данных смотрелся бы скорее всего отлично.
Да, формально 1 и 1,5 — разница в полтора раза. Но найти приложение, которое это заметит, непросто.
А NVMe — это уже другая история и там обычные scheduler не используются.
Один шаблон — пять минут.
Это отдельная история. Добавлять еще один параметр в эту статью не стал. Иначе бы история существенно занянулась. Так что все «из коробки».
Так исторически сложилось. Не стояло задачи «выжать все», а так конечно можно было бы еще много разных параметров накрутить. Обычно можно использовать «блок достаточно большого размера». Так что увеличение, скажем до 512 КБ или 1024 КБ, мало что изменит.
Для самого fio конечно direct=1. Но все-таки «что б не мерить кэш» — это неоднозначный вопрос.
Тесты проводились с изменением параметра iodepth от 1 до 256. Возможно стоило еще обратить внимание на numjobs. Надо будет попробовать и сравнить результаты.
Не очень понятен выбор материала для сравнения. Да и как минимум цифры разные. Так что вероятно все-таки что-то изменилось. Например, условия тестирования.
Тесты проводились на блочных устройствах без ограничения объема. В случае виртуальных дисков на lvm и в формате raw диски имели объем 64 ГБ, как и указано в тексте. Диски предварительно не заполнялись. Время тестирования для каждого шаблона — пять минут.
Мне был интересен Proxmox. В принципе, можно попробовать повторить на vmware.
Для примера сравнил опцию в «сложносочиненной» схеме — fio на файле по 10 Гбит/с сети через NFS с сервера с массивом RAID, для которого используется кэш writeback — разницы нет никакой. Правда не забываем, что используется и directio=1.
Так что вопрос в итоге сводится к частоте подачи команды flush. Что, на мой взгляд, определяется требованиями решаемых задач.
Безусловно для некоторых задач важен flush. Но он сам по себе несколько противоречит идее кэширования. Кроме того, мы в данном случае тестируем аппаратный контроллер. И если уж «идти до конца», то там, кроме кэша на SSD, будет еще кэш в оперативной памяти контроллера и кэши на жестких дисках (если не выключили).
Так что все зависит от постановки задач — сколько соломинок требуется подстелить (тех же двойных блоков питания, двух контроллеров, бекплейна с парой экспандеров, трех ИБП, нескольких линий подачи питания и т.п. до уже совсем другой истории).
На мой взгляд, для протестированных конфигураций больше интересна скорость без fsync, чем с ним. Иначе получится что с одной стороны мы хотим кэшировать, а с другой — обеспечить синхронизацию каждой операции записи.
А dd гонять вообще очень странное занятие, если хочется оценить скорость. О чем и на этом сайте немало написано.
У mdadm тоже встречаются «истории» (недавно в зеркале пропал диск, часть софта делала вид, что он есть и пыталась использовать с жуткими записями в логах, а после пересканирования шины диск поменял букву...).
С другой стороны, ошибки могут быть везде и всегда. Вопрос их «глубины», цены, отношения производителя/разработчика и т.п.
Что касается max latency правильнее иметь большой массив данных после теста и его уже анализировать. Не факт, что тот же fio полезную цифру выдаст.
С винчестерами (см. первые графике в статье) конечно все стабильнее.
Не говоря уже о выборе самой этой файловой системы, ее настроек и тестов. Например, btrfs с настройками по умолчанию шикарно ведет себя на случайной записи из-за COW, но вот потом последовательное чтение этого файла становится по факту случайным.
На указанных контроллерах опция кэширование идет в комплекте.
Есть аналогичные тесты bcache и dm_cache. Если интересно, могу сделать материал. enchanceio «не взлетел», flashcache вызывал падение ОС при попытке его протестировать :). btier — это немного другая история.
Да, конечно данные 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
С синтетикой проверять кэширование непросто, о чем и было сказано в статье. Зато она может показать «самый сложный» сценарий. Лучше бы конечно реальные приложения, но их не всегда удобно масштабировать, повторять и т.п.