Скорость записи на ZFS

Т.е. на пул2 включено сжатие и тестовый файл пишет быстро,
а на пул1 сжатие не включено и тестовый файл пишет медленно?

Факт того, что на одиночный HDD не может писаться файл со скоростью 250mb/s вас не настораживает никак?

Файл из нулей?

Это же zfs, там и не такое может быть, оно просто в кеш все пишет

Т.е. на пул2 включено сжатие и тестовый файл пишет быстро,

а на пул1 сжатие не включено и тестовый файл пишет медленно?

Я в топике вроде как понятно написал, что сжатие включено в обоих пулах.

Факт того, что на одиночный HDD не может писаться файл со скоростью 250mb/s вас не настораживает никак?

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

Это же zfs, там и не такое может быть, оно просто в кеш все пишет

Я кэш ограничил 2Гб.

ну тогда

$ zpool iostat 1

и смотри.

Почему так медленно пишет на raidz?

Может как-то утыкается в производительность контроллера к которому диски подключены? Всё-таки через него приходится больше данных прокачивать.

$ zpool iostat 1

Смотрел, данных, чтобы сделать какие либо выводы явно маловато.

Может как-то утыкается в производительность контроллера к которому диски подключены?

Мать asus sapertooth FX990, контроллер на борту хороший, все SATA-3.

А вот читает с пула raidz аж со свистом - 480 МБ/сек, с пула на одиночном харде предсказуемо 150 Мб/сек.

с пула на одиночном харде предсказуемо 150 Мб/сек.

диски все одинаковые?

Выключай сжатие, генерируй 100gb из /dev/random, между проверками пулов перезагружайся и приходи.

диски все одинаковые?

Да, все одинаковые Seagate 7200 Barracuda [ST2000DM001].

Выключай сжатие

из /dev/zero:

raidz-pool - 465 Мб/сек 1hhd-pool - 203 Мб/сек

100gb из /dev/random

Это ты пошутил, наверное. Из /dev/random генерится в час по чайной ложке.

генерируй 100gb из /dev/random

Да, шмишно :) Лучше пару бд-ремуксов аватара взять в 60fps. Как раз стока выйдет.

А контрольные суммы врублены там и сям?

из /dev/zero

Мне нравится, когда в zfs пишут нули

А контрольные суммы врублены там и сям?

А как проверить?

Мне нравится, когда в zfs пишут нули

Ну как надо та?

А как проверить?

zfs get checksum

Ну как надо та?

Ну не надо нули то писать, ёпт! Ты даже скорость fs не в состоянии проверить исключив кеш, о чём говорить..

А контрольные суммы врублены там и сям?

Включено везде.

Ну не надо нули то писать, ёпт! Ты даже скорость fs не в состоянии проверить исключив кеш, о чём говорить..

ню-ню, кто бы говорил.

генерируй 100gb из /dev/random

Твоё предложение? Сам пробовал? Хотя, о чём тут можно говорить..

Твоё предложение? Сам пробовал?

Идиот не способен воспринимать аналогии? Прости, не сразу понял степень твоего идиотизма.

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

вместо того чтобы ответить на технический вопрос

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

Когда меня спрашивают, почему на файловой системе знающей все о записанных на ней данных нельзя писать нули

Я тебя об этом не спрашивал.

мне сразу становится понятно

А чего ты сюда вернулся то тогда? Ещё немножко объяснить мне какой я тупой и какой ты умный? Я, лично к тебе, никаких вопросов не имею и прошу уйти отсюда.

Вообще говоря можно, если отключено сжатие. Иначе действительно скорость записи упрется в производительность процессора.

Странно, я всегда получал производительно для линейной записи вида (количество дисков- количество дисков на избыточность) * скорость записи на 1 диск.

Возможно в массиве raidz один из дисков убытый, что тормозит весь массив. Попробуйте посмотреть iostat -x

медленно пишет на raidz.

для постоянной записи, RAIDZ - плохой выбор, в связи с его медленной скоростью записи.

http://iboxjo.livejournal.com/208447.html

товарищи, подскажите куда копать:

На фрибсд 9.2х64 имею пул из трех 2тб дисков разной модели. На каждом устройство geli и из них слеплен пул raidz1 размером соответственно около 4тб.

