Комментарии к публикации ««20 тысяч IOPS на узел — хорошие показатели с учётом задержек в 5 мс». Для OLTP — нет»

28.04.2020 13:01:05 R_Voland

R_Voland — Tue, 28 Apr 2020 13:01:05 GMT

Кто блин мешает закрепить файлы БД на быстрых дисках то? Autotiering — маркетинговая уловка всего лишь.

14.02.2019 19:55:55 speshuric

speshuric — Thu, 14 Feb 2019 19:55:55 GMT

Чем поделиться есть. Времени — нет :)

14.02.2019 08:51:36 realscorp

realscorp — Thu, 14 Feb 2019 08:51:36 GMT

Сегодня нашел вашу статью, случайно, по ссылке в комментарии к другой статье.
Отличная статья! Очень полезно и познавательно!
Пишите еще — уверен, вам есть, чем поделиться :)

28.06.2018 08:04:35 romxx

romxx — Thu, 28 Jun 2018 08:04:35 GMT

Именно это и было сделано. Но речь идет про «покажите вывод fio по max latency»

28.06.2018 06:59:18 tlv

tlv — Thu, 28 Jun 2018 06:59:18 GMT

В приличных тест-сценариях принято прогревать оборудование тестовой нагрузкой некоторое время перед началом собственно измерений.

20.06.2018 09:07:04 ildarz

ildarz — Wed, 20 Jun 2018 09:07:04 GMT

Ну так покажите распределение латентности, а не average (причем желательно не случайное чтение с очередью 32, а последовательную запись с очередью 1), и не нужны будут никакие аналогии. А так приведенные вами цифры в свете озвученных в статье проблем не значат ровным счетом ничего.

19.06.2018 21:29:19 speshuric

speshuric — Tue, 19 Jun 2018 21:29:19 GMT

У меня в комменте не было ни одной цифры, я не мог их передернуть. У меня было только вспомненное место из художественной книги :)
Да еще и наглядно иллюстрирующее подход.

Или я что-то не понял?

19.06.2018 18:51:02 romxx

romxx — Tue, 19 Jun 2018 18:51:02 GMT

«Плохая аналогия — это хуже, чем никакой аналогии». В данном случае аналогия явно хромает. Если вы увидите, что после 24-часового теста значение max — полсекунды, например, при этом — это значение пришлось на первые три секунды с момента старта 24-часового теста, то само по себе что это вам даст полезного?
Так что аналогия с автомобилем, тут скорее другая будет, что конструкторы рассчитывают, что за миллион поворотов руля только один раз произойдет поломка.

19.06.2018 18:28:49 amarao

amarao — Tue, 19 Jun 2018 18:28:49 GMT

Вы передёргиваете цифры.

Если у нас 0.01% операций (на самом деле цифра ниже, примерно одна из 100000) занимает 10 секунд, а оставшиеся — 5мс, то средняя latency — 5ms. И медианная latency — 5ms. И даже 99.99% персентиль — 5ms. Но при этом каждый пользователь высоконагруженной системы сталкнётся с задержками в 10с. Почему? Потому что любое устройство в продакшене обслуживает куда больше, чем 1000000 операций за своё время. Некоторые столько обслуживают за час, или даже за 10 минут.

И вот субд, которая раз в десять минут фризится на 10 секунд.

Тут же проблема не в «производители мудаки», а «покупатели не на ту метрику смотрят».

19.06.2018 16:34:38 speshuric

speshuric — Tue, 19 Jun 2018 16:34:38 GMT

Это ж классика

Моя задача заключается в правильном применении секретной формулы.
Чистая арифметика.
Классическая задачка из учебника.
Если новая машина, произведенная компанией, на которую я работаю, выехала из Чикаго со скоростью шестьдесят миль в час, и тут у нее заклинило дифференциал, и она улетела в кювет, разбилась, бензобак взорвался и все, кто были в салоне, сгорели заживо, должна ли компания отозвать все проданные автомобили этой модели на доработку?
Возьмите общее количество проданных на настоящий момент автомобилей (А), умножьте на среднее количество серьезных отказов (В), а затем умножьте произведение на среднюю стоимость урегулирования иска родственников пострадавших во внесудебном порядке (С).
А х В х С = X. Вот во сколько нам обойдется проблема, если мы не будем отзывать модель на доработку.
Если Х превышает стоимость доработки, томы производим доработку, и аварий больше не бывает.
Если Х меньше, чем стоимость доработки, то мы доработку не производим.

