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

Когда я только начал замечать проблемы и полез в гугл за ответами, со всех сторон начали сыпаться советы по тестированию скорости диска с помощью утилиты dd.

dd

Отгадайте пословицу: dd if=/dev/zero of=/dev/null Из пустого в порожнее

Как написано в man’е, производит конвертирование и копирование файла. Описание очень скудное и не дает представления о том на что способна эта замечательная программа.
Это не сильно соотносится сейчас с нашей темой, но принцип устройства VFS предполагает что буквально все в системе должно быть представлено как “файл”, в том числе и устройства. С этим связано одно из самый популярных применений dd – возможность побайтово склонировать целый диск, раздел, или какую-то их часть.

dd if=/dev/sda of=/dev/sdb

Команда выше полностью скопирует информацию с одного диска на другой со всеми “потрохами”: идентификаторами разделов, файловыми системами, метаданными и полезной нагрузкой.
Добавив status=progress можно будет наблюдать за течением сего процесса.

Также, например, если не указывать куда перенаправлять вывод (без директивы of=), то вывод просто получим на экран (stdout).

dd if=/etc/os-release

Впрочем, в мане или на просторах сети полно информации о дэдэшечке, не будем повторяться.

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

> dd if=/dev/zero of=/tmp/testfile bs=1G count=1

1073741824 bytes (1,1 GB, 1,0 GiB) copied, 10,0035 s, 107 MB/s

Теперь пробежимся по значимым опциям.

bs = размер блока. Т.к dd работает именно поблочно, то это будет размером его атомарной операции, считать n байт => записать n байт, ни больше ни меньше. Поддерживается указание арифметических операций, например bs=2x80x18b (размер дискеты). По умолчанию bs равен 512b

count = тут понятно, это просто счетчик.

status = progress – периодически отписываться в stderr о прогрессе.

iflag \ oflag = чтение или запись может производится особым образом.

• direct – отправлять запросы минуя кэш (direct I/O)
• dsync – использовать синхронное I/O (synchronized I/O), т.е. каждое последующее IO только после завершения предыдущего.

conv = обработка, которая происходит между in и out. В основном используется директива noerror, остальные весьма специфичны, и редко встречались или требовались мне на практике.

Таким образом, можно проводить тесты линейной записи или чтения.
Можно регулировать размер блока, который будет записан\прочитан.
Есть возможность писать, с просьбой ядру не использовать кэш.
Можно использовать синхронное I/O.

Подводя некий итог, можно понять что dd может достаточно хорошо отрабатывать простые синтетические тесты, и позволяет оценить некоторые параметры работы дисков. Но реальную нагрузку и производительность дисковой подсистемы с ее помощью оценить
нереально.

А нам надо видеть чем занимаются диски. Разбираемся дальше.

iotop

Аналог top, только типо для дисков.

Можно наблюдать список процессов, и различные показатели по столбцам: thread ID, IO приоритет, пользователя, интенсивность свопа и некий процент IO.

IO priority – be\rt\id означают класс процесса (best-effort, real-time, idle), а значение от 0 до 7 приоритет относительно других процессов (меньшие значения подразумевают больший приоритет). Эти значения можно изменить с помощью утилиты ionice, но помните, что приоритеты смотрит I/O scheduler, упоминаемый в предыдущей статье. И умеют это только “весовые” виды планировщиков, т.е. CFQ, BFQ и Kyber (насчет него неточно). Также, приоритеты не работают для асинхронной записи.
Swap – так как процессу отводится некоторая часть всей очереди на ввод-вывод, то процент от этой части, являющийся свопингом будет отображен в этом значении.
I/O – работает по тому же принципу что и swap, но отображает время затрачиваемое на ожидание ввода-вывода.

Также в верхней части экрана есть значения {Total,Actual} DISK {READ,WRITE}. Как написано в мане, Total read\write подразумевает весь обмен между процессами и дисковой подсистемой ядра.

Actual read\write – обмен между дисковой подсистемой ядра и драйверами оборудования.
Таким образом значения Total и Actual могут ощутимо отличаться как раз таки из-за кэша и планировщика.

