☰

dm-cache, похоже, не работает — никакой разницы в производительности

tag-icon • tag-icon linux hard-drive memory ssd cache
dm-cache, похоже, не работает — никакой разницы в производительности

Я создаю устройство dm-cache с помощью своего скрипта: http://pastebin.com/KTSzL6EA

Фактически он выполняет следующие команды:

dmsetup create suse-cache-metadata --table 0 15872 linear /dev/mapper/suse-cache 0
dmsetup create suse-cache-blocks --table 0 125813248 linear /dev/mapper/suse-cache 15872
dmsetup create storagecached --table 0 2930266112 cache /dev/mapper/suse-cache-metadata /dev/mapper/suse-cache-blocks /dev/mapper/storage 512 1 writethrough default 0
dmsetup resume storagecached

на 60 ГБ SSD LVM томе для кэширования 1,5 ТБ USB 2.0 HDD. Я монтирую кэшированное dm устройство с:

mount -t btrfs -o noatime,autodefrag,compress=lzo,space_cache /dev/mapper/storagecached /mnt/storage

Однако, похоже, это вообще не работает. Я заметил, что внешний жесткий диск раскручивается КАЖДЫЙ раз, когда я обращаюсь к любому контенту на кэшированном устройстве, и каждый раз, когда какой-то бот обращается к моему веб-сайту, даже если он должен быть кэширован, я полагаю, и это довольно раздражает и в конечном итоге приводит к ошибкам ввода-вывода примерно через неделю, потому что внешний жесткий диск не может справиться с постоянными раскрутками и остановками.

Я решил провести несколько тестов, и копирование файла размером 8 ГБ в /dev/null с помощью ddкоманды достигает всего 40 МБ/с. Это та же скорость, что и у некэшированного HDD. Всегда. Как при холостом запуске с очищенным кэшем, так и при третьем или четвертом чтении, которое, как я думаю, должно быть кэшировано. SSD, используемый для кэша, достигает 92 МБ/с на корневом разделе. Конечно, после каждого теста я очищал кэш RAM Linux, чтобы исключить влияние кэширования RAM на производительность.

Я на самом деле использую этот скрипт на 2 ПК, и ни один из них, похоже, не работает. Я знаю, что сквозная запись не ускорит запись, но меня больше беспокоит чтение в любом случае.

РЕДАКТИРОВАТЬ:

После изучения dmsetup statusлогов я заметил, что у меня ужасно низкие показатели попадания в кэш. Может ли это быть ошибкой btrfs?

решение1

dm cache требуется некоторое время для продвижения блоков на устройство кэширования. В отличие от linux ram cache, политика dmcache по умолчанию требует по крайней мере нескольких чтений определенных данных для продвижения их на SSD, обычно много чтений, более 10. В сочетании с относительно большим объемом свободной оперативной памяти в машине, может потребоваться много времени для "обучения" dmcache. Если размер кэша аналогичен объему свободной оперативной памяти, а часто используемые данные занимают много места, он может вообще не работать нормально.

решение2

Используйте lvmcache(7) для настройки, и вы будете намного счастливее. Также man-страница очень полезна для начала работы. Помните о политиках обратной/сквозной записи и политике кэширования smq, которая включена по умолчанию только в новых релизах (после ядра 4.2). Также это по умолчанию в RHEL 7.2+ или около того.

Вы можете посмотреть мое выступление:https://www.youtube.com/watch?v=6W_xK5Ks-Lw или прочитайте слайды:https://www.linuxdays.cz/2017/video/Adam_Kalisz-SSD_cache_testing.pdf

Связанный контент