Поводом написать эту статью стал весьма достойный обзор Как мы тестировали VMware vSAN... компании КРОК. Обзор-то достойный, но в нем есть фраза, с которой я борюсь уже больше десятка лет. Админы СХД, виртуализаторы и интеграторы раз за разом повторяют: "Задержки в 5 мс — это отличный показатель". Даже цифра в 5 мс десять лет не меняется. Я это слышал вживую от весьма уважаемых админов уже не меньше десятка раз. От менее уважаемых — десятки, а уж сколько раз читал в интернете… Нет, нет, нет. Для OLTP нагрузок 5 мс, особенно так, как их обычно измеряют — это epic fail. Мне приходилось объяснять причины этого уже много раз, на этот раз я решил собрать свои мысли в переиспользуемую форму.
Сразу оговорюсь, что в упомянутой выше статье этих ошибок нет, скорее фраза сработала как триггер.
Типичное начало
Всё что описано в данной статье, верно для распространенных СУБД, используемых для типичной бизнесовой OLTP. Больше всего у меня опыт с MS SQL Server, но, как минимум, для PostgeSQL, Oracle и Sybase многие моменты и выводы также останутся верны.
Производительностью СУБД обычно недовольны все. Если в крупной системе есть СУБД — а она, внезапно, почти всегда есть — то эта СУБД и есть узкое место. Ну или сразу станет узким местом, если начать оптимизировать всё остальное. И вот, приходит заказчик и говорит человеческим голосом: "Помоги! Спаси! Заплатили $NNNNNNNN за сервера и СХД, а скорость не растет! Уж и администратор настраивал и вендор консультировал, а всё равно не шевелится." Если разработчики системы подходят под определение Лаврова (обойдёмся без точной цитаты), а специалисты эксплуатации и сопровождения "борются с инцидентами перезагрузкой сервера", то часто и проблема простая и незатейливая: отсутствуют индексы, кривые запросы, фатальные ошибки настройки (про которые в документации жирным написано "так делать нельзя!!!"), излишние блокировки, взаимоблокировки и прочая простая и понятная ерунда. Таких случаев много, большинство, но не все. Если система в сложности или нагрузке перешла некоторый невидимый предел, то она либо сдохнет от этих проблем, либо перейдёт на следующий уровень.
IMHO, лучшим средством сейчас является SQL Server First Responder Kit, продвигаемый Брентом Озаром. Этот инструмент развивается весьма активно. Еще есть достойный набор от Гленна Берри, он тоже не забросил свой проект. Оба набора по-своему прекрасны, чтение комментариев и запросов в первый раз открывает много нового. Я сам всегда начинаю осматриваться с sys.dm_os_waitsats, беглого взгляда на Error log и выяснения, есть ли хоть сколько-то работающая система резервного копирования.
На этом уровне уже сервер не стоит под столом директора, диски уже не внутри сервера, а в СХД, разработчики знают про индексы, а администраторы уже умеют PowerShell, и менеджеры ИТ начинают говорить умные слова типа SLA и RPO/RTO. Вот на этом уровне возникает интересная ситуация:
- СУБД является узким местом.
- Сервер вроде бы по всем показателям должен быть достаточен.
- Программно СУБД дальше улучшать можно, но сложно (либо переходить на более дорогие лицензии, либо переходить в "красную зону кривой им. Шипилёва" по оптимизации)
- Дисковая система куплена дорогая и, вроде даже как-то настроена.
Ан нет. Крокодил не ловится, не растет кокос, и производительность системы такая же или ниже чем на старом сервере. Смотрю в sys.dm_os_waitsats и вижу WRITELOG, PAGEIOLATCH_SH и PAGEIOLATCH_EX в топе, среднее время ожидания 5+ мс. Ну типично, чо: "Эй, админы и DBA, тут у вас дисковая система — bottleneck" и вот тут начинается старая песня про 5 мс:
- У нас 5 мс по SLA
- Да у нас полка 20000 IOPS тащит
- Нам вендор сказал, что все файлы БД можно на один раздел
- У нас виртуализация и гиперконвергентность и мы не можем выделять отдельные диски под БД
- По нашим данным утилизация сервера 5%
- Всё настроено по рекомендациям
- Вашим БД не нужна большая производительность, она не делает больше 300 IOPS (а у нас же полка на 20000 IOPS)
Кстати, всё вышесказанное не только про "свои" сервера, но и про облачные сервисы и виртуализацию. Там есть кучка своей специфики, но типичная клиническая картина примерно та же: в меру оптимизированная БД, неглупые сотрудники разработки и сопровождения, по процессору и памяти резерв есть, "выхлоп" от дальнейших вложений почти равен нулю.
Так вот. Эта вся песня про "5 мс" чушь и ерунда. Если вы сами такое говорите — читайте эту статью. А если вам такое говорят — готовьте аргументы. Раньше, когда я слышал эти слова, я злился, но я уже не злюсь. У меня, как у того горшка с петуньей из "Автостопом по галактике" только одна мысль: "Ну вот опять...".
Кто виноват?
Почему БД такая медленная? Ну казалось бы, типичный сервер с 20-64 ядрами на частоте 2-3 ГГц способен выполнить 50-150 миллиардов простых операций, а максимальные (синтетические) тесты баз данных показывают на подобных машинах всего лишь 10000-50000 транзакций в секунду. Эй! Это ж от миллиона до десятка возможных миллионов операций на транзакцию. Это не просто много, это очуметь как много.
Такого оверхеда стоят ACID-требования к транзакциям.
- Atomicity — либо вся транзакция выполнена, либо вся не выполнена.
- Consistancy — на входе и на выходе из транзакции система в целостном состоянии
- Isolation — транзакции не видят промежуточных состояний друг друга
- Durability — если уж транзакцию успешно завершили (закоммитили), то вне зависимости от обстоятельств внесенные изменения должны остаться в системе.
К слову, буква-в-букву эти требования не выполняются почти нигде и никогда, а в распределённых системах просто никогда (CAP-теорема мешает). Для нашей ситуации скорее всего дороже других стоит требование "D", это требование обеспечивается ключевым механизмом всех распространенных OLTP СУБД: WAL, write-ahead log (PostgeSQL), он же журнал транзакций (SQL Server), он же REDO log (Oracle). Вот он — камень на шее производительности, и он же фундамент Durability транзакций.
Что такое WAL
Давайте ненадолго забудем про современные SSD, про крутые СХД. Пусть у нас есть сервер, в нем один или несколько дисков.
Любая транзакция, даже вставка одной записи, как минимум потенциально, а на самом деле почти всегда и реально — неатомарное действие. Нам почти всегда нужно изменить не только ту страницу, где лежит запись, но и страницы индексов, возможно, служебные страницы. При этом в одной транзакции одна и та же страница может поменяться много раз. Плюс у нас параллельно могут выполняться другие транзакции. Более того — соседние во времени транзакции постоянно "теребят" одни и те же страницы. Если мы будем дожидаться записи каждой страницы на диск перед продолжением действий, а именно это по сути требуется в Durability, то нам придётся записывать во много раз больше и ждать обязательного окончания каждой записи на энергонезависимый носитель. Никаких кешей, никакой перестановки операций в очереди, а иначе не будет целостности! Более того, нам как-то надо отмечать какие данные уже по фиксированным транзакциям, а какие — ещё нет (и какие были данные раньше). Для понимания — типичный одиночный жёсткий диск (HDD) в таком режиме даст 50-100 IOPS и это константа уже 20 лет. На одну даже маленькую транзакцию потребуется 5-10 операций записи. Ах, да, чтобы знать, что записывать — надо прочитать. Даже очень-очень высоконагруженные на запись OLTP системы читают в раза 3 больше чем пишут. Таким образом наша транзакция стоит 20-40 IO, а значит 0,2-0,8 секунд на диск.
2 транзакции в секунду. Маловато? Давайте попробуем раскидать по дискам? Ой, а нам надо всё равно дожидаться пока предыдущий запишется и параллельность в итоге отсутствует. Как быть? А давайте заведем файл-журнал в который будем последовательно записывать все операции записи в БД и отметки транзакций! Плюсы:
- Информация об операции может быть гораздо компактнее чем запись всей страницы (типичный размер страницы 8 КиБ, информация записываемая в журнал часто 0,5-1 КиБ).
- Вместо записи о том зафиксирована транзакция или нет прямо в страницу — достаточно меток о начале и фиксации транзакции в журнале.
- Страницы можно записывать не после каждой транзакции — ещё в несколько раз меньше. Процесс чтения/записи данных полностью "отвязан" от журнала.
- Главное. Если наш журнал положить на отдельный диск и писать записи последовательно, то за счет того, что не требуется постоянно перепозиционировать головки диска, даже бытовой HDD в таком режиме выжимает до 1000 IOPS, учитывая что мелкие транзакции "стоят" 2-4 записи в журнале, то можно выжать 200-400 TPS
- При сбое состояние файла данных можно восстановить по такому журналу, а при отмене транзакции по нему можно откатить изменения
Такой журнал и называется write-ahead log/transaction log/REDO log.
Ура! Супер! Было 2 транзакции в секунду, стало 300 — улучшили в 150 раз. А какой ценой? Как выясняется, цена значительна:
- Во всех распространенных СУБД запись в журнал строго последовательна. За запись в журнал отвечает один поток. У вас 100 процессоров? Круто. А в журнал всё равно будет писать один поток. Глубина очереди — ровно единица.
- Всё ещё — никаких кешей ОС, никаких перестановок операций. Требования durability остались. Операции write-through: пока диск не ответил "я записал, я точно-точно записал прямо на поверхность, а не в кеш" СУБД не продолжает работу.
- Если файл журнала положить на диск с данными, то почти все преимущества последовательной записи пропадут. Более того — по хорошему, если несколько баз на сервере, то и несколько дисков под журналы.
- Откат транзакций (по крайней мере в MS SQL Server) — прочитать журнал и восстановить по нему состояние. Это столько же или даже больше операций записи, сколько было операций записи в транзакции. Rollback — дорого!
Это объяснение очень упрощенное, "на пальцах". Для нашей темы этого хватит. WAL — ключевой, фундаментальный механизм обеспечения транзакционности, он обязательно write-through, доступ однопоточный только на последовательную запись, с точки зрения хранилища глубина очереди 1.
- Совсем вводная статья Как устроены базы данных
- Для SQL Server есть отличный цикл статей Как перестать называть журнал транзакций SQL Server лог-файлом и прекратить борьбу за его размер.
- Интересно взглянуть немного с другой стороны, вот, например, расшифровка отличного доклада про in-memory СУБД Tarantool
- В каждой СУБД есть обширные разделы, поясняющие работу WAL.
Тему write-ahead logging в БД должен хотя бы в минимальном объёме знать каждый, кто так или иначе администрирует СУБД, или инфраструктуру СУБД, или разрабатывает базы данных.
WAL и СХД
Производители СХД "с рождения" сталкиваются с СУБД. Именно для баз данных бизнес покупает эти безумно дорогие комплексы: от street price хранилищ Dell-EMC, HP, Hitachi, NetApp при верстке бюджета глаза наполняются слезами у большинства топ-менеджеров, если они, конечно, не получат процент от этой цены. Но тут есть инженерно-маркетинговый конфликт. Я его поясню на примере Dell-EMC, но только потому что помню, где у них документация.
Итак:
- Журнал однопоточный, без очереди
- Журнал write-through, то есть задержки (latency) "вечные" по сравнению с производительностью CPU
- OLTP-нагрузки это много относительно небольших транзакций,
- Большинство других нагрузок СУБД так или иначе параллелятся.
Закон Амдала беспощадно говорит нам, что однопоточная низкопроизводительная нагрузка сделает бесполезными добавление процессоров, а производительность будет определяться именно журналом. Более того, в этот момент нам станет наплевать на производительность СХД в IOPS, а станет важным только latency.
Но не стоит сбрасывать со счетов другие дисковые операции — чтение и запись в файлы данных и в tempdb. Чтение — тоже "ждущая" операция. Пока страница данных не прочитана с диска в память, процессор её обрабатывать не может. Но для этих операций возможны большие очереди и перестановка операций в этой очереди: СУБД часто знает, какие страницы надо дозагрузить в память, какие сбросить на диск и ставит в очередь на чтение сразу много. Так как в этом сценарии важно, когда закончится последняя операция из пачки, то в этой нагрузке нам наоборот важнее IOPS, чем latency отдельной операции. Для понимания масштабов: операций чтения в типичной OLTP системе 85%-95%. Да-да-да, операций записи на порядок меньше.
Инженеры-разработчики СХД вендора плотно работают с вендорами СУБД, и отлично понимают все технические нюансы работы СУБД с дисковой подсистемой. Правильное планирование, разбиение и выделение дисковых ресурсов для СУБД — сложная и важная компетенция администратора СХД. У того же Dell-EMC даже базовые white-paper H14621 и H12341 по рекомендациям разбиения для SQL Server — по сотне страниц. Эй! Это не детальная дока, это самый общий white-paper! Там есть ещё куча специфичных (h15142, h16389… там их тьма). Не отстают и "смежники" из VMware — Architecting Microsoft SQL Server on VMware vSphere. Обратите внимание, это документы не только и не столько для DBA, сколько для админов инфраструктуры и СХД.
Ещё отмечу, что во всех этих документах нарезаются отдельные LUN для данных, для журналов и для базы tempdb. Да, где-то в свежих документах аккуратно говорят, что для All-Flash решений нет смысла отделять журналы на физически отдельные носители, но LUNы все ещё предлагают нарезать отдельно. Если данные и журналы свалить в один LUN, то с точки зрения ОС это будет одна очередь IO. И вот тут будет проблема. У операций с журналом latency станет сразу на порядок больше. А из-за того, что в очереди появятся неперемещаемые операции с журналом, просядет IOPS на файлах данных и tempdb. Это не "открытие века", это азбучная истина работы с БД. Она не устарела и не отменена с появлением All-Flash. Да, задержки на операции с SSD быстрее на порядок, чем на операции с HDD, но всё ещё на пару порядков медленнее операций с памятью. IO всё ещё узкое место СУБД.
И в технических документах правильно делается акцент, что в журналах транзакций не важно количество IOPS, а важно, чтобы latency была минимальной (в современных пишут, что менее 1 мс).
А маркетологам надо продавать. Гиперконвергентность! Виртуализация! Гибкость развертывания! Дедупликация! Простота настройки! Много-много IOPS! Красивые презентации, уверенный голос, строгие костюмы. Ну а как иначе продать решение с 6-7-значным ценником в долларах? За этим как-то забывается, что от СХД можно добиться либо latency, либо throughput, но не обоих сразу, что какая-нибудь лицензия на балансировщик нагрузки стоит как еще одна полка, что если интенсивная запись будет длиться больше часа, то оперативной памяти контроллеров не хватит и производительность просядет до "как будто кеша нет", что обучение сотрудников заказчика стоит еще 100000 рублей за первый курс, ну и подобные уловки…
5 мс
То ли наслушавшись-начитавшись маркетологов, то ли от лени, то ли ещё из-за каких-то тараканов, но почему-то часто админы СХД делают примерно так. Берем большую полку, всю её объединяем в что-то плоское, нарезаем на thin provisioned LUNs и раздаём по LUN на сервер. Или по два, потому что "системный раздел хорошо дедуплицируется". А когда, я вижу, что с дисковой подсистемой со стороны SQL ад-ад-ад, то начинается та самая песня, что "5 мс отличный показатель", что "100000 IOPS", "Ваша нагрузка на СХД менее 5%"
НЕТ.
- Для OLTP систем на разделе с WAL/журналами транзакций 5 мс это недопустимый показатель. На "почти-коммодити" железяке за цену в 1000 (прописью: в тысячу) раз дешевле нормальным показателем сейчас будет 0,1-0,3 мс. А завтра — 0,01 мс. Скорость, как у HDD 2008 года по цене целого подъезда квартир в Москве не нужна. Никакое "удобство обслуживания" этого не стоит.
- Вендор пишет, что журналы транзакций не требовательны к IOPS и их можно положить на HDD? Да, это так. Но для этого надо чтобы эти диски ни одна
заразазадача кроме записи журналов СУБД не трогала. И чтобы СХД отвечала серверу, что данные записаны, сразу как данные легли в энергонезависимую память (это гораздо раньше, чем они будут записаны) - "Тонкие" диски для реальных OLTP БД — зло.
- Для WAL абсолютно неинтересно сколько там можно выжать IOPS на глубине очереди 10 или 20. Там нет глубины.
- Для WAL абсолютно не показатель, что очередь IO в ОС "всего лишь около 1". Она не будет больше.
- Нет, DBA и разработчики БД не "дятлы криворукие, которые не могут нормально настроить, чтобы запись в WAL параллелилась" (реальное мнение админа)
- Логика любителей считать утилизацию "раз ваша система нами криво настроенная в один раздел не делает 10000 IOPS, значит её надо перенести с high-end массива на mid-range" — это неправильная логика.
- Если у 40-ядерного сервера загрузка процессора 2,5 процента, то это не значит, что ему нечем заняться, а, скорее всего, значит, что есть какая-то задача, которая блокирует все остальные.
Когда какая-нибудь загрузка данных на ноутбуке разработчика выполняется 5 минут, а на 40 ядерном сервере с 1 ТиБ RAM и СХД за полмиллиона долларов та же самая задача выполняется час, то даже у самых терпеливых заказчиков появятся вопросы обоснованности затрат.
| Средняя задержка на разделе с WAL | никогда не будет в секунду больше транзакций, чем: |
|---|---|
| 5 мс | 200 |
| 1 мс | 1000 |
| 0,5 мс | 2000 |
| 0,1 мс | 10000 |
| 0,05 мс | 20000 |
Что делать
Советы администраторам и DBA
Для OLTP перестаньте считать "утилизацию" и IOPS. Отдельно замечу — совсем не смотрите на IOPS с большой глубиной очереди: даже на разделах с данными большие очереди обычно короткий всплеск или что-то, что не влияет на реальную производительность OLTP.
Делить дисковое пространство на LUN — это не прихоть DBA. У базы данных есть несколько разных профилей нагрузки дисковой подсистемы. Как минимум можно выделить следующее:
- Работа с файлами данных. Обычно это чтение и запись случайными блоками по 8/64 КиБ. Чтений 80-95%. Очереди возникают: в периоды обслуживания, в периоды массовой загрузки, на неэффективных или массовых запросах и при checkpoint. На производительность влияет отзывчивость по чтению. Важно, чтобы выравнивание 8/64 КиБ блоков "всквозную" проходило через всю систему хранения.
- Работа с
tempdb— то же самое, что и работа с файлами данных, но чтений обычно 40-75% и отзывчивость на запись может быть важной. В современных системах MS SQL эта БД может быть загруженной в несколько раз сильнее, чем БД с данными. В некластерной конфигурации СУБД этот раздел должен быть исключен из всяких СХД-шных репликаций. Его содержимое после перезагрузки сервиса всё равно будет уничтожено. - Работа с архивными данными/DWH. Чтений близко к 100%. Размер одного блока чтения обычно 64 КиБ. Запросы читают много и подряд, поэтому очередь может скакать и до 1000 и больше.
- Работа с журналами транзакций. Чтение только для обслуживания (резервное копирование, репликация и т.п.), на производительность приложений влияет только запись. Запись блоками 0,5-64 КиБ. Без очереди, в один поток. Задержка критична для приложений.
- Резервное копирование и восстановление. С точки зрения БД это чтение большими блоками (часто 1 МиБ). Важно, что эта нагрузка может упереться в каналы/шины (и FC, и Ethernet) и в производительность процессоров СХД в некоторых случаях. Резервное копирование одного сервера может повлиять на производительность других серверов того же SAN/СХД.
- Работа с файлам приложения: это логи, default trace, бинарные файлы и т.п. Эта нагрузка редко бывает существенной и важна только при старте системы.
Есть и другие виды нагрузки, но они слегка экзотичны (например, может быть хранилище файлов, хранящихся в БД в виде каталога FileStream). У всех этих видов нагрузки разные, зачастую противоречащие требования к дискам. Если они все свалены на один раздел, то вы не только ухудшаете производительность, но очень важно, что лишаетесь возможности понять из-за чего система тормозит, а также лишаетесь возможности улучшить только ту часть которая требует улучшения без глобальных улучшений/апгрейдов СХД. Поэтому главная рекомендация:
Ознакомьтесь с рекомендациями производителя СХД и СУБД, постарайтесь разобраться "почему они так советуют" и спроектируйте систему с учетом разных видов нагрузки. Разнесите принципиально разные виды нагрузки на разные разделы.
Ну и до кучи
- Читайте не маркетинговый бред, а техническую документацию. Для Dell/EMC и SQL Server начните со ссылок в статье.
- Техническую документацию проверяйте замерами. Эти замеры сравнивать с неким "коммодити" примером (например, на NUCах c SSD, как вариант, да). Работайте по циклу гипотеза-проверка-анализ, честно проверяя свои гипотезы.
- Администраторам СХД и ферм виртуализации нужно планировать развертывание вместе с DBA, если там будут сколько-то нагруженные БД (даже 200 транзакций в секунду).
- Если у вас используется геораспределённная синхронная кластеризация (МetroСlaster и его родня), посмотрите, не вносит ли он задержек, которые недопустимы. Эти кластеризации могут давать запросто +0,5 мс, и когда было 0,2, а с кластером стало 0,7 то производительность упадет до 3 раз.
- Проектировать надо понимая, что со временем ситуация изменится и что систему потребуется изменять. Если у вас сейчас раздел
tempdbне нагружен, то, возможно, разработчики БД в следующей версии включат RCSI и в 12 чаов ваша карета превратится в тыкву. - Latency почти всегда важнее throughput. И это продолжает быть верным и в облачных технологиях, и в "гиперконвергентных системах", и виртуальных фермах. Если вы улучшаете throughput увеличивая latency, то скорее всего ошибаетесь. Такое делать можно только очень обоснованно.
MS SQL Server
Если говорить про MS SQL, то на самом деле есть некоторое количество способов снизить нагрузку на bottleneck журнала транзакций, может кому-то поможет:
- Часто я вижу рекомендацию не делать большие транзакции. Это правильно. Но транзакции не должны быть и слишком мелкими. 1000 транзакций подряд вставляющие по одной строке могут быть в 5-30 раз дольше одной транзакции с 1000
INSERT. И, да, напомню, что если вы не открыли транзакцию явно, то поведением по умолчанию будет "каждая команда — отдельная транзакция". - У
tempdbжурнал транзакций "не настоящий". У него есть кеширование. Поэтому, если вам нужны промежуточные вычисления, то не делайте их в постоянных таблицах. - Если нужно вставить много записей, то следует использовать BULK INSERT или другой вариант минимально протоколируемых операций. Минимально протоколируемыми могут быть только операции типа вставки записей и перестроения индекса, и только в моделях восстановления "Simple" и "Bulk logged". И, кстати, во всех остальных случаях разницы производительности между моделями Simple/Bulk logged и Full нет никакой. По массовой загрузке до сих пор самое полезное — The Data Loading Performance Guide, но эта статья постепенно устаревает. На закуску (правда про ETL, а не OLTP) ещё одна статья почти десятилетней давности We Loaded 1TB in 30 Minutes with SSIS, and So Can You
- В свежих версиях SQL Server есть Delayed Transaction Durability — режим, в котором можно получить производительность ценой надёжности.
- В свежих версиях SQL Server есть In-Memory OLTP. Технология с кучей ограничений, но при грамотном точечном применении может оказаться полезной.
- Посмотрите, нет ли ненужных синхронных зеркалирований, ненужных синхронных AlwaysOn реплик.
***
Вот и всё. Нет никой магии. 20000 IOPS с 5 мс latency и с очередью 4-16 ничего не говорит о производительности СХД для задач OLTP. Для OLTP надо правильно размечать СХД, правильно выбирать метрику производительности и уметь измерять её.
На горизонте есть очень интересный новый участник борьбы за производительность систем хранения для БД. Это Intel Optane. У нынешних SSD "красивые" цифры производительности начинаются от глубины очереди 4, что на самом деле не очень жизненно. Плюс эта производительность на запись обеспечивается некоторым объёмом оперативной памяти внутри SSD, и, если запись идёт достаточно интенсивно, то потом наступает существенная деградация производительности. А еще у SSD ограничен ресурс. Да, у современных серверных и топовых "гражданских" он достаточно большой, но совсем не бесконечный. И тут на сцене появляется Intel Optane: судя по тестам несерверных моделей (раз, два ) задержки на случайных операциях на очереди глубины 1 выходят на уровень около 20 микросекунд. Это по сути без кеширования, без деградации. SSD при таком же профиле начинают тупить до 100-300 мкс. Ресурс уже сейчас выходит за типичный ресурс SSD.
Ну цена, да. Но потенциально эта железка открывает новые горизонты производительности OLTP "традиционной", не in-memory архитектуры без отказа от ACID. А с другой стороны latency 20 мкс заставляет задуматься о судьбе "обычных" СХД. На low-latency требованиях им будет очень тяжело конкурировать с Optane (снова привет встроенным системам хранения?).
Это всё очень круто и я надеюсь на успех (и подешевление) Optane.
Комментарии (53)
gridem
17.06.2018 21:43+1К слову, буква-в-букву эти требования не выполняются почти нигде и никогда, а в распределённых системах просто никогда (CAP-теорема мешает).
CAP теорема и ACID — это ортогональные вещи, и одно другому не мешает. См. Spanner, Cockroach DB, YT. Поэтому про "никогда" я бы не говорил в таком разрезе.
speshuric Автор
17.06.2018 22:54Я и согласен и нет. Про ортогональность: хотя буква C в CAP (consistency, availability, partition tolerance) и означает совсем не то, что C в ACID, но эти темы не ортогональны. C в CAP по значению почти эквивалент значению буквы D из ACID. Так, что вы в целом правы, что «не мешает», но вот с «ортогональны» я не соглашусь.
А вообще, все СУБД (и распределённые и нет) достаточно «творчески» подходят к ACID, нераспределенные особенно к I — isolation (любые уровни изоляции отличные от SERIALIZABLE нарушают изоляцию), распределенные к C и D (плюс там хитрый вопрос что такое раньше/позже).kmu1990
18.06.2018 00:11+1C в CAP и D в ACID имеют очень мало чего общего (кроме того что они соседние буквы в алфавите), любой мусор можно зафиксировать на диске, сообственно есть системы хранения которые так и делают. Кроме того когда вы говорите о невозможности и упоминаете CAP, вам нужно найти соответсвия сразу C и A из CAP в ACID, в противном случае CAP без C или A не особо что-то ограничивает. Т. е. даже если мы на секунду забудем что C из CAP не имеет соответсвий в ACID, то нам все еще придется разобраться с A из CAP и наоборот.
SergeyMax
17.06.2018 23:47Для OLTP систем на разделе с WAL/журналами транзакций 5 мс это недопустимый показатель
А вот в доке EMC, на которую вы ссылаетесь, написано, что 5 мс — это Excellent для данных, и Very good — для транлогов. Кому верить?speshuric Автор
18.06.2018 00:18+1Кому верить?
Никому. Серьёзно. У EMC цифры "что такое хорошо" меняются год от года. Сколько могут прямо щас — столько и Excellent. Вот в H12341 (октябрь 2013) и H14621 (декабрь 2015):
Судя по тому что цифры в них одинаковые, эта табличка не менялась уже пять лет.
В другом документе цифры меньше, но он тоже 2013 года.
И за эти 5 лет как раз почти всюду в high load стали использоваться All flash SSD решения. Тут надо не верить, а смотреть на конкретную СХД и выжимать из неё производительность. 1 мс было отлично 5 лет назад, но это не значит, что сейчас нельзя достигнуть большего.
Karpion
18.06.2018 01:53+1Даже цифра в 5 мс десять лет не меняется.
Это примерно соответствует 12'000 оборотов в минуту — если считать, что задержка равна одному обороту диска. Ну и с чего ей меняться, если диаметр диска не меняется, и скорость звука тоже?
Советы по диагностике SQL Server
Это для любого SQL-сервера? Или для какого-то одного?
Никаких кешей, никакой перестановки операций в очереди, а иначе не будет целостности!
Вообще говоря, перестановки возможны. Но там надо тщательно следить за тем, чтобы перестановки были не любые, а только допустимые. И я не уверен, что дисковой подсистеме (отдельному диску и/или СХД) можно объяснить, что можно переставлять, а что нельзя.
чтобы знать, что записывать — надо прочитать
Можно выравнивать записи СУБД на размер сектора. Правда, с индексами будет тяжко — они маленькие…
Но кстати — прочитанное можно свободно кэшировать и использовать повторно.
На одну даже маленькую транзакцию потребуется 5-10 операций записи.
Операции одной транзакции — свободно раскидываются по дискам.
Давайте попробуем раскидать по дискам? Ой, а нам надо всё равно дожидаться пока предыдущий запишется и параллельность в итоге отсутствует.
Если наш журнал положить на отдельный диск и писать записи последовательно
А если разделить журнал на несколько дисков?
за счет того, что не требуется постоянно перепозиционировать головки диска
Дело не в позиционировании головок. А в ожидании прихода под головку нужного сектора.
Во всех распространенных СУБД запись в журнал строго последовательна.
А что мешает нескольким процессорам готовить записи для журнала и складывать их главному процессору для записи? Главный процессор окажется вообще не нагружен — узким местом будет диск.
Всё ещё — никаких кешей ОС, никаких перестановок операций.
Это не страшно, если транзакции будут накапливаться в очереди и записываться на диск одним большим блоком (одной большой операцией записи).
администраторы уже умеют PowerShell
А почему не Bash?speshuric Автор
18.06.2018 02:25+2Ну и с чего ей меняться, если диаметр диска не меняется, и скорость звука тоже?
Например, с того, что сейчас почти везде используются SSD. Впрочем, 10 лет назад разделение по дискам имело более критичное значение.
Это для любого SQL-сервера?
Я не знаю другого продукта на рынке, который называется именно "SQL Server" кроме произведенного Microsoft. Но, согласен, лучше было уточнить.
… Вообще говоря, перестановки возможны…
… выравнивать записи…
… свободно раскидываются по дискам...Наверное, возможно многое. Но сейчас write-ahead logging является одним из основных ограничений производительности. И эта бодяга тянется как минимум с 1992 года.
А если разделить журнал на несколько дисков?
Иногда приходится, но очень-очень редко нужно больше двух параллельных дисков (точнее 4 потому что обычно это RAID10). Что нужно сделать чтобы узким местом стал отдельный SSD для WAL я даже не представляю.
Это не страшно, если транзакции будут накапливаться в очереди и записываться на диск одним большим блоком (одной большой операцией записи).
Страшно. Реально страшно. Вы собираетесь ответить пользователю, что транзакция зафиксирована, а на самом деле нет. При сбое вы потом целостность не соберете.
А почему не Bash?
Поздравляю, вы нашли пасхалку :) Именно PowerShell написано осознанно. Администрировать linux, не зная bash — невозможно. А называться администратором Windows не зная PowerShell — сложно, но возможно.
Miron11
18.06.2018 02:46-1Это не страшно, если транзакции будут накапливаться в очереди и записываться на диск одним большим блоком (одной большой операцией записи).
Страшно. Реально страшно. Вы собираетесь ответить пользователю, что транзакция зафиксирована, а на самом деле нет. При сбое вы потом целостность не соберете.
********
Нет, WAL это не совсем то, что Вы говорите. Противоречие начинается в вилке, где сходится энергонезависимая память и построчная запись. Поэтому при настройке системы, даже самый глупый, но аккуратный зануда инженер, без диплома ВУЗа ( как я ) первым делом
1. проверяет, если есть энергонезависимая память, её размеры, и рассчитывает, на краешке рукава, сколько её может / будет использоваться при условии, что система испытывает расчетные нагрузки ( их выясняют у бизнеса )
2. принимают решение, пользоваться или нет этим устройством. И если отказываются, то все как в статье, которую Вы написали, а если принимают, то дальше очень интересно, и совсем иначе. Образ этой кэши выстраивается отдельным устройством. И оно имеет права на параллельные процессы. Которые в свою очередь субъект различных правил оптимизации. И если правила достаточно просты ( прослеживая варианты сочетания транзакций ), а система блокировок верно рассчитана, то тогда все очень хорошо на очень не дорогих запоминающих устройствах. И тогда начинается грызня с маркетингом, которые лишаются тех самых процентов от сделки при покупке СХД.speshuric Автор
18.06.2018 03:08+1Если WAL лежит отдельно, то есть много вариантов, как хранилищу отчитаться в ОС, что всё сделано. Многие СХД и RAID-контроллеры отвечают, что «всё записано», когда реально данные только попали в память «с батарейкой». 100% записи, последовательной. Там гора вариантов.
Если вы нагрузку WAL бросите в общий котёл, то ничего этого не получите. Там полно в очереди таких, которым «только справочку получить».Miron11
18.06.2018 03:33+1Все так, и в комментарии все по — моему расставлено по местам.
Надо только напомнить, что встав на ножи с меркетингом, приходится помнить о том, чтобы вовремя менять батарейки и если уйти в отпуск, то придется прилететь в течение 48 часов, чтобы включить машины, иначе батарейки сядут.
Но в общем — то получается экономия как минимум пол миллиона долларов ( самый дешевый SAN ). Хватает на 5 позиций инженеров :) Есть за что бороться.
n1nj4p0w3r
18.06.2018 14:41Последовательная запись, как правило проходит мимо весьма небольшого и драгоценного кэша, СХД это чуть большее чем рейд-контроллер из 90х
speshuric Автор
18.06.2018 20:26На самом деле это уже частности. Главная идея в том, что задержка на LUN (или другое вендор-зависимое название) с 100% последовательной записи на порядок меньше, чем когда есть случайные чтения и записи в тот же LUN. Как конкретно железяка подключена, как эта железяка делает быструю запись мне не настолько важно (пока есть доверие, что записано значит может быть прочитано).
Да, СХД типа VNC или VMax это больше, сложнее и дороже, чем рейд-контроллер. Но по большому счету в этой разнице latency «виновата» не СХД, а ОС, которая для одного «физического» с её точки зрения будет держать одну очередь.
Karpion
18.06.2018 20:27+1Например, с того, что сейчас почти везде используются SSD.
Я слабо слежу за темой. Но мне кажется, SSD приличного размера (пригодного для корпоративных БД) всё ещё имеют неприличную цену.
Я не знаю другого продукта на рынке, который называется именно «SQL Server» кроме произведенного Microsoft.
«SQL-Server» — это название категории серверов. Аналогично: «FTP-Server». Это как название «хищник» — включает в себя много видов.
Т.к. M$явные маркетологи любят брать название категории для своего продукта — следует уточнять, говорим ли мы о всей категории или же о M$явном продукте.
Иногда приходится, но очень-очень редко нужно больше двух параллельных дисков (точнее 4 потому что обычно это RAID10).
Да не нужен там RAID0 (RAID1 нужен для надёжности). RAID0 даже плох — тормозит в случае, если очередная запись ляжет на два диска (пересечёт границу stripe-блока).
Страшно. Реально страшно. Вы собираетесь ответить пользователю, что транзакция зафиксирована, а на самом деле нет. При сбое вы потом целостность не соберете.
LoL, где я предлагал «ответить пользователю до записи на диск»? Делаем так:
* Запросы на проведение транзакций копятся в RAM-памяти. Клиентам сообщается: «запрос принят в обработку (т.е. повторно слать не надо), но запрос ещё не завершён».
* Запросы/транзакции, не конфликтующие по доступу к данным, объединяются в блоки.
* Затем, при освобождении диска — блок транзакций пишется на диск одной операцией записи. И после этого клиенту можно сказать «транзакция зафиксирована в БД».
Тут есть тонкость: при сбое питания на сервере — клиент должен определить, что принятый в обработку запрос пропал. И сделать это так, чтобы если запрос не пропал — чтобы он не выполнился дважды.
Это решается присвоением каждому запросу уникального id (как обеспечить уникальность — отдельный вопрос; например, с использованием уникального имени клиента и нумерации запросов силами клиента). Повторный запрос с этим же id — распознаётся сервером как повторный; независимо от того, был ли этот запрос выполнен или пока ещё висит очереди. А если первый запрос погиб при сбое питания — то выполняется как новый.
amarao
18.06.2018 10:59Статья и да, и нет.
Да — если вы мне продадите устройства, у которых в 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с? Остальное же быстро! (/сарказм).Areso
18.06.2018 13:57Говорят, эту проблему решает Intel Optane.
amarao
19.06.2018 12:17Пока не щупал, но то что официалы говорят — не очень. Так же средняя latency. Которая стала ниже, но… Вот стоит субд, мурыжит тысячи операций в секунду. Тут, раз, задержка в 10с на одно IO. Как такое объяснять? «База данных ушла на базу. Вас много, я одна».
Areso
19.06.2018 12:54Т.е., по-вашему, это проблема в СУБД, а не в железе?
Что является источником такой проблемы?amarao
19.06.2018 15:25Нет, конечно. Это проблема дисков снизу. Но для пользователя всё равно виновата база, потому что «тормозит». Причём на тестах ССД хорошо, а потом херак транзакиция и человек своими глазами видит, как insert в пустую таблицу на 1кб выполняется 10с с localhost'а.
speshuric Автор
19.06.2018 13:11Судя по тестам, там задержка не сильно ниже, но она на очереди 1 близка к константе. Там нет хитроштопанной логики и кешей и нет жирных CoW, как на SSD. Обычные SSD «на коротких дистанциях» компенсируют это кэшем, и именно поэтому в обычных тестах оптаны показывают себя очень близко к обычным хорошим SSD. А выигрывают в проигрышных для SSD вариантах типа 100% random write 4kQ1.
Хотя я тоже пока подожду готовых решений. Может в жизни всё и не так радужно.
speshuric Автор
18.06.2018 20:37Ну во-первых WAL это всё-таки не random, а seq. Во-вторых WAL может быть и не 4k за порцию, а меньше. Но я согласен, что SSD и тут может давать выбросы. И, кстати, на выделенных HDD многие СХД выжимают очень и очень хорошую производительность в этом режиме, так что упираются в каналы.
И, как заметил предыдущий комментатор, я расчитываю на прорыв Intel Optane. Посмотрите мой PS про SSD. Более того, если оптаны не обладают каким-то скрытым изъяном, то те скорости (задержки), которые они дают, делают спорным применение SAN/СХД на критичных к производительности приложениях. На VMax/VNC и подобных СХД пока еще никто не заморачивается на roundtrip до конечного приложения в десятки микросекунд.
amarao
19.06.2018 12:18+1Мне удавалось получить адские задержки на последовательном IO тоже. Ключевое — fsync. Поскольку ssd не может записать внутри себя 4к блок, то там всё равно происходит CoW (copy on write), который может утыкаться в GC и тормозить всё. Как раз жёсткие диски в линейной записи чувствуют себя круче, чем SSD.
speshuric Автор
19.06.2018 13:15Мы об одном и том же :)
на выделенных HDD многие СХД выжимают очень и очень хорошую производительность [в режиме seq write]
и
Как раз жёсткие диски в линейной записи чувствуют себя круче, чем SSD.
Yo1
18.06.2018 16:57а как эти навороченные схд сочетаются с оптимизаторами субд? регулярно наблюдаю проблемы когда оптимизатор оракла собрал статистику в момент когда датафайлы активно использовались и сидели в кеше/ssd, а когда пришло время запускать ночной джоб блоки таблиц вытеснились на тормозные hdd. в результате то что оптимизатор считал, что вычитает за 2 минуты нестед-лупом, в реальности долбит хдд часами.
devozerov
18.06.2018 19:33Звучит загадочно. Таблица просто так не расползается по HDD и SSD. Она находится внутри tablespace, который хранит данные в файлах. Вероятнее всего, в вашем случае речь идет либо о кривой конфигурации, либо о неверных выводах.
Yo1
18.06.2018 19:53+1в навороченных схд несколько уровней кеширования. «горячие» блоки гуляют по ssd и прочим кешам. поэтому скорость чтения датафайла утром и ночью запросто различаются на порядок.
speshuric Автор
18.06.2018 20:50Нет никакой загадки. Простейший и типичный кейс. Есть уровень, который хранится на HDD 7200 (tier2), и есть его кеш примерно на 10% по объёму на SSD (tier1). Ночью запускается обслуживание БД: резервное копирование, перестроение индексов, пересчет статистик. В итоге утром в tier1 какая-то хрень, а не нужные данные. Просто потому что СХД не обладает достаточной информацией о значении данных.
speshuric Автор
18.06.2018 20:41Есть такая проблема, для каждого вида нагрузки нужны фактически свои политики гуляния по tier'ам. Но вендоры СХД обычно предоставляют рекомендации.
А моё личное мнение, что для СУБД все эти «интеллектуальные» кеши уровня СХД — больше геморроя, чем пользы.
Yo1
18.06.2018 19:47в навороченных схд несколько уровней кеширования. «горячие» блоки гуляют по ssd и прочим кешам. поэтому скорость чтения датафайла утром и ночью запросто различаются на порядок.
romxx
18.06.2018 20:52+2А чего гиперпконвергенция? А вот вам гиперконвергенция:
Детали тут: longwhiteclouds.com/2017/11/14/1-million-iops-in-1-vm-world-first-for-hci-with-nutanix
Вот вам миллион рандомных IOPS блоком 8K в fio при 0,11ms IO latency.
Это просто не все гиперконвергенции одинаковы :)amarao
19.06.2018 12:20А когда fio закончит, покажите-ка его вывод с latency. Интересует max.
romxx
19.06.2018 14:02Тест шел сутки, это — средние steady результаты. За сутки там уж конечно что-то в max выстрелило, но это непоказательно.
amarao
19.06.2018 15:28Вы знаете, если бы дизайнеры автомобилей так делали, то было бы «за три года вождения max latency на повороте руля выстрелила несколько раз, но это не показательно. 99.9% поворотов руля отрабатывают за меньше чем 5мс, а что 0.01% — больше нескольких секунд — ну кого эти аварии волнуют?»
speshuric Автор
19.06.2018 19:34Это ж классика
Моя задача заключается в правильном применении секретной формулы.
Чистая арифметика.
Классическая задачка из учебника.
Если новая машина, произведенная компанией, на которую я работаю, выехала из Чикаго со скоростью шестьдесят миль в час, и тут у нее заклинило дифференциал, и она улетела в кювет, разбилась, бензобак взорвался и все, кто были в салоне, сгорели заживо, должна ли компания отозвать все проданные автомобили этой модели на доработку?
Возьмите общее количество проданных на настоящий момент автомобилей (А), умножьте на среднее количество серьезных отказов (В), а затем умножьте произведение на среднюю стоимость урегулирования иска родственников пострадавших во внесудебном порядке (С).
А х В х С = X. Вот во сколько нам обойдется проблема, если мы не будем отзывать модель на доработку.
Если Х превышает стоимость доработки, томы производим доработку, и аварий больше не бывает.
Если Х меньше, чем стоимость доработки, то мы доработку не производим.Чак Паланик, "Бойцовский клуб"
amarao
19.06.2018 21:28Вы передёргиваете цифры.
Если у нас 0.01% операций (на самом деле цифра ниже, примерно одна из 100000) занимает 10 секунд, а оставшиеся — 5мс, то средняя latency — 5ms. И медианная latency — 5ms. И даже 99.99% персентиль — 5ms. Но при этом каждый пользователь высоконагруженной системы сталкнётся с задержками в 10с. Почему? Потому что любое устройство в продакшене обслуживает куда больше, чем 1000000 операций за своё время. Некоторые столько обслуживают за час, или даже за 10 минут.
И вот субд, которая раз в десять минут фризится на 10 секунд.
Тут же проблема не в «производители мудаки», а «покупатели не на ту метрику смотрят».speshuric Автор
20.06.2018 00:29У меня в комменте не было ни одной цифры, я не мог их передернуть. У меня было только вспомненное место из художественной книги :)
Да еще и наглядно иллюстрирующее подход.
Или я что-то не понял?
romxx
19.06.2018 21:51«Плохая аналогия — это хуже, чем никакой аналогии». В данном случае аналогия явно хромает. Если вы увидите, что после 24-часового теста значение max — полсекунды, например, при этом — это значение пришлось на первые три секунды с момента старта 24-часового теста, то само по себе что это вам даст полезного?
Так что аналогия с автомобилем, тут скорее другая будет, что конструкторы рассчитывают, что за миллион поворотов руля только один раз произойдет поломка.ildarz
20.06.2018 12:07Ну так покажите распределение латентности, а не average (причем желательно не случайное чтение с очередью 32, а последовательную запись с очередью 1), и не нужны будут никакие аналогии. А так приведенные вами цифры в свете озвученных в статье проблем не значат ровным счетом ничего.
kmu1990
Пусть задержка по записи 5мс и мы пишем в журнал всегда последовательно. Если в базе данных параллельно выполняется N независимых транзакций, кто мешает объединить эти транзакции в одну запись в журнал? Если зависимость по данным отсутствует (и даже иногда когда она присутствует, но мы можем опустить этот случай для простоты) писать каждую транзакцию отдельным IO в журнал нет необходимости. Т. е. даже если каждая отдельная запись в журнал это 5мс, если эта запись коммитит сразу несколько транзакций то можно получить больше чем 200 транзакций в секунду и IO очередь при этом не нужна.
speshuric Автор
Я не знаю даже теоретического разумного решения, как определить, что транзакции независимы. То, что сейчас у них записи в разные таблицы — не показатель. Наверное, теоретически можно прикрутить какую-то эвристику, но сейчас ни в одной СУБД этого нет. Гораздо чаще, как в упомянутом Delayed Transaction Durability, идеальное соблюдение принципа приносится в жертву производительности.
kmu1990
1. Теоретически и даже практически разумные решения существуют и существовали довольно долгое время, например, классический 2PL автоматически заблокирует транзакцию, которая обращается к данным используемым другой транзакцией. Ниакой эвристики не нужно.
2. Транзакции совсем не обязательно должны быть независимы, нужно просто коммитить зависимые транзакции вместе.
speshuric Автор
2PL работает совсем на другом уровне. Плюс тут же вопрос даже не в коммите. Коммит — это просто записать в журнал, что транзакция с таким-то LSN закоммичена. В WAL пишется всё подряд и однопоточно. И реализовать запись корректной последовательной цепочки всех изменений с достаточной надёжностью и хитрой обработкой параллельность пока ни в одной СУБД, видимо, не смогли.
В том же MS SQL небольшой кэш для транзакций есть (см тут), но он для другого случая, когда транзакция записывает много данных.
В любом случае статья не о том, как "можно было бы сделать СУБД", а о том "как те СУБД которые есть заставить работать". При нормальном разбиении дисков 5к-20к TPS выжать на продакшн вполне можно. С оговорками про конкретную задачу и бюджет.
kmu1990
2PL работает на том уровне на котором его реализуют, так что я не очень понял на каком таком другом уровне он работет? Если он работает на уровне записей базы данных, то этого вполне достаточно.
Запись LSN в журнал — всего лишь одна из возможных реализаций коммита. Кроме того писать в WAL все подряд нет необходимости — это опять же всего лишь одна из возможных реализаций.
Более того, даже если допустить, что все существующие БД пишут в WAL все подряд, это совершенно никаким образом не запрещает объединить несколько обновлений WAL в 1 IO. Элементарно, в какой-то момент БД должна определить, что нужно записать в журнал. Все что нужно это просто подождать какое-то время перед тем как непосредственно выполнять эту запись и собрать данные с нескольких транзакций. Максимальная задержка может возрасти, но и параллельность при это тоже возрастет. Ничего хитрого в этом нет, простая пакетная обработка и амортизация затрат времени.
fivehouse
Так и работают уже давно все современные БД. Только этого не достаточно. Логика существенной части ПО выстроена на большом количестве (напр 400 в сек) последовательных транзакций для самых элементарных вещей. И там приходится всегда ждать физического окончания комита.
kmu1990
Это уже другая история. Одно дело сказать, что БД впринципе не может выполнять больше 200 транзакций в секунду, другое дело, что вам для одного логического действия нужно выполнять много последовательных транзакций. Одно утверждение указывает на проблему в БД и сторадже, другое на проблему в ПО, которое использует эту БД.
Yo1
на самом деле оракл еще с глубокой древности имел возможность поднимать несколько процессов пишущих в REDO лог. то была фича когда еще была распространена NUMA архитектура и предлагали на каждой партиции NUMA свой процесс писанинины в лог поднимать. другое дело что особо смысла это не имеет, т.к. нормально настроенный REDO запросто на hdd успевает писать десятки миллионов транзакций однопоточно. в тестах tpc.org и поболее есть тесты, при этом один процесс и hdd справляются.
VerdOrr
Пардон, что значит «была распространена NUMA архитектура»? Какая, по вашему, архитектура у современных двух- и более процессорных систем? С собственным контроллером памяти у каждого процессора и относительно медленными соединениями между ними? Другой вопрос, что в 2-/4-процессорных системах, из которых, в основном, сейчас строятся кластеры, накладные расходы относительно невелики. Но они есть и «special care must be taken in vCPU and vNUMA configuration to ensure performance is optimized»
smagen
В PostgreSQL есть подобное. Только записи WAL не объединяются, а просто процесс, который собирается сделать fsync на WAL, может подождать других. См. параметры commit_delay и commit_siblings.
postgrespro.ru/docs/postgrespro/10/wal-configuration
kmu1990
Из описания это не совсем то что я имел ввиду, или даже совсем не то, что я имел ввиду. Контрольные точки отмечают моменты в которых достоверно известно, что все предшествующие записи в журнале больше не нужны и могут быть удалены, между контрольными точками журнал все еще пишется и количество использованых IO операций при этом никак не контроллируется этими контрольными точками.
kmu1990
А хотя нет, вы правы, commit_delay на самом деле как раз то что я описывал выше, прошу прщения за невнимательное чтение.