Ключи
-a – iotop будет показывать аккумулированные данные с момента своего запуска. В таком режиме информация получается более наглядной.
-o – показывать только те процессы, у которых есть активность.
-d – интервал обновления.
-P – показывать не треды а процессы.

На самом деле, каких-то действительно полезных аналитических данных через iotop у меня не получалось добыть. Главное причина тому – нет разделения по блочным устройствам, показываются данные по всей системе целиком. Но в роли подспорья утилита однозначно хороша.

iostat

Является частью пакета sysstat.

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

Если же запускать в формате iostat число1 число2, то механизм работы будет следующим: число1 – это как часто опрашивать статистику, число2 – количество опросов. iostat 2 10 – опросить каждые 2 секунды,
всего 10 раз .

В верхней строчке идет статистика по CPU.
В принципе, все это можно увидеть в top:
%user – загрузка процессами выполняющимися в userpspace.
%nice – тот же userspace, но то что выполняется с настройками nice – определяющими приоритет у дискового шедулера
%system – то что кушают ядерные процессы
%iowait – процент времени которые CPU ждет ответа от дисковой подсистемы
%steal (может отсутствовать) – как правило, встречается в виртуализации, когда виртуальные машины бьются друг с другом за ресурсы
%idle – CPU отдыхает

Значения:

tps – количество I/O запросов устройству. Судя по ману, здесь отображаются запросы уже после их комбинирования планировщиком.
Без дополнительных ключей, остальные столбцы, думаю, понятны – запись и чтение в секунду, и сколько всего было записано\прочитано.

Другое дело с ключиком -х:
rrqm/s и wrqm/s – количество объединенных запросов чтения и записи соответственно.
r/s и w/s – количество i/o на чтение и запись в секунду.
rkB/s и wkB/s – чтение и запись в КБ\сек.
avgrq-sz – средний размер отправленных запросов (в секторах).
avgqu-sz – средняя длина очереди.
await, r_await, w_await – время запроса в очереди, плюс время на его обслуживание.
util – время в течении которого блочное устройство занято запросами на I/O в процентах.

В новых версиях iostat слегка изменились некоторые столбцы.
Добавились %rrqm и %wrqm – процент объединенных запросов.
areq-sz – средний размер запросов (бывший avgrq-sz, но в отличие от него не в секторах, а в килобайтах).
aqu-sz – средняя длина очереди (бывший avgqu-sz)
rareq-sz, wareq-sz – средний размер запроса для чтения\записи.

Кратко о ключах:

• с – только статистика по CPU.
• d – убрать статистику по CPU, только диски.
• g – позволяет группировать диски и отображать по ним суммарные значения. например: iostat -g my_disk_group sda sdb sdc. Получим статистику по трем дискам и их сумму в группе my_disk_group.
• H – вместе с -g уберет из вывода отдельные диски, оставив только суммарные значения по группе.
• h – human readable, но, как по мне, удобств не добавляет.
• j { ID | LABEL | PATH | UUID | … } – вывести название диска в указанном формате, по умолчанию LABEL.
• k и m – отображать значения в килобайтах или мегабайтах соответственно.
• N – использовать имена для device mapper томов. Удобно для LVM.
• p – отображать разделы
• t – штамп времени каждого отчета
• x – расширенная статистика.
• y – не показывать первый отчет, который показывает общую статистику с момента загрузки.
• z – не показывать устройства с неизменными значениями (типо неактивные).

/proc/sys/vm/block_dump

Можно включить отладку сброса dirty pages на диск.

echo 1 > /proc/sys/vm/block_dump

Сообщения о том, данные какого процесса сбрасываются можно увидеть в dmesg или логах ядра (количество сообщений пропорционально интенсивности записи, будьте готовы к срачу в логах)

Домашняя работа

А теперь на основании теоретических знаний из первой статьи и практических инструментов из текущей, попробуйте понять что происходит с линейной записью в этих четырех случаях, и почему получаются именно такие результаты? Какое узкое место системы в данном случае проявляется? Запись производится на один диск, файловая система XFS.

> dd if=/dev/zero of=/tmp/testfile bs=4k count=200000 
...
819200000 байт (819 MB, 781 MiB) скопирован, 5,26288 s, 156 MB/s 

