Потихоньку обновляю комп, дошли руки до новейшего изобретения отечественных учёных - persistent l2arc из zfs-2.0.0-rc1. Делюсь результатами эксперимента :)
Было - raid10 из терабайтных хардов, 8Гб памяти выделено под ARC. Стало - то же самое, плюс непропорционально много SSD-кеша.
[dan@dan-desktop ~]$ zpool list -v
NAME SIZE ALLOC FREE CKPOINT EXPANDSZ FRAG CAP DEDUP HEALTH ALTROOT
zhome 1.81T 894G 962G - - 55% 48% 1.32x ONLINE -
mirror 928G 447G 481G - - 55% 48.2% - ONLINE
ata-WDC_WD10EFRX-68FYTN0_WD-WCC4J2YD0FDE - - - - - - - - ONLINE
ata-WDC_WD10EFRX-68PJCN0_WD-WCC4J5PA4PCK - - - - - - - - ONLINE
mirror 928G 447G 481G - - 56% 48.2% - ONLINE
ata-WDC_WD10EFRX-68PJCN0_WD-WCC4J5YS0DFV - - - - - - - - ONLINE
ata-WDC_WD10EFRX-68PJCN0_WD-WCC4J7RHCS5S - - - - - - - - ONLINE
cache - - - - - - - - -
nvme-ADATA_SX8200PNP_2K292LAKACN2 477G 111G 366G - - 0% 23.3% - ONLINE
В каких условиях это применялось - довольно типичный десктоп, несколько жирных игрушек, файловый кеш мессенджера и браузера, условный торрент-клиент, работа с несколькими гит-репами. Интервал между ребутами - порядка пары недель.
Что получилось:
- За несколько дней набилось 100Гб кеша
- Потребление памяти - 200Мб
- Типичный хитрейт на больших интервалах времени - около 50% (против 99% у ARC)
- Чтения из l2arc происходит на порядок больше, чем записи
- Объем записи в день можно с горкой оценить как 20Гб в день
- Кеш не влияет на время монтирования. Впрочем, оно и без кеша занимает несколько секунд
- Запись, разумеется, быстрее не стала, но мне особо и не надо
Субъективно очень приятная тема. Если после рестарта запустить игрушку или сделать gis status в жирной репе - практически всё чтение идёт из кеша, со скоростью 50-200Мб/с, хитрейтом больше 90%. И всякая мелочь типа браузера ощутимо быстрее открывается.
Считаю, что это работает достаточно хорошо, чтобы пользоваться. Даже не буду заморачиваться и переносить часто используемые данные на SSD. Просто как-нибудь потом куплю харды побольше, если будет необходимость. Ниже куски выхлопа arc_summary
L2ARC size (adaptive): 121.5 GiB
Compressed: 91.5 % 111.1 GiB
Header size: 0.1 % 167.4 MiB
MFU allocated size: 67.3 % 74.8 GiB
MRU allocated size: < 0.1 % 656.0 KiB
Prefetch allocated size: 0.1 % 168.3 MiB
Data (buffer content) allocated size: 96.6 % 107.3 GiB
Metadata (buffer content) allocated size: 3.4 % 3.8 GiB
L2ARC breakdown: 525.7k
Hit ratio: 64.7 % 340.0k
Miss ratio: 35.3 % 185.6k
Feeds: 37.5k
ARC size (current): 99.9 % 8.0 GiB
Target size (adaptive): 100.0 % 8.0 GiB
Min size (hard limit): 12.2 % 1001.2 MiB
Max size (high water): 8:1 8.0 GiB
Most Frequently Used (MFU) cache size: 96.1 % 6.7 GiB
Most Recently Used (MRU) cache size: 3.9 % 281.4 MiB
Metadata cache size (hard limit): 75.0 % 6.0 GiB
Metadata cache size (current): 29.3 % 1.8 GiB
Dnode cache size (hard limit): 10.0 % 614.4 MiB
Dnode cache size (current): 70.0 % 429.9 MiB
ARC hash breakdown:
Elements max: 2.1M
Elements current: 100.0 % 2.1M
Collisions: 1.1M
Chain max: 7
Chains: 393.3k
ARC misc:
Deleted: 73.1k
Mutex misses: 36
Eviction skips: 12
Eviction skips due to L2 writes: 0
L2 cached evictions: 16.4 GiB
L2 eligible evictions: 3.7 GiB
L2 eligible MFU evictions: 2.0 % 77.2 MiB
L2 eligible MRU evictions: 98.0 % 3.7 GiB
L2 ineligible evictions: 19.4 MiB
ARC total accesses (hits + misses): 58.8M
Cache hit ratio: 99.1 % 58.2M
Cache miss ratio: 0.9 % 525.7k
Actual hit ratio (MFU + MRU hits): 99.1 % 58.2M
Data demand efficiency: 99.2 % 39.4M
Data prefetch efficiency: 0.0 % 372
Cache hits by cache type:
Most frequently used (MFU): 96.5 % 56.2M
Most recently used (MRU): 3.5 % 2.0M
Most frequently used (MFU) ghost: 0.2 % 103.8k
Most recently used (MRU) ghost: < 0.1 % 28.6k
Cache hits by data type:
Demand data: 67.0 % 39.0M
Demand prefetch data: 0.0 % 0
Demand metadata: 33.0 % 19.2M
Demand prefetch metadata: 0.0 % 0
Cache misses by data type:
Demand data: 60.0 % 315.5k
Demand prefetch data: 0.1 % 372
Demand metadata: 33.0 % 173.5k
Demand prefetch metadata: 6.9 % 36.4k 372
