ZFS primarycache=metadata и recordsize

lexa - 28/Янв/2017 13:06

Значит продолжение вот этой истории (в стиле "что вижу - то пою"): Про zfs primarycache (самая мякотка там в комментариях):

  1. Поставил бэкапному dataset recordsize=64k (что соответствует типичному запросу на чтение самбой)
  2. Подождал несколько дней, новые бэкапы создались с таким размером записи
  3. Поставил primarycache=metadata
  4. Запустил проверку одного из новых бэкапов:
    • Скорость чтения снизилась до 100-150Mb/sec (было, с мегабайтной записью и primarycache=all 150-200)
    • Скорость чтения с дисков соответствует скорости отдачи в сеть, "зря" ничего не читается.
    • zfs-mon показывает ZFETCH, но я вот не понимаю куды оно фетчит, если в ARC как бы запрещено? Или не запрещено? Она же показывает ARC hits на уровне 30%, чего я тоже не понимаю.

Таким образом

  • Гипотеза о том, что пар уходил в свисток (читалась длинная запись, которая потом нигде не сохранялась) - ну вроде да.
  • Соотношение disk/network должно было быть 16:1 (если от мегабайтной записи мы хотим 64к, а остальное выкидываем), а было ~4:1. Не понимаю. vdev cache?
  • То как стало - хоть оно и медленнее - меня устраивает.
    Но ТОЛЬКО  если при этом не происходит размывания ARC.
    Как проверить - непонятно, ну буду посматривать на соотношения Most Recently Used/Most Frequently Used, по идее сразу после утренних бэкапов ранее должен был бы быть пик Recently (3-4xARC побэкапили, все frequently - вытеснили).

     

Comments

geomflash - 30/Янв/2017 11:24

"Соотношение disk/network должно было быть 16:1"
Теперь я не понимаю. Почему? Не складывается у меня картинка в голове ни при каких раскладах :-).

"То как стало - хоть оно и медленнее - меня устраивает"
Думаю, есть большие шансы получить близко к тому, как было при primarycache=all. Совет был - уравнять размеры. Но ты так и не сказал о каком размере smb блока договорились твой windows и самба сервер. Также никто не заставлял уравнивать со стороны recordsize :-). Тем более, заранее было известно, что raidz чувствителен к размеру recordsize.

"Но ТОЛЬКО если при этом не происходит размывания ARC."
Интересное требование ;-). Наверно это уже ближе к теме - какая настройка для ARC была бы оптимальна для самба сервера, выполняющего какие-то конкретные задачи. Поэтому нужно определиться, что ты подразумеваешь под размыванием ARC и для чего тебе это нужно.

lexa - 30/Янв/2017 12:00

>> Поэтому нужно определиться, что ты подразумеваешь под размыванием ARC и для чего тебе это нужно.

Я подразумеваю следующее:
- пришел бэкап-клиент
- записал свои 100+ гигов
- верифицировал их (то есть прочитал)

Что после этого будет в ARC (который 30Gb) если никакой другой нагрузки в это время нет?
И второй вопрос - а зачем оно там, если шансов читать это в ближайшие сутки - ~0, да и вообще ~0

geomflash - 30/Янв/2017 13:54

Вся метадата от 100+ гигов данных точно залезет в ARC. Какой у неё будет размер не знаю. Наверняка при записи около 10% (vfs.zfs.dirty_data_max) тоже будет вытолкано из ARC-а. Может ещё что-то.

lexa - 30/Янв/2017 14:01

про метадату вопросов нет, конечно влезет.
Но если primarycache=all, то там даты будет полный ARC.

geomflash - 30/Янв/2017 14:12

Ну как бы с датой уже разобрались, что она туда не попадает :-).

lexa - 30/Янв/2017 14:25

Ну да, =metadata на этом пуле задумывалось именно ради этого.

Насколько оно эффективно - это хороший вопрос, надо полноценный мониторинг zfs прикрутить бы, графики смотреть.

geomflash - 31/Янв/2017 11:08

Когда у меня были только гигабитные линки , я кэширование данных не включал. Всё равно всё упиралось в 115MB/s, а установка =all имеет не только исключительно положительные свойства :-). Но тебя это похоже не касается.

"Она же показывает ARC hits на уровне 30%, чего я тоже не понимаю."
Вчера на это не обратил внимание. С тем, что показывает hits в ARC без поллитры не разберёшься :-), а если разберёшься, то поймёшь, что практическая польза от неё стремится к нулю. Я на эту статистику внимания не обращаю и тебе не советую :-).

lexa - 31/Янв/2017 11:15

"ну так других то ведь нет".

Для нормальных датасетов, с *cache=all - zfs-mon кажет цифры, которые очень похожи на правду.
Ну там если нагрузить большим потоком, то отношение read с блинов/read с l2arc очень похоже на L2ARC hits.

А другой статистики-мониторинга все едино не видать.

geomflash - 31/Янв/2017 14:01

Я не про правду, а про интерпретацию :-). Простой эксперимент. Создать большой файл (чтобы не обращать внимания на начальную статистику). Перегрузиться, сразу zfs-stats -ER. Прочитать большой файл и опять zfs-stats -ER. С одной стороны факт, что файл один раз физически прочитан с дисков, с другой стороны цифры статистики. Вглядишься, вдумаешься и вправду не врут :-). Но затем перестаёт мучить вопрос: как же так могло получиться, что при ежедневном физическом чтении 350 гигабайт с дисков (файлы каждый день процентов на 80 другие) и памяти в сервере всего 16 гиг - за три мясяца работы Cache Hit Ratio под 80% ;-).

lexa - 31/Янв/2017 14:26

Поиграюсь при случае на втором ящике.

На основном - у меня теперь полугиговый L2ARC, работает, мне нравится, но вот каждая перезагрузка - как серпом.

lexa - 30/Янв/2017 11:58

>> "Соотношение disk/network должно было быть 16:1"

Мегабайт (записи) прочли, 64к отдали самбе, остальное - выкинули?

Как посмотреть "о чем договорились windows/samba" - не знаю, но размеры чтений-записей в smb4.conf выставлены именно в 64к (потому что больше, вроде бы, не бывает?)

geomflash - 30/Янв/2017 13:58

У меня windows 7, когда раньше разбирался нашёл:
https://technet.microsoft.com/en-us/library/ff625695(v=ws.10).aspx
Смотри про Large MTU support. На recordsize=1M не проверял, но на 128k точно работает.

lexa - 30/Янв/2017 14:04

Как посмотреть размер запроса (который прилетает)?

lexa - 30/Янв/2017 14:09

The default is 0 for Windows 8 only. In Windows 8, the SMB redirector transfers payloads as large as 1 MB per request,

Т.е. на 8-ке large mtu включено с раздачи.

geomflash - 30/Янв/2017 14:28

Я наткнулся на это когда сравнивал размер читаемого файла с реальным объёмом чтения с дисков. Мне этого было достаточно, поэтому как можно ещё даже и не пытался узнать. Создаёшь тестовый файл, чтобы легче анализировать, загоняшь метадату в ARC (простое чтение, заодно можно проверить, что при каждом чтении с дисков считывается ровно размер файла), затем читаешь по сети и смотришь сколько реально прочиталось с дисков.