Приключение пакетишки
Для ЛЛ: сложности отладки производительности дисковых подсистем в среде виртуализации.
Каждый вечер, когда солнце прячется за верхушки сосен, на небе зажигаются звезды, а где-то в лесу неподалеку начинает ухать сова, которую мы уже два месяца не можем поймать, чтобы сварить из нее суп, — так вот: каждый раз, когда на нашу свалку опускается темнота, вся детвора собирается вокруг ржавого чайника в пустой нефтяной цистерне на западной окраине, чтобы попить кипятка, съесть по кусочку сахара и послушать сказку на ночь.
(проследовать за кроликом)
Зашел в нашем колхозном клубе разговор о том, как в конфету «подушечку» варенье попадает, и постепенно перешли на то, как данные из приложения попадают на диск, и где можно на граблях попрыгать, и на взрослых, и на детских.
Итак, у нас есть «данные».
Если речь заходит о том, что надо быстро и много работать с хоть сколько-то большими объемами данных, то обычно у производителя есть рекомендации «как лучше организовать дисковое пространство». Обычно. Но не всегда.
Общеизвестно, что:
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
Полная версия сами знаете где, а то вдруг окажется, что статья, как только что произошло с статьей про рынок труда, уйдет в черновики с обоснованием «малобукаф подача не той системы»
