Страшные тормоза zfs

Victor Sudakov написал(а) к All в Oct 15 09:44:56 по местному времени:

Dear All,

zfs поверх geli, 10.2-RELEASE amd64, RAM 4G. Диски по полтора терабайта, каждый диск (точнее ada?.eli устройство) - отдельный zpool. Используются как хранилище фильмов и музыки с раздачей по NFS.

Странные явления наблюдаются. Иногда простое удаление каталога с подкаталогами
может идти единицы минут! Иногда хэшинг какого-нибудь торрента вводит диск в
состояние ступора. А вчера после некорректного ребута в состоянии "Mounting ZFS
filesystems" загрузка ОС ждала больше часа при бешеной активности винта, при этом после загрузки обнаружилось, что на fs появилось много свободного места по сравнению с тем, что было до ребута.

Что это вообще? Может я zfs готовить не умею? Никакого специального тюнинга zfs не проводил. Дедуп не включал, снапшотов не создавал, scrub ошибок не находит.

Victor Sudakov, VAS4-RIPE, VAS47-RIPN
--- GoldED+/BSD 1.1.5-b20110223-b20110223

Valentin Davydov написал(а) к Victor Sudakov в Oct 15 13:22:12 по местному времени:

From: Valentin Davydov <sp@m.davydov.spb.su>

> From: Victor Sudakov <Victor.Sudakov@f49.n5005.z2.fidonet.org>
> Date: Mon, 12 Oct 2015 09:44:56 +0300
>
>zfs поверх geli, 10.2-RELEASE amd64, RAM 4G.

Воткни 16-32. И перезагружай пореже.

Вал. Дав.

Диски по полтора терабайта, каждый
>диск (точнее ada?.eli устройство) - отдельный zpool. Используются как хранилище
>фильмов и музыки с раздачей по NFS.
>
>Странные явления наблюдаются. Иногда простое удаление каталога с подкаталогами
>может идти единицы минут! Иногда хэшинг какого-нибудь торрента вводит диск в
>состояние ступора. А вчера после некорректного ребута в состоянии "Mounting ZFS
>filesystems" загрузка ОС ждала больше часа при бешеной активности винта, при
>этом после загрузки обнаружилось, что на fs появилось много свободного места по
>сравнению с тем, что было до ребута.
>
>Что это вообще? Может я zfs готовить не умею? Никакого специального тюнинга zfs
>не проводил. Дедуп не включал, снапшотов не создавал, scrub ошибок не находит.
>
>Victor Sudakov, VAS4-RIPE, VAS47-RIPN
--- ifmail v.2.15dev5.4

Victor Sudakov написал(а) к Valentin Davydov в Oct 15 17:03:56 по местному времени:

Dear Valentin,

12 Oct 15 13:22, you wrote to me:
>>
>> zfs поверх geli, 10.2-RELEASE amd64, RAM 4G.

VD> Воткни 16-32. И перезагружай пореже.

Почему именно 16-32, а не скажем 64-128? Формула расчета есть или по принципу "мало не бывает"?

Зачем 16 гиг памяти, чтобы просто удалить файл на fs?

Victor Sudakov, VAS4-RIPE, VAS47-RIPN
--- GoldED+/BSD 1.1.5-b20110223-b20110223

Alex Korchmar написал(а) к Victor Sudakov в Oct 15 15:33:51 по местному времени:

From: Alex Korchmar <noreply@linux.e-moe.ru>

Victor Sudakov <Victor.Sudakov@f49.n5005.z2.fidonet.org> wrote:

VS> Почему именно 16-32, а не скажем 64-128?
проверенный миллиардами леммингов оптимум.

VS> Зачем 16 гиг памяти, чтобы просто удалить файл на fs?
чтобы просто удалить - низачем. Чтобы тебе перестало быть невмоготу
ждать пока она его удалит - нужны. Причина банальна: никто не
собирается оптимизировать fs, разработанную для петабайтных стораджей,
чтобы она приемлемо работала на устаревшем хламе, да еще и поверх
достаточно неоптимальных наслоений.

А зачем вообще поверх полутора терабайт нужна zfs?

> Alex

--- ifmail v.2.15dev5.4

Victor Sudakov написал(а) к Alex Korchmar в Oct 15 21:16:50 по местному времени:

Dear Alex,

12 Oct 15 15:33, you wrote to me:

VS>> Почему именно 16-32, а не скажем 64-128?
AK> проверенный миллиардами леммингов оптимум.