Чак Паланик, "Бойцовский клуб"

19.06.2018 12:28:19 amarao

amarao — Tue, 19 Jun 2018 12:28:19 GMT

Вы знаете, если бы дизайнеры автомобилей так делали, то было бы «за три года вождения max latency на повороте руля выстрелила несколько раз, но это не показательно. 99.9% поворотов руля отрабатывают за меньше чем 5мс, а что 0.01% — больше нескольких секунд — ну кого эти аварии волнуют?»

19.06.2018 12:25:58 amarao

amarao — Tue, 19 Jun 2018 12:25:58 GMT

Нет, конечно. Это проблема дисков снизу. Но для пользователя всё равно виновата база, потому что «тормозит». Причём на тестах ССД хорошо, а потом херак транзакиция и человек своими глазами видит, как insert в пустую таблицу на 1кб выполняется 10с с localhost'а.

19.06.2018 11:02:05 romxx

romxx — Tue, 19 Jun 2018 11:02:05 GMT

Тест шел сутки, это — средние steady результаты. За сутки там уж конечно что-то в max выстрелило, но это непоказательно.

19.06.2018 10:15:41 speshuric

speshuric — Tue, 19 Jun 2018 10:15:41 GMT

Мы об одном и том же :)

на выделенных HDD многие СХД выжимают очень и очень хорошую производительность [в режиме seq write]

Как раз жёсткие диски в линейной записи чувствуют себя круче, чем SSD.

19.06.2018 10:11:47 speshuric

speshuric — Tue, 19 Jun 2018 10:11:47 GMT

Судя по тестам, там задержка не сильно ниже, но она на очереди 1 близка к константе. Там нет хитроштопанной логики и кешей и нет жирных CoW, как на SSD. Обычные SSD «на коротких дистанциях» компенсируют это кэшем, и именно поэтому в обычных тестах оптаны показывают себя очень близко к обычным хорошим SSD. А выигрывают в проигрышных для SSD вариантах типа 100% random write 4kQ1.

Хотя я тоже пока подожду готовых решений. Может в жизни всё и не так радужно.

19.06.2018 09:54:41 Areso

Areso — Tue, 19 Jun 2018 09:54:41 GMT

Т.е., по-вашему, это проблема в СУБД, а не в железе?
Что является источником такой проблемы?

19.06.2018 09:20:45 amarao

amarao — Tue, 19 Jun 2018 09:20:45 GMT

А когда fio закончит, покажите-ка его вывод с latency. Интересует max.

19.06.2018 09:18:58 amarao

amarao — Tue, 19 Jun 2018 09:18:58 GMT

Мне удавалось получить адские задержки на последовательном IO тоже. Ключевое — fsync. Поскольку ssd не может записать внутри себя 4к блок, то там всё равно происходит CoW (copy on write), который может утыкаться в GC и тормозить всё. Как раз жёсткие диски в линейной записи чувствуют себя круче, чем SSD.

19.06.2018 09:17:18 amarao

amarao — Tue, 19 Jun 2018 09:17:18 GMT

Пока не щупал, но то что официалы говорят — не очень. Так же средняя latency. Которая стала ниже, но… Вот стоит субд, мурыжит тысячи операций в секунду. Тут, раз, задержка в 10с на одно IO. Как такое объяснять? «База данных ушла на базу. Вас много, я одна».

19.06.2018 08:49:57 VerdOrr

VerdOrr — Tue, 19 Jun 2018 08:49:57 GMT

Пардон, что значит «была распространена NUMA архитектура»? Какая, по вашему, архитектура у современных двух- и более процессорных систем? С собственным контроллером памяти у каждого процессора и относительно медленными соединениями между ними? Другой вопрос, что в 2-/4-процессорных системах, из которых, в основном, сейчас строятся кластеры, накладные расходы относительно невелики. Но они есть и «special care must be taken in vCPU and vNUMA configuration to ensure performance is optimized»

