Производительность дисковой подсистемы и NFS

Меня интересует размер блока в 4 КБ - почему именно 4?

Предположу, что

1. стандартный размер блока ФС (man mkfs.ext4)
2. стандартный размер страницы памяти. обращение к свопу будет идти такими блоками (getconf PAGE_SIZE)

Как я понял, 4 КБ - это для измерения IOPS, а 4 МБ - уже для измерения пропускной способности

Да. 1 MiB для bandwidth достаточно, имхо. ЕМНИП, 4 Мб как-то связаны с типовой нагрузкой от БД oracle. Не DBA, подробностей не знаю

Часто пишут, что пользоваться командой dd недопустимо для измерения пропускной способности. Хотел узнать почему.

Потому, что

1. работает через файловый кэш (вроде можно отключить)
2. годится только для измерения bandwidth, а не iops

Можно ли измерять производительность сетевой шары NFS через те же утилиты, через которые измеряют производительность локальных дисков? Я про dd, fio и др. Это методически верно?

Не думаю. nfs клиент в любом случае будет работать через сеть и через файловый кэш

Можешь запустить fio локально, чтобы оценить дисковую подсистему. А nfs скорее будет зависеть ещё от сети и настроек сетевого стека

ibm например предлагает iozone https://www.ibm.com/support/pages/using-iozone-benchmark-nfs

Как понять какие тесты необходимы для получения производительности? Пишут, что можно исходить из задач диска или NASа, а как тут понять какая загрузка диска будет (последовательное или произвольное чтение/запись)? Нет ли каких-нибудь шаблонов для типовых нагрузок?

У меня такой информации нет. Настрой мониторинг текущей нагрузки

Было актуально, лет 20 назад, сейчас что процессоры, что девайсы в целом по сложности работы и взаимодействия приближаются к вызову фаербола из воздуха, ну кроме размера блока и его связь с размером страницы памяти, так называемое direct io требует чтобы блоки памяти которые планируются записать должны быть выровненны.

В плане dd - вполне годидся, из проблем не обладает достаточной гибкостью, т.к. умеет только линейное чтение запись, что к реальной жизни имеет оч простредственное отношение, и для более качественной оценки нужны всякие там random/read/write/rewrite/parallel…, да оно умеет в direct io, но оно отбрасывает не только кеш ОС, но и кеш самого диска, что напроч смазывает картину, по сути если хочется измерить предельные возможности железа, то необходимо использовать направленное на это ПО, часто предоставляемое бесплатно вендорами, но в реалиях приложения работают с файлами и директориями на ФС и вот это уже реально интересно.

Про размер блоков дисков, да, чаще всего совпадает с 4к, можно посмотреть чрезе smartctl

=== START OF INFORMATION SECTION ===
Device Model:     ST20000NT001-3LT101
Serial Number:    ZVT9X0MN
LU WWN Device Id: 5 000c50 0e6f514fd
Firmware Version: EN01
User Capacity:    20,000,588,955,648 bytes [20.0 TB]
Sector Sizes:     512 bytes logical, 4096 bytes physical
Rotation Rate:    7200 rpm
Form Factor:      3.5 inches
Device is:        Not in smartctl database 7.3/5319
ATA Version is:   ACS-4 (minor revision not indicated)
SATA Version is:  SATA 3.3, 6.0 Gb/s (current: 6.0 Gb/s)
Local Time is:    Tue Jun 27 15:41:21 2023 CEST
SMART support is: Available - device has SMART capability.
SMART support is: Enabled

ну или для nvme, там чутка другие правила игры, т.к. обмен происходит через буфер страниц, размера N, но всёже

=== START OF INFORMATION SECTION ===
Model Number:                       ASint AS806 512GB
Serial Number:                      AA000000000000003801
Firmware Version:                   V0808A0
PCI Vendor/Subsystem ID:            0x126f
IEEE OUI Identifier:                0x000000
Controller ID:                      1
NVMe Version:                       1.3
Number of Namespaces:               1
Namespace 1 Size/Capacity:          512,110,190,592 [512 GB]
Namespace 1 Formatted LBA Size:     512
Local Time is:                      Tue Jun 27 16:10:08 2023 CEST
Firmware Updates (0x12):            1 Slot, no Reset required
Optional Admin Commands (0x0017):   Security Format Frmw_DL Self_Test
Optional NVM Commands (0x0015):     Comp DS_Mngmt Sav/Sel_Feat
Log Page Attributes (0x03):         S/H_per_NS Cmd_Eff_Lg
Maximum Data Transfer Size:         64 Pages
Warning  Comp. Temp. Threshold:     83 Celsius
Critical Comp. Temp. Threshold:     85 Celsius

но фича в том, для обратной совместимости досихпор эмулируют 512байтные сектора, да и работа с самим диском, в случае с HDD, идёт через LBA контроллер, который собсно и рулит кешем, мапингом номера сектора в головка/диск/дорожка и пр, с ФС и НФС там вообще жесть начинается, а если ещё LVM, умный планировщик диска в ОС и становится вообще страшно.