И что, после добавления памяти странные проблемы исчезнут?

VS>> Зачем 16 гиг памяти, чтобы просто удалить файл на fs?
AK> чтобы просто удалить - низачем. Чтобы тебе перестало быть невмоготу
AK> ждать пока она его удалит - нужны. Причина банальна: никто не
AK> собирается оптимизировать fs, разработанную для петабайтных стораджей,
AK> чтобы она приемлемо работала на устаревшем хламе, да еще и поверх
AK> достаточно неоптимальных наслоений.

Дожили, 64-битный процессор и 4 ГБ ОЗУ уже устаревший хлам.

AK> А зачем вообще поверх полутора терабайт нужна zfs?

Ради удобств в эксплуатации, которые она дает. Уж явно не ради объема данных, у UFS предельный объем тоже в зеттабайтах измеряется.

Victor Sudakov, VAS4-RIPE, VAS47-RIPN
--- GoldED+/BSD 1.1.5-b20110223-b20110223

Alex Korchmar написал(а) к Victor Sudakov в Oct 15 19:04:29 по местному времени:

From: Alex Korchmar <noreply@linux.e-moe.ru>

Victor Sudakov <Victor.Sudakov@f49.n5005.z2.fidonet.org> wrote:

VS>>> Почему именно 16-32, а не скажем 64-128?
AK>> проверенный миллиардами леммингов оптимум.
VS> И что, после добавления памяти странные проблемы исчезнут?
думаю, как минимум часть из них - да. За подробностями - что бывает при
отступлении от протоптанных троп - можешь почитать документацию фринаса,
обхохочешься. (geli тоже не очень натоптана, остается надеяться, что это
не новая дорога нах...)

VS> Дожили, 64-битный процессор и 4 ГБ ОЗУ уже устаревший хлам.
в общем-то, да. На моем служебном ноуте восемь, и это уже в общем-то
минимально необходимое количество.

AK>> А зачем вообще поверх полутора терабайт нужна zfs?
VS> Ради удобств в эксплуатации, которые она дает. Уж явно не ради объема
VS> данных, у
проблема, что ее писали именно ради объема. Потому что в какой-то момент,
внезапно, выяснилось что дешевые диски доросли до размеров, когда прежние
подходы перестают нормально масштабироваться. Остальное - как раз
побочные эффекты того, что средние требования к железу заведомо
покрывают мелкие накладные расходы.

VS> UFS предельный объем тоже в зеттабайтах измеряется.
на бумаге. На практике, даже если не обращать внимания на цену и
эффективность контроллера, позволяющего более-менее адекватно
использовать массив всего лишь в шесть-восемь терабайт, я не говорю
о "надежно", а так чтоб хотя бы минимально быть уверенным что там
хранятся еще данные, а не шесть терабайт сида для рандом генератора,
первая же встреча с fsck на таком объеме запомнится тебе надолго.

То есть размеры структур - да, позволяют натянуть ее на такой объем.
А подход - не позволяет на нем работать с приемлемой эффективностью.


> Alex

--- ifmail v.2.15dev5.4

Victor Sudakov написал(а) к Alex Korchmar в Oct 15 11:04:04 по местному времени:

Dear Alex,

12 Oct 15 19:04, you wrote to me:

[dd]

VS>> Дожили, 64-битный процессор и 4 ГБ ОЗУ уже устаревший хлам.
AK> в общем-то, да. На моем служебном ноуте восемь, и это уже в общем-то
AK> минимально необходимое количество.

Так на твоем службном ноуте поди винда, потому и.

AK>>> А зачем вообще поверх полутора терабайт нужна zfs?
VS>> Ради удобств в эксплуатации, которые она дает. Уж явно не ради
VS>> объема данных, у
AK> проблема, что ее писали именно ради объема. Потому что в какой-то
AK> момент, внезапно, выяснилось что дешевые диски доросли до размеров,
AK> когда прежние подходы перестают нормально масштабироваться. Остальное
AK> - как раз побочные эффекты того, что средние требования к железу
AK> заведомо покрывают мелкие накладные расходы.

Судя по названию, может ты и прав, что ради объема. Но и в остальном получилось настолько революционно и удобно, что просто хочется пользоваться независимо от объема данных. Например boot environments чего стоят.

