ZFS L2ARC performance
Преамбула:
(У одного моего друга) есть ZFS-pool такой вот конфигурации:
- i5-2400 CPU @ 3.10GHz
- avail memory = 16477163520 (15713 MB)
- FreeBSD 12.0-CURRENT #4 r302772M
- 8xTb SATA в RAIDZ2.
Подключены к Adaptec 5805, сделаны simple volumes по одному диску - 3 консумерских SSD-шки (OCZ Vertex4, OCZ Agility 3, Intel 520) в L2ARC
- я пробовал объединять их в gstripe, счастья не увидел особого
- и сейчас они как отдельные диски подключены.
На пуле лежат RAW-фоточки к которым я хожу readonly.
Сделаны такие вот настройки, касающиеся ZFS:
/boot/loader.conf:
vm.kmem_size="14G"
vfs.zfs.arc_max="12G"
vfs.zfs.l2arc_write_boost="400000000"
vfs.zfs.l2arc_noprefetch="0"
/etc/sysctl.conf:
vfs.zfs.l2arc_write_max=300000000
vfs.zfs.l2arc_norw=0
vfs.zfs.min_auto_ashift=12
А теперь мы берем каталог с 45Gb файлов и копируем его на локальный SSD раза эдак 4. Исходя из того, что на 4-й раз у нас будет и Frequent use и Recent use.
Получается фигня.
Во-первых, медленно.
Во-вторых, эффективность ARC и L2ARC - невысокая. Ну то есть десятки процентов, а я ожидал бы ~100. Вот что кажет zfs-mon -a в процессе чтения одного и того же набора данных по N-му разу:
В третьих, и по zpool iostat и по просто iostat видно, что основное чтение идет с магнитных дисков.
Вот iostat -x (aacdN - HDD, adaN - SSD):
А вот zpool iostat -v 3 (специально ловил момент когда на SSD побольше, бывает и меньше)
Как мы видим:
- На SSD-шках что-то есть (в сумме 100Gb, потому что там кроме каталога на 45G с которым я упражняюсь, накопилось еще столько же за предыдущие 5 дней аптайма)
- Там гарантированно есть то, что я в тестах прочитал уже несколько раз (раз 6 уже). Судя вот по объему.
- Несмотря на это, основное чтение идет с основного пула
Вопросов у меня, понятно два (или один)
- Какого хрена?
- Что я делаю не так?
Comments
Попробовать поиграть с
Попробовать поиграть с recordsize на датасетах, с которых идёт чтение?
Да, буду делать.
Да, буду делать.
И, возможно, поиграть с размером L2ARC. Я вот размахнулся, а наверное надо гигов с 20 начать.
В тред призывается Слава
В тред призывается Слава Ольховченков!
Ну вот recordsize сильно
Ну вот recordsize сильно влияет.
Сейчас я методику стабилизировал вроде - к вечеру расскажу.
Кэширование на ssd патерна
Кэширование на ssd патерна "последовательный доступ" довольно проблемная задача. Многие системы кэширования справляются с ней не очень (вплоть до ухудшения производительности). Хотя L2ARC использует самый простой(лёгкий) метод кэширования на ssd, я всё же предполагаю, что у него тоже всё не очень хорошо. Косвенно это подтверждают настройки по умолчанию, пытающие исключить кэширование последовательного доступа. Хотя это можно проверить :-).
Оно какое-то адаптивное.
Оно какое-то адаптивное.
То есть "читаю один и тот же набор данных" (70G файлов на одном dataset):
- по сети (скорость ограничивает Samba?) - много чтений с HDD
- локально, на сервере, tar cf /dev/null . - (практически) все читается из кэша
Нахожусь в недоумении.
Может на это влияют
Может на это влияют "ускорялки" от самбы? aio, raw и т.п.?
aio нету, с ним медленнее (у
aio нету, с ним медленнее (у меня).
Но самба может делать readahead, это да (вроде нужно включить, не разбирался пока). И это будет влиять.
Не зная всех ньюансов мне
Не зная всех ньюансов мне сложно интерпретировать твои результаты :-). Поэтому решил провести простейший тест на определение производительности L2ARC при последовательном чтении. L2ARC до этого теста не использовал, поэтому повторил настройки из поста. Памяти 16 гигабайт, поэтому выбрал чтение двух 32 гигабайтных файлов. При первом чтении кэшируется 990MB, при втором 152MB, при третьем 15MB... :-). Нашел, что vfs.zfs.l2arc_noprefetch должен быть установлен до имрорта пула. Поменял значения vfs.zfs.l2arc_write_boost и vfs.zfs.l2arc_write_max на 268435456 (256MB). Экспортнул/импортнул пул. При первом чтении закэшировалось 2050MB, при втором 883MB, при третьем 20MB... :-).
У тебя получилось найти параметры при которых L2ARC начинает кэшировать при последовательном чтении?
У меня консистентные
У меня консистентные результаты получались с L2ARC кэширующим при записи.
То есть я делал zfs send | zfs recv (с одного пула на другой) с разным размером записи.
И этот процесс - заполнял L2arc на все данные.
При этом l2arc_write_* - большие
l2arc_noprefetch=0 - подействовал сразу, без импорта-экспорта, на скаку (теперь я знаю что не должен был :)
l2arc_norw=0
И результаты такие (send | recv, а потом последовательные чтения tar cf /dev/null):
- чем больше recordsize
- тем меньше l2arc hits по zfs-mon (~100% для 128k и меньше, 50-70% для 1M)
- но тем больше скорость исполнения tar cf, с мегабайтным блоком получается больше 700Mb/sec
При этом таких скоростей по самбе на чтение нету. Есть ~400, независимо от l2arc
На этой фазе я опечалился, мне прислали багу в rawdigger - и я переключился на нее.
У меня самба раскочегарилась
У меня самба раскочегарилась на чтение до 600 примерно, но дальше тоже не идёт.
Но для этого пришлось делать для интерфейса
ethertool -K eth2 ntuple on
ethertool -G eth2 rx 2048 tx 2048
(по умолчанию 512 было, если поставить больше 2048, то тест ATTO начинает какие-то чудеса показывать)
Клиент - Win10.
А какой смысл в ntuple в
А какой смысл в ntuple в данном случае? Квадрупляй (2IP, 2порта) вроде одинаковый для одной сессии, все пойдет все равно в одну очередь?
Никакого, но от отключает ATR
Никакого, но от отключает ATR. У меня так быстрее, выигрываю почти 100mb/s. Возможно, заморочки виртуального линукса...
Мда, на скорости 600+ это еще
Мда, на скорости 600+ это еще и принять некуда, одиночные SSD не могуть.
Очереди поувеличивать на интерфейсе - да, полезно оказалось.
Как это некуда? А изображение
Как это некуда? А изображение прочесть с NAS и показать на десктопе? Его же не надо локально сохранять.
600Mb/sec мой варез не жует.
600Mb/sec мой варез не жует. Скорее вот 300-350
5fps/Sony A7R2 uncompressed - это ~400
Ну то есть можно, понятно, программу написать, но не хочется.
Ну так технологии не стоят на
Ну так технологии не стоят на месте. Процессор помощнее, новые инструкции - и начнёт справляться. Если бы скорости передачи по сети росли с такой скоростью, как процессоры, то мы бы уже давно пользовались беспроводным 10G WiFi с добитием на 10км :)
Не на то жалуетесь!
Не на то жалуетесь!
В 95-м году я сидел в университете за Sun SparcStation 20 с 50-мегагерцовым процессором а дома - за 486/DX50 (могу путать +-год).
А сеть была 10-мегабитная и дома (дома, впрочем, ее не было ибо было не надо, была бы - была бы десятка) и в МГУ.
Сейчас 10-гигабитная сеть и 60-мбит интернет - более доступны, чем в 1000 раз более медленные тогда (10Mbit, заметим, была shared на всех, не switched).
За это время (20 лет) CPU не стали в 1000 раз быстрее. То есть формально - может и стали, по факту - все-таки нет, потому что память не стала в 1000 раз быстрее (а все уперто в нее).
А диски стали быстрее может быть в 20 раз, даже не в 100. Поэтому получился огромный разбаланс.
Сейчас, да, SSD (NVMe) более-менее вроде бы возвращают ситуацию к балансу 20-летней давности. То есть можно возвращать "те" алгоритмы работы с диском (которые были простые "не париться").
Я к тому, что жаловаться надо, на самом деле, на диски. Затем - на память, затем - на процессоры. А сети - развиваются быстрее всего.
Не соглашусь по поводу 1000
Не соглашусь по поводу 1000 раз, всё таки 10G для конечного пользователя с десктопом - это пока очень редко. В настоящий момент правильнее будет сравнивать 10мбит и 1гбит, т.е. в 100 раз. Причём на пятки гигабиту уже начинает наступать WiFi. Такими темпами переход десктопов на проводной 10G может и не наступить :)
А с NVMe да, интересно. Раньше ж как - "мы создали SSD со скоростью 200Mb/s... а мы 250! ... а мы 400! (хор "ууууу!!!"). Т.е. постепенно так подбирались к 500. И тут выходит консьюмерский NVMe и нна сразу - "2Gb на запись, 1G на чтение". Я вот при таких раскладах следующий свой комп планирую на NVMe и вообще без HDD. Соответственно буду искать и корпус, в котором всего этого нет, потому что нафик не надо.
А 20 лет назад у "конечного
А 20 лет назад у "конечного пользователя дома" скорость была 0.
А на кафедре у нас (130 сотрудников вроде) был наверное десяток компьютеров - и только три в сети.
В 2001-м году в рамблере на серверах (!) была сотка, а гигабит - только между свитчами и то не везде, а кое где агрегация была.
А процесоры уже были - гигагерц тогда.
С тех пор - на серверах 100 раз по сети, а "100 раз по процессору" наберется только если 30-ядерные Xeon которые только на выставках бывают - учесть.
Что касается SSD/NVMe - революция еще только грядет.
Сейчас нужно выкинуть все алгоритмы оптимизации общения с диском (вроде кэширования r/o данных в памяти) и заменить новыми. Пока еще не.
Да не, ставили сеть, если
Да не, ставили сеть, если нужно было. По 10мбит сетке в 98-м, кажется, резались в Quake шесть на шесть на квартире в Питере. В 96-м кинули с соседом по подвалу кабель, он мне интернет расшаривал.
Не было просто массовой необходимости - про NAS юзеры ешё не знали, умных телевизоров не было, интернет по модему... Бэкап помещался на CD и дублировался на второй, записанный на болванку другой фирмы и на другом резаке. Самый крутой бэкап назывался Quantum Fireball, лежащий на полочке на видном месте :)
В SSD/NVMe самое интересное - технологичность и объём (физический). Клепать микросхемы IMHO проще, чем балансировать диски. И потенциал параллельности не ограничен физическими размерами. Срок жизни со временем решится сам собой, или избыточностью, или новыми технологиями. Да и не нужно срок вытягивать до бесконечности, моральное устаревание приходит намного раньше.
Революцию очень должен
Революцию очень должен толкнуть 3D XPoint. Который быстрее флэша во сколько там раз? 10? 100? Ну, обещают.
SSD/SATA - это уже революция
SSD/SATA - это уже революция (относительно типичных 10ms access на HDD).
И, подозреваю, во многих местах она уже случилась, только об этом не кричат, считая ключевым технологическим преимуществом.
а почему именно NVMe? чем оно
а почему именно NVMe? чем оно от pci-e отличается? )
Так ничем же (если мы PCIe
Так ничем же (если мы PCIe-вариант рассматриваем).
И в этом одновременно и беда, lanes будет дефицит.
Причём на пятки гигабиту уже
Причём на пятки гигабиту уже начинает наступать WiFi.
Только в сельской местности. В многоквартирниках там и близко ничего подобного нет. И откуда быть, если стены с арматурой внутри (что убивает 5+Ghz), а видно 20+ сетей разом (что делает 2.4Ghz даже не 54 мегабита, а хорошо если 10, что уж там по 300 вспоминать)?
В пределах одной квартиры
В пределах одной квартиры вполне нормально. А в пределах комнаты - так вообще без проблем. Избавление от кабелей, которые на виду - первая цель WiFi. Так сказать, последний метр (по аналогиии с "последней милей") :)
Я как бы из собственного
Я как бы из собственного опыта говорю.
Квартира, 78 квадратов, 3 комнаты и кухня, монолитно-пенобетонный дом (внутренние стены — монолит, внешние — пенобетонные блоки, так что вся арматура внутри, а не снаружи), 7 этаж из 10. 2.4Ghz из угла коридора (где естественней всего делать "серверную" по плванировке вартиры) с антеннами на 10dBi уверенно накрывают всю квартиру, но на каждый из трёх реально существующих каналов видно больше 10 сетей. 5Ghz с теми же антеннами (отдельно антенн на 5Ghz я, кстати, не нашёл, они есть, но стоят каждая больше, чем мой рутер, потому что во внешнем исполнении и вообще профессиональные) не добивает до кухни.
Привет.
А на 2.4Ghz рутер в отладочном режиме вообще ругается регулярно, что даже бикон отправить не может, столько конкурентов, что тишины в эфире нет достаточной.
Репитеры, очевидно, ситуацию не улучшат, потому что они только увеличат загруженность эфира. Нужны именно что точки доступа на проводе в каждое помещение. А уж если тащить везде провода, то можно сразу их в компы воткнуть :-)
Я именно AP на проводе и имел
Я именно AP на проводе и имел в виду, забыл просто как называется :))
Вместо люстры на потолок и
Вместо люстры на потолок и 60Ghz!
Вот, кстати, вполне. Адаптеры
Вот, кстати, вполне. Адаптеры, которые ethernet через электросеть пропихивают, давали уверенные 150мбит (при рекламе в 1Gbit, естесственно...), сейчас, может, уже и больше, давно не слежу. Чем не вариант :)
тогда уж 600ТГц )
тогда уж 600ТГц )
Т.е. 2.4Ghz работает good
Т.е. 2.4Ghz работает good enough что бы на диване с ноута ютьюб посмотреть (если не 1080p, а попроще), но вот рассматривать его в роли замены даже гигабитной сети до десктопа я не готов совершенно, это несопоставимые скорости. Хотя формально, 300 мегабит, 2x150, да.
300 - это "n". Уже давно "ac"
300 - это "n". Уже давно "ac" используется, там скорости намного веселее. И на 5Ghz, 2.4 у меня тоже так себе, хотя дом всего пять этажей.
Ну блин, там усложнили кодинг
Ну блин, там усложнили кодинг, расширили каналы, увеличили агрегацию, да, но место в эфире оно занимает всё то же. И 5Ghz всё так же отлично экранируется, а 2.4Ghz всё так же засран. Это же фундаментальные проблемы, они усложнением модуляции и увеличением ширины спектра (в рамках того же диапазона) плохо решаются уже. Чуть-чуть решаются, более хитрая модуляция + более хитрый канальный кодер (и, главное, декодер, кодер-то не фокус) может вытащить сколько-то там децибел ещё, конечно, но это всё очень конечный ресурс.
Т.е. надо понимать, что эти
Т.е. надо понимать, что эти технологии вплотную приблизились к пределу Шеннона. И там каждый dBi SNR'а важен. Эфир общий, с SNR плохо, уход в друге частоты приводит к проблемам с экранированием. Потому и говорю — 60GHz, line of sight :)
Встраивать в лампочки
Встраивать в лампочки
Сеть доставлять туда по проводам 220в
Отличная ж штука!
Ну в общем, да, как-то так.
Ну в общем, да, как-то так.
10G WiFi с добитием на 10км
Вы серьёзно??!
Это ж какие частоты нужны!!... И какая ширина канала!
Или Вы в далёком будущем живёте? ;-)
Надеюсь дожить :)
Надеюсь дожить :)
Боюсь, тут гамма-лазер нужен
Боюсь, тут гамма-лазер нужен будет
Вроде разобрался. Cкорость
Вроде разобрался. Cкорость последовательного чтения файла размером 32GB:
- с hdd пула(зеркало из двух дисков) - 162MB/s;
- c ssd(L2ARC) - 399MB/s.
Файл полностью(99,999%) читался с ssd. При чтении из ARC и L2ARC этого же файла скорость составила 560MB/s. Максимальная скорость чтения ssd (dd if=/dev/ada1 of=/dev/zero bs=1m count=32k) - 410MB/s. Так как при чтении с L2ARC читались данные и метаданные (около 16MB), то потеря 3% скорости ssd, учитывая все перемещения данных, это очень достойный результат. Не удалось пока определить скорость при чтении из L2ARC и одновременной записи в L2ARC. Также пока не удалось проверить какая скорость перезаписи блоков в L2ARC. Если будет время завтра проверю. Алгоритм кэширования по чтению совершенно не похож на применяемые в flashcache, bcache, dm-cache. Он не предсказуем, но похоже имеет свои плюсы :-).
При чтении файла закэшированного в L2ARC по самбе (1 гигабит) чтение производилось только с ssd.
Алгоритм кэширования по
Алгоритм кэширования по чтению совершенно не похож на применяемые в flashcache, bcache, dm-cache. Он не предсказуем, но похоже имеет свои плюсы :-).
Он называется ARC (Adaptive Cache Replacement), собственно, и хорошо описан в оригинальной статье. Это удачный гибрид LRU и MRU, самобаланчирующий сколько процентов места отдать LRU, а сколько MRU.
Не знаю что с bcache и dm-cache‚ но flashcache — всего лишь LRU, причём, что важно, не просто LRU, а всего 4-way associative (каждый блок может попасть всего в 4 места в кэше, а не куда угодно), а ARC в этих терминах полностью ассоциативный (как и кэши в памяти).
C flashcache разбирался
C flashcache разбирался довольно давно, но помнится мне что ассоциативность была по умолчанию 512.
(https://github.com/facebookarchive/flashcache/blob/master/src/flashcache.h).
Возможно имелся в ввиду gcache, но там по-моему брались 3 бита (всё равно получается ассоциативность 8).
Если мне не изменяет память, алгоритм замещения в flashcache по умолчанию fifo. lru по-моему нужно было включать. Но речь была совершенно не об этом :-).
Вопрос: как поместить для проверки весь файл в L2ARC используя только чтение?
>> как поместить для проверки
>> как поместить для проверки весь файл в L2ARC используя только чтение?
Вот у меня возникло вчера подозрение, что это какой-то более сложный процесс, чем просто ARC(-cache).
Ну типа "если диски - не самое медленное место /а сеть - медленнее и читают не на полной скорости/ - давайте с них тоже почитаем"
>> Ну типа "если диски - не
>> Ну типа "если диски - не самое медленное место /а сеть - медленнее и читают не на полной скорости/ - давайте с них тоже почитаем"
Интересное предложение/предположение :-).
Сегодня заново прочитал вчерашние тестовые файлы. Все файлы размером 32GB. Первые два были записаны в пул до установки L2ARC и по ним производилось только чтение (многократное :-)). Третий файл был записан в пул после установки L2ARC и во время записи был в полном объёме помещен в L2ARC. Скорости и откуда читались данные:
1 - 169MB/s (43% hdd, 57% ssd, 0% ARC);
2 - 344MB/s (3% hdd, 97% ssd, 0% ARC);
3 - 420MB/s (0% hdd, 99,8% ssd, 0,2% ARC).
Самое интересное - первый файл читался намного чаще других :-). Ещё один интересный вывод - при чтении файла больше половины (57%) из ssd скорость чтения возросла незначительно (всего на 4%). L2ARC не заполнен (размер ssd - 120GB), поэтому вытеснений из него не было. Также возник вопрос, а что находится в ARC(12GB) :-) ? Последие 40-50 раз читались только эти три файла.
А как вы "скорость ARC"
А как вы "скорость ARC" оцениваете? по zfs-mon и hit ratio?
По дискам то понятно, есть iostat, все видно.
В ARC, помимо прочего, находится индекс от L2ARC. 200 (по другим данным - 400) байт на record.
Если recordsize стандартный (128k), то понятно что индекс получается небольшой, 200/400Mb.
>> А как вы "скорость ARC"
>> А как вы "скорость ARC" оцениваете?
Оценка была не скорости ARC, а объёма прочитанных данных. Объём файла 32768MB. Объём метаданных на данном датасете приблизительно 14MB. Recordsize на данном датасете 64kB. Размер в 64kB был выбран (насколько я правильно понял из исходников) исходя из размера блока в 64kB на L2ARC. Как я понял меньшие recordsize или группируются или пишутся с потерей пространства до 64kB. Объём прочитанных/записанных данных можно брать из iostat, но я использую свой geom c выдачей статистики по всем операциям (READ, WRITE, DELETE, FLUSH). Кстати, при добавлении L2ARC ssd (точнее выделенное пространство) полностью очищается (TRIM). Также он очищается при экспорте/импорте и я предполагаю при загрузке системы. Здесь разработчики молодцы - сделали как положено :-). Надеюсь и при замещении блоков в L2ARC тоже будут использовать TRIM. На счёт дополнительного объёма для обслуживания L2ARC в курсе, но не 12GB же :-). Вообще интересно наблюдать как в top менются MFU и MRU :-).
А, ну то есть по разнице.
А, ну то есть по разнице. "все что не с дисков - то из ARC", разумно.
Заодно вот спрошу, вдруг вы знаете
geom stripe (freebsd) транслирует TRIM (delete) дальше на провайдеров?
>> geom stripe (freebsd)
>> geom stripe (freebsd) транслирует TRIM (delete) дальше на провайдеров?
Транслирует и FLUSH тоже.
Кстати, в zfs по умолчанию на основной пул (обычно hdd) шлются DELETE (TRIM). Вроде как не критично, но смотрел не на сильно заполненном пуле. Возможно на сильно заполненном - это как-то будет лишним :-). Поэтому vfs.zfs.trim.enabled=0. Зачем слать лишние команды :-).
trim_enabled=0 не отлючит ли
trim_enabled=0 не отлючит ли TRIM на l2arc тож?
Пока не дошёл - не знаю, но
Пока не дошёл - не знаю, но перед началом тестирования у себя включил. Посмотрим :-).
Вот что-то я в полном
Вот что-то я в полном недоумении.
Есть folder, 21Gb, примерно вдвое больше ARC
делают tar cf /dev/null folder
много раз подряд.
И смотрю на zpool iostat -v 5
Через раз. После каждого прогона выжидаю, пока все по нулям по IO устаканится
- ~100% чтений из L2ARC, общее время на исполнение 24 cек
- ~20% чтений с HDD. 35 секунд
Система только в том, что оно так мигает, строго через раз.
Пойду опять напьюсь
Я уже писал о
Я уже писал о "непредсказуемости" :-).
Если посмотреть на "классический" подход по кэшированию читаемых данных, то увидим "понятные/предсказуемые" алгоритмы/политики. У flashcache и bcache кэшировать всегда по первому чтению. У dm-cache эта величина настраивается (по умолчанию, если мне не изменяет память, кэшировать после четвёртого (или восьмого) чтения). У L2ARC, как я понимаю, во время чтения текущие данные попадают (если они ещё не там) в ARC, а выталкиваться в L2ARC должны данные, которые находятся в конце LRU(MRU). Что это за данные - это ещё вопрос :-). Также нужно учитывать, что MFU живёт "своей жизнью" и тоже периодически забирает/отдаёт данные в LRU(MRU). Также существуют ghost списки недавно вытесненных данных из кэша. Причём у LRU(MRU) и MFU они свои :-). Если к этому добавить настраиваемые sysctl по ограничению/разрешению записи в L2ARC (.l2arc_noprefetch, .l2arc_write_max, .l2arc_norw, ...) и влияние соотношения размера файла и размера ARC (пока ещё не совсем понятного), то предсказать, когда читаемые данные попадут в L2ARC и в каком объёме становиться довольно сложно (если вообще возможно) :-).
При замещении данных в L2ARC данные пишутся поверх старых. Вывод при полном заполнении L2ARC будет снижаться скорость записи на ssd. Никакие техники поддержания скорости записи заполненного ssd (TRIM, Over-Provisioning) на уровне L2ARC не применяются :-(. Хотя для применённой политики замещения LRU в L2ARC этого наверно и стоило ожидать.
"Твоему другу", исходя из марок его ssd, стоит это учитывать. Хотя для некоторых ssd построенных на SandForce и TRIM бы мало помог :-). Также есть подозрение об использовании части одних и тех же ssd под ZIL и L2ARC. Как бы это вступает в противоречие с попыткой получить высокую производительность :-). Если ещё учесть gstripe, то ... :-))).
Мой друг передает, что если
Мой друг передает, что если толк от SSD-L2ARC есть (а по "жизненным тестам" - он есть, причем дело именно в latency - у один раз (давно) прочитанного набора файлов - превьюшки в FRV показываются мгновенно "как с локального SSD"),
то купить пару мелких (60-100Gb) серверных SSD - совершенно не заломает.
Пока же - ну сточу эти старые диски, ну так и хрен с ними, им срок жизни по любому подходит к.
zfs читает с L2ARC на
zfs читает с L2ARC на удивление хорошо. При чтении одного большого файла стабильно видна очередь в три запроса чтения по 128kB к ssd. Если верны мои предположения и блок L2ARC равен 64kB, то это как бы намекает на оптимизацию (присутствие планировщика) чтения. С другой стороны видно, что если закэшировалась только часть файла, то профита как бы и не видно. Как обеспечить кэширование файла при чтении в полном объёме пока не ясно. Да и в комментариях к исходному коду разработчики настаивают "The main role of this cache is to boost the performance of random read workloads.". Хотя файл впервые публиковался в 2005 и возможно многое поменялось :-).
Профит есть, он огромен. Вот
Профит есть, он огромен. Вот последовательные чтения одного и того же каталога (ранее в тестировании не принимал участия). Каталог 70Gb, 1866 файлов, ARC - 14Gb, L2Arc - 120.
Начиная с 4-го прохода в L2ARC ничего не писало практически.
То есть 4-е и далее "чтение каталога" - выигрыш 2x где-то.
Надо еще поиграться с
А это типичная нагрузка -
А это типичная нагрузка - чтение каталога по несколько раз? FRV раз за разом картинку снова читает, если по файлам туда-сюда бегать?
По идее, NVMe диск в качестве L2ARC должен рулить. А если на нём ещё и overprovisioning сделать (под L2ARC отдать только половину диска), так совсем хорошо должно стать?
Это типичная нагрузка если
Это типичная нагрузка если "работать с фоточками". Особенно если работать не "только сегодня", а постепенно обрабатывать большую съемку. Ну там неделю сидеть и обрабатывать.
FRV, потом raw-конвертор.
FRV - держит кэш прочитанных, но не очень большой, максимум можно выставить - 40 файлов. Но это в одной сессии работы же.
Для Lightroom по идее то же
Для Lightroom по идее то же самое? Хоть там превьюшки локально хранятся, но при переключении в 1:1 оно вроде основной файл подтягивает.
Lr по идее кэш равок не
Lr по идее кэш равок не держит.
В любом же случае, при нынешнем размере файлов - ни в какой RAM кэш большая сессия съемочная не влезет.
И от чего хочется уйти - это от копирования всего на SSD, работы, потом копирования результатов обратно,хочется чтобы оно само, в фоне, пусть не 100% оптимально, а только 75.
Согласен :-).
Согласен :-).
Пункт два - это несогласованность скорости чтения с пула (hdd) и скорости чтения/записи c кэша (ssd). По моему опыту скорость кэша (ssd) по возможности должна грубо превосходить в три раза скорость пула (hdd). Если со скоростью чтения всё вроде нормально, то со скоростью записи есть вопросы. Кстати, пункт два может быть довольно часто встречаемым в реальной жизни. Можно нарваться на ситуацию, что пункт 4 будет постоянно куда-то убегать :-).
"Дальше прыгает". Я тоже это наблюдал и меня это немного смущает :-).
Скорость линейной записи
Скорость линейной записи нулей на этот страйп - ~900mb/sec. Жмется, понятно.
Скорость чтения "не нулей" что я видел по iostat- 750mb/s
Скорость записи не нулей - неизвестна, /dev/random сильно медленнее
Если не жалко ssd :-), то
Если не жалко ssd :-), то нижнюю оценку по скорости записи можно легко произвести. На блочном уровне заполнить весь объём с помощью dd if=/dev/random (random действительно медленный, у меня dd if=/dev/random of=/dev/zero около 70Mb/s, придётся довольно долго ждать :-)). Затем с помощью fio запустить случайную запись блоками 64kB (или наверно даже правильнее 128kB) наверное в два потока (я думаю этого будет достаточно) на весь выделенный объём объёмом записи на пару гигабайт (пример запуска: fio --name=random128k --rw=randwrite --filename=/dev/stripe/L2ARC --bs=128k --group_reporting --thread --numjobs=2 --size=2g --direct=1 --gtod_reduce=1). Получится практически точная эмуляция записи в L2ARC на заполненном ssd. Также можно заодно проверить с помощью dd скорость чтения. Но я думаю скорость чтения из пула (8 дисков в raidz2) будет для этой конфигурации кэша (три ssd в страйпе) довольно высока. Поэтому наверно надо смириться, что при последовательном чтении кэш просто не будет успевать записывать и часть считанных данных будет пролетать мимо кэша :-).
Экспериментально выяснено,
Экспериментально выяснено, что два SSD в страйпе (на SATA-600 портах) работают быстрее трех (600+600+300).
Поэтому два SSD в страйпе.
Ща мы еще тут поиграем в "15" и на 60-ки разложим скомпилированный Qt (это фактически RO, а место на быстрых дисках под него жалко)
Ну как бы намекалось, что
Ну как бы намекалось, что разнородные диски (как ещё оказалось на разноскоростных портах) в страйпе всегда будут работать со скоростью самого медленного :-).
Ну да.
Ну да.
Но я думал что 3 гигабита - это 3 гигабита. А там 260Mb/sec. Чуть больше двух гигабит.
Да, TRIM используется, похоже
Да, TRIM используется, похоже, только при полной чистке, но не при замещении.
Только не MRU а LFU, конечно.
Только не MRU а LFU, конечно.
Я знал, что винда виновата...
Я знал, что винда виновата... отключил на интерфейсе в винде "Interrupt Moderation Rate" (--> Off), сразу чтение зашкалило за гигабайт с рамдиска.
а что за сетевые? я сейчас
а что за сетевые? я сейчас как раз тестирую, latency у всех отличается.
Если я правильно помню, то
Если я правильно помню, то Intel X540 (как и у меня)
Обе - X540-T2, соединены
Обе - X540-T2, соединены напрямую кабелем (пока одним). На одной стороне CentOS VM под ESXi, порт проброшен в VM (pass-through). На другой стороне Win10. Обе карты в PCIe 3.0 x8 слотах (2.0 есть только x4).
О блин!
О блин!
Да, с SSD (на самом деле из кэша) на страйп из SSD файл стал входить прямо вот душа радуется как.
Непонятная история.
Непонятная история.
У меня же на двух портах 10G рабочей станции - два FreeBSD-ящика.
Вот на том линке, который "быстрый NAS" - убираю AIM и "начинает входить быстро", 1+GB/sec пока влезает в кэш на приемной стороне.
На другом - убираю AIM и становится медленнее.
Разница в том, что на "быстром NAS" стоит карточка с прошивкой "как из китая приехало" (я даже версию не смотрел), а остальные две карты - перешиты на последнюю фирмварь, без этого на них ругалось про checksum error.
Загадочная вещь этот ваш 10G
У меня обе карты "как из
У меня обе карты "как из китая". В сторону NAS было сразу быстро (с поправкой на буферы и т.е.), в сторону винды медленно. После отключения IM стало быстро и в сторону винды.
Я не очень понимаю, в чём проблема.
С одной стороны, стенд лепим из "верёвок" и палок.
С другой, одиночный SSD не прокачивает имеющийся сетевой линк (страйпа 2*SSD нет ведь?).
И с третьей, ... Кажется владелец блога незаметно для самого себя вляпался в классическую западню скоростей:
тормозит сеть (1Gb/s, если кто забыл) - меняем сетевое железо;
тормозит дисковая подсистема, меняем и оптимизируем контроллеры и ФС (и её опции);
снова "узкое горлышко" - сеть -- обновляем подсистему сети;
ЁКЛМН! снова "диски тормозят"! ...
...
... особенно учитывая "апгрэйд почти даром". ;-)
Может, уже имеет смысл сформулировать ТЗ, ... или наплевать на затраты?
Моё дилетантское ИМХО.
Страйп есть (даже из трех, но
Страйп есть (даже из трех, но третий сильно медленнее), выдает 920Mb/sec
Это быстрее дисков даже по bw, не говоря про latency - потому и хочется его использовать.
а ТЗ простое - хочется счастья, даром, чтобы никто не ушел
Паритет?
Паритет?
10Gb - сеть и ~1Gb SSD-страйп?
;-)
900Mb/s - это 7гигабит с
900Mb/s - это 7гигабит с хвостиком.
Но мне хватит, да.
Мне и 600 хватит, если с такой скоростью (т.е. малой латентностью) получится читать мелкие файлы (ну там мегабайта по 4).