Comments 15
Все хорошо, но может стоило добавить нормальный список моделей, которые вы относите к тому или иному классу? Иначе это просто голая теория и рекламная шелуха, мол какие мы хорошие, только 50-й класс ставим ;)
Класс — при этом такие вещи как шифрование на уровне железа и защита от сбоев питания при помощи конденсаторов. Или наличие тротлинга у разных м.2 моделей от самсунга из-за перегрева. Это все конечно же ерунда. Вопросы надежности и стабильности параметров в рабочих станциях видимо совершенно не нужны. Делл стремится пробить дно сохраняя корпоративное лицо уже несколько лет. Выдвигая какие-то мифические «классы», делая вид что они достаточно авторитетны для введения классификации.
В вашем анализе отсутсвует два важных момента.
1. Есть большая разница между random write и random write + flush. Большая — это примерно в тридцать раз. Я не шучу.
На первой попавшей ssd я имею 15к IOPS на рандомную запись, и имею около 500 IOPS на рандомную запись с flush'ем. Её можно проверить, если добавить ключ --fsync=1 для fio (бенчмарк надо делать на файловой системе). Это приводит к передаче в устройство команды flush, и это очень тормозит. Все транзакционные системы СУБД, файловые системы, системы управления пакетами/апдейтами используют flush для консистентности, то есть производительность при flush определяет user expirience (на одной софт ставится мгновенно, на второй тупит).
2. Maximum latency. Традицонно, все SSD проигрывают шпиндельным дискам по этому параметру. Лучшее, что я видел — делало 8 секунд пиковую задержку (100% SPAN), худшее — больше 80. Секунд. На одну (самую неудачную) операцию.
1. Есть большая разница между random write и random write + flush. Большая — это примерно в тридцать раз. Я не шучу.
На первой попавшей ssd я имею 15к IOPS на рандомную запись, и имею около 500 IOPS на рандомную запись с flush'ем. Её можно проверить, если добавить ключ --fsync=1 для fio (бенчмарк надо делать на файловой системе). Это приводит к передаче в устройство команды flush, и это очень тормозит. Все транзакционные системы СУБД, файловые системы, системы управления пакетами/апдейтами используют flush для консистентности, то есть производительность при flush определяет user expirience (на одной софт ставится мгновенно, на второй тупит).
2. Maximum latency. Традицонно, все SSD проигрывают шпиндельным дискам по этому параметру. Лучшее, что я видел — делало 8 секунд пиковую задержку (100% SPAN), худшее — больше 80. Секунд. На одну (самую неудачную) операцию.
Стабильность производительности у потребительских моделей очень низкая. Стоит смотреть в сторону серверных моделей, я все больше убеждаюсь что только серверные ССД — полноценные продукты. Там и конденсаторы которые позволяют дописать кеш, и стабильные честные показатели. Именно по этому они слегка ниже потребительских моделей, у которых пиковые показатели «дутые» за счет кешей. Я себе купил Intel 750, Intel 3710 и Intel 320. Если хотите могу прогнать на них тесты на максимальную задержку и запись со сбросом кеша, т.к. и самому интересно. Но fio запустить не смогу, т.к. линукса нет и ставить не буду.
Немного материалов на тему, которые дают надежду на стабильность в производительности:
www.anandtech.com/show/6433/intel-ssd-dc-s3700-200gb-review/3
blogs.technet.microsoft.com/filecab/2016/11/18/dont-do-it-consumer-ssd
Немного материалов на тему, которые дают надежду на стабильность в производительности:
www.anandtech.com/show/6433/intel-ssd-dc-s3700-200gb-review/3
blogs.technet.microsoft.com/filecab/2016/11/18/dont-do-it-consumer-ssd
К сожалению, даже на топовых серверных SSD производительность «с flush'ем» кратно хуже, чем без него, и многосекундные пиковые latency — тоже норма. Включая «ulrafast PCI-E devices».
К сожалению или к счастью, но я не могу найти подтверждение ваших слов в интернете.
Например:
www.storagereview.com/intel_ssd_910_series_enterprise_pcie_review
www.storagereview.com/intel_ssd_dc_p3700_25_nvme_ssd_review
Судя по графику максимальной задержки записи — она не превышает 150мс для некоторых серверных моделей Интела. И разброс очень маленький.
Насчет тестов с flush'ем — я про них вообще ни чего найти не могу в интернете.
В общем предложение про проверку вашей гипотезы на доступном мне оборудовании остается в силе. Еще смогу проверить на каком-то OCZ, сата самсунгах(750 и 850) и маленьких(4гб) SLC дисках.
Например:
www.storagereview.com/intel_ssd_910_series_enterprise_pcie_review
www.storagereview.com/intel_ssd_dc_p3700_25_nvme_ssd_review
Судя по графику максимальной задержки записи — она не превышает 150мс для некоторых серверных моделей Интела. И разброс очень маленький.
Насчет тестов с flush'ем — я про них вообще ни чего найти не могу в интернете.
В общем предложение про проверку вашей гипотезы на доступном мне оборудовании остается в силе. Еще смогу проверить на каком-то OCZ, сата самсунгах(750 и 850) и маленьких(4гб) SLC дисках.
Для меня проблема с flush'ами стала сюрпризом, когда я готовил диски для ceph'а (который эти флаши использует постоянно). Я даже пол-года ругался с вендором, и они с -цатой попытки выкатили версию, в которой flush'и стали делаться существенно лучше.
тест простой: fio --name fsync_test --blocksize=4k --ioengine=libaio --iodepth=1 --direct=1 --buffered=0 --rw=randwrite --filename=/mnt/testdrive/test --size 800G --fsync=1
Файловая система — по вкусу.
Да, разумеется, пиковые latency надо мерять с флашами. Без — не смотрел и не интересовался.
Для понимания проблемы, весь OLTP делает flush'и для транзакций: dpkg — делает. rpm — делает. postgres — делает. mariadb — делает. mongo — опционально делает.
Я так понимаю это тест вызывает fsync, утилиту характерную для линукс среды. Моих знаний не хватает чтоб понять что есть аналогом этой утилиты в среде Виндовс.
Но есть статья от postgres
и ссылаются на такое вот частное исследование
Судя по всему, fsync фактически отключает кеш на запись, и от того идет жуткое падение производительности и износ диска. У моделей с «Enhanced Power Loss Data Protection», или по простому — с конденсаторами, не нужно отключать кеш, т.к. его сохранность гарантируется, все транзакции будут дописаны в случае сбоя.
Не берусь утверждать, но возможно можно настроить СУБД под работу на ССД.
Но есть статья от postgres
The 3rd generation Intel 320 and 710 series drives do not have any of these problems, having added a capacitor to provide battery-backup for flushing the drive cache when power drops.
и ссылаются на такое вот частное исследование
Судя по всему, fsync фактически отключает кеш на запись, и от того идет жуткое падение производительности и износ диска. У моделей с «Enhanced Power Loss Data Protection», или по простому — с конденсаторами, не нужно отключать кеш, т.к. его сохранность гарантируется, все транзакции будут дописаны в случае сбоя.
Не берусь утверждать, но возможно можно настроить СУБД под работу на ССД.
Не важно, что оно вызывает, важно, что когда операция проходит по блочному стеку проходят команды SYNCHRONIZE CACHE (0x91 или 0x35), которые, цитирую:
Соответственно, flush говорит «сбрось кеш на диск», и это hard requirement для OLTP систем. Если SSD начинает мухлевать и игнорировать этот флаг (продолжая держать несохранённые данные в wb-кеше), то мы имеем eventual corruption в результате выключения питания на долгое время, всяких странных bus reset'ов и т.д.
СУБД (и подобные им системы, наподобие ceph'а) гарантируют консистентность данных только если блочное устройство выполняет сброс кеша по команде.
Более того, они это делают очень часто. ceph, например, делает один flush на каждый iops. (две записи и один flush). То же самое делают системы управления пакетами (dpkg). Насколько я знаю, винда, при установке апдейтов, тоже делает транзакции таким образом (основная причина, почему апдейты такие медленные и унылые).
Таким образом, реальная производительность устройств под нагрузкой должна происходить с учётом производительности flush-операций. Которые могут занимать десятки секунд в неудачные моменты времени. И единицы милисекунды в удачные.
На удивление, жёсткие диски, в этих условиях работают медленее, но равномернее — пиковые latency у HDD редко превышают единицы секунд.
UPD: Мне лениво искать, но верьте мне на слово, в SATA поддержка flush'а тоже есть. Я не помню, отдельная это команда, или флаг «write barrier» на WRITE операцию, но они точно есть.
SCSI Commands Reference Manual, Rev. A 3.46
SYNCHRONIZE CACHE (10) command
The SYNCHRONIZE CACHE (10) command (see table 140) requests that the device server ensure that the specified logical blocks have their most recent data values recorded in non-volatile cache and/or on the medium, based on the SYNC_NV bit. Logical blocks include user data and, if the medium is formatted with protection information enabled, protection information. Logical blocks may or may not be removed from volatile cache and non-volatile cache as a result of the synchronize cache operation.
Соответственно, flush говорит «сбрось кеш на диск», и это hard requirement для OLTP систем. Если SSD начинает мухлевать и игнорировать этот флаг (продолжая держать несохранённые данные в wb-кеше), то мы имеем eventual corruption в результате выключения питания на долгое время, всяких странных bus reset'ов и т.д.
СУБД (и подобные им системы, наподобие ceph'а) гарантируют консистентность данных только если блочное устройство выполняет сброс кеша по команде.
Более того, они это делают очень часто. ceph, например, делает один flush на каждый iops. (две записи и один flush). То же самое делают системы управления пакетами (dpkg). Насколько я знаю, винда, при установке апдейтов, тоже делает транзакции таким образом (основная причина, почему апдейты такие медленные и унылые).
Таким образом, реальная производительность устройств под нагрузкой должна происходить с учётом производительности flush-операций. Которые могут занимать десятки секунд в неудачные моменты времени. И единицы милисекунды в удачные.
На удивление, жёсткие диски, в этих условиях работают медленее, но равномернее — пиковые latency у HDD редко превышают единицы секунд.
UPD: Мне лениво искать, но верьте мне на слово, в SATA поддержка flush'а тоже есть. Я не помню, отдельная это команда, или флаг «write barrier» на WRITE операцию, но они точно есть.
Спасибо, почитаю как вызывать эти команды под виндой. Но относительно кеша и конденсаторов — они не просто хранят содержимое кеша, они позволяют его сбросить на флеш в случае пропадания питания. Т.е. «values recorded in non-volatile cache» выполняется для ссд с кондером всегда. А состояние кондеров контролируется самодиагностикой и доступно среди смарт параметров.
Тем не менее как реагируют диски на эту команду я не знаю. Может мухлюют а может и нет. Но доки уверяют что можно отключать синхронизацию на таких дисках, можно ли им верить не знаю, наверное нужно делать тесты с выдергиванием дисков.
Тем не менее как реагируют диски на эту команду я не знаю. Может мухлюют а может и нет. Но доки уверяют что можно отключать синхронизацию на таких дисках, можно ли им верить не знаю, наверное нужно делать тесты с выдергиванием дисков.
Мы спекулируем о потрошках этих устройств. Насколько я понимаю, кеш там довольно ограничен по объёму и под нагрузкой может оказываться, что устройство вынуждено делать какие-то существенные операции даже в режиме «с использованием кеша». (кроме того, там же описывается флаг, который требует скинуть даже non-volatile кеш).
На практике я описываю результаты своих бенчмарков под ceph'ом — и даже самые top grade диски начинают выглядеть довольно умеренно. Flush резко увеличивает max latency.
Что удивительно, это становится заметно только на длинных пробегах. Например, для 730ых интелов на 40Гб span'е max latency = 11ms (block=4k, iodepth=10), а на 400Гб span тот же тест даёт max latency 17 секунд (17000 милисекунд).
На практике я описываю результаты своих бенчмарков под ceph'ом — и даже самые top grade диски начинают выглядеть довольно умеренно. Flush резко увеличивает max latency.
Что удивительно, это становится заметно только на длинных пробегах. Например, для 730ых интелов на 40Гб span'е max latency = 11ms (block=4k, iodepth=10), а на 400Гб span тот же тест даёт max latency 17 секунд (17000 милисекунд).
Кеш у 730ых не больше 1гб, т.е. сильно меньше 40гб, и по сути задача кеша исключительно насобирать записей на одну целую страницу, прежде чем ее записывать. Это уже снимает главную проблему и задержек и износа. А сколько если не секрет вы оставляли для over-provisioning в тесте с 730ым? А ваш тест только фиксирует максимальную задержку или так-же считает количество таких событий? Насколько критичный единичный лаг за двойную перезапись накопителя?
Я не знаком с ceph'ом, но постгрес не часто перезаписывает данные, он генерирует кучу новых файлов с патчами. Т.е. если СХД собран на ССД достаточного объема, с ОР в 20%, то двукратных непрерывных перезаписей происходить не будет, и скорее всего не будет 17 секундных лагов.
Я не знаком с ceph'ом, но постгрес не часто перезаписывает данные, он генерирует кучу новых файлов с патчами. Т.е. если СХД собран на ССД достаточного объема, с ОР в 20%, то двукратных непрерывных перезаписей происходить не будет, и скорее всего не будет 17 секундных лагов.
На продакшене норма у ceph'а — утилизация дисков <80% (т.е. минимум 20% свободно), на тестах я обычно оставляю 80-160Гб (400 для 480, 800 для 960, etc).
Точное число я не фиксировал, но когда первый раз такое обнаружил, то сделал latency log, по ощущениям, оно очень редко. fio тоже согласно, потому что там идёт <0.1% такого. (Это не отменяет удачно залипшего IO на 17 секунд в продакшене на Самой Важной Транзакции).
postgres имеет журналы ограниченного размера, примерно такие же журналы на ceph'е.
Я воспроизводил эти лаги при IO не на ceph, а просто fsync на файловую систему (я выше показывал пример скрипта). Для меня гигантским сюрпризом было радикальное снижение производительности при переходе с бенчмарков голых блочных устройств (или файловых систем без fsync) на бенчмарк с fsync'ом.
Который я считаю наиболее точным инфимумом для производительности устройства. (В любой другой ситуации устройство будет вести себя лучше).
Точное число я не фиксировал, но когда первый раз такое обнаружил, то сделал latency log, по ощущениям, оно очень редко. fio тоже согласно, потому что там идёт <0.1% такого. (Это не отменяет удачно залипшего IO на 17 секунд в продакшене на Самой Важной Транзакции).
postgres имеет журналы ограниченного размера, примерно такие же журналы на ceph'е.
Я воспроизводил эти лаги при IO не на ceph, а просто fsync на файловую систему (я выше показывал пример скрипта). Для меня гигантским сюрпризом было радикальное снижение производительности при переходе с бенчмарков голых блочных устройств (или файловых систем без fsync) на бенчмарк с fsync'ом.
Который я считаю наиболее точным инфимумом для производительности устройства. (В любой другой ситуации устройство будет вести себя лучше).
Раз уж здесь официальный блог DELL — то можно вас попросить написать статью про Generation 14 of Poweredge? Вроде ещё в прошлом году начали продавать 14е поколение, но особо нигде (по крайней мере здесь) не писали про это.
И если можно — то более техническую, чем маркетинговую статью.
И если можно — то более техническую, чем маркетинговую статью.
Добрый день! Как раз недавно в блоге Dell EMC на HH такая статья появилась: habrahabr.ru/company/dellemc/blog/344100
Sign up to leave a comment.
Классификация устройств хранения данных в рабочих станциях, на примере линейки Dell Precision