> dd if=/dev/zero of=/tmp/testfile bs=781M count=1 oflag=direct
...
818937856 байт (819 MB, 781 MiB) скопирован, 8,7302 s, 93,8 MB/s

> dd if=/dev/zero of=/tmp/testfile bs=4k count=200000 oflag=direct 
...
819200000 байт (819 MB, 781 MiB) скопирован, 39,5175 s, 20,7 MB/s

> dd if=/dev/zero of=/tmp/testfile bs=4k count=2000 oflag=dsync 
...
8192000 байт (8,2 MB, 7,8 MiB) скопирован, 60,7651 s, 135 kB/s

В последнем примере специально количество блоков меньше в сто раз, потому что иначе очень долго ждать

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

Ответ будет в отдельном посте или в следующей части. Всех благ!

О секторах, блоках и адресации

Мне показалось очень нужным рассмотреть на низком уровне работу механических дисков (хотя и все равно поверхностно, как ни крути). Дело в том, что можно легко запутаться во всех этих секторах и блоках разных калибров. И у этого есть исторические аспекты. Маленько разберемся:

Сектор приз на барабане.

Сектором называется минимальная область диска, которая имеет адрес. Раньше дефолтным размером было 512 байт. Теперь современный стандарт – 4096 байт, известный как advanced format. Если коротко – на картинке выше изображен физический сектор. Логический сектор – это “виртуальный” размер сектора о котором может сообщать вам диск. Можно пронаблюдать через команду fdisk -l /dev/$device.

Кластер или блок.

Эти слова часто имеют очень путанное использование. Вроде как в линуксе слово “cluster” не применяется, либо можно считать его синонимичным определению блока. А вот блок… С ним часто происходят разночтения.
В первую очередь нужно закрепить понимание, что это просто абстракция, логическое представления единицы обрабатываемых данных. Порой, блоками называют как логические так и физические секторы диска, только подразумевая взгляд со стороны ОС. Как бы для диска это сектор, но для самой операционки это всего лишь некий абстрактный блок, который диск соизволил отдать (в случае SSD или некоторых SCSI это действительно “фиктивный” сектор). А иногда, слегка поднявшись по структуре блочных устройств, так называют структурные единицы уровня файловой системы. Это все является блоками, но без контекста можно запутаться. Я постараюсь не создавать двусмысленности в статьях, и не использовать слово “кластер” касательно файловой системы, и писать “физический сектор” или “логический сектор” там, где подразумевается именно соответствующий сектор.

Выравнивание разделов.

Как я уже упоминал, слово “блок” может использоваться при использовании различных сущностей: блок как логический сектор на диске, блок как структурная единица файловой системы, менеджера томов, RAID-массива. А ведь все это может вполне себе работать в связке. А теперь представьте, что внезапно каждая из этих сущностей считает блоком совсем не то, что считает другая. Это породило бы массу неприятностей…

На самом деле, такой исход маловероятен, но теоретически возможен. Впрочем, механизмы создания логических томов, RAIDов, ZFS пулов и прочего, автоматизировано умеют выравниваться вдоль разделов или всего диска или может даже друг друга (почему нет?). Но во-первых, так было не всегда, а во-вторых, иногда тоже есть нюансы. Итак зачем нужно выравнивание?

Запустив fdisk -l /dev/$device обратите внимание на размер логического и физического сектора и стартовый сектор. Скорее всего, у вас все в порядке, и будет такая картина:

Sector size (logical/physical): 512 bytes / 4096 bytes

Device       Start
/dev/sda1      2048

Проблема возникает, когда первым логическим сектором у вас является 63й.

Device       Start
/dev/sda1      63

Но почему именно 63?
Стандартной схемой всегда считалось начинать раздел сразу после окончания первой дорожки или цилиндра (track, cylinder).

А при старом типе адресации CHS (cylinders, heads, sectors) адрес сектора в дорожке мог кодироваться только 6 битами (0-63).
На смену CHS пришел LBA (logical block address), добавляющий дополнительный уровень абстракции между адресацией диска и драйвера ОС. С тех пор напрямую с геометрией диска работать не принято, и используются уже много раз упомянутые логические секторы\блоки.