19.06.2018 05:20:01 Yo1

Yo1 — Tue, 19 Jun 2018 05:20:01 GMT

на самом деле оракл еще с глубокой древности имел возможность поднимать несколько процессов пишущих в REDO лог. то была фича когда еще была распространена NUMA архитектура и предлагали на каждой партиции NUMA свой процесс писанинины в лог поднимать. другое дело что особо смысла это не имеет, т.к. нормально настроенный REDO запросто на hdd успевает писать десятки миллионов транзакций однопоточно. в тестах tpc.org и поболее есть тесты, при этом один процесс и hdd справляются.

18.06.2018 17:57:01 speshuric

speshuric — Mon, 18 Jun 2018 17:57:01 GMT

Круто, правда круто.

18.06.2018 17:52:40 romxx

romxx — Mon, 18 Jun 2018 17:52:40 GMT

А чего гиперпконвергенция? А вот вам гиперконвергенция:

Детали тут: longwhiteclouds.com/2017/11/14/1-million-iops-in-1-vm-world-first-for-hci-with-nutanix

Вот вам миллион рандомных IOPS блоком 8K в fio при 0,11ms IO latency.
Это просто не все гиперконвергенции одинаковы :)

18.06.2018 17:50:08 speshuric

speshuric — Mon, 18 Jun 2018 17:50:08 GMT

Нет никакой загадки. Простейший и типичный кейс. Есть уровень, который хранится на HDD 7200 (tier2), и есть его кеш примерно на 10% по объёму на SSD (tier1). Ночью запускается обслуживание БД: резервное копирование, перестроение индексов, пересчет статистик. В итоге утром в tier1 какая-то хрень, а не нужные данные. Просто потому что СХД не обладает достаточной информацией о значении данных.

18.06.2018 17:41:11 speshuric

speshuric — Mon, 18 Jun 2018 17:41:11 GMT

Есть такая проблема, для каждого вида нагрузки нужны фактически свои политики гуляния по tier'ам. Но вендоры СХД обычно предоставляют рекомендации.
А моё личное мнение, что для СУБД все эти «интеллектуальные» кеши уровня СХД — больше геморроя, чем пользы.

18.06.2018 17:37:27 speshuric

speshuric — Mon, 18 Jun 2018 17:37:27 GMT

Ну во-первых WAL это всё-таки не random, а seq. Во-вторых WAL может быть и не 4k за порцию, а меньше. Но я согласен, что SSD и тут может давать выбросы. И, кстати, на выделенных HDD многие СХД выжимают очень и очень хорошую производительность в этом режиме, так что упираются в каналы.

И, как заметил предыдущий комментатор, я расчитываю на прорыв Intel Optane. Посмотрите мой PS про SSD. Более того, если оптаны не обладают каким-то скрытым изъяном, то те скорости (задержки), которые они дают, делают спорным применение SAN/СХД на критичных к производительности приложениях. На VMax/VNC и подобных СХД пока еще никто не заморачивается на roundtrip до конечного приложения в десятки микросекунд.

18.06.2018 17:27:27 Karpion

Karpion — Mon, 18 Jun 2018 17:27:27 GMT

Например, с того, что сейчас почти везде используются SSD.

Я слабо слежу за темой. Но мне кажется, SSD приличного размера (пригодного для корпоративных БД) всё ещё имеют неприличную цену.

Я не знаю другого продукта на рынке, который называется именно «SQL Server» кроме произведенного Microsoft.

«SQL-Server» — это название категории серверов. Аналогично: «FTP-Server». Это как название «хищник» — включает в себя много видов.
Т.к. M$явные маркетологи любят брать название категории для своего продукта — следует уточнять, говорим ли мы о всей категории или же о M$явном продукте.

Иногда приходится, но очень-очень редко нужно больше двух параллельных дисков (точнее 4 потому что обычно это RAID10).

Да не нужен там RAID0 (RAID1 нужен для надёжности). RAID0 даже плох — тормозит в случае, если очередная запись ляжет на два диска (пересечёт границу stripe-блока).

