Skip to Content

ZFS

FreeBSD ZFS performance: просто возьмите молоток побольше

СБ, 11/06/2010 - 14:38 — lexa

Если поискать в этом блоге, особенно в каментах, то найдете что ZFS на трех дисках (RAIDZ) давала у меня скорость чтения/записи порядка 75-80 Mb/sec. Так оно и было до недавнего времени, пока я с этой скоростью не уперся в скорость на сети (samba).

Пришлось навести следствие. Выяснилось очень простое, хотя и не вполне очевидное:

  • У меня был даунклоченый Core2Duo: 1.86Ghz работающий на ~1.6, задаунклочил летом, по случаю жары, просто на всякий случай.
  • При этом при чтении с ZFS system time как правило не рос выше 50%, что я неверно интерпретировал как однопоточность ZFS (судя по всему, неверно, ибо потом в тестах видел и 70% system) и верно интерпретировал как упертость в процессор.
  • Банальный оверклок того же горшка (и памяти) приводил к почти линейному росту скорости FS.

Тогда я пошел в лабаз и купил там еще один 2TB диск и 3.06-гигагерцовый C2D (E7600), собрал все в кучку (дисков стало 4) и результат:

  • 170-195 Mb/sec на запись
  • 230-280 Mb/sec на чтение
Скорость, судя по всему, зависит от того, в какую зону диска, побыстрее или помедленнее, файловая система положила файл. System при этом держится на уровне 20-30%, а изменение частоты горшка на производительность почти не влияет. Ну и Samba в диск больше не упирается.

Все тестирование делалось методом 

dd if=/dev/zero of=file bs=1M count=20000
dd if=file of=/dev/null bs=1M
То есть речь о больших файлах, с мелкими всегда все сложнее и хуже.

Поэтосамое по-настоящему

СБ, 10/30/2010 - 20:58 — lexa

Если вы хотите поеба потрахаться по-настоящему, предлагаю такой вот метод:

  • Создаете ZFS-том терабайт эдак на шесть (меньше не пробовал) на FreeBSD 8.1-RELEASE/STABLE.
  • И записываете туда пару-тройку сотен тысяч файлов с русскими (и европейскими) именами в кодировке UTF-8.
Если вам очень повезет, то вы получите ненулевое количество каталогов в которых нельзя сделать ls или find (и естественно, все остальные, получающие список файлов, вроде du). Если повезет слегка, то ls работать будет, а вот rm * - нет. И rm конкретный-файл - тоже нет.

Единственная выявленная система - это очень длинные, под лимит, имена файлов. Не только русские, но и европейские (с умляутами).

gptzfsboot и все все все....

СР, 10/27/2010 - 12:35 — lexa

В копилку знаний сисадмина:

Если у вас ZFS, RAIDZ и загрузка с RAIDZ и вы ставили FreeBSD 8.1-RELEASE

То не поленитесь поапгрейдить бут-блоки на более свежие, те которые в 8.1 - не умеют грузиться с degraded array.

Подробности тут: www.freebsd.org/cgi/query-pr.cgi?pr=148655

Да, а если ваш массив в состоянии resilvering (навернувшийся диск заменили, но массив не успел перестроиться), то и новые бутблоки имеют шанс не загрузиться...

P.S. Нет, диск не ломался, это я просто like to move it, move it, все массивы в доме наращивал до размера побольше....

Народная мудрость

ВС, 06/20/2010 - 20:51 — lexa

Примета:

Сделать zpool upgrade, но не сделать gpart bootcode ... -p gptzfsboot - означает поипаться от души поиметь немало веселых минут.

Особенно с учетом того, что zpool upgrade делается на лету, а отсутствие нужной версии boot loader становится заметно после перезагрузки. Которая у меня, например, случилась через две недели.

Наука о контактах

СР, 12/16/2009 - 22:42 — lexa

Вот такие вот приятные сообщения стал я получать от системы. 

Dec 15 07:39:40 home-gw kernel: ad2: TIMEOUT - FLUSHCACHE48 retrying (1 retry left)
Dec 15 08:02:37 home-gw kernel: ad2: TIMEOUT - FLUSHCACHE48 retrying (1 retry left)
Dec 15 08:31:23 home-gw kernel: ad2: TIMEOUT - FLUSHCACHE48 retrying (1 retry left)
Dec 15 08:55:29 home-gw kernel: ad2: TIMEOUT - FLUSHCACHE48 retrying (1 retry left)
Dec 15 08:58:23 home-gw kernel: ad2: TIMEOUT - FLUSHCACHE48 retrying (1 retry left)
Dec 15 09:01:10 home-gw root: ZFS: vdev I/O failure, zpool=zroot path=/dev/ad2p2 offset=412440274432 size=1536 error=5
Dec 15 09:01:10 home-gw kernel: ad2: TIMEOUT - WRITE_DMA48 retrying (1 retry left) LBA=805547573
Dec 15 09:01:10 home-gw kernel: ad2: FAILURE - WRITE_DMA48
Как видно, несколько раз в час.

Поменял кабель - не помогло. Подумал, воткнул в другой порт (диск стал ad6). Как рукой сняло, уже полтора дня ни одного разрыва все тихо.

Вот и верь после этого в электронику.

root on ZFS

СБ, 12/12/2009 - 20:13 — lexa
Для тонких ценителей. 
zroot on / (zfs, local)
zroot/home on /home (zfs, local)
zroot/tmp on /tmp (zfs, local, nosuid)
zroot/usr on /usr (zfs, local)
..... и еще с десяток томов под разные нужды....
3 диска, RAIDZ1, 4 терабайта места, "домашний роутер".

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

В частности, расширять root pool нельзя, поэтому идея-фикс по переносу данных без многократного переписывания данных не проканала. А была она такая:

  • Было два двухтерабайтника в зеркале, место кончилось, купил третий.
  • Разбиваем зеркало, из двух дисков (один старый, один новый) делаем RAIDZ1, переписываем туда данные.
  • Добавляем второй старый диск в тот же RAID.
Увы, пришлось вылить на внешние диски, собрать массив, налить обратно....

По органолептическим ощущениям, диски сильно меньше нагружены, чем в gmirror, отчего меньше греются. Какой-то статистики наберу за неделю, расскажу....

SSD рулят

Втр, 10/20/2009 - 23:02 — lexa

Потестировал тут SSD-диск (G.Skill Falcon, 128Gb) на одной read-only задаче. Два дня тестировал.

Если не вдаваться в подробности, то это большая (в примере было 90Gb) база данных со случайным доступом. Запросы к ней бывают короткие и длинные, при этом короткие на обычных дисках упираются в seek, а длинные ограничены и скоростью линейного чтения тоже.

Получилось:

  • Короткие запросы (коих большинство) ускорились примерно в 15 раз.
  • Длинные - в 4-5 раз.

Кроме того, для длинных запросов не падает общий throughput под параллельной нагрузкой (несколько одновременных запросов), тогда как для HDD - падает.

Syndicate content


.