Зная IOPS можно узнать и пропускную способность, умножив IOPS на размер блока. 30 000 IOPS x 4K = 120 000 K/s. = 117 MB/s.
А вот как латентность вычислить из IOPS? Графики выше явно говорят, что зависимость не линейная, т.е. вычислить латентность из IOPS нельзя.
Вернее так, если у вас бенчмарк имеет глубину 1 и 1 очередь, то да, время за которое у вас выполнится одна операция и придет подтверждение ее выполнения и является латентностью по определению. Т.е. 1/(число IOPS) = время 1 операции.
По мере роста глубины и потоков у вас латентность становится больше среднего времени выполнения операций за некоторое время. Т.е. вычислять латентность при Q>1 и T>1 делением 1 на IOPS нельзя.
Вот для примера латентность на корпоративном SSD Intel вот отсюда.
Вот еще пример того же источника, что разные SSD могут себя сильно по разному вести при записи.
А это пример пользовательского SSD, у которого латентность 5 мс (как у HDD) уже при 25 тыс. IOPS.
Латентность - важная величина. NVMe для баз данных именно за нее и выбирают (NAND-то одинаковая и в SATA и в NVMe). Поэтому её стоит приводить в бенчмарках.
Все немного сложнее получается. Появляется дополнительный программный слой и дополнительный аппаратный (контроллер).
Только вчера читал тестирование PostgreSQL 2014 года и на SATA у них было что-то там 50 тыс. tps, а на NVMe 400 тыс. tps, а в RAM если диск держать 1500 тыс. tps.
Люди смотрят на такие бенчмарки и хотят, конечно, NVMe и почти x10 к работе базы.
Если там стоит аппаратный контроллер с writeback, есть вероятность, что все записанные данные уместились в его ОЗУ и это тест скорости ОЗУ контроллера.
NVMe вроде хвалят за низкую латентность. Если ядро часто переключает контекст и латентность переключения много больше NVMe, то подозреваю, что наоборот, разница между SATA SSD и NVMe будет труднее обнаружить.
Кстати, вот пример сравнения Baremetal https://elibsystem.ru/node/503 с Hyper-V, KVM на SATA SSD c древним контроллером, но и там довольно хорошо видна сильная зависимость производительности от гипервизора.
Вообще надо понять что тестировать-то хочется.
Абстрактную производительность NVMe? Производительность NVMe в Hyper-V в одиночной ВМ (не убивает ли оверхед Hyper-V низкую задержку NVMe)? Производительность NVMe при большом количестве ВМ, все из которых одновременно генерируют нагрузку по сравнению с SATA (качественное сравнение есть ли разница при большой нагрузке в условиях конкуренции кучи ВМ за CPU и NVMe)? Во всех трех случаях очевидно методика тестирования разная.
Более того, от того пишутся ли данные синхронно или последовательно тоже результаты бенчмарка зависят, а тут сюрприз, SSD часто нужны для баз данных, а РСУБД пишут часто последовательно (потому-что в журнал) малым количеством потоков с частыми fsync. Т.е. базы данных даже близко не выдают максимально возможные IOPS-ы на запись.
Дальше надо понимать, что NVMe хороши низкой задержкой. Но! Но когда 100500 ВМ генерируют параллельно нагрузку и утилизируют SSD в полку, общая пропускная способность конечно будет высокой (у SSD чем больше одновременных потоков - тем больше IOPS и мегабайт), но вот задержки начнут сильно нарастать, а в статье задержки вообще не представлены! Т.е. при миллионе IOPS задержки какие? Вот для примера про латентность от Intel:
Поэтому зная, что все зависит от всего (производительность от нагрузки случайная/последовательная, размера кластера, как часто fsync шлется, размера очереди, конкуренции за CPU множества ВМ, драйверов, ФС, гипервизора, writeback, способности ВМ читать из ОЗУ вместо диска из-за виртуализации и т.д.) надо, ну если хочется во всех этих аспектах посмотреть что происходит, делать не один тест, а на каждую из задач по тесту.
Естественно, синтетика с большим количеством очередей может совершенно не походить по профилю нагрузки на поведение баз данных. Так что логично поинтересоваться у клиентов какие базы гонять собираются и побенчмаркать базы на NVMe/SATA и посмотреть, есть ли разница. Естественно начинаются приколы, что SATA будет контроллер использовать и он тоже может и свои настройки иметь и задеркжи и т.д.
Итого: непростое это дело производительность дисковой подсистемы измерять!
На чтение думаю это действительно хорошая производительность.
С записью сложнее. Запись в SSD в writeback-же работает и поэтому пока кеша хватает, производительность очень высокая, а задержки низкие. Тоже на уровне 100 мкс или меньше.
Соответственно, если сеть добавляет задержку в 100 мкс (0.1мс), то при собственной задержке 100 мкс и direct-записи это снижение производительности случайной записи в 2 раза. Если SSD latency 50 мкс, то снижение в 3 раза и т.д.
Что и видим на графике по отставанию записи от чтения для SSD.
Про URI все просто (это не URL в смысле location, а именно идентификаторы).
Положим нужен способ сделать идентификаторы, но такой, чтобы глобально они были уникальными. Положим Организация1 хочет сделать свое расширение и придумала идентификатор Идент1. Как сделать так, чтобы другая Организация2 случайна не придумала для своих задач идентификатор тоже Идент1?
Надо добавить префикс организации. Тогда идентификатор будет Организация1.Идент1 и Организация2.Идент1.
Естественно нужен способ, чтобы этот префикс тоже был глобально уникальным. Доменное имя и является глобально уникальным. Вот и всё.
В России таки тоше пошел тренд на "цифровые следы" и конечно под ними стоит понимать не просто отметки в дневниках или в LMS. Если начинается борьба за качество образовательных ресурсов и качество обучение, нужен трекинг чтобы понять КАК проходили учебный ресурс.
xAPI этот трекинг и обеспечивает. А дальше можно использовать на что фантазии хватит (ну и квалификации).
Расскажу что xAPI дает при использовании с конструктором H5P.
Сам H5P не пишет в LRS xAPI события, но выплевывает их и надо просто каким-то своим кодом их собрать, записать и отобразить. У меня в электронной библиотеке ELiS для этого есть модуль интеграции H5P: https://elibsystem.ru/node/475.
Так вот о пользе: можно просто открыть трек взаимодействия пользователя с конкретным образовательным ресурсом и как-бы из-за плеча посмотреть, а чем пользователь занимался.
Это может быть полезно чтобы понять, как в реальности люди взаимодействуют с ресурсом, не занимаются ли перебором вариантов ответов, возвращаются ли к перерешиванию заданий, насколько быстро двигаются и т.д.
На рисунке выше слева ресурс, справа сессия взаимодействия с ним одного из пользователей, на которой видно как человек перебирает результаты решения задания на множественный выбор.
С помощью трекинга можно не только присмотреться к решению заданий, но и лучше понять как учащиеся с ресурсом взаимодействуют, чтобы его улучшить (не всегда известно, особенно если люди учатся только удаленно, в чем у них возникают проблемы).
Я согласен, что с точки зрения выбора интерфейсов для общих хранилок проблемы нет, что не измерили локальную производительность одиночного SSD.
Но мне кажется это в принципе должно быть интересно какой вклад вносит вот это вот вся сеть хранения в латентность и IOPS по сравнению с прямым подключением.
Клиент заведет тикет, баг исправят. Программист, устраняя баг из тикета, будет нести пользу бизнесу.
Здесь все-таки надо правильно акценты расставить, не что баги - это хорошо, не что плохой код - это хорошо, а что в оплачиваемое время работнику надо работать то, что от него работодатель хочет, а не то, что работнику кажется важным, а работодателю не важным.
Что хочет работодатель - доносит менеджер проекта или начальник, если такая иерархия.
А можете проверить еще локальную производительность SSD? Интересуют задержки, IOPS, чтобы понять на сколько увеличивают задержки и IOPS сеть и СХД.
Вопрос возник из-за графика сравнения SSD vs HDD, где производительность SSD при 4k на уровне 40 000 IOPS. Очевидно здесь запись идет на единственный SSD. А если этот SSD в сервер локально воткнуть и по той же методике в него что-то пописать, сколько получится?
Ну и методику бы описать, чем тестировали с какими параметрами.
Похожая история была на Drupal. Был сайт с Drupal и решено ему мобильную версию на React написать.
Правда был нюанс: некоторые модули пишут свой JS в футер и хидер и не было желания все такие модули переписывать, т.е. реактовый интерфейс надо было запускать вместе со всеми друпаловскими JS/CSS и первая загрузка приложения вышла заметно медленнее, чем без React.: https://elibsystem.ru/node/491
Связано также с тем, что реактивное приложение в начале грузит зависимые компоненты и лишь потом отрисовывает, в то время как при стандартном подходе браузер начинает отображать интерфейс сразу по ходу загрузки.
Результаты
Очередь 10, IOPS 5000, Вычисляем по формуле latency = QD/IOPS = 2 мс. А измеренная по бенчмарку 5-8 мс с большим среднеквадратичным отклонением.
Postgres там наверняка тестировали "стандартным" pgbench.
С малой глубиной ни о каких 1+ млн. IOPS или 7 ГБ/c не может быть и речи. Так что это не привычка, а маркетинг -)
Выполнил пример для Hetzner NVMe на Intel DC S3500 SATA, подключенным как JBOD через контроллер. Proxmox, ZFS, LXC, CentOS8.
fio --filename=/fio.test --size=20G --direct=1 --rw=randrw --bs=4k --ioengine=libaio --iodepth=8 --iodepth_batch_submit=8 --runtime=60 --numjobs=6 --time_based --group_reporting --name=iops-test-job --eta-newline=10Результат в 3 раза ниже, чем у вас:
latency 31 мкс, IOPS 10k, bw 40 MB/s
Если бы вместо LXC был KVM, еще бы в 1.5-2 раза упало бы все.
Правда конечно бы на актуальных SSD сравнить c SATA и NVMe. Но похоже что да, есть смысл в NVMe.
З.Ы. При использовании Proxmox ZFS выбирают за бесплатные снапшоты с локальных дисков для контейнеров, а не за супернадежность.
Зная IOPS можно узнать и пропускную способность, умножив IOPS на размер блока. 30 000 IOPS x 4K = 120 000 K/s. = 117 MB/s.
А вот как латентность вычислить из IOPS? Графики выше явно говорят, что зависимость не линейная, т.е. вычислить латентность из IOPS нельзя.
Вернее так, если у вас бенчмарк имеет глубину 1 и 1 очередь, то да, время за которое у вас выполнится одна операция и придет подтверждение ее выполнения и является латентностью по определению. Т.е. 1/(число IOPS) = время 1 операции.
По мере роста глубины и потоков у вас латентность становится больше среднего времени выполнения операций за некоторое время. Т.е. вычислять латентность при Q>1 и T>1 делением 1 на IOPS нельзя.
Вот для примера латентность на корпоративном SSD Intel вот отсюда.
Вот еще пример того же источника, что разные SSD могут себя сильно по разному вести при записи.
А это пример пользовательского SSD, у которого латентность 5 мс (как у HDD) уже при 25 тыс. IOPS.
Латентность - важная величина. NVMe для баз данных именно за нее и выбирают (NAND-то одинаковая и в SATA и в NVMe). Поэтому её стоит приводить в бенчмарках.
Все немного сложнее получается. Появляется дополнительный программный слой и дополнительный аппаратный (контроллер).
Только вчера читал тестирование PostgreSQL 2014 года и на SATA у них было что-то там 50 тыс. tps, а на NVMe 400 тыс. tps, а в RAM если диск держать 1500 тыс. tps.
Люди смотрят на такие бенчмарки и хотят, конечно, NVMe и почти x10 к работе базы.
Если там стоит аппаратный контроллер с writeback, есть вероятность, что все записанные данные уместились в его ОЗУ и это тест скорости ОЗУ контроллера.
1 ГБ - очень мало. Лучше файл делать больше.
NVMe вроде хвалят за низкую латентность. Если ядро часто переключает контекст и латентность переключения много больше NVMe, то подозреваю, что наоборот, разница между SATA SSD и NVMe будет труднее обнаружить.
Кстати, вот пример сравнения Baremetal https://elibsystem.ru/node/503 с Hyper-V, KVM на SATA SSD c древним контроллером, но и там довольно хорошо видна сильная зависимость производительности от гипервизора.
Вообще надо понять что тестировать-то хочется.
Абстрактную производительность NVMe? Производительность NVMe в Hyper-V в одиночной ВМ (не убивает ли оверхед Hyper-V низкую задержку NVMe)? Производительность NVMe при большом количестве ВМ, все из которых одновременно генерируют нагрузку по сравнению с SATA (качественное сравнение есть ли разница при большой нагрузке в условиях конкуренции кучи ВМ за CPU и NVMe)? Во всех трех случаях очевидно методика тестирования разная.
Более того, от того пишутся ли данные синхронно или последовательно тоже результаты бенчмарка зависят, а тут сюрприз, SSD часто нужны для баз данных, а РСУБД пишут часто последовательно (потому-что в журнал) малым количеством потоков с частыми fsync. Т.е. базы данных даже близко не выдают максимально возможные IOPS-ы на запись.
Дальше надо понимать, что NVMe хороши низкой задержкой. Но! Но когда 100500 ВМ генерируют параллельно нагрузку и утилизируют SSD в полку, общая пропускная способность конечно будет высокой (у SSD чем больше одновременных потоков - тем больше IOPS и мегабайт), но вот задержки начнут сильно нарастать, а в статье задержки вообще не представлены! Т.е. при миллионе IOPS задержки какие? Вот для примера про латентность от Intel:
Поэтому зная, что все зависит от всего (производительность от нагрузки случайная/последовательная, размера кластера, как часто fsync шлется, размера очереди, конкуренции за CPU множества ВМ, драйверов, ФС, гипервизора, writeback, способности ВМ читать из ОЗУ вместо диска из-за виртуализации и т.д.) надо, ну если хочется во всех этих аспектах посмотреть что происходит, делать не один тест, а на каждую из задач по тесту.
Естественно, синтетика с большим количеством очередей может совершенно не походить по профилю нагрузки на поведение баз данных. Так что логично поинтересоваться у клиентов какие базы гонять собираются и побенчмаркать базы на NVMe/SATA и посмотреть, есть ли разница. Естественно начинаются приколы, что SATA будет контроллер использовать и он тоже может и свои настройки иметь и задеркжи и т.д.
Итого: непростое это дело производительность дисковой подсистемы измерять!
Спасибо.
На чтение думаю это действительно хорошая производительность.
С записью сложнее. Запись в SSD в writeback-же работает и поэтому пока кеша хватает, производительность очень высокая, а задержки низкие. Тоже на уровне 100 мкс или меньше.
Соответственно, если сеть добавляет задержку в 100 мкс (0.1мс), то при собственной задержке 100 мкс и direct-записи это снижение производительности случайной записи в 2 раза. Если SSD latency 50 мкс, то снижение в 3 раза и т.д.
Что и видим на графике по отставанию записи от чтения для SSD.
Эм, народу интересно, но не солидно профессионалам пробелы в знаниях на публику озвучивать?)
Про URI все просто (это не URL в смысле location, а именно идентификаторы).
Положим нужен способ сделать идентификаторы, но такой, чтобы глобально они были уникальными. Положим Организация1 хочет сделать свое расширение и придумала идентификатор Идент1. Как сделать так, чтобы другая Организация2 случайна не придумала для своих задач идентификатор тоже Идент1?
Надо добавить префикс организации. Тогда идентификатор будет Организация1.Идент1 и Организация2.Идент1.
Естественно нужен способ, чтобы этот префикс тоже был глобально уникальным. Доменное имя и является глобально уникальным. Вот и всё.
Соглашусь с Максимом.
В России таки тоше пошел тренд на "цифровые следы" и конечно под ними стоит понимать не просто отметки в дневниках или в LMS. Если начинается борьба за качество образовательных ресурсов и качество обучение, нужен трекинг чтобы понять КАК проходили учебный ресурс.
xAPI этот трекинг и обеспечивает. А дальше можно использовать на что фантазии хватит (ну и квалификации).
Расскажу что xAPI дает при использовании с конструктором H5P.
Сам H5P не пишет в LRS xAPI события, но выплевывает их и надо просто каким-то своим кодом их собрать, записать и отобразить. У меня в электронной библиотеке ELiS для этого есть модуль интеграции H5P: https://elibsystem.ru/node/475.
Так вот о пользе: можно просто открыть трек взаимодействия пользователя с конкретным образовательным ресурсом и как-бы из-за плеча посмотреть, а чем пользователь занимался.
Это может быть полезно чтобы понять, как в реальности люди взаимодействуют с ресурсом, не занимаются ли перебором вариантов ответов, возвращаются ли к перерешиванию заданий, насколько быстро двигаются и т.д.
На рисунке выше слева ресурс, справа сессия взаимодействия с ним одного из пользователей, на которой видно как человек перебирает результаты решения задания на множественный выбор.
С помощью трекинга можно не только присмотреться к решению заданий, но и лучше понять как учащиеся с ресурсом взаимодействуют, чтобы его улучшить (не всегда известно, особенно если люди учатся только удаленно, в чем у них возникают проблемы).
А не знаю, на новом наверное.
Здесь видимо каждый о своём.
Проекты, в которых 3 ошибки - это много и повод отказаться от подрядчика - это какие-то микропроекты.
Это какой-то странный бизнес. В нем поди и тестировщиков нет, раз у программистов сразу идеальный код?)
Я согласен, что с точки зрения выбора интерфейсов для общих хранилок проблемы нет, что не измерили локальную производительность одиночного SSD.
Но мне кажется это в принципе должно быть интересно какой вклад вносит вот это вот вся сеть хранения в латентность и IOPS по сравнению с прямым подключением.
Клиент заведет тикет, баг исправят.
Программист, устраняя баг из тикета, будет нести пользу бизнесу.
Здесь все-таки надо правильно акценты расставить, не что баги - это хорошо, не что плохой код - это хорошо, а что в оплачиваемое время работнику надо работать то, что от него работодатель хочет, а не то, что работнику кажется важным, а работодателю не важным.
Что хочет работодатель - доносит менеджер проекта или начальник, если такая иерархия.
Спасибо за интересное тестирование!
А можете проверить еще локальную производительность SSD? Интересуют задержки, IOPS, чтобы понять на сколько увеличивают задержки и IOPS сеть и СХД.
Вопрос возник из-за графика сравнения SSD vs HDD, где производительность SSD при 4k на уровне 40 000 IOPS. Очевидно здесь запись идет на единственный SSD. А если этот SSD в сервер локально воткнуть и по той же методике в него что-то пописать, сколько получится?
Ну и методику бы описать, чем тестировали с какими параметрами.
Похожая история была на Drupal. Был сайт с Drupal и решено ему мобильную версию на React написать.
Правда был нюанс: некоторые модули пишут свой JS в футер и хидер и не было желания все такие модули переписывать, т.е. реактовый интерфейс надо было запускать вместе со всеми друпаловскими JS/CSS и первая загрузка приложения вышла заметно медленнее, чем без React.: https://elibsystem.ru/node/491
Связано также с тем, что реактивное приложение в начале грузит зависимые компоненты и лишь потом отрисовывает, в то время как при стандартном подходе браузер начинает отображать интерфейс сразу по ходу загрузки.
Сверху стандартное отображение, снизу с React.