Если очередь и в правду была 1, то: 20000 IOPS - это 50 микросекунд на один ввод или вывод (1000000 микросекунд (1 сек) / 20000 IOPS ) 50000 IOPS - это 20 микросекунд на один ввод или вывод (1000000 микросекунд (1 сек) / 50000 IOPS )
Я не нашел в доках "миссии" NVMe 2.0. Предположу, что оно создавалось для возможности эффективного использования NVMe по сети. И мне кажется , что цель достигнута. А доказательством можно считать разницу в 30 микросекунд между локальным диском и удаленным.
>>> Заявленный миллион IOPS на NVMe диске в таком сценарии превратился 50 тысяч для локального диска и 20 тысяч для диска, подключенного по NVMe OF.
Тут Вы не учли физику. Миллион в секунду - это 1 сек / 1000000 = 1 микросекунда на один ввод или вывод. Выши результаты показывают 20 микросекунд. Уточните у производителя как получить миллион. Скорее всего там тест был на чтение, да еще были прогреты файловый кэш или включен буфер. Производители часто не про маленькие, но важные детали.
>>>Тестирование производительности дисковой подсистемы производилось по наихудшему сценарию. 50/50 чтение/запись
Сходу не удалось найти материалов, но на сколько я помню для ssd худшим сценарием есть последовательная запись.
Скажите, пожалуйста, какой средний, максимальный размеры БД? Так же про средний и пиковый (в высокий сезон) tps на БД. Я не проверял, но мне действительно верится в лечении «детских болячек» разработчиков при составлении запросов и «проектирование» БД жесткими ограничениями и правилами на старте разработки. Если к этому добавить ответственность разработчика за эксплуатацию своего кода (это же придется заглядывать под свой код)… здорово если в ситилинке так! Но так же мне кажется, что нагрузки на БД у вас нет таких, при которых необходимо начинать пользоваться инструментами для профилировки запросов, изучении работы планировщиков обработки аппаратных прерываний или блокировок при выполнении околоатомарных( в сторону инструкций процессоров) операциях над данными. К сожалению, мне на сегодня нечем на личном опыте показать необходимость администраторов БД. Поэтому приведу пример коллег из Тензора: у них есть статья, где они пишут 1 ТБ данных в день. Не будьте так категоричны и не обижайте коллег) они вам скоро понадобятся) спасибо за статью, очень интересная. До свидания.
В следующем году попробуйте потратить время на изменения в архитектуре, которые позволять подключать новых провайдеров и балансировать нагрузку между ними. Если сумеете, то после этого счета за облака будут еще меньше)
я бы поставил Вам минус, да не имею права. Имею пару хостов, овирт, гластер — проблем с доступностью ВМ пока не имеем даже с учетом того что сплитбрен в автомтическом режиме не переживем. Да, есть проблемы, которых можно было избежать на этапе проектирования, но тогда не было достаточно опыта. И проблемы эти решаемы, руки просто не доходят.
Еще копеечку внесу:
Вы вынелси каталог БД на отдельный диск. Далее можно и wal-файлы складывать на отдельный диск. Даже обычного SATA должно хватить на много т.к. производится последовательная запись.
Спасибо. Производитель диска говорит что скорость случайной записи с блоками по 4 кБ равна 400KIOPS. В одном LUN 12 дисков в RAID10. (12*400000)/2=1200KIOPS. Ваш же тест показал всего 438KIOPS. Где же остальное?
У нас, например, 400 гиговая база превращается в 30 гиговый дамп с помощью штатных «компрессоров». И еще скажите, пожалуйста, сильно ли отличается время восстановления из копии в отличии от того же pg_restore?
Если очередь и в правду была 1, то:
20000 IOPS - это 50 микросекунд на один ввод или вывод (1000000 микросекунд (1 сек) / 20000 IOPS )
50000 IOPS - это 20 микросекунд на один ввод или вывод (1000000 микросекунд (1 сек) / 50000 IOPS )
Я не нашел в доках "миссии" NVMe 2.0. Предположу, что оно создавалось для возможности эффективного использования NVMe по сети. И мне кажется , что цель достигнута. А доказательством можно считать разницу в 30 микросекунд между локальным диском и удаленным.
>>> Заявленный миллион IOPS на NVMe диске в таком сценарии превратился 50 тысяч для локального диска и 20 тысяч для диска, подключенного по NVMe OF.
Тут Вы не учли физику. Миллион в секунду - это
1 сек / 1000000 = 1микросекунда на один ввод или вывод. Выши результаты показывают 20 микросекунд. Уточните у производителя как получить миллион. Скорее всего там тест был на чтение, да еще были прогреты файловый кэш или включен буфер. Производители часто не про маленькие, но важные детали.>>>Тестирование производительности дисковой подсистемы производилось по наихудшему сценарию. 50/50 чтение/запись
Сходу не удалось найти материалов, но на сколько я помню для ssd худшим сценарием есть последовательная запись.
Скажите, пожалуйста, какой средний, максимальный размеры БД? Так же про средний и пиковый (в высокий сезон) tps на БД. Я не проверял, но мне действительно верится в лечении «детских болячек» разработчиков при составлении запросов и «проектирование» БД жесткими ограничениями и правилами на старте разработки. Если к этому добавить ответственность разработчика за эксплуатацию своего кода (это же придется заглядывать под свой код)… здорово если в ситилинке так! Но так же мне кажется, что нагрузки на БД у вас нет таких, при которых необходимо начинать пользоваться инструментами для профилировки запросов, изучении работы планировщиков обработки аппаратных прерываний или блокировок при выполнении околоатомарных( в сторону инструкций процессоров) операциях над данными. К сожалению, мне на сегодня нечем на личном опыте показать необходимость администраторов БД. Поэтому приведу пример коллег из Тензора: у них есть статья, где они пишут 1 ТБ данных в день. Не будьте так категоричны и не обижайте коллег) они вам скоро понадобятся) спасибо за статью, очень интересная. До свидания.
В следующем году попробуйте потратить время на изменения в архитектуре, которые позволять подключать новых провайдеров и балансировать нагрузку между ними. Если сумеете, то после этого счета за облака будут еще меньше)
Чо накинулись-то. Статья про инфраструктуру огонь!
Хорошая попытка, Нутаникс))
а у вас процедура процесса вывода оборудования из эксплуатации не содержит пункта «Снять с мониторинга»?
Вы вынелси каталог БД на отдельный диск. Далее можно и wal-файлы складывать на отдельный диск. Даже обычного SATA должно хватить на много т.к. производится последовательная запись.