А теперь быстренько вернемся к недавней теме о секторах. Ведь с точки зрения окружности, нумерованный сектор, тот что выделен зеленым, это набор состоящий из уникальных физических секторов с каждого цилиндра и головки. И каждый раз, в нумерации CHS (цилиндр, головка, сектор), он отображает один и тот же номер физического сектора, с координатой (x,y,1), где x- номер цилиндра, y – номер головки, 1 – первый сектор (только нумерация секторов идет с единицы, всего остального с нуля).
Возможно, именно на границе перехода с CHS на LBA так сильно перемешались понятия логических\физических\блоков\секторов, ведь, как только появился дополнительный слой абстракции, пропала эта явная связь между сектором окружности и адресом, а его логический адрес перестал отображать физическое расположение.

Если вернуться к Advanced Format, при котором физический сектор больше логического, то по нашему “блинчику” это выглядит так:

Теперь к сути выравнивания.
И если как-то сошлись звезды, и у вас “недоехал” раздел до 2048-го сектораЛогического блока (кстати, или любого другого, кратного 4 килобайтам, пусть даже 64-го), то ситуация будет выглядеть следующим образом:

Видно что 4k блоки файловой системы съехали на 512 байт относительно 4k блоков диска. Такая ситуация порождает дополнительные накладные расходы, когда при работе с одним блоком, диску, по факту, приходится оперировать двумя.

В утилите parted есть даже команда проверки выравнивания.

# проверяем 1 раздел на выравнивание по начальному и конечному сектору 
parted /dev/sda align-check optimal 1

/sys/block/device

sysfs – виртуальная файловая система, в которой отражены значения различных переменных ядра.

В директории /sys/block будут все Ваши блочные устройства, а в директории устройства и в файле stat – статистика работы с этим устройством. Для начала, поглядим на них.

/sys/block/$device/stat

Информация взята из документации, где также присутствуют значения “discard” для ядер 4.19 и выше. На текущий момент такие ядра по дефолту есть только в rolling-release дистрибутивах, и потому здесь их не включил, тем паче, discard-операции применимы только для SSD и thin-provision устройств.

Получив значения (например командой cat) мы сможем наблюдать 11 цифр, разделенных табуляцией. Каждый “столбик” отображает свое значение.

1. read I/Os
2. read merges
3. read sectors
4. read ticks
5. write I/Os
6. write merges
7. write sectors
8. write ticks
9. in-flight
10. io-ticks
11. time-in-queue

read и write I/O – количество завершенных I/O операций.
read и write merges – значение увеличивается, при присоединении нового I/O запроса к запросу в очереди. (вспоминаем, например readahead из прошлой части)
read и write sectors – количество прочитанных или записанных секторов
read и write ticks – произведение времени нахождения и количества запросов ожидающих в очереди или суммарное время ожидания I/O за секунду, в миллисекундах. Так, если в 60 запросов, в среднем, ждут 30 миллисекунд, то значение будет 30*60=1800ms
in_flight – I/O отправленные драйверу, но еще не выполненные. Сюда не входят те запросы, которые стоят в очереди.
io_ticks – время за секунду, при котором устройство имеет в очереди запросы. Что-то вроде утилизации.
time_in_queue – По документации это read + write ticks, но на практике я заметил что такая арифметика не выходит.

time_in_queue

Я посмотрел в исходники ядра, но все равно не смог понять почему цифры таки не сходятся. Единственная догадка на текущий момент: это происходит из-за округлений подсчетов в единицу времени.
Эх, если бы я умел в С…

“Руками” эти метрики смотреть не очень информативно, а вот собирать системами мониторинга – очень даже.

/sys/block/$device/queue

В директории queue содержится большая часть интересностей.

Опять же, не хочется в тупую заниматься переводом документации, поэтому постараюсь привести только максимально полезные данные. Полный список в доках по ссылке выше. Также часть параметров есть в русских доках по redhat 6.

Итак, в директории /sys/block/$device/queue можно найти следующие файлы, cat’нув которые, получим значения:

