ZFS primarycache=metadata и recordsize
lexa - 28/Янв/2017 13:06
Значит продолжение вот этой истории (в стиле "что вижу - то пою"): Про zfs primarycache (самая мякотка там в комментариях):
- Поставил бэкапному dataset recordsize=64k (что соответствует типичному запросу на чтение самбой)
- Подождал несколько дней, новые бэкапы создались с таким размером записи
- Поставил primarycache=metadata
- Запустил проверку одного из новых бэкапов:
- Скорость чтения снизилась до 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
"Соотношение disk/network
"Соотношение disk/network должно было быть 16:1"
Теперь я не понимаю. Почему? Не складывается у меня картинка в голове ни при каких раскладах :-).
"То как стало - хоть оно и медленнее - меня устраивает"
Думаю, есть большие шансы получить близко к тому, как было при primarycache=all. Совет был - уравнять размеры. Но ты так и не сказал о каком размере smb блока договорились твой windows и самба сервер. Также никто не заставлял уравнивать со стороны recordsize :-). Тем более, заранее было известно, что raidz чувствителен к размеру recordsize.
"Но ТОЛЬКО если при этом не происходит размывания ARC."
Интересное требование ;-). Наверно это уже ближе к теме - какая настройка для ARC была бы оптимальна для самба сервера, выполняющего какие-то конкретные задачи. Поэтому нужно определиться, что ты подразумеваешь под размыванием ARC и для чего тебе это нужно.
>> Поэтому нужно определиться
>> Поэтому нужно определиться, что ты подразумеваешь под размыванием ARC и для чего тебе это нужно.
Я подразумеваю следующее:
- пришел бэкап-клиент
- записал свои 100+ гигов
- верифицировал их (то есть прочитал)
Что после этого будет в ARC (который 30Gb) если никакой другой нагрузки в это время нет?
И второй вопрос - а зачем оно там, если шансов читать это в ближайшие сутки - ~0, да и вообще ~0
Вся метадата от 100+ гигов
Вся метадата от 100+ гигов данных точно залезет в ARC. Какой у неё будет размер не знаю. Наверняка при записи около 10% (vfs.zfs.dirty_data_max) тоже будет вытолкано из ARC-а. Может ещё что-то.
про метадату вопросов нет,
про метадату вопросов нет, конечно влезет.
Но если primarycache=all, то там даты будет полный ARC.
Ну как бы с датой уже
Ну как бы с датой уже разобрались, что она туда не попадает :-).
Ну да, =metadata на этом пуле
Ну да, =metadata на этом пуле задумывалось именно ради этого.
Насколько оно эффективно - это хороший вопрос, надо полноценный мониторинг zfs прикрутить бы, графики смотреть.
Когда у меня были только
Когда у меня были только гигабитные линки , я кэширование данных не включал. Всё равно всё упиралось в 115MB/s, а установка =all имеет не только исключительно положительные свойства :-). Но тебя это похоже не касается.
"Она же показывает ARC hits на уровне 30%, чего я тоже не понимаю."
Вчера на это не обратил внимание. С тем, что показывает hits в ARC без поллитры не разберёшься :-), а если разберёшься, то поймёшь, что практическая польза от неё стремится к нулю. Я на эту статистику внимания не обращаю и тебе не советую :-).
"ну так других то ведь нет".
"ну так других то ведь нет".
Для нормальных датасетов, с *cache=all - zfs-mon кажет цифры, которые очень похожи на правду.
Ну там если нагрузить большим потоком, то отношение read с блинов/read с l2arc очень похоже на L2ARC hits.
А другой статистики-мониторинга все едино не видать.
очень похожи на правду
Я не про правду, а про интерпретацию :-). Простой эксперимент. Создать большой файл (чтобы не обращать внимания на начальную статистику). Перегрузиться, сразу zfs-stats -ER. Прочитать большой файл и опять zfs-stats -ER. С одной стороны факт, что файл один раз физически прочитан с дисков, с другой стороны цифры статистики. Вглядишься, вдумаешься и вправду не врут :-). Но затем перестаёт мучить вопрос: как же так могло получиться, что при ежедневном физическом чтении 350 гигабайт с дисков (файлы каждый день процентов на 80 другие) и памяти в сервере всего 16 гиг - за три мясяца работы Cache Hit Ratio под 80% ;-).
Поиграюсь при случае на
Поиграюсь при случае на втором ящике.
На основном - у меня теперь полугиговый L2ARC, работает, мне нравится, но вот каждая перезагрузка - как серпом.
>> "Соотношение disk/network
>> "Соотношение disk/network должно было быть 16:1"
Мегабайт (записи) прочли, 64к отдали самбе, остальное - выкинули?
Как посмотреть "о чем договорились windows/samba" - не знаю, но размеры чтений-записей в smb4.conf выставлены именно в 64к (потому что больше, вроде бы, не бывает?)
У меня windows 7, когда
У меня windows 7, когда раньше разбирался нашёл:
https://technet.microsoft.com/en-us/library/ff625695(v=ws.10).aspx
Смотри про Large MTU support. На recordsize=1M не проверял, но на 128k точно работает.
Как посмотреть размер запроса
Как посмотреть размер запроса (который прилетает)?
The default is 0 for Windows
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 включено с раздачи.
Я наткнулся на это когда
Я наткнулся на это когда сравнивал размер читаемого файла с реальным объёмом чтения с дисков. Мне этого было достаточно, поэтому как можно ещё даже и не пытался узнать. Создаёшь тестовый файл, чтобы легче анализировать, загоняшь метадату в ARC (простое чтение, заодно можно проверить, что при каждом чтении с дисков считывается ровно размер файла), затем читаешь по сети и смотришь сколько реально прочиталось с дисков.