Все это дело железобетонно работало на протяжении полугода (через самбу шарю файлопомойку) и вот дойдя до размера свободного пространства около 10гб все начало жутко тормозить на запись. При 50гб свободного пространства все работало нормально.

Я освободил места до 93гб, но скорость не желает возвращаться. Даже при записи с флэшки!!! фоток или скачке торрента на полной скорости интернета (около 5мб/с) на шару все встает колом через 10-15 секунд причем подвисает конкретно, венда ругается что шара недоступна, секунд через 20-30 отвисает.

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

smartctl длинный тест всех трех винтов прошел, в смарте криминала нет. zpool status все ок, делал полный scrub - сделался в общем то шустро (хотя начало было медленным, потом разогнался), учитывая что 4тб всякие iostat и vmstat прояснения не дали

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

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

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

http://www.solarisinternals.com/wiki/index.php/ZFS_Best_Practices_Guide
--
Keep pool space under 80% utilization to maintain pool performance. Currently, pool performance can degrade when a pool is very full and file systems are updated frequently, such as on a busy mail server. Full pools might cause a performance penalty, but no other issues. If the primary workload is immutable files (write once, never remove), then you can keep a pool in the 95-96% utilization range. Keep in mind that even with mostly static content in the 95-96% range, write, read, and resilvering performance might suffer.
---

Так что освобождайте 20% и проверяйте еще раз.

освободил более 700гб, 80% занято на пуле. ситуация не изменилась никак. дело в каком то из винтов, как проверить, подскажите пожалуйста?

zpool status -v

С массивом всё хорошо, глянь ещё смарт хардов, на всякий случай. У тебя scrub сейчас работает, а когда он работает ФС тормозит.

скраб запустил на всякий случай после освобождения 700гб места.

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

Jun 18 02:32:29 server smartd[1398]: Device: /dev/ada2, SMART Prefailure Attribute: 1 Raw_Read_Error_Rate changed from 115 to 105
Jun 18 02:32:29 server smartd[1398]: Device: /dev/ada2, SMART Prefailure Attribute: 7 Seek_Error_Rate changed from 40 to 41

в смарте из криминального для этого диска замечено:

Raw_Read_Error_Rate 65270464
Seek_Error_Rate 5798218790868
High_Fly_Writes 1

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

пересмотрел все логи системные - ничего кроме сообщений смарта выше не нашел

вот еще:

# iostat -x
                        extended device statistics
device     r/s   w/s    kr/s    kw/s qlen svc_t  %b
ada0       2.9  16.3    45.3  1321.2    0   7.1   2
ada2      42.8   1.9  3736.7    60.9   10  10.6   7
ada3      42.8   1.9  3729.1    60.9    0   5.9   6
ada4      36.9   1.9  3738.1    61.0    0  13.4   7
ada1       1.2  13.3    20.9  1296.9    0  11.2   2

постоянно при нагрузке значение qlen

В линуксячем iostat нет такого параметра, так что man не помог, но полагаю что это query length. Могу предположить, что длинная очередь только на одном харде массива не очень хорошо. Попробуй поменять хард в массиве.

из мана на freebsd:

The extended iostat device display, with the -x flag specified,
           shows the following statistics:

           r/s     read operations per second
           w/s     write operations per second
           kr/s    kilobytes read per second
           kw/s    kilobytes write per second
           qlen    transactions queue length
           svc_t   average duration of transactions, in milliseconds
           %b      % of time the device had one or more outstanding transac‐
                   tions

может есть еще какие нибудь команды, чтобы продиагностировать винт? пока что поменять возможности винт нет, да и хотелось бы удостовериться точно. все таки 4тб разобрать и потом опять собрать - это дело геморное...

гугление на тему «iostat queue length» особой ясности не внесло.

при чём здесь iostat? queue length, оно же depth, никак не гуглится? покажи

iostat -xdn 1

echo zfs_vdev_max_pending::print | mdb –kw

set zfs:zfs_vdev_max_pending=1

о вот сейчас поймал iostat -x на таком выводе:

# iostat -x
                        extended device statistics
device     r/s   w/s    kr/s    kw/s qlen svc_t  %b
ada0       2.9  16.2    44.9  1308.1    0   7.1   2
ada2      48.3   2.0  4323.2    60.9    0   9.8   7
ada3      48.0   2.0  4315.7    61.0    1   5.6   6
ada4      42.2   2.0  4324.6    61.0    8  12.2   8
ada1       1.2  13.2    20.7  1284.1    0  11.1   2