По сути чтобы обойти все особенности кешей и пр лабуды, надо просто смотреть с какой реально скорость происходит копирование/пермещение/чтение файликов, при «регулярном» использовании, и дальше уже разматывать клубок, в противно случае если делать множество операций за короткий промежуток времени на небольших объёмах то результат будет смаззаным, благодаря особеностям одного из многочисленных абстрактных слоёв, задействованных в процессе передачи данных

Здравствуйте, Спасибо большое за ответы. Можно только еще один вопрос: не могу понять что такое queue/очередь в терминах того же CrystalDisk и чем оно отличается от threads? Подскажите, по-простому, пожалуйста, что это за зверь такой.

CrystalDisk

хз что это

то такое queue/очередь

Буквально очередь для запросов I/O. Фактически, это максимальное количество запросов, которые уже отправлены и ждут выполнения

nfs и производительность слова-антагонисты.

Возможно не угадаю с контекстом вопроса, но попробую, приложения не просят диск записать данные в конеретное место (если это не спец софт для работы с железом на низком уровне или драйвер), оно обращается к ОС, типа «дорагая ОС, кожанный опять чтото от меня хочет, и мне надо прочитать данные из этого файлика», ОС у нас нынче многозадачные, а условный жёсткий диск/сетевая карта/… одна у мамы такая красивая и ОС складывает эти запросы в очередь, очередь обрабатывается в соответствии с алгоритмом планировщика почитать можно тут, староватое, но на русском и вроде понятно, чем быстрее это всё работает, тем меньше будет размер очереди, чем тормознее, тем больше очередь, не уверен на 100% что именно это кристал диск показывает, но по логике должно быть оно. Поток, он же thread в линуксе это просто ещё одна копия приложения, которая выполняется паралельно и эти процессы шарям между собой некий набор ресурсов для общения между собой (эт прям оч грубо, но суть должна быть ясна).

Кстати этот загадочный load average в линукс, как раз отображает средний по больнице показатель размера всех очередей, если например начать чтото копировать по nfs и выдернуть сетевой шнур из nfs сервера, то очередь начнёт быстро расти, в надежде что сервер вернётся и мы ему всё скормим, и вот как раз этот load average выростет до небес

sparks@bastet:~> uptime 
 14:28:13  up 1 day  6:32,  1 user,  load average: 0.59, 0.66, 0.62

load average это не среднее всех очередей. Это вполне конкретный показаетель - среднее число процессов, которые ожидают очереди на выполнение

На самом деле мы оба и правы и не правы одновременно, но в контексте объяснения про очереди, приведённая мной формулировка, показалась мне умесной

быстрее это всё работает, тем меньше будет размер очереди, чем тормознее, тем больше очередь

в первом приближении это так. но. глубина (лимит, максимальный размер) очереди ограничен. в т.ч. в ОС

У storage’ей и отдельных дисков тоже есть своя глубина очереди (максимальный размер)

Поступившие запросы ставятся в очередь (если ещё есть куда, см. выше про лимит) и передаются дальше

Длина (текущая длина, а не глубина) очереди - число запросов, которые УЖЕ поступили и ЕЩЁ не выполнены. ОСь их все выполняет. Storage все запросы в СВОЕЙ очереди тоже выполняет

Глубина очереди - это лимит. максимальное число запросов, которые могут одновременно находится в очереди. Т.е. которые ОСь будет прямо сейчас обрабатывать

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

Error 7 occurred at disk power-on lifetime: 3405 hours (141 days + 21 hours)
  When the command that caused the error occurred, the device was active or idle.

  After command completion occurred, registers were:
  ER ST SC SN CL CH DH
  -- -- -- -- -- -- --
  84 43 00 00 00 00 00  Error: ICRC, ABRT at LBA = 0x00000000 = 0

  Commands leading to the command that caused the error were:
  CR FR SC SN CL CH DH DC   Powered_Up_Time  Command/Feature_Name
  -- -- -- -- -- -- -- --  ----------------  --------------------
  60 00 30 00 a1 b9 40 08      01:44:42.408  READ FPDMA QUEUED
  60 00 28 00 a0 b9 40 08      01:44:42.408  READ FPDMA QUEUED
  60 00 78 00 9c b9 40 08      01:44:42.407  READ FPDMA QUEUED
  60 00 20 00 9f b9 40 08      01:44:42.406  READ FPDMA QUEUED
  60 00 18 00 9e b9 40 08      01:44:42.406  READ FPDMA QUEUED

На заре карьеры, довелось какоето время работать сетевиком в интернет провайдере, там относительно часто встречалось нечто подобное, если один из участников не понимает IEEE 802.3x aka Flow Control, и тогда очередь благоволучно перегружалась, пакеты начали отбрасываться, по итогу оно вроде бы и работает, но просто дико медленно

facepalm

это - проблемы с диском. а вовсе не «не смогли договориться»

Не, конкретно в этом примере «не смогли договориться», UDMA_CRC_Error_Count из за корявой реализации NCQ, это промежуточный косяк драйвера на некоторых чипсетах, в особенности AMD, свежие версии ядра этим не страдают

Спасибо!!