WSUS shows incorrect Needed Count (or: how to get it to 100%?)

I want to monitor which of my servers need updates so I installed WSUS. Installation went fine and the servers are getting their updates now from WSUS.

Проблема

Недавно я установил новый диск и создал на нем zpool:

/# zpool create morez /dev/sdb

После некоторого использования я заметил, что он работает довольно медленно:

/morez# fio --name rw --rw rw --size 10G
   read: IOPS=19.6k, BW=76.6MiB/s (80.3MB/s)(5120MiB/66834msec)
  write: IOPS=19.6k, BW=76.6MiB/s (80.3MB/s)(5120MiB/66834msec)

Этот тест довольно похож на мой реальный вариант использования . Я читаю умеренное количество (~ 10k) изображений (~ 2 MiB каждое) с диска. Они были записаны все сразу, когда диск был почти пуст, поэтому я не ожидаю, что они будут фрагментированы.

Для сравнения я протестировал ext4:

/# gdisk /dev/sdb
...
/# mkfs.ext4 -f /dev/sdb1 && mount /dev/sdb1 /mnt && cd /mnt
/mnt# fio --name rw --rw rw --size 10G
   read: IOPS=48.3k, BW=189MiB/s (198MB/s)(5120MiB/27135msec)
  write: IOPS=48.3k, BW=189MiB/s (198MB/s)(5120MiB/27135msec)

и btrfs:

/# mkfs.btrfs -f /dev/sdb1 && mount /dev/sdb1 /mnt && cd /mnt
/mnt# fio --name rw --rw rw --size 10G
   read: IOPS=51.3k, BW=201MiB/s (210MB/s)(5120MiB/25528msec)
  write: IOPS=51.3k, BW=201MiB/s (210MB/s)(5120MiB/25528msec)

Что могло быть причиной проблем с производительностью с ZFS и как я могу сделать это быстрее?

Неудачная попытка решения

Я также попытался явно установить размер сектора для zpool, так как мой диск ( Seagate ST1000DM003 ) использует 4096 байт физического секторов:

/# zpool create -o ashift=12 morez /dev/sdb

Это не улучшило производительность:

/morez# fio --name rw --rw rw --size 10G
   read: IOPS=21.3k, BW=83.2MiB/s (87.2MB/s)(5120MiB/61573msec)
  write: IOPS=21.3k, BW=83.2MiB/s (87.2MB/s)(5120MiB/61573msec)

Наблюдение

Как ни странно, использование zvol имело отличную производительность:

/# zfs create -V 20G morez/vol
/# fio --name rw --filename /dev/zvol/morez/vol --rw rw --size 10G
   read: IOPS=52.7k, BW=206MiB/s (216MB/s)(5120MiB/24852msec)
  write: IOPS=52.7k, BW=206MiB/s (216MB/s)(5120MiB/24852msec)

Почему это влияет только на файловые системы ZFS, а не на zvols?

Расширенное тестирование для btrfs

В комментариях было высказано предположение, что разница может быть связана с кешированием. После дальнейшего тестирования я не верю, что это так. Я увеличил размер теста btrfs намного выше объема памяти моего компьютера, и его производительность по-прежнему была значительно выше, чем у ZFS:

/# mkfs.btrfs -f /dev/sdb1 && mount /dev/sdb1 /mnt && cd /mnt
/mnt# $ fio --name rw --rw rw --size 500G --runtime 3600 --time_based --ramp_time 900
   read: IOPS=41.9k, BW=164MiB/s (172MB/s)(576GiB/3600003msec)
  write: IOPS=41.9k, BW=164MiB/s (172MB/s)(576GiB/3600003msec)

Информация о системе

Программное обеспечение

  • Arch Linux, версия ядра 4.11.6
  • ZFS в Linux 0.6.5.10
  • fio 2.21

Аппаратное обеспечение

Информация о ZFS

Вот как выглядели свойства ZFS до запуска fio. Это просто результат создания zpool с настройками по умолчанию.

# zpool get all morez
NAME   PROPERTY                    VALUE            SOURCE
morez  size                        928G             -
morez  capacity                    0%               -
morez  altroot                     -                default
morez  health                      ONLINE           -
morez  guid                        [removed]        default
morez  version                     -                default
morez  bootfs                      -                default
morez  delegation                  on               default
morez  autoreplace                 off              default
morez  cachefile                   -                default
morez  failmode                    wait             default
morez  listsnapshots               off              default
morez  autoexpand                  off              default
morez  dedupditto                  0                default
morez  dedupratio                  1.00x            -
morez  free                        928G             -
morez  allocated                   276K             -
morez  readonly                    off              -
morez  ashift                      0                default
morez  comment                     -                default
morez  expandsize                  -                -
morez  freeing                     0                default
morez  fragmentation               0%               -
morez  leaked                      0                default
morez  feature@async_destroy       enabled          local
morez  feature@empty_bpobj         enabled          local
morez  feature@lz4_compress        active           local
morez  feature@spacemap_histogram  active           local
morez  feature@enabled_txg         active           local
morez  feature@hole_birth          active           local
morez  feature@extensible_dataset  enabled          local
morez  feature@embedded_data       active           local
morez  feature@bookmarks           enabled          local
morez  feature@filesystem_limits   enabled          local
morez  feature@large_blocks        enabled          local

