Еще одна причина уйти с ZFS

Sergey Anohin написал(а) к Alex Korchmar в Jul 19 11:14:15 по местному времени:

Нello, Alex!

AK> но чтобы базы пошустрее работали, как минимум размеры блока надо привести
AK> к рекомендуемым. А у тебя 8x multiply при записи.

выставил 16, файлы копирнул, удалил источник, копировал обратно,
или надо dump\restore?

С наилучшими пожеланиями, Sergey Anohin.

--- wfido

Alex Korchmar написал(а) к Sergey Anohin в Jul 19 12:26:03 по местному времени:

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

Sergey Anohin <Sergey.Anohin@p1.f10.n5034.z2.fidonet.org> wrote:

AK>> но чтобы базы пошустрее работали, как минимум размеры блока надо привести
AK>> к рекомендуемым. А у тебя 8x multiply при записи.
SA> выставил 16, файлы копирнул, удалил источник, копировал обратно,
а зачем?
достаточно было любым способом убрать с дороги оригинал и переименовать
копию в db/mysql или где оно должно было быть. она даже сама
перемонтируется куда надо.

SA> или надо dump\restore?
он на zfs не работает

> Alex

--- ifmail v.2.15dev5.4

Eugene Grosbein написал(а) к Alex Korchmar в Jul 19 17:12:18 по местному времени:

08 июля 2019, понедельник, в 22:23 NOVT, Alex Korchmar написал(а):

EG>> Так это и значит, что recordsize не фиксированный в ZFS.
AK> включишь компрессию - будет нефиксированный (что характерно - независимо от
AK> наличия самой компрессии, просто этот код в других случаях не задействован).
AK> Не включишь - будет block size, как sun нам завещала.
AK> учитывая что у mysql как раз block size всегда фиксированный, но ни разу не
AK> 128k - есть смысл именно такой и назначить. (только не забывая что для логов
AK> он не подходит, и они должны быть на отдельной fs)

А что плохого в том, что операции с логами будут занимать по нескольку блоков?

Eugene
--- slrn/1.0.3 (FreeBSD)

Eugene Grosbein написал(а) к Slawa Olhovchenkov в Jul 19 17:13:09 по местному времени:

08 июля 2019, понедельник, в 22:56 NOVT, Slawa Olhovchenkov написал(а):

SO>>> я никогда не видел другого механизма, отличного от:
SO>>> - для файлов меньше recordsize используется block sizes округленный
SO>>> вверх по ashift - для остальных файлов используется block sizes равный
SO>>> recordsize
EG>> Так это и значит, что recordsize не фиксированный в ZFS.
EG>> Я понимаю, что в контексте видео-CDN на ZFS практически
EG>> нет регулярных файлов, меньше 128K, но они есть в других контекстах.
EG>> Плюс сами каталоги могут быть меньше 128K, а они тоже файлы.
SO> контекст в которым это сказал -- был про innodv файлы, т.е. подразумевалось
SO> "фиксированный или переменный в пределах файла".
SO> так вот в пределах файла он фиксированный.

В пределах файла - это очевидно, я имел в виду про файловую систему в целом.

Eugene
--- slrn/1.0.3 (FreeBSD)

Alex Korchmar написал(а) к Eugene Grosbein в Jul 19 14:17:36 по местному времени:

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

Eugene Grosbein <Eugene.Grosbein@f1.n5006.z2.fidonet.org> wrote:

EG> А что плохого в том, что операции с логами будут занимать по нескольку блоков?
чем плохо на syncronous linear write дробить запись на блоки
крошечного размера? Ну действительно, чем бы это?

> Alex

--- ifmail v.2.15dev5.4

Eugene Grosbein написал(а) к Alex Korchmar в Jul 19 22:37:38 по местному времени:

09 июля 2019, вторник, в 14:17 NOVT, Alex Korchmar написал(а):

EG>> А что плохого в том, что операции с логами будут занимать по нескольку
AK> блоков?
AK> чем плохо на syncronous linear write дробить запись на блоки
AK> крошечного размера? Ну действительно, чем бы это?

Так дробиться-то оно будет внутри ядря уже, оверхеда на сисколлы не будет.
А дальше write cache всё выровняет.

Eugene
--
Choose no life
--- slrn/1.0.3 (FreeBSD)

Alex Korchmar написал(а) к Eugene Grosbein в Jul 19 20:17:16 по местному времени:

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

Eugene Grosbein <Eugene.Grosbein@f1.n5006.z2.fidonet.org> wrote:

EG> Так дробиться-то оно будет внутри ядря уже, оверхеда на сисколлы не будет.
EG> А дальше write cache всё выровняет.
там syncronous write. Будет сидеть и ждать подтверждения на каждый.
даже при том что дальше кэша самого hdd дело не пойдет - обмен по sata шине
будет вот именно этими блоками.

> Alex
--- ifmail v.2.15dev5.4

Eugene Grosbein написал(а) к Alex Korchmar в Jul 19 03:03:50 по местному времени:

09 июля 2019, вторник, в 20:17 NOVT, Alex Korchmar написал(а):

EG>> Так дробиться-то оно будет внутри ядря уже, оверхеда на сисколлы не будет.
EG>> А дальше write cache всё выровняет.
AK> там syncronous write. Будет сидеть и ждать подтверждения на каждый.
AK> даже при том что дальше кэша самого hdd дело не пойдет - обмен по sata шине
AK> будет вот именно этими блоками.

гм-гм, а у SATA большой оверхед на передачу одного блока?

Если нет и шина SATA становится узким местом,
то проблема recordsize у ZFS это не основная проблема
такой машины, imho.

Eugene
--
Поэты - страшные люди. У них все святое.
--- slrn/1.0.3 (FreeBSD)

Alex Korchmar написал(а) к Eugene Grosbein в Jul 19 13:18:44 по местному времени:

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

Eugene Grosbein <Eugene.Grosbein@f1.n5006.z2.fidonet.org> wrote:

EG> гм-гм, а у SATA большой оверхед на передачу одного блока?
у пнуть драйвер - выставить параметры для dma - инициировать передачу -
вернуть подтверждение - очевидно, немалый. У поисков места для нового блока
и замены метаинформации в десяти местах (напоминаю, это zfs) - тоже.

EG> Если нет и шина SATA становится узким местом,
при потоковой передаче она им не является, в сравнении с бесконечными
инициациями и подтверждениями на каждый блок.

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


> Alex

--- ifmail v.2.15dev5.4

Andrey Ostanovsky написал(а) к Alex Korchmar в Jul 19 14:23:54 по местному времени:

Нello Alex!

08 Jul 19 10:02, you wrote to Eugene Grosbein:

AK> потому что купить нормальное оборудование и уволить самоучку без
AK> мотора обойдется дешевле прямо сейчас,

Это - взаимоисключающие вещи. :) Нормальное оборудование надо покупать под проект, за результат работы которого человек (разработчик проекта) - будет отвечать своей головой/зарплатой лет 5 или 10.

Где взять сегодня такого человека? С улицы, или от "интегратора", который в лучшем случае немножко знает то, что продает...

В результате традиционная картина "витязь на распутье". :)

Andrey

--- GoldED+/BSD 1.1.5-b20070503