VS>> UFS предельный объем тоже в зеттабайтах измеряется.
AK> на бумаге. На практике, даже если не обращать внимания на цену и
AK> эффективность контроллера, позволяющего более-менее адекватно
AK> использовать массив всего лишь в шесть-восемь терабайт, я не говорю
AK> о "надежно", а так чтоб хотя бы минимально быть уверенным что там
AK> хранятся еще данные, а не шесть терабайт сида для рандом генератора,
AK> первая же встреча с fsck на таком объеме запомнится тебе надолго.

soft updates journalling помогает от fsck. Но с ним не работают снапшоты.

А на тему "быть уверенным что там хранятся еще данные, а не мусор" опять-таки только zfs помогает с ее контрольными суммами.

AK> То есть размеры структур - да, позволяют натянуть ее на такой объем.
AK> А подход - не позволяет на нем работать с приемлемой эффективностью.

Victor Sudakov, VAS4-RIPE, VAS47-RIPN
--- GoldED+/BSD 1.1.5-b20110223-b20110223

Valentin Davydov написал(а) к Victor Sudakov в Oct 15 15:59:47 по местному времени:

From: Valentin Davydov <sp@m.davydov.spb.su>

> From: Victor Sudakov <Victor.Sudakov@f49.n5005.z2.fidonet.org>
> Date: Mon, 12 Oct 2015 17:03:56 +0300
>
> >> zfs поверх geli, 10.2-RELEASE amd64, RAM 4G.
>
> VD> Воткни 16-32. И перезагружай пореже.
>
>Почему именно 16-32, а не скажем 64-128?

128 хуже не будет, если физически в мать влезает.

>Формула расчета есть или по принципу
>"мало не бывает"?

Формулы нет, есть методика. Грубо говоря, добавлять память и смотреть
под типичной нагрузкой до тех пор, пока не станет хорошо (MFU перестанет
расти, дисковая запись превысит дисковое чтение и т.п.).

Вал. Дав.
--- ifmail v.2.15dev5.4

Дмитрий Долженко написал(а) к Victor Sudakov в Oct 15 17:30:24 по местному времени:

From: Дмитрий Долженко <dol@mig.phys.msu.ru>

12.10.2015 9:44, Victor Sudakov пишет:
> Dear All,
>
> zfs поверх geli, 10.2-RELEASE amd64, RAM 4G. Диски по полтора терабайта, каждый
> диск (точнее ada?.eli устройство) - отдельный zpool. Используются как хранилище
> фильмов и музыки с раздачей по NFS.
>
> Странные явления наблюдаются. Иногда простое удаление каталога с подкаталогами
> может идти единицы минут! Иногда хэшинг какого-нибудь торрента вводит диск в
> состояние ступора. А вчера после некорректного ребута в состоянии "Mounting ZFS
> filesystems" загрузка ОС ждала больше часа при бешеной активности винта, при
> этом после загрузки обнаружилось, что на fs появилось много свободного места по
> сравнению с тем, что было до ребута.
>

У меня было похожее при раздаче ZFS стораджа по smb.
Помогло

ifconfig em0 -tso4

Те же проблемы были с картой msk0 лечились так же.

firewall и natd на машине нет.

D.

--- ifmail v.2.15dev5.4

Dmitry Miloserdov написал(а) к Valentin Davydov в Oct 15 17:34:55 по местному времени:

From: Dmitry Miloserdov <dmitry@bis.ru>

13.10.2015 15:59, Valentin Davydov пишет:
>> From: Victor Sudakov <Victor.Sudakov@f49.n5005.z2.fidonet.org>
>> Date: Mon, 12 Oct 2015 17:03:56 +0300
>>
>>>> zfs поверх geli, 10.2-RELEASE amd64, RAM 4G.
>>
>> VD> Воткни 16-32. И перезагружай пореже.
>>
>> Почему именно 16-32, а не скажем 64-128?
>
> 128 хуже не будет, если физически в мать влезает.
>> Формула расчета есть или по принципу
>> "мало не бывает"?
> Формулы нет, есть методика. Грубо говоря, добавлять память и смотреть
> под типичной нагрузкой до тех пор, пока не станет хорошо (MFU перестанет
> расти, дисковая запись превысит дисковое чтение и т.п.).

А если не станет хорошо?
Если на диске из 1.5Т свободно 10мег и весь ввод/вывод уже давно
генерится самим zpool?
Запись превысит чтение на хранилище музыке и фильмов тогда когда
памяти будет большем чем нужной музыки и фильмов. Оно точно того стоит?
--- ifmail v.2.15dev5.4