Последние изменения в IO-стеке Linux с точки зрения DBA

[bzzz00]

Вторая частая проблема — сбой записи Write-Ahead Log. Проявляется, когда нагрузка настолько мощная, что даже последовательно записываемый журнал упирается в диск.

странная формулировка, так скажу.

[BasicWolf]

Интересный материал, но читается очень тажело. Такое ощущение, что текст писал Йода одновременно отражая массированную атаку штурмовиков.

[Vitaly2606]

Это уже не субд.

[nikolayv81]

И не на обычном железе для app а на специальном, и мы так плавно подходим к существующим аппаратно-программным комплексам, но остаётся один вопрос, что делать тем чьи доходы не дают возможности использовать специализированные решения?

[slysha]

Откуда инфа про наслоение чекпоинтов???

[vadv]

ну как откуда, в control-файле же информация про два checkpoint'а

[leon_ti]

В статье упор сделан на NVMe. Вопрос: эти изменения как-то отражаются в работе SATA SSD?

[ultimate_darkness]

Насколько я знаю, история с перестройкой блочного стека (blk-mq) началась с nvme, т.к. там на аппаратном уровне много очередей обработки запросов, которые было сложно эффективно загрузить существующей на тот момент инфраструктурой.

В sas и sata (который в linux реализуется трансляцией из scsi -> ata) множества очередей нет, так что и профит от blk-mq будет совсем не такой, как на nvme.

Еще была отдельная история с оптимизацией некоторых драйверов sas hba под blk-mq, но руками трогать это не приходилось.

Короче, вряд ли мы увидим драматическое улучшения работы sata ssd. Да и те, кому это надо скорее перейдут на nvme.