Для ЛЛ: сложности отладки производительности дисковых подсистем в среде виртуализации.

Каждый вечер, когда солнце прячется за верхушки сосен, на небе зажигаются звезды, а где-то в лесу неподалеку начинает ухать сова, которую мы уже два месяца не можем поймать, чтобы сварить из нее суп, - так вот: каждый раз, когда на нашу свалку опускается темнота, вся детвора собирается вокруг ржавого чайника в пустой нефтяной цистерне на западной окраине, чтобы попить кипятка, съесть по кусочку сахара и послушать сказку на ночь.

 (проследовать за кроликом)

Зашел в нашем колхозном клубе разговор о том, как в конфету "подушечку" варенье попадает, и постепенно перешли на то, как данные из приложения попадают на диск, и где можно на граблях попрыгать, и на взрослых, и на детских.

Итак, у нас есть «данные».
Если речь заходит о том, что надо быстро и много работать с хоть сколько-то большими объемами данных, то обычно у производителя есть рекомендации «как лучше организовать дисковое пространство». Обычно. Но не всегда.

Общеизвестно, что:
Microsoft SQL работает с страницами по 8 кб, а сохраняет данные экстентами (extent) по 8 страниц – 64 Кб, и рекомендации для MS SQL - cluster (NTFS allocation) size в 64 Кб.  (1) . Все просто, все понятно, и.

И даже есть статья Reading Pages / cчитывание страниц про  Read-Ahead (Упреждающее чтение) экстентами по, вроде как, 64к, хотя прямо на странице этого не указано.

Для Oracle все тоже как-то описано – есть статья Oracle Workloads and Redo Log Blocksize – 512 bytes or 4k blocksize for redo log (VMware 4k Sector support in the roadmap) Oracle Workloads and Redo Log Blocksize – 512 bytes or 4k blocksize for redo log (VMware 4k Sector support in the roadmap)

Для PostgreSQL на Windows пишут просто: и так сойдет!- The default allocation unit size (4K) for NTFS filesystems works well with PostgreSQL.

Что там рекомендуют в проприетарном Postgrepro?

Да ничего, вместо документации и тестов – обсуждение на тему 8Kb or 4Kb ext4 filesystem page size из 2019 года.

Ладно, для простоты (более полная и занудная версия про размеры страниц в памяти будет на Пикабу) будем считать (хотя это и не всегда верно), что из приложения в Linux вылетит пакет размером 4к в сторону диска.

И, в первую очередь пакет попадет в буфер ОС, оттуда отправится в очереди, потом в драйвер диска, затем операция будет перехвачена гипервизором, и перенаправлена туда, куда гипервизор посчитает нужным. Если вы работаете не в среде виртуализации, а в контейнерах, то там все еще интереснее.

Настоящие проблемы только начинаются

Пропустим ту часть, где Linux отвечает приложению, что информация точно записана, инфа сотка, если вы понимаете, о чем я.

Дальше у пакета, в зависимости от настроек гипервизора, есть варианты, например:

Отправиться в путешествие по сети здорового человека блоками по 2112 байт.
Правда, если вы альтернативно одаренны, и не следите за ретрансмитами, отброшенными пакетами, не настроили ano и mpio, то вы на ровном месте, на бильярдном столе яму найдете. И в ней утонете. Или наоборот, медленно высохнете (Slow drain in Fibre Channel: Better solutions in sight )

Отправиться в путешествие по сети бедного человека tcp блоками – в iSCSI или в NFS. Нарезка «по питерски» на блоки от 1500 до 9000 – на ваш вкус.

Отправиться в путешествие по сети нормального человека – в iSCSI или в NFS, но в Ge UDPwagen, со всеми остановками – DCB, lossless ethernet, congestion control.

И, самый неприятный вариант – отправиться на локальные диски, потому что по бедности ничего другого нет, и это самый плохой вариант. То есть, почти самый плохой, но есть нюансы.

Почему этот вариант плох?

Потому что, в случае проблем в стеке богатого человека, вы можете увидеть задержки в гостевой системе, задержки в системе гипервизора, посмотреть QAVG, KAVG, DAVG и сказать – проблемы где-то тут. Конечно, иногда приходится и в vsish ходить, и про Disk.SchedNumReqOutstanding знать, а то, что еще хуже, читать по не русски всякие документы типа vSAN Space Efficiency Technologies

В случае проблем в стеке не такого богатого человека – вы можете просто взять и включить:

Get-VM | Format-List Name,ResourceMeteringEnabled

Enable-VMResourceMetering -VMName NameOfVM

Get-StorageQoSFlow -CimSession ClusterName | Sort-Object InitiatorIOPS -Descending | select -First 5

Что делать в остальных случаях, я как-то не очень понимаю, потому что load average покажет что угодно, кроме того что мне интересно, а iotop и sysstat хороши, но показывают не то, что мне надо. Хотя - и так сойдет, главное не забывать валить вину на кого угодно.

Но и это не самая большая проблема, потому что на этом месте в игру вступает

БОЛЬШОЕ ФИНАЛЬНОЕ КРОИЛОВО

И, наконец, данные начинают приземляться на диски

Тут кто-то вспомнит выравнивание разделов (partition alignment), но это параметр, про который стоит помнить, и иногда проверять.

Самая простая часть кроилова, это IO amplification. С ним все просто, пришел пакет в 512 байт на 4к разметку – пришлось делать много операций. Открываете статью Cluster size recommendations for ReFS and NTFS из списка литературы, читаете. Потом возвращаетесь к началу этой заметки, и делаете ААА, вот про что это было.

Особенно больно будет, если у вас на хосте развернуто любое программно-определяемое хранилище – хоть vSAN, хоть storage space, хоть storage space direct.

Там вы еще полной ложкой поедите не только IO amplification, но и Storage Spaces Direct Disk Write-Caching Policy, CSV BlockCache, и на сладкое - alternate data streams, вместе с Read-Modify-Write
Just a dose that'll make you wish you were born a woman

Полная версия сами знаете где, а то вдруг окажется, что статья, как только что произошло с статьей про рынок труда, уйдет в черновики с обоснованием "малобукаф подача не той системы"