add_random (RW) – (RW означает что параметр доступен для перезаписи, RO – только чтение). Забавно, но есть так называемая “энтропия диска“, которую используют для генерации случайных чисел. Этим параметром можно ее включать (1)\выключать (0).

physical_block_size (RO) – размер физического сектора на диске. Как видите, в названии параметра написано блок, то есть по-сути это размер сектора о котором сообщает нам диск.

logical_block_size (RO) – размер логического сектора диска.

max_hw_sectors_kb (RO) – несмотря на слово “сектор”, это максимальный возможный размер переданных за один запрос данных в килобайтах. Т.е. по-сути это максимальный размер чего? Надеюсь, вы догадались, это максимальный размер I\O.

max_sectors_kb (RW) – здесь как раз мы задаем ограничение на размер I/O. Я всегда по умолчанию наблюдал значение 1280 кб, но оно вроде может и варьироваться, но не знаю по каким критериям. Это значение, что логично, нельзя выставить больше чем max_hw_sectors_kb.

minimum_io_size (RO) – минимальный размер I/O. Ожидаемо, следует из размера логического сектора.

nomerges (RW) – объединение запросов. 0 – алгоритмы работают на полную катушку, 1 – только простые, 2- полностью отключено.

nr_requests (RW) – Число запросов чтения или записи в очереди. Если очередь переполнилась, процесс будет ждать ее освобождения.

optimal_io_size (RO) – некоторые устройства умеют сообщать оптимальный размер I/O для себя.

read_ahead_kb (RW) – размер упреждающего чтения (было в первой части цикла).

rotational (RW) – параметр, определяющий является ли диск механическим или нет. Если выставить значение вручную, то можно превратить обычный HDD в SSD для диска будут использоваться соответствующие оптимизации.

write_cache (RW) – режим работы write back (запись в кэш) или write through (мимо кэша ОС). Хоть значение и RW, его лучше не изменять, так как оно изменяет лишь видение ситуации со стороны ядра, но не диска. WriteThrough подразумевается тогда, когда кэшированием занимается другое устройство, например RAID-контроллер.

Грязный гарри (Dirty Pages)

Dirty pages – специальных механизм отложенной записи на диск, при котором хранящиеся в памяти данные помечаются “грязными”, то есть ожидающими записи на диск. По-сути, является одной из структурных частей механизма дискового кэширования. Учтем это, и пойдем дальше.

/proc/sys/vm/

По отработанной схеме, переведу только описание параметров имеющих корреляцию с темой работы дисков.

dirty_background_bytes и dirty_background_ratio – Отражает ограничение по количеству памяти с “грязными”я даже не знаю как правильно перевести этот термин страницами, превышение которого обязывает ядро начать сбрасывать страницы на диск. Может быть, соответственно задано жестко в байтах либо в процентном отношении от доступной памяти системы. Обнуляют значения друг друга.

Если что, “доступная память” не равно “вся память системы”. Доступную память, как и dirty pages можно пронаблюдать в /proc/meminfo.

grep -e "Dirty\|MemAvailable" /proc/meminfo

Подробнее про meminfo в доках редхат.

dirty_bytes и dirty_ratio – Это лимит на количество dirty pages которое не должно быть превышено. Так же, либо в байтах , либо в процентах от MemAvailable.

dirty_writeback_centisecs – время “протухания” dirty pages, это максимальное время, которое они могут хранится в памяти до сброса на диск. Указано в сотых долях секунды.

dirty_writeback_centisecs – как часто просыпается поллер pdflush, чтобы выполнить сброс dirty-bytes на диск.

Таким образом, dirty pages у нас имеют право без проблем накапливаться до значения dirty_background_ratio либо пока не истечет время их нахождения в памяти равное dirty_writeback_centisecs, после чего они начинают сбрасываться на диск. При этом они могут продолжать накапливаться, покуда не достигнут своего предела dirty_ratio.