# zfs get all morez
NAME   PROPERTY              VALUE                  SOURCE
morez  type                  filesystem             -
morez  creation              Thu Jun 29 19:34 2017  -
morez  used                  240K                   -
morez  available             899G                   -
morez  referenced            96K                    -
morez  compressratio         1.00x                  -
morez  mounted               yes                    -
morez  quota                 none                   default
morez  reservation           none                   default
morez  recordsize            128K                   default
morez  mountpoint            /morez                 default
morez  sharenfs              off                    default
morez  checksum              on                     default
morez  compression           off                    default
morez  atime                 on                     default
morez  devices               on                     default
morez  exec                  on                     default
morez  setuid                on                     default
morez  readonly              off                    default
morez  zoned                 off                    default
morez  snapdir               hidden                 default
morez  aclinherit            restricted             default
morez  canmount              on                     default
morez  xattr                 on                     default
morez  copies                1                      default
morez  version               5                      -
morez  utf8only              off                    -
morez  normalization         none                   -
morez  casesensitivity       sensitive              -
morez  vscan                 off                    default
morez  nbmand                off                    default
morez  sharesmb              off                    default
morez  refquota              none                   default
morez  refreservation        none                   default
morez  primarycache          all                    default
morez  secondarycache        all                    default
morez  usedbysnapshots       0                      -
morez  usedbydataset         96K                    -
morez  usedbychildren        144K                   -
morez  usedbyrefreservation  0                      -
morez  logbias               latency                default
morez  dedup                 off                    default
morez  mlslabel              none                   default
morez  sync                  standard               default
morez  refcompressratio      1.00x                  -
morez  written               96K                    -
morez  logicalused           72.5K                  -
morez  logicalreferenced     40K                    -
morez  filesystem_limit      none                   default
morez  snapshot_limit        none                   default
morez  filesystem_count      none                   default
morez  snapshot_count        none                   default
morez  snapdev               hidden                 default
morez  acltype               off                    default
morez  context               none                   default
morez  fscontext             none                   default
morez  defcontext            none                   default
morez  rootcontext           none                   default
morez  relatime              off                    default
morez  redundant_metadata    all                    default
morez  overlay               off                    default
11
задан 30 June 2017 в 05:54
2 ответа

Примечание: поскольку в задании fio отсутствует direct = 1 ( http://fio.readthedocs.io/en/latest/fio_doc.html#cmdoption- arg-direct ) некоторый объем выполняемых операций ввода-вывода (как чтение , так и запись) может кэшироваться операционной системой, искажая ваши результаты (и делая числа искусственно завышенными). Само по себе это еще больше усложняется следующим:

  • ZFS в Linux либо не поддерживает O_DIRECT (поэтому открытие не выполняется), либо, если это так, то делает это, тихо возвращаясь к буферизованному вводу / выводу. O (см. Пункт 3 https://github.com/zfsonlinux/zfs/commit/a584ef26053065f486d46a7335bea222cb03eeea ).
  • В некоторых случаях BTRFS и ext4 будут возвращать O_DIRECT] O_DIRECT Буферизованный ввод-вывод.

Имейте в виду, что O_DIRECT по-прежнему выполняет буферизованный ввод-вывод, поскольку в Linux O_DIRECT является скорее подсказкой (см. раздел ссылок ) https://stackoverflow.com/a/46377629/2732969).

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

4
ответ дан 2 December 2019 в 21:53

Хотя мне и старому, этот вопрос заслуживает ответа.

fio по умолчанию выдает IOP размером 4 КБ; В наборах данных ZFS по умолчанию используется запись 128 КБ. Это несоответствие означает, что каждая запись 4 КБ вызывает чтение / изменение / запись всей записи 128 КБ.

ZVOL, с другой стороны, по умолчанию используют размер блока 8 КБ. Это означает, что запись 4K вызывает гораздо меньший цикл чтения / изменения / записи записи 8K, и, если повезет, две записи 4K могут быть объединены в одну запись 8K (что требует без чтения / изменения / писать вообще).

Размер записи набора данных ZFS можно изменить с помощью zfs set recordize = 8K , и в этом случае он должен давать более или менее эквивалентную производительность, чем ZVOL. Однако при использовании для относительно больших передач (OP говорил о файлах размером 2 МБ, которые, будучи изображениями, должны полностью считываться каждый раз при доступе к ним), лучше иметь large размер записи / размер блока, иногда даже больше, чем настройка по умолчанию (128K).

6
ответ дан 2 December 2019 в 21:53

Теги

Похожие вопросы