Кэш дискового массива на SSD

Сейчас меня, конечно, заклюют, но все же :). Поставь FreeBSD 10 на ZFS. И пусти SSD под L2ARC.

Рассматривал вариант, но у raid-z, если верить прочитанному, количество iops на vdev в общем случае равно количеству iops самого медленного диска. Это напрягает, а проверять пока не на чем.

А у ZFS on Linux совсем всё плохо с надёжностью?

но у raid-z, если верить прочитанному, количество iops на vdev в общем случае равно количеству iops самого медленного диска

это где такие глупости пишут?

это где такие глупости пишут?

Везде? Логично же, что если при записи на vdev блок данных бьётся на куски и пишется на несколько дисков, то для чтения этого блока придётся запросить все диски, на которых эти куски находятся.

http://constantin.glez.de/blog/2010/06/closer-look-zfs-vdevs-and-performance http://naplo.sartek.net/2010/06/closer-look-at-zfs-vdevs-and.html http://nex7.blogspot.ru/2013/03/readme1st.html https://pthree.org/2012/12/13/zfs-administration-part-viii-zpool-best-practic...

количество iops на vdev в общем случае равно количеству iops самого медленного диска.

Ну так это в любом рейде такое, даже в аппаратном (с отключенным write cache, конечно). Поскольку у вас торренты, то для дата-сета с файлом можно сделать zfs set fs:zfs_nocacheflush=1, тогда будет откладываться сброс на винnы при sync и производительность не сильно пострадает.

с увеличением количества торрентов

большой SSD под кэш.

/0

Реально активно около 15% раздач Их общий размер составляет менее 10% от размера данных

эти 15% используются _постоянно_, но это не значит, что используются только они. Кеш поможет тогда, и только тогда, когда 85% раздач вообще не используются. (не чаще 1 раза в сутки).

А у ZFS on Linux совсем всё плохо с надёжностью?

скастуй тазика, он фанатег, и всё расскажет (я не кастую, ибо он на меня обиженный)

http://bcache.evilpiepirate.org/

Ещё я бы битмап на SSD перенёс. Если производительность совсем критична - можно полностью отказаться от битмапа, но в случае неправильного выключения массив будет пересобираться целиком

А у ZFS on Linux совсем всё плохо с надёжностью?

Всё стабильно, юзаю уже несколько лет, ни разу не упало ничего. Нагрузки приличные.

а чегой-то у вас софтовый рейд5 на чтение тормозит?

Неужто гигабитный внешний канал? Но даже если так, то всё равно, тормоза будут не очень большими.

эти 15% используются _постоянно_, но это не значит, что используются только они. Кеш поможет тогда, и только тогда, когда 85% раздач вообще не используются. (не чаще 1 раза в сутки).

Это зависит от логики и настроек кэша. В идеальном случае, состав 15% будет изменяться редко и медленно, а 85% вообще никогда не попадут в кэш и будут всегда читаться с диска.

Это зависит от логики и настроек кэша. В идеальном случае, состав 15% будет изменяться редко и медленно, а 85% вообще никогда не попадут в кэш и будут всегда читаться с диска.

ну хорошо. Не забудь отписаться о результатах. Мне отписываться нечего, ибо я не осилил.

Неужто гигабитный внешний канал?

2*100, но rtorrent читает с диска в 3-4 раза больше данных, чем отправляет в сеть. Если как-то решить эту проблему, то необходимость кэширования отпадёт сама собой.

а чегой-то у вас софтовый рейд5 на чтение тормозит?

Нагрузка, вестимо. А может я что-то неправильно делаю.

koi-sama@koi-nas:~$ iostat -xk
Linux 3.2.0-4-amd64 (koi-nas)   01/18/2014      _x86_64_        (2 CPU)

avg-cpu:  %user   %nice %system %iowait  %steal   %idle
          16.45    1.79   10.05   37.87    0.00   33.84

Device:         rrqm/s   wrqm/s     r/s     w/s    rkB/s    wkB/s avgrq-sz avgqu-sz   await r_await w_await  svctm  %util
sda              98.30     6.11   92.44    1.05 11936.67    26.80   255.94     2.47   26.39   25.81   77.37   9.22  86.19
sdb             100.41     6.23   94.15    1.05 12192.80    27.31   256.72     2.66   27.92   27.31   82.23   9.11  86.77
sdc             101.05     6.22   93.03    1.05 12145.25    27.25   258.78     2.54   27.01   26.45   76.81   9.18  86.37
sdd              98.18     6.10   93.47    1.04 11978.96    26.76   254.07     2.58   27.27   26.73   75.84   9.15  86.49
sde               0.35     7.07    9.76   12.52   130.50   239.90    33.24     0.41   18.45    9.92   25.10   3.21   7.15
md0               0.00     0.00  767.09    1.57 48237.93    71.68   125.70     0.00    0.00    0.00    0.00   0.00   0.00

но rtorrent читает с диска в 3-4 раза больше данных, чем отправляет в сеть

Попробуйте rtorrent заменить µTorrent-ом или qbittorrent-ом без X-ов. У меня когда-то тоже была подобная проблема.

rtorrent заменить µTorrent-ом или qbittorrent-ом без X-ов

Я как-то искал клиент с функциональной веб-мордой (rss, метки), так и не нашёл. А теперь к требованиям добавляется ещё и API (xmlrpc). transmission-daemon разве что попробовать.