laptop_mode – интересный режим, подразумевает что если на текущий момент ОС загружена на устройстве с аккумулятором и не подключена к питанию, то нужно использовать специальный механизм сброса dirty pages. Суть режима заключается в следующем: раз на первый план вынесено энергопотребление, то нужно максимально сократить время работы механической части диска – его вращения и раскрутки. Для этого категорически не подходит обычная логика работы сброса кэшей (описанная выше), так как она способствует “размазыванию” нагрузки на диск во времени. Следовательно, для компоновки и разнесения обращений к диску, сброс dirty pages производится только если диск уже находится в движении, например, после read i/o. Время жизни dirty pages возрастает до 10 минут (можно изменить). Присутствует много интересностей, типо возможности сильно задрать readahead или сменить частоту CPU. Подробнее, как обычно, в документации.

Я думаю, с глухой теорией пора завязывать. В следующей части мы рассмотрим базовые инструменты для мониторинга дисков.

Доп информация:

Хорошая презенташка от Christoph Anton Mitterer, взято отсюда: https://www.dcache.org

Так уж получилось, что я любитель пробовать все самое новенькое и продвинутое. И когда я планировал миграцию домашнего сервачка с убунты на proxmox, то решил что хочу попробовать что-то экстравагантное. У меня уже был небольшой опыт пользования BTRFS и ZFS, да и LVM2, а хотелось попробовать все. Хотя история с развалившейся ext4, которой не помог журнал, еще не успела меня подкосить, я все же уже был повернут лицом к таким важным технологиям как soft-RAID, volume management, snapshots и, непосредственно, регулярный бекап. Так как я нищеброд, то в распоряжении у меня было очень мало дисковых ресурсов, а распределить место хотелось максимально эффективно. Пришлось как следует поколхозить!

Под систему и сервисы я смог выделить два однотерабайтных HDD и один на 500Gb. Логика подсказывает, с дисками разного размера много каши не сваришь: зазеркалить не получится (да и зачем зеркало из трех дисков?), сделать RAID5 тоже.

Но линкусовый софт-рейд mdadm работает с разделами – собственно чтобы собрать к примеру raid1 из двух дисков, нужно создать на каждом из них соответствующий раздел с меткой “Linux RAID” и уже из этих разделов дальше собирать зеркало. К тому же, это в моем случае было обязательно еще и просто потому, что загрузчику UEFI нужно увидеть на диске раздел fat32, на котором уже загрузить grub а потом kernel + initramfs. Если этот efi-раздел будет с неправильной меткой, то загрузчик его не воспримет.

В итоге собрать все это непотребство я решил таким образом:

Получился раздел /dev/md0 на 500 Гб, состоящих из двух зеркалируемых разделов sda2 и sdb2, а также раздел /dev/md5 на 1ТБ состоящий из трех разделов по 500 Гб: sda3, sdb3, sdc1.

К слову сказать, все эти sda, sdb, sdc самому mdadm’у до лампочки: при создании массива всю служебную информацию он записывает в специальный суперблок и при загрузке системы сам собирает все диски как надо. Независимо от уровня рейда, достаточно иметь суперблок от одного диска, чтобы знать к какому массиву он принадлежит, сколько в нем всего должно быть дисков и т.п.

На md0 (все же следовало бы назвать его md1) создана группа томов LVM sysvg, а в ней логические тома: rootlv (для самой системы) swaplv (понятно, раздел подкачки) и thinlv (специальный тонкий том).

На md5 также создана volume group с двумя томами, один тоже под системные контейнеры, один для пользователей.

Рядом из трех дисков был собран raidz, представляющий собой нечто похожее на RAID5, только средствами ZOL (ZFS on linux). На схеме его нет, возможно речь о нем пойдет в другой статье.

Все это было успешно развернуто и работало, хотя и попахивало тормозами. Обрастало контейнерами и виртуалками, как-то, в общем, жило. В то, как это работало без тормозов, вносил свой вклад еще и тот самый raidz, с которого были смонтированы файловые системы, на которых хранится, непосредственно, полезная нагрузка. Он как раз работает без нареканий, быстро и качественно.

Когда пришло время хоть сколько-нибудь значимых нагрузок на системные сервисы, и когда их просто стало достаточно много (они же все еще и логи пишут) то начались проблемы – отзывчивость сервака упала до совсем низких пределов – спасало только то, что не использовался swap, иначе бы система была практически в лежачем состоянии.

И я начал изучать теорию.

Продолжение на следующей странице