У меня есть сервер с контроллером LSI MegaRAID SAS 9260-4i, RAID-5 с 3 дисками по 2 ТБ. Я провел небольшое тестирование производительности (с iozone3), и цифры ясно показывают, что политика кеширования записи также влияет на производительность чтения. Если я установлю политику WriteBack, я получу примерно в 2 раза более высокую производительность чтения по сравнению с WriteThrough. Как кеш записи может повлиять на производительность чтения?
Вот подробности настройки:
megacli -LDInfo -L0 -a0
Adapter 0 -- Virtual Drive Information:
Virtual Drive: 0 (Target Id: 0)
Name :
RAID Level : Primary-5, Secondary-0, RAID Level Qualifier-3
Size : 3.637 TB
Is VD emulated : Yes
Parity Size : 1.818 TB
State : Optimal
Strip Size : 512 KB
Number Of Drives : 3
Span Depth : 1
Default Cache Policy: WriteThrough, ReadAhead, Direct, No Write Cache if Bad BBU
Current Cache Policy: WriteThrough, ReadAhead, Direct, No Write Cache if Bad BBU
Default Access Policy: Read/Write
Current Access Policy: Read/Write
Disk Cache Policy : Disabled
Encryption Type : None
Bad Blocks Exist: No
Is VD Cached: No
При включенном WriteBack (все остальное без изменений):
Default Cache Policy: WriteBack, ReadAhead, Direct, Write Cache OK if Bad BBU
Current Cache Policy: WriteBack, ReadAhead, Direct, Write Cache OK if Bad BBU
Некоторые цифры из iozone3:
WriteThrough:
random random
KB reclen write rewrite read reread read write
2033120 64 91963 38146 144980 139122 11795 21564
2033120 128 83039 90746 118660 118147 21193 33686
2033120 256 78933 40359 113611 114327 31493 51838
2033120 512 71133 39453 131113 143323 28712 60946
2033120 1024 91233 76601 141257 142820 35869 45331
2033120 2048 58507 48419 136078 135220 51200 54548
2033120 4096 98426 70490 119342 134319 80883 57843
2033120 8192 70302 63047 132495 144537 101882 57984
2033120 16384 79594 29208 148972 135650 124207 79281
WriteBack:
random random
KB reclen write rewrite read reread read write
2033120 64 347208 302472 331824 302075 12923 31795
2033120 128 354489 343420 292668 322294 24018 45813
2033120 256 379546 343659 320315 302126 37747 71769
2033120 512 381603 352871 280553 322664 33192 116522
2033120 1024 374790 349123 289219 290284 43154 232669
2033120 2048 364758 342957 297345 320794 73880 264555
2033120 4096 368939 339926 303161 324334 128764 281280
2033120 8192 374004 346851 303138 326100 186427 324315
2033120 16384 379416 340577 284131 289762 254757 356530
Некоторые подробности о системе:
/dev/sda4 /var ext4 rw,relatime,user_xattr,barrier=1,data=ordered 0 0Используя кэш обратной записи, вы экономите дисковые операции ввода-вывода в секунду. Контроллер может объединять небольшие записи в одну большую запись.
Таким образом, для чтения доступно больше операций ввода-вывода в секунду.
Это предполагает, что тесты проводятся одновременно. Если данный тест предназначен только для чтения или только для записи, это не имеет значения.
политика обратной записи делать влияют на производительность красного при использовании таких тестов, как iozone, потому что эти инструменты тестирования измеряют производительность чтения, считывая данные, которые они написали ранее. следовательно, когда iozone запускает тесты чтения, некоторые данные все еще находятся в кеше, что значительно увеличивает скорость чтения. это не зависит от размера файлов, так как рейдовый адаптер не знает файлов или даже файловых систем. Все, что он знает, - это операции ввода-вывода и блоки. имейте в виду iozonr, я бы использовал инструмент для тестирования производительности fs и thug полностью абстрагирует оборудование. возможно, используя -J / -Y, вы могли бы смягчить эффекты политики обратной записи и получить представление о вашей производительности чтения ... или использовать настоящий инструмент для тестирования жестких дисков (hdparm?)
На какой файловой системе выполняется этот тест?
На ум приходит время. Если ваша файловая система смонтирована с параметром atime или отсутствует параметр монтирования no / relatime, вы будете получать запись при каждом чтении.
(atime означает запись времени последнего доступа к файлам)
Было бы полезно, если вы опубликуете вывод
mount
и укажите, на каком устройстве вы проводили тесты.
Вполне вероятно, что по мере записи файла он также записывается как непрерывный блок на диске.
Одна вещь, которую предыдущие решения не учитывают, - это разница между тем, как команды обратной и сквозной записи обрабатываются на контроллере.
Обратная запись означает, что когда контроллер получает команду, он немедленно сообщает обработчику ОС, что она «в порядке», и дает следующую команду. Write-Хотя ожидает, пока каждая отдельная команда сообщит об успехе, перед обработкой следующего запроса.
В результате команды помещаются в очередь быстрее. Затем параметр Read-Ahead для массива начнет заполнять кеш непрерывным потоком данных.
Вы можете увидеть, что упреждающее чтение с более быстрой организацией очереди команд немного помогает, если вы посмотрите на очень небольшие процентные различия между событиями произвольной записи и произвольного чтения, которые в основном устраняют усиление опережающего чтения, особенно при меньших размерах блоков.
Еще одна вещь, которая может повлиять на производительность, - это размер среза и размер блока, определяющий, сколько разных головок задействовано в каждой операции чтения или записи.
Наиболее очевидная причина в том, что операции чтения происходят из кеша, а не из самого диска. Помните, что с WriteBack записанные данные хранятся в кэше, пока RAID-контроллер не получит шанс / не решит записать их на диск. Однако имеет смысл, что если одни и те же данные читаются (или что-то еще, что они все еще хранятся в кэше), тогда он использует кеш для извлечения данных, а не занимается относительно дорогостоящим чтением с диска.