Свежие комментарии

Меня два месяца (с небольшим перерывом) не было дома, не помню ничего по памяти.

Вот запустил верификацию бэкапа. Вижу такое:

ZFS real-time cache activity monitor
Seconds elapsed: 197

Cache hits and misses:
                                  1s    10s    60s    tot
                     ARC hits:   398    332    368    264
                   ARC misses:   336    292    323    232
         ARC demand data hits:   335    286    314    224
       ARC demand data misses:     0      0      0      1
     ARC demand metadata hits:     2      2      2      2
   ARC demand metadata misses:     0      0      0      0
       ARC prefetch data hits:    61     43     50     38
     ARC prefetch data misses:   336    292    323    231
   ARC prefetch metadata hits:     0      2      2      1
 ARC prefetch metadata misses:     0      0      0      0
                   L2ARC hits:     0      0      0      0
                 L2ARC misses:   336    292    323    232
                  ZFETCH hits:  1458   1361   1525   1085
                ZFETCH misses:  2662   2473   2617   1792
           VDEV prefetch hits:     0      0      0      0
         VDEV prefetch misses:     0      0      0      0

Cache efficiency percentage:
                          10s    60s    tot
                  ARC:  53.21  53.26  53.23
      ARC demand data: 100.00 100.00  99.56
  ARC demand metadata: 100.00 100.00 100.00
    ARC prefetch data:  12.84  13.40  14.13
ARC prefetch metadata: 100.00 100.00 100.00
                L2ARC:   0.00   0.00   0.00
               ZFETCH:  35.50  36.82  37.71
        VDEV prefetch:   0.00   0.00   0.00

Это, конечно, повод еще раз подумать про размер записи на бэкапном томе....

Но доля бэкапов-верификаци в общем ZFS-трафике у меня очень велика.

Собственно вот:
 

 zpool iostat
               capacity     operations    bandwidth
pool        alloc   free   read  write   read  write
----------  -----  -----  -----  -----  -----  -----
zbackup     3,05T  1,48T     12      6  10,9M  1,89M
zdata       16,8T  21,2T      2      2  2,03M   291K
----------  -----  -----  -----  -----  -----  -----

90% В записи и 80 в чтении.

Я почти уверен, что статистика сильно испорчена моими экспериментами.

Вдогонку - то что прилетело письмом, там неправильная статистика пула (ada0 - это загрузочный, а надо ada1), на сайте - верно.

Если можно, ещё iostat -Ix одного hdd из пула и ssd (L2ARC). А я за причинённые хлопоты, постараюсь, что-то подсказать. Может и пригодится :-).

ARC Size: 55.76% 16.17 GiB
Target Size: (Adaptive) 55.76% 16.17 GiB
Min Size (Hard Limit): 12.50% 3.62 GiB
Max Size (High Water): 8:1 29.00 GiB

L2: сейчас занято 258G из 500 возможных.

ZFS-stats у меня не показателен совсем т.к. L2 разрешен только на некоторых датасетах. А скажем там где кино и подобное - нет, соответственно цифры заниженные.

Реальная эффективность кэша при работе именно с равчиками - процентов 70-90 получается в зависимости от интенсивности работы с каталогом. Это по zfs-mon.

Сейчас zfs-stats показывает вот такое, но
а) маленький аптайм, я апгрейдился же
б) я делал эксперименты именно по кэшируемости в L2 (вот тот самый tar cf /dev/null large-folder, который обсуждали уже весной), поэтому цифры выше реальных

FreeBSD 11.1-RELEASE-p1 #1 r322394: Fri Aug 11 12:55:37 MSK 2017 lexa
11:57AM  up 3 days, 22:58, 1 users, load averages: 0,10 0,18 0,16

------------------------------------------------------------------------

ARC Efficiency:                                 18.33m
        Cache Hit Ratio:                62.16%  11.39m
        Cache Miss Ratio:               37.84%  6.94m
        Actual Hit Ratio:               39.41%  7.22m

        Data Demand Efficiency:         88.11%  6.67m
        Data Prefetch Efficiency:       32.53%  8.21m

        CACHE HITS BY CACHE LIST:
          Anonymously Used:             29.74%  3.39m
          Most Recently Used:           37.30%  4.25m
          Most Frequently Used:         26.11%  2.97m
          Most Recently Used Ghost:     1.35%   154.11k
          Most Frequently Used Ghost:   5.50%   626.04k

        CACHE HITS BY DATA TYPE:
          Demand Data:                  51.59%  5.88m
          Prefetch Data:                23.45%  2.67m
          Demand Metadata:              6.07%   691.54k
          Prefetch Metadata:            18.88%  2.15m

        CACHE MISSES BY DATA TYPE:
          Demand Data:                  11.44%  793.43k
          Prefetch Data:                79.90%  5.54m
          Demand Metadata:              8.28%   574.23k
          Prefetch Metadata:            0.39%   26.77k

------------------------------------------------------------------------

Никогда не задумывался что там у акрониса внутри.

Но исходя из общих соображений
- оно знает структуру NTFS
- оно знает какие файлы изменились (по дате или по контрольным суммам - умеет оба)
- ну и пишет, получается, только нужное.

То есть это не 'dd', а, в юниксных терминах, dump

Ну вот тем не менее - мне кажется, что это место тоже стало быстрее.

Сам по себе листинг 5к файлов - вменяемо быстрый и так.

Под просмотром большого каталога я понимал получение только информации о файлах данного каталога, а здесь немного другая задача. Для hdd в raidz и recordsize=1m оно как бы по определению не может быть быстро. По сути определяющим будет время случайного доступа большими блоками, а у zfs в данной конфигурации с этим проблемы.

Да, из тела.
Там "десятки килобайт" (т.е. 0.1%).

Мне кстати вот кажется, что
tar cf /dev/null bigfolder1
tar cf /dev/null bigfolder2
И так по кругу

Стали работать предсказуемее, чем раньше. Нет впечатления, что что-то выкидывают из кэша вникуда (место записи в L2)

Так ты же уже обновился :-).

Кстати, автор сжатия в арке и той "твоей проблемы" - одно лицо :-))).