Страшно. Реально страшно. Вы собираетесь ответить пользователю, что транзакция зафиксирована, а на самом деле нет. При сбое вы потом целостность не соберете.

LoL, где я предлагал «ответить пользователю до записи на диск»? Делаем так:
* Запросы на проведение транзакций копятся в RAM-памяти. Клиентам сообщается: «запрос принят в обработку (т.е. повторно слать не надо), но запрос ещё не завершён».
* Запросы/транзакции, не конфликтующие по доступу к данным, объединяются в блоки.
* Затем, при освобождении диска — блок транзакций пишется на диск одной операцией записи. И после этого клиенту можно сказать «транзакция зафиксирована в БД».

Тут есть тонкость: при сбое питания на сервере — клиент должен определить, что принятый в обработку запрос пропал. И сделать это так, чтобы если запрос не пропал — чтобы он не выполнился дважды.
Это решается присвоением каждому запросу уникального id (как обеспечить уникальность — отдельный вопрос; например, с использованием уникального имени клиента и нумерации запросов силами клиента). Повторный запрос с этим же id — распознаётся сервером как повторный; независимо от того, был ли этот запрос выполнен или пока ещё висит очереди. А если первый запрос погиб при сбое питания — то выполняется как новый.

18.06.2018 17:26:25 speshuric

speshuric — Mon, 18 Jun 2018 17:26:25 GMT

На самом деле это уже частности. Главная идея в том, что задержка на LUN (или другое вендор-зависимое название) с 100% последовательной записи на порядок меньше, чем когда есть случайные чтения и записи в тот же LUN. Как конкретно железяка подключена, как эта железяка делает быструю запись мне не настолько важно (пока есть доверие, что записано значит может быть прочитано).
Да, СХД типа VNC или VMax это больше, сложнее и дороже, чем рейд-контроллер. Но по большому счету в этой разнице latency «виновата» не СХД, а ОС, которая для одного «физического» с её точки зрения будет держать одну очередь.

18.06.2018 16:53:22 Yo1

Yo1 — Mon, 18 Jun 2018 16:53:22 GMT

в навороченных схд несколько уровней кеширования. «горячие» блоки гуляют по ssd и прочим кешам. поэтому скорость чтения датафайла утром и ночью запросто различаются на порядок.

18.06.2018 16:47:36 Yo1

Yo1 — Mon, 18 Jun 2018 16:47:36 GMT

18.06.2018 16:33:57 devozerov

devozerov — Mon, 18 Jun 2018 16:33:57 GMT

Звучит загадочно. Таблица просто так не расползается по HDD и SSD. Она находится внутри tablespace, который хранит данные в файлах. Вероятнее всего, в вашем случае речь идет либо о кривой конфигурации, либо о неверных выводах.

18.06.2018 13:57:58 Yo1

Yo1 — Mon, 18 Jun 2018 13:57:58 GMT

а как эти навороченные схд сочетаются с оптимизаторами субд? регулярно наблюдаю проблемы когда оптимизатор оракла собрал статистику в момент когда датафайлы активно использовались и сидели в кеше/ssd, а когда пришло время запускать ночной джоб блоки таблиц вытеснились на тормозные hdd. в результате то что оптимизатор считал, что вычитает за 2 минуты нестед-лупом, в реальности долбит хдд часами.

18.06.2018 11:41:09 n1nj4p0w3r

n1nj4p0w3r — Mon, 18 Jun 2018 11:41:09 GMT

Последовательная запись, как правило проходит мимо весьма небольшого и драгоценного кэша, СХД это чуть большее чем рейд-контроллер из 90х

18.06.2018 10:57:05 Areso

Areso — Mon, 18 Jun 2018 10:57:05 GMT

Говорят, эту проблему решает Intel Optane.

18.06.2018 07:59:48 amarao

amarao — Mon, 18 Jun 2018 07:59:48 GMT

Статья и да, и нет.