разницы с "-d" и без нет, а «n1» показывает только одно устройство и из другого пула.

команды «mdb» на фрибсде нет, есть вот такое:

# sysctl -a | grep zfs | grep pending
vfs.zfs.vdev.min_pending: 4
vfs.zfs.vdev.max_pending: 10
vfs.zfs.vdev.trim_max_pending: 64

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

ИМХО дело в каком то из винтов. как проверить винты на фрибсде - вот в чем вопрос

Что пишет вывод команды «zpool upgrade -v»?

На фрибсд 9.2

Обновиться не пора ли? Между прочим, в последних версиях пофикшены обнаруженные проблемы с ZFS.

на 9.3? beta же еще... подожду релиза (я знаю про качество бет у фри, но тем не менее ;) а на 10ку как то сыкотно переползать на боевом серваке, меня все устраивает и на 9ке.

zpool и zfs проапгрейжены до версий в составе 9.2 - обновиться некуда. вообще не думаю что это трабла zfs, хотя...

вот закончились полные тесты ddrescue со всех трех дисков на чтение - все отлично, ошибки по нулям. я в прострации...

дождусь окончания скраба после увеличения свободного пространства и попробую пул на запись еще раз

Тормозить может нечаянно включенная дедупликация.

нету дедупликации.

на сервак никто кроме меня не заходит, а я заходил последний раз 2 месяца назад, т.е. все проблемы с изменением ОС, ПО, настроек сразу можно исключить.

проблема произошла сама по себе, попискивающий звук из системника при обращении к шаре продолжается, проблема осталась и после скраба, свободного места на пуле 21%...

вот закончились полные тесты ddrescue со всех трех дисков на чтение - все отлично, ошибки по нулям. я в прострации...

Дык у тебя по условиям задачи тормозит запись, а не чтение - тестировал то ты чтение, когда проблема в записи.

попискивающий звук из системника при обращении к шаре продолжается,

Ну, что сказать - если есть в запасе хотя бы один 2TB диск, меняй по очереди и делай resilver, пока «писк» не уйдет.

И молись чтобы во время 4 итераций ресилвера у тебя какой-нибудь еще диск не сказал адйос.

Кстати, выложи zpool get all zpoolhome03

Ну, что сказать - если есть в запасе хотя бы один 2TB диск, меняй по очереди и делай resilver, пока «писк» не уйдет.

И молись чтобы во время 4 итераций ресилвера у тебя какой-нибудь еще диск не сказал адйос.

вот это-то и страшно... и хотелось бы с первого раза угадать виновника, поэтому и спрашиваю насчет как его определить.

Кстати, выложи zpool get all zpoolhome03

zpoolhome03  size                   5,44T                  -
zpoolhome03  capacity               78%                    -
zpoolhome03  altroot                -                      default
zpoolhome03  health                 ONLINE                 -
zpoolhome03  guid                   13744697753473308863   default
zpoolhome03  version                -                      default
zpoolhome03  bootfs                 -                      default
zpoolhome03  delegation             on                     default
zpoolhome03  autoreplace            off                    default
zpoolhome03  cachefile              -                      default
zpoolhome03  failmode               wait                   default
zpoolhome03  listsnapshots          off                    default
zpoolhome03  autoexpand             off                    default
zpoolhome03  dedupditto             0                      default
zpoolhome03  dedupratio             1.00x                  -
zpoolhome03  free                   1,17T                  -
zpoolhome03  allocated              4,26T                  -
zpoolhome03  readonly               off                    -
zpoolhome03  comment                -                      default
zpoolhome03  expandsize             0                      -
zpoolhome03  freeing                0                      default
zpoolhome03  feature@async_destroy  enabled                local
zpoolhome03  feature@empty_bpobj    active                 local
zpoolhome03  feature@lz4_compress   active                 local

Дык у тебя по условиям задачи тормозит запись, а не чтение - тестировал то ты чтение, когда проблема в записи.

я уже просто не знаю что пробовать...

Для начала... замени блок питания. Писк из системника — примета не очень хорошая.

ZeroFS

не, попискивает именно со стороны дисковой подсистемы, это не БП

Как оно всё закончилось то? Любопытно, что было.