Комментарии 104
Про 45GB — отформатируйте раздел NTFS с бОльшим размером сектора и проверьте ещё раз, помнится, при дефолтном размере в 4 Кбайт файл размером больше 16ТБ занимает больше 2^32 секторов и вызывает по меньшей мере один баг в windows backup, и пусть я лопух и у вас не терабайтные файлы, но никакой гарантии, что тест не зависит от размера логического сектора. Как вариант, сами NVMe имеют быстрый кэш в 32ГБ, а по факту туда SSD пихнули, типа и так сойдет. На интерес, было бы неплохо проверить скажем 1ТБ NVMe M.2 в материнке с такими же условиями, кто его знает, может, вообще уперлись в перегрев.
Апд: беглый поиск в гугле выдал, что использование native NVMe драйвера от Микрософт может приводить к «проблемам» (без описания), а также интересный тест github.com/microsoft/diskspd/issues/91 на файле размером 960ГБ, показывающий схожую, но при этом плавающую проблему с I/O. Попробуйте использовать драйвер NVMe-диска от Intel (если у вас Intel NVMe, я не в курсе пока ещё о совместимости дров на NVMe).
>Как вариант, сами NVMe имеют быстрый кэш в 32ГБ, а по факту туда SSD пихнули, типа и так сойдет.
Не хочу портить вашу стройную теорию, но NVMe - это спецификация, как SCSI и SATA. Поэтому никакой SSD туда не пихали, они все и так SSD и Flash память там одного типа независимо от конроллера и поддерживаемой спецификации.
Про кэш слегка некорректно выразился — «пихнули 32ГБ SLC-кэша а остальной объем TLC и контроллер медленный». Правда, даже в таком случае скорость не должна была провалиться ниже скорости работы с SSD, а источник провала надо искать в программах.
Как правило в накопителях корпоративного уровня кэши если и используются, то они не приводят к падению скорости. Это на домашних накопителях есть жесткая отсечка, когда скорость записи можно в разы упасть.
Сейчас SLC-кеши могут быть динамические. Пока диск первый раз не перезаписан, всё свободное пространство может быть SLC. Затем постепенно SLC может уменьшаться до некоторого порога, который в корпоративных дисках сильно больше домашних.
Если нужно совсем без SLC, то это Intel Optane.
Если нужно совсем без SLC, то это Intel Optane.
Не понял, это как? Диски корпоративные же все TLC и MLC.
Диск изначально весь SLC. По мере записи SLC меняется на TLC.
Поэтому SLC-кеш изначально объемом в весь диск, по мере записи SLC-кеш уменьшается до некоего уровня.
Поэтому пока первый раз такой диск полностью не запишешь, он будет более высокие скоростные характеристики показывать и выше надёжность.
Поэтому SLC-кеш изначально объемом в весь диск, по мере записи SLC-кеш уменьшается до некоего уровня.
Поэтому пока первый раз такой диск полностью не запишешь, он будет более высокие скоростные характеристики показывать и выше надёжность.
И где можно подтверждение подобного прочитать? Я первый раз слышу про такой механизм, ни один производитель такого не упоминал. Гугл выдает какие-то исследования и теоретезирования на форумах, не более.
Зачем это вообще делать, если производители просто добавляют побольше резервного пространства скрытого и именно за счет него получают нужный уровень DWPD. Порой позволяя юзеру менять этот резерв самостоятельно. Упомянутый в статье P4610 это обычный TLC диск с большим резервом, от чего у него такие странные паспортные объемы.
Зачем это вообще делать, если производители просто добавляют побольше резервного пространства скрытого и именно за счет него получают нужный уровень DWPD. Порой позволяя юзеру менять этот резерв самостоятельно. Упомянутый в статье P4610 это обычный TLC диск с большим резервом, от чего у него такие странные паспортные объемы.
blocksandfiles.com/2019/11/25/intel-dynamic-cache-665p-ssd-goes-faster-lasts-longer
1. SLC работает на запись быстрее MLC/TLC/QLC;
2. У SLC меньше износ.
1. SLC работает на запись быстрее MLC/TLC/QLC;
2. У SLC меньше износ.
Это все очевидно. SLC кэш не случайно добавляют в диски среднего ценового сегмента.
А статья вообще не про это:
1. самое главное, тут речь о домашнем QLC диске, где без SLC кэша просто невозможно, ибо флэш чертовски медленный
2. идея с переменных кэшем здесь в возможности балансирования размера кэша и числа резервных ячеек. Чем больше занят диск, тем больше нагрузка на флэш оставшийся. Логично пожертвовать кэшем в этих условиях. Это не про скорость и не про свободное пространство.
Поэтому непонятно, зачем это нужно диску корпоративного уровня, у которого зарезервирован приличный кусок флэша и так, а контроллер мощный, чтобы держать постоянную скорость записи без всяких кэшей. p4610 1.6ТБ из статьи скорее всего имеет в резерве 400ГБ флэша.
А статья вообще не про это:
1. самое главное, тут речь о домашнем QLC диске, где без SLC кэша просто невозможно, ибо флэш чертовски медленный
2. идея с переменных кэшем здесь в возможности балансирования размера кэша и числа резервных ячеек. Чем больше занят диск, тем больше нагрузка на флэш оставшийся. Логично пожертвовать кэшем в этих условиях. Это не про скорость и не про свободное пространство.
Поэтому непонятно, зачем это нужно диску корпоративного уровня, у которого зарезервирован приличный кусок флэша и так, а контроллер мощный, чтобы держать постоянную скорость записи без всяких кэшей. p4610 1.6ТБ из статьи скорее всего имеет в резерве 400ГБ флэша.
Ну да, я вверху и писал, P4610 это обычный TLC диск. И чего? И думаю никакого SLC кэша у него внутри нет. Ни переменного, ни постоянного.
Думаю, что есть.
Проверьте: запишите последовательно всю доступную ёмкость (2 раза) и посмотрите на график скорости записи.
Проверьте: запишите последовательно всю доступную ёмкость (2 раза) и посмотрите на график скорости записи.
Проверять мне не на чем. Практика показывает, что корпоративного уровня диски кэшей не имеют. Это также отражают и спеки — p4610 со своими 200к IOPS на запись в 2 раза проигрывает дешманскому 970 evo. У последнего как раз SLC кэш есть. Еще круче p5600, топовый pcie4 диск — у него запись еще меньше, 118к. Да и это просто абсурд, когда диск для высоких нагрузок на запись будет проседать по скорости. Кому он нафиг сдался такой? Поэтому кэши это удел дешевых дисков для домашних нагрузок, где всем пофиг будет на просадку скорости. А в корпоративном сегменте даже QLC диски без кэша делают — как вот P4320, от чего на запись он может выдать всего 36к IOPS.
Действительно в корпоративных дисках пиарится именно устойчивая скорость записи. Означает ли это отсутствие кешей?
Что касается спеков, Intel как ответственная компания, если бы SLC и использовался, конечно бы написала не пиковую скорость, а устоявшуюся.
Что касается спеков, Intel как ответственная компания, если бы SLC и использовался, конечно бы написала не пиковую скорость, а устоявшуюся.
Означает ли это отсутствие кешей?
Да, потому что при заполнении кэша скорость падает. Это базовый закон информатики. В домашнем сегменте тоже кстати есть образец диска с устойчивой скоростью записи — 970 pro. Именно благодаря отсутствию SLC кэша.
Что касается спеков, Intel как ответственная компания, если бы SLC и использовался, конечно бы написала не пиковую скорость, а устоявшуюся.
Опять же, кому он такой сдался? Если у меня база данных миллион транзакций в секунду гоняет и внезапно эта цифра падает до 500тыс, то мне как-то до пофиг будет, что интел заявил скорость именно 500тыс. Мне от диска стабильная скорость нужна, а не гадать, в какой момент у него там кэш кончится.
Более того, сейчас начинается переход на SSD диски, в которых даже резервной области больше нет. Так называемые ZNS диски. Все потому, что на этом рынке людям не охота платить за резервную область, а заодно страдать от сборки мусора, которая непредсказуемо влияет на скорость диска. Поэтому в ZNS ни резерва, ни сборки мусора, ни тем более кэшей каких-то.
В паспорте написано 500 тыс. IOPS. По факту некоторое время может 1 млн. IOPS. Естественно, те кто хотят знать на что способен диск проведут нагрузочное тестирование на своей нагрузке и своими глазами увидят когда произойдет переход на паспортные 500 тыс.
Не понимаю требования: «По паспорту 500 тыс. IOPS и это плохо, что некоторое время диск работает в 1 млн. IOPS, хочу чтоб всегда работал в 500 тыс. IOPS».
По ZNS несколько иное написано, что неиспользуемые блоки есть, просто они все равно видны. Это не тоже самое, что полное отсутствие неиспользуемых блоков. Да и как себя файловая система должна вести, когда часть блоков из строя выйдет? Сама собой уменьшиться? Занулять всё, что в такие блоки запишут?
Не понимаю требования: «По паспорту 500 тыс. IOPS и это плохо, что некоторое время диск работает в 1 млн. IOPS, хочу чтоб всегда работал в 500 тыс. IOPS».
По ZNS несколько иное написано, что неиспользуемые блоки есть, просто они все равно видны. Это не тоже самое, что полное отсутствие неиспользуемых блоков. Да и как себя файловая система должна вести, когда часть блоков из строя выйдет? Сама собой уменьшиться? Занулять всё, что в такие блоки запишут?
когда произойдет переход на паспортные 500 тыс.
Не увидят. Они увидят переменную скорость и выкинут этот диск на помойку. При реальной нагрузке отсечка просадки скорости будет происходить в случайные моменты времени, потому что ссд это черный ящик. По той же причине отказываются от сборки мусора в ссд — это непредсказуемый процесс.
Не понимаю требования: «По паспорту 500 тыс. IOPS и это плохо, что некоторое время диск работает в 1 млн. IOPS, хочу чтоб всегда работал в 500 тыс. IOPS».
А я понимаю. Зачем мне диск, у которого непредсказуемая скорость? Не нужен он мне такой. Либо пусть 500тыс всегда выдает, либо я пойду к другому вендору. Предсказуемое поведение всегда лучше непредсказуемого, даже если первое чуть хуже (латентность или пропускная способность, не важно). Факт остается фактом, в корпоративном сегменте кэшей нет.
По ZNS несколько иное написано, что неиспользуемые блоки есть, просто они все равно видны. Это не тоже самое, что полное отсутствие неиспользуемых блоков. Да и как себя файловая система должна вести, когда часть блоков из строя выйдет? Сама собой уменьшиться? Занулять всё, что в такие блоки запишут?
Это зависит от производителя, сколько резерва ему надо. В предельном случае, вообще нисколько. У ZNS как правило не будет файловой системы. Можно лишь придумать костыли для эмуляции, но это нужно лишь для легаси. Да, часть блоков выйдет из строя — вся зона будет помечена мертвой. Как с этим поступать дело приложения. Диск минимум задач на себя берет и более не является черным ящиком, который хер знает что внутри творит.
Это кому нужны такие диски, у которых зоны могут прийти битыми буквально с фабрики и они могут грохнуться на следующий день эксплуатации?
Я здесь вижу все-таки другую историю: один физический SSD делится на несколько логических и админ может сам выбирать уровень резервирования, там где записи много будет — оставляет резерв побольше (просто делая раздел поменьше), а там где записи будет мало, выбирает резерв поменьше.
А сейчас резерв выбирают производители и не всегда это удобно.
Ну может я и не прав, конечно.
Я здесь вижу все-таки другую историю: один физический SSD делится на несколько логических и админ может сам выбирать уровень резервирования, там где записи много будет — оставляет резерв побольше (просто делая раздел поменьше), а там где записи будет мало, выбирает резерв поменьше.
А сейчас резерв выбирают производители и не всегда это удобно.
Ну может я и не прав, конечно.
Это не будет работать так просто по одной простой причине — зоны в ZNS дисках можно писывать только в конец. Более того, в самом эффективном режиме работы nvme командой zone append приложение даже не знает, куда оно в зоне пишет — адрес указателя диск сам вернет после записи. Сама запись не содержит LBA, и посылаться они будут в кучу потоков параллельно. Как только указатель дошел до конца зоны, она блокируется и переходит в read-only режим.
Идея здесь в другом. У нас есть куча приложений, которым нафиг не нужная файловая система. Базы данных в основном, вроде rockdb или ceph (он уже работает с дисками без файловой системы). Они хранят sstable на диске, которые не меняются после записи. Есть compaction операция, которая склеивает несколько sstable в одну, а старые удаляет. Это идеально ложится на append-only семантику ZNS дисков. А при compaction старые зоны просто очищаются полностью, сбрасывают указатель в начало зоны и готовы к работе дальше.
Очевидно, что навернуть сверху этого обычную файловую систему так просто не получится. Есть попытки какие-то, но это очевидные костыли. Уже есть примитивная файловая система, которая каждую зону предоставляет как файл, в который можно писать в конец только. Опять же, костыли и легаси. Нормальные приложения будут писать конкретно под ZNS диски, чтобы они работали с зонами напрямую.
Идея здесь в другом. У нас есть куча приложений, которым нафиг не нужная файловая система. Базы данных в основном, вроде rockdb или ceph (он уже работает с дисками без файловой системы). Они хранят sstable на диске, которые не меняются после записи. Есть compaction операция, которая склеивает несколько sstable в одну, а старые удаляет. Это идеально ложится на append-only семантику ZNS дисков. А при compaction старые зоны просто очищаются полностью, сбрасывают указатель в начало зоны и готовы к работе дальше.
Очевидно, что навернуть сверху этого обычную файловую систему так просто не получится. Есть попытки какие-то, но это очевидные костыли. Уже есть примитивная файловая система, которая каждую зону предоставляет как файл, в который можно писать в конец только. Опять же, костыли и легаси. Нормальные приложения будут писать конкретно под ZNS диски, чтобы они работали с зонами напрямую.
Это технология Силикона контроллера. Корректнее диск пишется как SLC. По биту на ячейку. По мере заполнения ячейки записываются добавочно и становятся MLC.
В одном и том же гипервизоре на разных гостевых ОС было не отличить, SSD внутри сервера или NVMe.
При этом если не брать в расчёт 45Гб файл — разница в 4-10 раз в пользу NVMe. Да и суть NVMe не только в бОльшем кол-ве IO, но в более низких задержках, которые вы не отразили в сводных таблицах. А голые IO без задержек — не показатель. Как и отсутствие профиля нагрузки.
Да и что за тест в 10/45Гб??? Берите сотнями или тысячами гигов, с записью, перезаписью и тд, тогда будет показательно, а иначе — только воздух портить, что NVMe ни лучше, чем SSD
Первое, что мы узнали, — что NVMe не объединяется в RAID нормальными способами, то есть в итоге надёжных дисков ждать не стоит.
Пдождите, есть же аппаратные контроллеры, где-то рядом упоминался тот же MegaRAID 9460-8i — до 24 устройств NVMe
А скорость работы с ним какая? Может он не умеет нормально в NVMe-спецификацию и диски окажутся урезаны до SAS-скорости со стороны рейд-массива. («Кстати» вытер, хотя для HP «i» это намамные контроллеры)
В этом случае мы будем ограничены пропускной способностью PCI-E шины в которую воткнут RAID контроллер. Хотелось бы задействовать пропускную способность сразу нескольких шин.
Шина максимум 16х, накопители 4х. 4 накопителя уже отлично ползут на максималках.
Не думаю. По IOPS как минимум не вытянет.
Товарищи минусующие знают что-то, чего я не знаю? Выше речь про рейд контроллер, в который собрались втыкать 4 nvme диска. Это несколько миллионов IOPS. Есть вообще контроллеры на рынке, которые на такое способны?
Шина максимум 16х, накопители 4х. 4 накопителя уже отлично ползут на максималках.
Если речь о 4-х NVMe дисках, воткнутых в PCe 16x, то всё же вам RAID-контролер не нужен, каждый накопитель будет использовать 4 линии монопольно, RAID программный и просадка по IOPS может быть только по какой-то иной причине (недостаток ресурсов CPU, ошибка в ПО и т.д.).
1. 16х слот ограничит скорость в любом случае до 4 дисков
2. Еще раньше этого контроллер задохнется
Судя по спеке, это обычный SAS контроллер, которому присобачил сердес для pcie. Дай бог оно миллион иопсов вытянет. Мы и на SATA SSD запросто упирались в пределы даже тупого HBA.
SSD (не важно даже, SATA, SAS, NVMe) диски и аппаратный рейд вещи несовместимые, только софтовый с минимальным вмешательством ОС. Скорости огромные. Собственно, аппаратный рейд сам по себе скорее мертв вне зависимости от интерфейса.
2. Еще раньше этого контроллер задохнется
Судя по спеке, это обычный SAS контроллер, которому присобачил сердес для pcie. Дай бог оно миллион иопсов вытянет. Мы и на SATA SSD запросто упирались в пределы даже тупого HBA.
SSD (не важно даже, SATA, SAS, NVMe) диски и аппаратный рейд вещи несовместимые, только софтовый с минимальным вмешательством ОС. Скорости огромные. Собственно, аппаратный рейд сам по себе скорее мертв вне зависимости от интерфейса.
Запустил тест 4кб 30%wr на Intel 660p, получил 102551 IOPS на 50Гб файле, и 102728 IOPS на 10Гб.
Диск, на котором вы провели тест относится к пользовательскому сегменту. Мы же используем серверные решения, которые отличаются большей надежностью. Обратите внимание, что тесты запускались внутри виртуальной машины.
Ни первое, ни второе не объясняет разницы на два порядка между одинаковыми по сути тестами. У вас сохранились отчёты, которые генерирует diskspd?
Вот ссылка на архив, с парой отчётов diskspd с результатами, которые близки к указанным в статье.
А есть нормальные тесты: тесты, запускаемые с хоста; тесты с линейным и случайным чтением и записью, блоками разного размера, и тестовым объёмом хотя бы в 50 Гб, что бы все SLC/DDR-кэши накопителей проскочить? Пока что вы фактически померили «hdparm'ом» NVMe-накопители, получили погоду на Марсе. А после рассказали опять сказку про то какие плохие High-CPU, потому что вы их охладить не смогли. Статье достойное имя: «Как мы не смогли» :-)
есть нормальные тесты: тесты, запускаемые с хоста
Мы сосредоточились на тестах, запускаемых с виртуальных машин, т. к. наша основная цель предоставить высокую производительность нашим клиентам. Как показывает практика, гипервизор вносит свою роль в производительность дисковой системы под виртуальной машиной.
рассказали опять сказку про то какие плохие High-CPU, потому что вы их охладить не смогли
Тут дело не в том, что смогли или не смогли. В настоящее время не существует решений корпоративного класса для HI-CPU, а десктопное железо мы не используем.
Кстати про диски. Судя по всему, вы ставили Intel в формате U2.
Сами по себе enterprise диски бывают оптимизированные для по крайней мере 3 профилей нагрузки — Read, Write и Mixed use, чаще всего для первого и последнего. Какие использовали вы? Правильно ли я понял, что Intel?
Кстати, у них в D5 серии честно написано (ноли не забыл):
Random Read (100% Span) — 800000 IOPS
Random Write (100% Span)- 6100 IOPS
А вот у D7 уже лучше:
Random Read (100% Span) — 700000 IOPS
Random Write (100% Span) — 170000 IOPS
По сути, D5 это read optimized, а D7 — mixed use.
Как настраивали диски для виртуалок? Пробрасывали само устройство? Enterprise диски часто умеют в namespaces и фактически могут «аппаратно виртуализироваться», прикидываясь независимыми устройствами (то самое /dev/nvme1n0, где 0 — на самом деле namespace). Или LVM?
Может вы вообще просто виртуальный диск файлом создали на NVME SSD, вы к сожалению не рассказываете, а это прям совсем разные кейсы.
Что касается процессоров, то в общем-то большинство хостеров (по крайней мере иностранных) не скрывает, что у них стоит десктопное железо в конфигурациях с высокой тактовой частотой. Тут скорее речь же про single thread performance, так?
В этом случае да, single thread в серверном железе уже давно отстает, но тут есть интересная альтернатива посередине — AMD Threadripper Pro. ECC, широкие внешние шины, PCIe4, более-менее вменяемый теплопакет, вкусная для серверного железа цена и скорость в single/multithread thread выше, чем у Xeon Gold 6244 и аналогов (сильно выше).
Хотя есть еще конечно Epyc 74F3 какой-нибудь, который не сильно медленнее в single core.
Сами по себе enterprise диски бывают оптимизированные для по крайней мере 3 профилей нагрузки — Read, Write и Mixed use, чаще всего для первого и последнего. Какие использовали вы? Правильно ли я понял, что Intel?
Кстати, у них в D5 серии честно написано (ноли не забыл):
Random Read (100% Span) — 800000 IOPS
Random Write (100% Span)- 6100 IOPS
А вот у D7 уже лучше:
Random Read (100% Span) — 700000 IOPS
Random Write (100% Span) — 170000 IOPS
По сути, D5 это read optimized, а D7 — mixed use.
Как настраивали диски для виртуалок? Пробрасывали само устройство? Enterprise диски часто умеют в namespaces и фактически могут «аппаратно виртуализироваться», прикидываясь независимыми устройствами (то самое /dev/nvme1n0, где 0 — на самом деле namespace). Или LVM?
Может вы вообще просто виртуальный диск файлом создали на NVME SSD, вы к сожалению не рассказываете, а это прям совсем разные кейсы.
Что касается процессоров, то в общем-то большинство хостеров (по крайней мере иностранных) не скрывает, что у них стоит десктопное железо в конфигурациях с высокой тактовой частотой. Тут скорее речь же про single thread performance, так?
В этом случае да, single thread в серверном железе уже давно отстает, но тут есть интересная альтернатива посередине — AMD Threadripper Pro. ECC, широкие внешние шины, PCIe4, более-менее вменяемый теплопакет, вкусная для серверного железа цена и скорость в single/multithread thread выше, чем у Xeon Gold 6244 и аналогов (сильно выше).
Хотя есть еще конечно Epyc 74F3 какой-нибудь, который не сильно медленнее в single core.
В статья же есть модель. P4610 оптимизированы для write-intensive нагрузок.
Да, действительно, пропустил. Спасибо!
Ну, тогда ничего кроме софотовых проблем и не остается.
Ну, тогда ничего кроме софотовых проблем и не остается.
С софтом в виртуалках вообще непросто. Несколько лет назад была ситуация, когда софт на примерно одинаковых виртуалках у разных провайдеров работал очень по разному, в 2 или в три раза быстрее (без использования дисков, все в памяти). Тюнинг виртуалок ничего не дал, как результат — переехали к другому облачному провайдеру.
Intel VROC (Virtual RAID on CPU)
Пробовали в различных вариантах. Производительность всегда оказывалась хуже, чем без RAID'a.
Можете поделиться какими-нибудь оценками по VROC? На сколько % проседает рейд1, например?
VROC — это программно-аппаратная реализация. В Linux будет обслуживаться через тот же mdadm. Результаты будут как у mdadm. Из плюсов только помигать индикаторами и загрузиться с рейда на Windows. RAID1 поведёт себя предсказуемо: просядет на мелких блоках, выровняется на средних, при случайном чтение с 8к и выше будет расти скорость пока не достигнет удвоенной скорости одного накопителя на блоках в 1М.
Intel SSD DC P4610 Series 1.6TB, 2.5in PCIe 3.1 x4, 3D2, TLC — не слишком ли много маркетинга в скорости этих дисков?
Возьмите нормальный Intel Optane, например SSD-накопитель Intel Optane DC серии P5800X и протестируйте
Возьмите нормальный Intel Optane, например SSD-накопитель Intel Optane DC серии P5800X и протестируйте
Это действительно потенциально интересный тест — посмотреть какой прирост производительности дадут диски более высокого класса. Но нужно понимать, что это диски более высокого ценового сегмента и их использование может быть ограничено финансовыми соображениями.
С чего вдруг? Это диски для интенсивной записи с огромным ресурсом под базы данных. Интеловские диски еще не самые быстрые будут.
При этом из-под гостевой ОС видно производительность 3,6 вместо 4,5 в бусте.
То, что там не видно, не означает, что там нет буста. Бенчмарк какой-нибудь прогоните с выключенным и включённым бустом, например, 7-zip, и увидите разницу
Это хорошо при пиках на десктопе (но не в играх)
Почему вы так думаете? От повышения частоты хорошо всем, кто использует процессор, в т.ч. играм
но очень плохо для сервера под нагрузкой с несколькими клиентами
Почему?
В любимой игре вы наверняка захотите чтобы у вас была высокая производительность в течение нескольких часов непрерывно, а не только в моменты, когда у процессора включается Turbo Boost. Примерно тоже самое и у сервера - нужно чтобы у виртуальных машин была возможность в любой момент получить высокую долю CPU, а не только в моменты когда доступен Turbo Boost.
В любимой игре я хочу максимальный фреймрейт, причём не средний, а 1% и 0.1% (худшие моменты), но речь сейчас не про это.
Вот например на картинке в последних шести столбиках указаны частоты процессоров Intel 2017 года (у всех современных аналогично) при нагрузка на 1, 2, 3, ..., 6 ядер.
Производитель исходит из того, что бюджет на тепловую мощность можно потратить весь на одно ядро, сильно повысив там напряжение и соответственно потолок частоты, а можно на два, повысив чуть ниже, и так далее. Базовая частота, которая Base на картинке, это такая, на которой при нагрузке на все ядра потребление будет такое, как указано в столбике TDP.
Вы про оверпровиженинг слышали? Можно конечно зарезервировать за виртуальными машинами весь CPU, хотя так никто не делает, потому что это дорого. Тогда просто берите по табличке частоты при нагрузке на все ядра
Вот например на картинке в последних шести столбиках указаны частоты процессоров Intel 2017 года (у всех современных аналогично) при нагрузка на 1, 2, 3, ..., 6 ядер.
Производитель исходит из того, что бюджет на тепловую мощность можно потратить весь на одно ядро, сильно повысив там напряжение и соответственно потолок частоты, а можно на два, повысив чуть ниже, и так далее. Базовая частота, которая Base на картинке, это такая, на которой при нагрузке на все ядра потребление будет такое, как указано в столбике TDP.
Примерно тоже самое и у сервера — нужно чтобы у виртуальных машин была возможность в любой момент получить высокую долю CPU
Вы про оверпровиженинг слышали? Можно конечно зарезервировать за виртуальными машинами весь CPU, хотя так никто не делает, потому что это дорого. Тогда просто берите по табличке частоты при нагрузке на все ядра
О, наконец то хостер на Хабре пишет про хостинг! Уважуха.
Спасибо! Если хотите почитать еще про наш хостинг, это можно сделать здесь.
Про raid0 с nvme скажу вот что: 2 года назад собирал 6 дисков в рейд на одном pci-e слотет4 и 2 на мамке. Скорости чтения-записи около 20гб/сек. Собирал на мамке msi x399 creation. Сейчас под чиа стоят пара собранных в рейд0 дисков seagate firecuda 520. Скорость 10-11гб/сек, f2fs. Я предполагаю, что кто-то там у вас не посчитал pci-e линии). Ещё нужно форматировать правильно, и правильно указывать stripe size в mdadm, имхо по дефолту скорости рили выходят ниже, чем одного диска)
Чето статья совсем каким-то зеленым админом написана. Не надо распространять путаницу со сравнением nvme и ssd. Первое это протокол (да еще и не привязанный к физическому интерфейсу). Второе это тип диска. SSD может быть sata, sas, nvme.
Все прекрасно объединяется. Берете софтварный рейд типа mdraid и вперед.
Что это за поток сознания? Какие шины? Шина одна, у нее есть число линий. Покуда этих линий достаточно, диски будут работать настолько параллельно, насколько могут. Проблемы начинаются с добавлением pcie свитчей и всяких других контроллеров. Nvme диски подключаются напрямую к процессору и только так достигают своих скоростей. Как раз такие никакие контроллеры не нужны, от них будет только хуже.
Серверный рынок сплошь на m2. Просто используют их как загрузочные диски.
Это самое стандартное для них название. Вся суть nvme заключается в предоставлении диском кучи независимых очередей команд, в которые надо пихать как можно больше всего и ни о чем не думать. Как только ОС пытается умничать, то скорость падает.
Чего? Турбобуст постоянно в работе. Более того, интел позволяет даже загружать в процессор профили для различных типов нагрузок начиная с cascade lake.
А по тестам, я думаю их точность соответствуют общему техническому уровню статьи. Проблема явно не в диске или его протоколе.
Первое, что мы узнали, — что NVMe не объединяется в RAID нормальными способами
Все прекрасно объединяется. Берете софтварный рейд типа mdraid и вперед.
Грубо говоря, когда мы используем RAID, мы его включаем в одну PCIe-шину и мы ограничены этой PCI Еxpress, и только несколько дисков можем распараллелить по разным шинам. Нужны контроллеры.
Что это за поток сознания? Какие шины? Шина одна, у нее есть число линий. Покуда этих линий достаточно, диски будут работать настолько параллельно, насколько могут. Проблемы начинаются с добавлением pcie свитчей и всяких других контроллеров. Nvme диски подключаются напрямую к процессору и только так достигают своих скоростей. Как раз такие никакие контроллеры не нужны, от них будет только хуже.
M2 чаще используют в десктопах
Серверный рынок сплошь на m2. Просто используют их как загрузочные диски.
Более того, в CrystalDiskMark этот параметр называется Queue, хотя очередью это можно назвать с некоторой натяжкой.
Это самое стандартное для них название. Вся суть nvme заключается в предоставлении диском кучи независимых очередей команд, в которые надо пихать как можно больше всего и ни о чем не думать. Как только ОС пытается умничать, то скорость падает.
То есть турбобуст не врубается на сервере почти никогда.
Чего? Турбобуст постоянно в работе. Более того, интел позволяет даже загружать в процессор профили для различных типов нагрузок начиная с cascade lake.
А по тестам, я думаю их точность соответствуют общему техническому уровню статьи. Проблема явно не в диске или его протоколе.
Не надо распространять путаницу со сравнением nvme и ssd. Первое это протокол (да еще и не привязанный к физическому интерфейсу). Второе это тип диска.
В личном кабинете многих провайдеров при заказе сервера есть выбор NVME либо SSD. Под NVME подразумевается NVME SSD. Мы в статье как раз и тестируем NVME SSD. Когда пользователь выбирает NVME диск, то цена почти всегда становится несколько больше. Согласитесь, что если пользователь платит больше, то он ожидает некоторого прироста производительности, за счет нового протокола. Мы в данной статье и пытаемся этот прирост оценить.
Серверный рынок сплошь на m2. Просто используют их как загрузочные диски.
Мы как хостинг провайдер, в первую очередь оцениваем возможность предоставления конечному клиенту.
Вся суть nvme заключается в предоставлении диском кучи независимых очередей команд, в которые надо пихать как можно больше всего и ни о чем не думать. Как только ОС пытается умничать, то скорость падает.
Тоже так думали, что разработчику конечного ПО «можно ни о чем не думать», чтобы получить преимущество от NVME, пока не посмотрели исходный код diskspd. Далеко не все ПО опирается на асинхронные вызовы.
В личном кабинете многих провайдеров при заказе сервера есть выбор NVME либо SSD. Под NVME подразумевается NVME SSD. Мы в статье как раз и тестируем NVME SSD. Когда пользователь выбирает NVME диск, то цена почти всегда становится несколько больше. Согласитесь, что если пользователь платит больше, то он ожидает некоторого прироста производительности, за счет нового протокола. Мы в данной статье и пытаемся этот прирост оценить.
К чему это все? Вы пишите техническую статью, так пользуйтесь правильными терминами. То, что личные кабинеты добавляют путаницы, не повод за ними повторять. Nvme SSD это такой же SSD как любой другой.
Тоже так думали, что разработчику конечного ПО «можно ни о чем не думать», чтобы получить преимущество от NVME, пока не посмотрели исходный код diskspd. Далеко не все ПО опирается на асинхронные вызовы.
Под «не думать» подразумевалось другое. Для nvme дисков всегда отключаются любые планировщики IO в ядре ОС. Они приводят только к существенному падению скорости. Nvme оптимизирован для того, что команды посылаются во множество потоков в произвольном порядке и так же в произвольном порядке возвращаются ответы. Все остальное это головная боль контроллера накопителя, который с этим намного лучше справится.
Вам пытаются указать, что во втором случае корректно писать «sata ssd», а не просто «ssd».
Тараканы плакали... и продолжали использовать RAID с гипервизорами... Зачем? Взяли бы ceph, набили его чем нашли, и горя бы не знали и zip можно купить хоть за углом...
У цефа оверхед еще больше чем аппартного рейда и вообще цеф изначальро объектное хранилище и блочные диски вуртуалок на нем это еще плюс к оверхеду. В канале цефа была сылка на эксперимент где на самолетному конфиге из nvme не смогли выжать больше чем из декстопного ссд. В общем цеф это про много и надежно, но не очень быстро.
Никакое он не изначально объектное хранилище. У него архитектура, что он все на небольшие блоки делит, но делалось это для достижения нужных им качеств в плане надежности и масштабируемости. Vsan у VMWare вон тоже «объектное хранилище» внутри, хотя создан для виртуалок.
А про nvme, у кого-то руки кривые. Есть reference конфигурации от вендоров, где сеф спокойно миллионы ипсов гоняет на 5 серверах. Понятно, что оверхеда дофига. На то она и распределенная файловая система.
А про nvme, у кого-то руки кривые. Есть reference конфигурации от вендоров, где сеф спокойно миллионы ипсов гоняет на 5 серверах. Понятно, что оверхеда дофига. На то она и распределенная файловая система.
Это разные предложения вообще. Предложение клиенту дедика, или виртуалки в облаке или VPS, это вообще разные ценовые предложения. Здесь видимо рассматривают услугу дедика или vps.
Возвращать её через ErrorCode процесса неудачная идея. Например, если процесс завершится с ошибкой по какой-то другой причине, то код ошибки будет просто отображён в результате тестирования.
Формально говоря, такой штуки как ErrorCode — нет. Есть Exit Code, который может означать разное. Некоторые программы используют его для возврата кодов ошибок. Что касается данного случая — ну, если они изменили код diskspd (а вы выяснили, что они это сделали), то они могли и гарантировать нужное им использование Exit Code. Тут можно рассуждать о красоте архитектуры этого всего, но нельзя сделать однозначного вывода, что в коде есть баг.
Странные вообще-то методики тестирования. Начали с предположения, что NVMe могут как-то помочь Битриксу и 1С. Ну, взяли бы и потестировали Битрикс и 1С. Неужто за столько лет их существования у них нет performance тестов? Та даже если и нет — можно просто взять какой-нибудь обще-системный профайлер (тот же WPR) и запустить под какой-нибудь нагрузкой на сервере с SSD и с NVMe. Потом почитать логи, посмотреть графики. Тайминги I/O в них хорошо видны. Продавали бы потом клиентам не «вот видите, у нас тут бажный искусственный тест показал… ничего», а «вот, на графике I/O при такой-то нагрузке Битрикса мы видим х% разницы для NVMe». Было бы предметнее.
Все врут — факт. Особенно рекламы всяких там хостингов.
NVMe = SSD, зачем почти все выделяют NVMe в какой-то особенно быстрый класс? Если это не Optane/3dxpoint, то выделяться там нечему.
Внутри вашей P4610 TLC ячейки скорей всего даже хуже чем в ваших же «просто SSD» (MLC скорей всего). И лишь благодаря контроллеру и лишь в большой глубине очереди можно увидеть прирост скорости. В 1 поток отличий от SATA SSD практически не будет, все упирается в скорость самих ячеек. Это примерно как SAS и SATA HDD — да, у SAS есть преимущества и в каких-то ситуациях они заметны будут, но в большинстве случаев ведь «под капотом» все тот же медленный HDD. Только радикальная смена основы диска позволяет полностью раскрыться новому интерфейсу.
А они еще и в PCIe x4 лезут с этими своими TLC/QLC… показывая невероятные тысячи мб/с… в тесте на объеме 1гб и пустом новом диске.
Soft RAID легко делается и нормально работает и под windows/linux и на m.2/u.2.
Другой вопрос что подключать диски нужно не как-попало, а смотреть разводку pcie линий на материнке. Может к x4 слоту подходить 2 или 1 линия всего и она может идти в CPU, а может в PCH. И запросто может получиться, что втыкают бездумно в соседние x4 слота, из которых один x4 идет в CPU, а второй x2 в PCH… и потом удивляются результатам странным.
Также, как верно заметили, Xeon'ов на 4.5ГГц полно, правда они все для однопроцессорных систем, что скорей всего не подходит продавцам VPS'ок, где нужно выжимать максимальное количество ядер с сервера.
Другое дело что далеко не везде их (xeon'ы, которые могут 4.5ггц и выше) используют на полную. Нередко на хостингах вижу процессоры работающие на базовых или даже ниже частотах. Но можно же их держать постоянно в режиме между turbo (без большой нагрузки) и all-core-turbo (под нагрузкой), не давая проваливаться до базовой или даже ниже.
NVMe = SSD, зачем почти все выделяют NVMe в какой-то особенно быстрый класс? Если это не Optane/3dxpoint, то выделяться там нечему.
Внутри вашей P4610 TLC ячейки скорей всего даже хуже чем в ваших же «просто SSD» (MLC скорей всего). И лишь благодаря контроллеру и лишь в большой глубине очереди можно увидеть прирост скорости. В 1 поток отличий от SATA SSD практически не будет, все упирается в скорость самих ячеек. Это примерно как SAS и SATA HDD — да, у SAS есть преимущества и в каких-то ситуациях они заметны будут, но в большинстве случаев ведь «под капотом» все тот же медленный HDD. Только радикальная смена основы диска позволяет полностью раскрыться новому интерфейсу.
А они еще и в PCIe x4 лезут с этими своими TLC/QLC… показывая невероятные тысячи мб/с… в тесте на объеме 1гб и пустом новом диске.
Soft RAID легко делается и нормально работает и под windows/linux и на m.2/u.2.
Другой вопрос что подключать диски нужно не как-попало, а смотреть разводку pcie линий на материнке. Может к x4 слоту подходить 2 или 1 линия всего и она может идти в CPU, а может в PCH. И запросто может получиться, что втыкают бездумно в соседние x4 слота, из которых один x4 идет в CPU, а второй x2 в PCH… и потом удивляются результатам странным.
Также, как верно заметили, Xeon'ов на 4.5ГГц полно, правда они все для однопроцессорных систем, что скорей всего не подходит продавцам VPS'ок, где нужно выжимать максимальное количество ядер с сервера.
Другое дело что далеко не везде их (xeon'ы, которые могут 4.5ггц и выше) используют на полную. Нередко на хостингах вижу процессоры работающие на базовых или даже ниже частотах. Но можно же их держать постоянно в режиме между turbo (без большой нагрузки) и all-core-turbo (под нагрузкой), не давая проваливаться до базовой или даже ниже.
зачем почти все выделяют NVMe в какой-то особенно быстрый класс?
Потому что оно так и есть? Все Nvme накопители на рынке используют pcie интерфейс. Они значительно быстрее sata и sas ssd. Это отдельный класс устройств со своими сложностями, кучей разных формфакторов, коннекторов. И рынок плавно переходит на этот новый класс. Большинство серверных нагрузок легко может нагрузить эти диски, чтобы эти скорости увидеть. Уж VDS то точно, где дисками потенциально сразу куча народу пользуется.
зачем почти все выделяют NVMe в какой-то особенно быстрый класс?
Здесь скорее "почему", чем "зачем". В первую очередь потому, что SSD уперлись в пропускную способность интерфейса/ов SATA/SAS и ограничение протокола обмена данными по SAS (сколько помню, в нем можно максимум 256 очередей организовать, а в протоколе NVMe 64k, при этом скорости работы с носителем информации хватает на то, чтобы обрабатывать больше, чем 256 полностью забитых очередей), как следствие, sustained throughput у SATA/SAS SSD уступает NVMe SSD в несколько раз (здесь, например, в пять тире двадцать) как по IOPs так и по мегабайтам в секунду. А некоторым клиентам нужно быстродействие, которое SSD уже не обеспечивают, т.е. есть спрос на хранилище на дисках NVMe но не SATA/SAS SSD, а где есть спрос, там появляется предложение.
Про подключение — хм, имхо хороший вопрос, но я так понял, что здесь тестировался диск в одном и том же слоте, и в одном тесте он мог выдать сотню тысяч IOPs, во втором и тысячи не выдал.
В том и суть, что протокол может, но не обязательно что сможет диск, подключенный по нему. Давайте HDD подключим не по SATA, а по NVMe и будем рассуждать о преимуществах, скоростях и глубине очереди, попутно рекламируя супер-быстрый NVMe что-то там (хостинг, не хостинг — не важно). NVMe есть? Есть, все. А то что скорость будет все та же HDD'шная — это вы ничего не понимаете просто…
Мысль в том что важней что именно хранит информацию в диске, а протокол это уж скорей следствие. Если ячейки действительно шустрые, как optane например, диски на них ни у кого даже мысли не было делать на SATA т.к. он в 1 поток 4к около 400мб/с может, что почти потолок для SATA3. Так зачем же делают PCIe x4 NVMe SSD на всяких QLC ячейках, которые раз в 10 медленней… вопрос риторический.
Мысль в том что важней что именно хранит информацию в диске, а протокол это уж скорей следствие. Если ячейки действительно шустрые, как optane например, диски на них ни у кого даже мысли не было делать на SATA т.к. он в 1 поток 4к около 400мб/с может, что почти потолок для SATA3. Так зачем же делают PCIe x4 NVMe SSD на всяких QLC ячейках, которые раз в 10 медленней… вопрос риторический.
Так зачем же делают PCIe x4 NVMe SSD на всяких QLC ячейках, которые раз в 10 медленней… вопрос риторический.
QLC все равно прекрасно параллелятся. У них очень плохо все в запись, чтение работает хорошо и для холодных данных они отлично подходят, а тот же оптейн перед ними поставить как кэш записи. Но идея вообще в том, чтобы унифицировать стек. Индустрия отказывается от SAS и SATA. Люди переходят на nvme протокол. И гонять его собираются не только по pcie, но и по TCP и всяким другим сетевым фабрикам. И действительно не особо уже важно, чего там за этим nvme протоколом. Оптейн или SmartNic какой-нить, за которым массив дисков.
Что любопытно, вышла nvme 2.0 спека и одно из больших изменений — поддержка HDD nvmexpress.org/wp-content/uploads/NVM-Express-Base-Specification-2_0-2021.06.02-Ratified-4.pdf
Есть надежда, что такими темпами мы наконец сможем выкинуть iscsi и все гонять по nvme.
Есть надежда, что такими темпами мы наконец сможем выкинуть iscsi и все гонять по nvme.
Я лишь имел в виду что NVMe — тоже SSD, не надо его противопоставлять (причем серверные SATA SSD могут в определенных задачах быть даже лучше дешевых NVMe SSD). И то, что смешивают рекламщики все в кучу. В то время как NVMe SSD на TLC и 3DXpoint ячейках отличаются радикально по скорости. Т.е. обещают просто NVMe хостинг, люди подсознательно расчитывают на второе, а получают первое.
Так то понятно что NVMe интерфейс сильно лучше SATA. Но спасибо что HDD еще не додумались перевести на NVMe.
Так то понятно что NVMe интерфейс сильно лучше SATA. Но спасибо что HDD еще не додумались перевести на NVMe.
Т.е. обещают просто NVMe хостинг, люди подсознательно расчитывают на второе, а получают первое.
С чего вдруг? Никто в своем уме не рассчитывает, что ему хостинг оптейн даст. Даже в специфичных задач его по большей части как кэш используют. Люди, когда видят nvme, ожидают скоростей, который дают nvme pcie NAND диски, а это миллионы ипосов и гигабайты в секунду. Нормальный хостер еще конкретно скажет, сколько иопсов он готов предоставить. Да, для маркетологов nvme превратилось в обозначение конкретной категории продуктов, хотя это всего лишь протокол. Клиентам так наверняка проще, но в технической статье на хабре этому точно не место.
Ну за всех утверждать не стоит конечно. Есть хостинги и на optane… на которых та самая NVMe лэйбл выходит совсем ничего не значит на фоне большинства остальных якобы NVMe'шних хостингов. Народ видит… а, это еще один, такой же тормознутый как и все остальные… хотя ведь нет. Это и расстраивает.
Хотя на самом деле скорость процессора куда важней диска. И тут все еще печальней. На разных хостингах продают какие-то условные ядра, но различия в скорости могут быть в разы. Та же история что и с NVMe — называют просто «cpu core», а что там за core под капотом… даже у поддержки не всегда удается узнать заранее, не потратив время на проверку лично. И получается часто, что это «ядро» еле шевелится на 2ггц, когда хотелось бы (и может быть) раза в 2-2.5 шустрей. Но ядром считается и то и то.
Ну да, выдумывают какие-то Hi-CPU названия, а можно же просто написать модель процессора или хотяб частоты указывать везде и у hi- и у не-hi-.
Хотя на самом деле скорость процессора куда важней диска. И тут все еще печальней. На разных хостингах продают какие-то условные ядра, но различия в скорости могут быть в разы. Та же история что и с NVMe — называют просто «cpu core», а что там за core под капотом… даже у поддержки не всегда удается узнать заранее, не потратив время на проверку лично. И получается часто, что это «ядро» еле шевелится на 2ггц, когда хотелось бы (и может быть) раза в 2-2.5 шустрей. Но ядром считается и то и то.
Ну да, выдумывают какие-то Hi-CPU названия, а можно же просто написать модель процессора или хотяб частоты указывать везде и у hi- и у не-hi-.
Поэтому хостеры указывают IOPS. Это самый адекватный подход. Достаточно деления на быстрый/медленный, hdd/ssd. Вот как у яндекса сделано.
С процами тоже самое. Облачные провайдеры вроде в доках все говорят, какие где процы и сколько процентов времени процессора ты получаешь реально. Но это все равно непросто. У них типов инстансов туча, плюс они периодически старое выкидывают и меняют на более новые модели. Азур вон придумал универсальную метрику ACU, чтобы хотя бы относительные скорости были понятнее. Ну и всегда можно потестить самому.
С процами тоже самое. Облачные провайдеры вроде в доках все говорят, какие где процы и сколько процентов времени процессора ты получаешь реально. Но это все равно непросто. У них типов инстансов туча, плюс они периодически старое выкидывают и меняют на более новые модели. Азур вон придумал универсальную метрику ACU, чтобы хотя бы относительные скорости были понятнее. Ну и всегда можно потестить самому.
Сравнивать производительность для OLTP нагрузки (1С, SQL и т.п.) надо не в IOPS-ах и не в Throughput, а в Latency. Именно задержка единичной операции непосредственно влияет на отзывчивость систем. Широченная шина, обрабатывающая по 32 запроса параллельно не дает никакого толка для конкретного клиента. Каждый из 32 клиентов будет все равно ждать свою операцию. Длина queue имеет значение только для параллельной работы многих клиентов, то есть по факту влияет на максимальную поддерживаемую нагрузку. Это интересует хостера. А меня, как клиента, волнует именно latency!
Latency у NVMe/PCIe на порядок примерно лучше, чем у SAS. Поэтому я готов за него доплачивать. Потому что эффект виден в реальной работе. На результаты Diskspd/CrystalDiskMark вообще фиолетово.
А Throughput вообще интересует примерно никого и никогда.
Latency у NVMe/PCIe на порядок примерно лучше, чем у SAS. Поэтому я готов за него доплачивать. Потому что эффект виден в реальной работе. На результаты Diskspd/CrystalDiskMark вообще фиолетово.
А Throughput вообще интересует примерно никого и никогда.
Ну тут тоже не все так просто. Запрос может быть один, но на диск улететь может куча запросов и латентность в итоге будет по большей части скрыта и в идеальном варианте в сумме равняться латентности одной операции. И это будут все еще считанные микросекунды для NAND.
diskspd как раз показывает latency, так что его можно использовать для тестирования. Раньше была отдельная утилитка от MS симулирующая работу БД (вроде sqlio или как-то так), но от нее отказались т.к. есть diskspd.
отому что турбобуст, вообще-то, врубается специфически: процессор старается давать повышенную частоту при наличии питания и запаса по температуре. Это хорошо при пиках на десктопе (но не в играх), но очень плохо для сервера под нагрузкой с несколькими клиентами. То есть турбобуст не врубается на сервере почти никогда.
Спорное утверждение.
Например, у HP ProLiant есть настройка Power/Performance, при значении Maximum Performance его процессоры будут в турбе практически всегда (если не перегреются, чего добиться очень сложно).
У SuperMicro есть схожие настройки, но они могут работать кривовато)
Надо поиграться, есть тут под рукой щас суепрмикро.
.
У Линуса из Linus Tech Tips есть подборка видео про его быстрые сервера с NVMe дисками U2 и M2 — он достаточно подробно (по-английски, правда) рассказывает про проблемы, с которыми он столкнулся.
Посмотрите, вдруг что-то новое и интересное найдете.
Посмотрите, вдруг что-то новое и интересное найдете.
Вот уж его точно лучше не смотреть за советами. Поржать — можно. Ради этого он эти ролики и снимает. Единственный полезный ролик в этом плане был один из последних, где он словил конфликт AMD Epyc и P4510.
Я не про весь канал говорю — он развлекательный скорее, согласен, — а про его битву с дисками в серверах конкретно. Очень много полезной технической информации рассказывает, и решения предлагает. В случае с U2 ему помогло увеличение числа ядер, например, и он объяснял на цифрах — почему.
хз, сколько смотрел его видео с серверами, больше выглядят как ребенок, которой с новой игрушкой развлекается. А про U2, чего за ролик конкретный, может пропустил его. Я видел только эпик с интелами U2, там реально проблема, но он ее и не решил.
он и есть ребенок ) и да, я про этот ролик. проблема, как я понял, была им решена частично — в его пользу, ну а до конца должна решаться уже производителем.
Там проблем в несовместимости AMD платформы и этих конкретных дисков. Проблема на стыке прошивки диска, прошивки платформы, самой платформы и ОС. На уровне ОС все исправлено — в новых версиях линукса все его костыли с поллингом не нужны. На уровне диска ничего исправлять не будут. На уровне платформы — исправления в линуксе вроде проблему исправляют, а на новых эпиках вроде изначально все лучше. У Линуса к тому же сама платформа экспериментальная, в нее исправления тоже вносить никто не будет.
Я находил пост Вэндела, где он с этим всем для Линуса разбирался. Резюме там — на новых линукса и эпиках проблемы больше нет, а ZFS банально не готова к таким скоростям и пока можно даже не мечтать. На mdraid все бегает нормально.
Я находил пост Вэндела, где он с этим всем для Линуса разбирался. Резюме там — на новых линукса и эпиках проблемы больше нет, а ZFS банально не готова к таким скоростям и пока можно даже не мечтать. На mdraid все бегает нормально.
«Первое, что мы узнали, — что NVMe не объединяется в RAID нормальными способами».
Ещё как объединяются. У меня на лаптопе они объединены без проблем.
Ещё как объединяются. У меня на лаптопе они объединены без проблем.
CrystalDiskMark вроде никогда адекватных результатов для SSD и не показывал, его вообще не надо было использовать. Посмотрите обзоры IXBT и что они используют. Попробуйте IOmeter, там можно детально нагрузкой управлять как по чтению, так и по записи.
RAID сейчас многие собирают софтово. В винде же тоже можно, вот бы и собрали, раз так нужно. С софтовым RAID может быть печально если ОС умрет, но при обновлении ОС все равно все виртуалки смигрируются, так что не так опасно, а вот если аппаратный контроллер помрет, то веселья будет заметно больше. Количество багов к аппаратным контроллерам тоже не внушает уверенности в сохранности данных.
Здесь выше писали, что при записи в одну очередь разницу между nvme/sas/sata увидеть сложно т.к. тормозом является непосредственно запись в SSD, а не интерфейс. Гигабайты в секунду получаются при записи большой очередью т.к. SSD будут писать в разные ячейки одновременно и на этом можно прокачать IOPS и полосу пропускания. При последовательной записи и быстрые и медленные SSD выдадут на блоках по 4K около 50 тыс. IOPS.
При этом многие практически приложения были сильно оптимизированы во времена HDD чтобы писать последовательно в один поток (например СУБД) и у меня сайты на Drupal сохраняют материалы на SSD всего-лишь в два раза быстрее HDD (а никак не в сотни раз быстрее формальной разницы в IOPS). Поэтому синтетика может сильно завышать скорость по сравнению с реальными приложениями. На тех же СУБД, если вся база в ОЗУ влазит, не надо удивляться, что при чтении IOPS к дискам нет и использование nvme не дает прироста производительности.
Латентность на скриншотах в посте в десятки миллисекунд типична для HDD, а не SSD. Латентность SSD обычно в 50 раз меньше латентности HDD. C этим определенно надо разбираться, как и с провалом на 45ГБ.
Не написано, выключался ли WriteCache в хостовой Windows и в SATA RAID. Думаю не надо объяснять как кеш на запись может на результаты повлиять.
Тестирование Ceph можно, например, здесь посмотреть: www.proxmox.com/en/downloads/item/proxmox-ve-ceph-benchmark-2020-09
RAID сейчас многие собирают софтово. В винде же тоже можно, вот бы и собрали, раз так нужно. С софтовым RAID может быть печально если ОС умрет, но при обновлении ОС все равно все виртуалки смигрируются, так что не так опасно, а вот если аппаратный контроллер помрет, то веселья будет заметно больше. Количество багов к аппаратным контроллерам тоже не внушает уверенности в сохранности данных.
Здесь выше писали, что при записи в одну очередь разницу между nvme/sas/sata увидеть сложно т.к. тормозом является непосредственно запись в SSD, а не интерфейс. Гигабайты в секунду получаются при записи большой очередью т.к. SSD будут писать в разные ячейки одновременно и на этом можно прокачать IOPS и полосу пропускания. При последовательной записи и быстрые и медленные SSD выдадут на блоках по 4K около 50 тыс. IOPS.
При этом многие практически приложения были сильно оптимизированы во времена HDD чтобы писать последовательно в один поток (например СУБД) и у меня сайты на Drupal сохраняют материалы на SSD всего-лишь в два раза быстрее HDD (а никак не в сотни раз быстрее формальной разницы в IOPS). Поэтому синтетика может сильно завышать скорость по сравнению с реальными приложениями. На тех же СУБД, если вся база в ОЗУ влазит, не надо удивляться, что при чтении IOPS к дискам нет и использование nvme не дает прироста производительности.
Латентность на скриншотах в посте в десятки миллисекунд типична для HDD, а не SSD. Латентность SSD обычно в 50 раз меньше латентности HDD. C этим определенно надо разбираться, как и с провалом на 45ГБ.
Не написано, выключался ли WriteCache в хостовой Windows и в SATA RAID. Думаю не надо объяснять как кеш на запись может на результаты повлиять.
Тестирование Ceph можно, например, здесь посмотреть: www.proxmox.com/en/downloads/item/proxmox-ve-ceph-benchmark-2020-09
Раз пошла речь про влияние гипервизора на производительность работы с дисками, вот мой benchmark KVM vs baremetal vs Hyper-V на Sata SSD и синхронной записи.
Примечательно в результатах там то, что при многопоточной записи производительность сильно падает, что видимо объясняется частым переключением контекстов (т.е. большое количество виртуалок на хосте — плохо), а производительность чтения совершенно неадекватна т.к. в реальности чтение происходит из ОЗУ хостовой ОС, а не с дисков.
Ну и да, бенчмаркать дисковую систему очень нетривиально т.к. много что может сильно влиять на производительность и может случиться, что измеряешь не производительность nvme, а производительность своей программно-аппаратной конфигурации, которая в руках другого человека с другой конфигурацией железа, но теми же дисками не воспроизведется.
Примечательно в результатах там то, что при многопоточной записи производительность сильно падает, что видимо объясняется частым переключением контекстов (т.е. большое количество виртуалок на хосте — плохо), а производительность чтения совершенно неадекватна т.к. в реальности чтение происходит из ОЗУ хостовой ОС, а не с дисков.
Ну и да, бенчмаркать дисковую систему очень нетривиально т.к. много что может сильно влиять на производительность и может случиться, что измеряешь не производительность nvme, а производительность своей программно-аппаратной конфигурации, которая в руках другого человека с другой конфигурацией железа, но теми же дисками не воспроизведется.
Экспериментировал тут с новым и старым серверами и дисками, случайно обратил внимание на один диск, который дискмарк измерял как R 3500 W 3500 (грубо), а diskspd 3500/1800
Подсмотрел, с какими параметрами запускает diskspd дискмарк, он добавляет параметр -Z1024K
С ним скорость чтения и записи становятся одинаковыми (по тесту)
Кто-нибудь может пояснить про параметр -Z1024K у diskspd, правильно его использовать или нет? Что означает тот факт, что все остальные диски что у меня есть показывают одинаковые результаты с -Z1024K и без него, а один старый - см. выше?
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Все врут: эпопея с NVMe-серверами и Hi-CPU