Да — если вы мне продадите устройства, у которых в fsync-режиме (iodepth=1, block=4k, random write 100%) гарантированная минимальная latency 5ms, я буду просто счастлив. Почему? Потому что на современных устройствах (SSD, NVME), пики в реальных бенчмарках оказываются в районе секунд, в идеальных случаях — в районе многих сотен милисекунд.

fsync — критическое. Например, первый попавшийся SSD диск выдаёт мне 50кIOPS на запись. sustained, iodepht=32, span=100%, randow write 100%, blocksize=4k.

Но стоит в конфиг теста написать fsync=1, как скорость падает до 300-350IOPS с огромными пиками по latency.

Если что-то тормозит, надо включить writeback. Если что-то теряет данные и портит базу данных — надо выключить writeback.

Т.е. я хочу сказать, что max 5ms write latency как SLA, это безумно круто. Проблема в том, что редко кто готов дать SLA на max, обычно это либо avg, либо (у самых честных) — 99% персентиль. А что такого, если 0.01% операций тупит по 10с? Остальное же быстро! (/сарказм).

18.06.2018 05:20:18 kmu1990

kmu1990 — Mon, 18 Jun 2018 05:20:18 GMT

Это уже другая история. Одно дело сказать, что БД впринципе не может выполнять больше 200 транзакций в секунду, другое дело, что вам для одного логического действия нужно выполнять много последовательных транзакций. Одно утверждение указывает на проблему в БД и сторадже, другое на проблему в ПО, которое использует эту БД.

18.06.2018 00:33:44 Miron11

Miron11 — Mon, 18 Jun 2018 00:33:44 GMT

Все так, и в комментарии все по — моему расставлено по местам.

Надо только напомнить, что встав на ножи с меркетингом, приходится помнить о том, чтобы вовремя менять батарейки и если уйти в отпуск, то придется прилететь в течение 48 часов, чтобы включить машины, иначе батарейки сядут.

Но в общем — то получается экономия как минимум пол миллиона долларов ( самый дешевый SAN ). Хватает на 5 позиций инженеров :) Есть за что бороться.

18.06.2018 00:08:38 speshuric

speshuric — Mon, 18 Jun 2018 00:08:38 GMT

Если WAL лежит отдельно, то есть много вариантов, как хранилищу отчитаться в ОС, что всё сделано. Многие СХД и RAID-контроллеры отвечают, что «всё записано», когда реально данные только попали в память «с батарейкой». 100% записи, последовательной. Там гора вариантов.
Если вы нагрузку WAL бросите в общий котёл, то ничего этого не получите. Там полно в очереди таких, которым «только справочку получить».

17.06.2018 23:46:59 Miron11

Miron11 — Sun, 17 Jun 2018 23:46:59 GMT

Это не страшно, если транзакции будут накапливаться в очереди и записываться на диск одним большим блоком (одной большой операцией записи).

Страшно. Реально страшно. Вы собираетесь ответить пользователю, что транзакция зафиксирована, а на самом деле нет. При сбое вы потом целостность не соберете.
********
Нет, WAL это не совсем то, что Вы говорите. Противоречие начинается в вилке, где сходится энергонезависимая память и построчная запись. Поэтому при настройке системы, даже самый глупый, но аккуратный зануда инженер, без диплома ВУЗа ( как я ) первым делом
1. проверяет, если есть энергонезависимая память, её размеры, и рассчитывает, на краешке рукава, сколько её может / будет использоваться при условии, что система испытывает расчетные нагрузки ( их выясняют у бизнеса )
2. принимают решение, пользоваться или нет этим устройством. И если отказываются, то все как в статье, которую Вы написали, а если принимают, то дальше очень интересно, и совсем иначе. Образ этой кэши выстраивается отдельным устройством. И оно имеет права на параллельные процессы. Которые в свою очередь субъект различных правил оптимизации. И если правила достаточно просты ( прослеживая варианты сочетания транзакций ), а система блокировок верно рассчитана, то тогда все очень хорошо на очень не дорогих запоминающих устройствах. И тогда начинается грызня с маркетингом, которые лишаются тех самых процентов от сделки при покупке СХД.

17.06.2018 23:38:17 Miron11

Miron11 — Sun, 17 Jun 2018 23:38:17 GMT

Вы