LINUX.ORG.RU
ФорумAdmin

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

 , ,


1

3

Есть одна файлопомойка с торрентами и RAID5, который с увеличением количества торрентов и толщины канала начинает заметно тормозить под этой нагрузкой.

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

Отсюда вопрос - что для этих целей лучше выбрать, и имеет ли смысл этим вообще заниматься? Принимаются любые, самые смелые идеи, готов в том числе поставить другую систему и пересобрать массив. Главное чтобы не падало и требовало поменьше денег.

Цифры для понимания масштаба проблемы:

  • Данных (потенциально используемых) - 2.5ТБ
  • За месяц добавляется от 100 до 500ГБ.
  • Предел чтения в сутки - 2ТБ.
  • Реально активно около 15% раздач
  • Их общий размер составляет менее 10% от размера данных

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

iron ★★★★★
()
Ответ на: комментарий от iron

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

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

koi-sama
() автор топика
Ответ на: комментарий от koi-sama

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

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

EvgGad_303 ★★★★★
()
Ответ на: комментарий от EvgGad_303

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

Везде? Логично же, что если при записи на 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...

koi-sama
() автор топика
Ответ на: комментарий от koi-sama

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

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

iron ★★★★★
()

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

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

/0

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

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

emulek
()
Ответ на: комментарий от koi-sama

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

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

emulek
()

http://bcache.evilpiepirate.org/

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

selivan ★★★
()
Ответ на: комментарий от koi-sama

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

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

blind_oracle ★★★★★
()

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

anonymous
()

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

darkenshvein ★★★★★
()
Ответ на: комментарий от emulek

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

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

koi-sama
() автор топика
Ответ на: комментарий от koi-sama

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

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

emulek
()
Ответ на: комментарий от darkenshvein

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

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

koi-sama
() автор топика
Ответ на: комментарий от koi-sama

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

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

iron ★★★★★
()
Ответ на: комментарий от iron

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

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

koi-sama
() автор топика
Ответ на: комментарий от koi-sama

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

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

iron ★★★★★
()

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

anonymous
()
Ответ на: комментарий от anonymous

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

koi-sama
() автор топика
Ответ на: комментарий от koi-sama

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

anonymous
()
Ответ на: комментарий от koi-sama

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

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

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

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

emulek
()
Ответ на: комментарий от anonymous

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

koi-sama
() автор топика
Ответ на: комментарий от emulek

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

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

koi-sama
() автор топика
Ответ на: комментарий от koi-sama

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

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

emulek
()
Ответ на: комментарий от emulek

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

blind_oracle ★★★★★
()
Ответ на: комментарий от koi-sama

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

emulek
()
Ответ на: комментарий от 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.

baka-kun ★★★★★
()
Ответ на: комментарий от baka-kun

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

koi-sama
() автор топика

Интересные вещи всплывают в интернетах. 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ГБ данных?

koi-sama
() автор топика
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.