Я как-то искал...

Вы смотрите на torrent библиотеку которую юзает тот или иной клиент. От этого и зависит его поведение. У µTorrent-а, qbittorrent-а и rtorrent-а они разные. Ибо сам клиент - это просто обертка над либой которая непосредственно организовывает работу по bittorrent протоколу.

Можно дропать все исходящие закачки со скоростью менее 100кб.\с, тогда количества Iopsов станет завались, а трафик будет почти тем же.

Нельзя. Торрент всегда запрашивает случайные чанки, протокол упоротый такой. Я как-то тестировал, на гигабите максимум получилось отдать 22МБ/с с rtorrent'a в обычные клиенты, больше - только в qBittorrent с последовательной загрузкой.

Файловый кластер 4кб х 500 iops (пара дисков) = 2 мБ\с
Файловый кластер 64кб х 500 iops = 32 мБ\с
Увеличь размер кластера\блока на ФС и все будет ОК (имхо)
cast dk-

Торрент всегда запрашивает случайные чанки, протокол упоротый такой.

это не баг, а фича. Иначе качать было-бы плохо. Другие протоколы без этой фичи тупо не прижились, кому нужна сеть, в которой ничего не скачать? Я тебе больше скажу — в торрентах это очень плохо реализовано. По уму нужно не случайный чанк отдавать/просить, а тот, который самый редкий. Иначе получается беда с релизами, куча личеров наседают на одного сида, и в итоге — затор. Такое можно увидеть на популярных новых раздачах.

Я как-то тестировал, на гигабите максимум получилось отдать 22МБ/с с rtorrent'a в обычные клиенты, больше - только в qBittorrent с последовательной загрузкой.

ed2k попробуй, там всё как раз в HDD упрётся. С торрентами полегче, но всё равно оно весь диск шерстит. Единственный вариант — убрать с раздачи всё ненужное. Можно скриптом это делать — т.е. как ненужное закачалось, быстро, решительно убираем из каталога с раздачами. И раздавать только SSD.

Увеличь размер кластера\блока на ФС и все будет ОК (имхо)

на ext* больше 4х не получится.

У нас же линукс, а не оффтопик, ФС разных завались.

оно всё равно чанками по 2М читает, т.ч. профита ИМХО не будет. Но я не пробовал...

Тогда уж на самом массиве stripe size менять - у меня 128к сейчас, а чтение, как показала практика, идёт блоками по 256к.

это не баг, а фича. Иначе качать было-бы плохо.

Это фича, которая при определённых обстоятельствах становится багом. Ничто же не мешает запрашивать случайные последовательности блоков.

Это фича, которая при определённых обстоятельствах становится багом. Ничто же не мешает запрашивать случайные последовательности блоков.

они и запрашиваются случайно в торренте.

Неточно выразился, я имел ввиду случайный блок и следующие за ним n блоков.

Я бы всё-таки попробовал bcache или еще какой flashcache, если активно только 15% раздач, то кэш на SSD подогреется как раз ими. 256-512гб ссд.

ну в итоге оно читает случайными чанками со всей поверхности по 2Мб. Как не крути...

ну это к koi-sama

у raid-z, если верить прочитанному, количество iops на vdev в общем случае равно количеству iops самого медленного диска

В общем случае это верно для любого массива с избыточностью на запись и для любого кроме умного зеркала на чтение. В идеале и RAID5, и RAIDZ на чтение выдадут одинаковые IOPS при прочих равных. Вот только RAID5 всегда ограничен шириной страйпа, поэтому может быть вынужден заниматься read-modify-write или читать больше необходимого. ZFS таким не болеет, пишет сколько надо, а читает даже не со всех дисков.

По факту RAIDZ умудряется «схитрить», и опережает по производительности ext4 на софтовом RAID5 в Линуксе минимум в пару раз на любой разумной нагрузке.

Когда нужны бешеные IOPS, в ZFS пуле просто создают более одного vdev, добавляют маленькое SSD зеркало под ZIL и SSD stripe под L2ARC.

А у ZFS on Linux совсем всё плохо с надёжностью?

Уже совсем всё неплохо. :)

хочу оптимизировать доступ к массиву, поставив ему большой SSD под кэш.

Во-первых, для ZFS лучше сперва наращивать объем RAM до упора. Дальше отдельно рассматривать запись и чтение. Увеличить IOPS записи можно быстрым SSD небольшого размера. Только vdev под ZIL должен быть надежным, поэтому проще всего сделать зеркало, а размер нужен небольшой: транзакции живут максимум пять секунд. Для L2ARC напротив важнее скорость чтения, а на надежность плевать: данные не потеряются при отказе кэша.

Самый простой вариант «для дома» — два SSD, на обоих два раздела: 4–10GB и остаток диска. Маленькие в зеркало для ZIL, большие — в страйп под L2ARC.

Спасибо, интересно. Соберу подопытную машинку и буду сравнивать.

Интересные вещи всплывают в интернетах. http://forums.freenas.org/threads/ssds-arc-and-zil.17191/#post-90640

Since your L2ARC uses RAM, you have to have more RAM than you would otherwise need. The common ratio is about 5:1. So your L2ARC shouldn't exceed 5x your ARC.

Как это вообще возможно? Оно правда может сожрать 8 гигов памяти на ссылки на 40ГБ данных?