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

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

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

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

SA> Вроде как речь о l2arc в разделе optional features, нет?
когда ты доберешься до статьи с тестами производительности - ты убедишься,
что в остальных случаях они получили потерю на порядок по сравнению с xfs

а то что ты нашел - это вообще писулька ни о чем.

SA> https://wiki.freebsd.org/ZFSTuningGuide
это вообще выкрасить и выбросить - набор бессмысленных заклинаний, не факт что
понимаемых автором вообще.

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


> Alex

--- ifmail v.2.15dev5.4

Sergey Anohin написал(а) к Alex Korchmar в Jul 19 13:07:55 по местному времени:

Нello, Alex!

SA>> короче стопим mysql копируем, удаляем, заливаем обратно?
AK> можно не заливать а перемонтировать клон вместо основного сразу.
AK> по дороге выставив ему блок в 16

ну вот примерно результаты эмпирического тестирования тупого копирования:
изначально было минут 35-40.

если с компрессией, с этими опциями:

root@server:/var/db/mysql/iblogs# sysctl vfs.zfs.cacheflushdisable
vfs.zfs.cacheflushdisable: 0
root@server:/var/db/mysql/iblogs# sysctl vfs.zfs.prefetch_disable
vfs.zfs.prefetch_disable: 0

и с этим
zfs set primarycache=metadata tank/db
zfs set atime=off tank/db
zfs set recordsize=16k tank/db/innodb
zfs set recordsize=128k tank/db/logs
с учетом перезаливки файлов туда-обратно получилось 19-21 минут

если вырубить
root@server:/var/db/mysql/iblogs# sysctl vfs.zfs.cacheflushdisable
vfs.zfs.cacheflushdisable: 1
root@server:/var/db/mysql/iblogs# sysctl vfs.zfs.prefetch_disable
vfs.zfs.prefetch_disable: 1

а так же
zfs set sync=disabled zroot/var/db/mysql
zfs set sync=disabled zroot/var/db/mysql/ibdata
zfs set sync=disabled zroot/var/db/mysql/iblogs

то в итоге получается минут 13-15. С ARC сжатием ничего не делалось, сейчас оно кажет

ARC: 3282M Total, 2762M MFU, 423M MRU, 4452K Anon, 17M Нeader, 72M Other
2876M Compressed, 3178M Uncompressed, 1.11:1 Ratio

Получается префетч не полезен ни в тупом копировании, ни при работе баз данных.

Обратно заливка кстати была всего:

(pts/3)[root@server:~]# time cp -R /var/db/mysql.back4 /var/db/mysql
0.047u 30.230s 7:52.50 6.4% 15+176k 121785+1012042io 1486pf+0w



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

--- wfido

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

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

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

SA> Получается префетч не полезен ни в тупом копировании, ни при работе баз данных.
ты не хочешь читать сначала что тебе пишут, а потом бросаться крутить
гайки которых ты не понимаешь?

Повторяю последний раз: префетч ВРЕДЕН при такой настройке, и она
КАТЕГОРИЧЕСКИ непригодна для тупого копирования данных вне зависимости от него.
И вообще ни для чего непригодна, потому что бессмысленное кручение ручек
к добру никогда никого не приводило.

Если бы мне было нужно зачем-то именно скопировать такую fs (не могу придумать
ни одного правдоподобного сценария, кроме вот разьве что компенсации
ошибки с block size и желания выключить ненужно-сжатие) - я бы
сделал clone, поменял у клона primarycache=all вернул бы префетч
на место, и скопировал бы с этого клона.


> Alex

--- ifmail v.2.15dev5.4

Eugene Grosbein написал(а) к Slawa Olhovchenkov в Jul 19 22:30:12 по местному времени:

07 июля 2019, воскресенье, в 22:43 NOVT, Slawa Olhovchenkov написал(а):

EG>>>> При 16% экономии сжатие не нужно независимо от размера блоков.
EG>>>> И вроде бы я читал, что recordsize лишь ограничивает размер блока,
EG>>>> он может быть и меньше - независимо от включения компрессии.
SO>>> ты читал неправильно

SO> https://docs.oracle.com/cd/E19120-01...fgv/index.html
EG>> The recordsize Property
EG>> Specifies a suggested block size for files in the file system.
EG>> This property is designed solely for use with database workloads
EG>> that access files in fixed-size records. ZFS automatically adjust
EG>> block sizes

SO> ну и в каком месте тут такое написанно?

Последнее предложение квоты.

Eugene
--- slrn/1.0.3 (FreeBSD)

Slawa Olhovchenkov написал(а) к Eugene Grosbein в Jul 19 20:46:36 по местному времени:

Нello Eugene!

08 Jul 19, Eugene Grosbein writes to Slawa Olhovchenkov:

EG>>>>> При 16% экономии сжатие не нужно независимо от размера блоков.
EG>>>>> И вроде бы я читал, что recordsize лишь ограничивает размер блока,
EG>>>>> он может быть и меньше - независимо от включения компрессии.
SO>>>> ты читал неправильно

SO>> https://docs.oracle.com/cd/E19120-01...71/gcfgv/index
SO>> .html
EG>>> The recordsize Property
EG>>> Specifies a suggested block size for files in the file system.
EG>>> This property is designed solely for use with database workloads
EG>>> that access files in fixed-size records. ZFS automatically adjust
EG>>> block sizes

SO>> ну и в каком месте тут такое написанно?

EG> Последнее предложение квоты.

ничего подобного тут не сказано. внимательно перечитывай, пока не заметишь что механизм "automatically adjust" тут не раскрыт.

я никогда не видел другого механизма, отличного от:

- для файлов меньше recordsize используется block sizes округленный вверх по ashift
- для остальных файлов используется block sizes равный recordsize

... linux это эльфы в файлах, гномы на столах, зомби в процессах, а на форумах спло
---

Sergey Anohin написал(а) к Alex Korchmar в Jul 19 21:22:53 по местному времени:

Нello, Alex!

SA>> Получается префетч не полезен ни в тупом копировании, ни при работе баз данных.
AK> ты не хочешь читать сначала что тебе пишут, а потом бросаться крутить
AK> гайки которых ты не понимаешь?
AK> Повторяю последний раз: префетч ВРЕДЕН при такой настройке, и она
AK> КАТЕГОРИЧЕСКИ непригодна для тупого копирования данных вне зависимости от него.
AK> И вообще ни для чего непригодна, потому что бессмысленное кручение ручек
AK> к добру никогда никого не приводило.

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


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

--- wfido

Eugene Grosbein написал(а) к Slawa Olhovchenkov в Jul 19 01:30:21 по местному времени:

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

SO> я никогда не видел другого механизма, отличного от:
SO> - для файлов меньше recordsize используется block sizes округленный вверх по
SO> ashift
SO> - для остальных файлов используется block sizes равный recordsize

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

Eugene
--
И кого не любишь, в лицо не знать, и смотреть на звезды и жить спокойно.
--- slrn/1.0.3 (FreeBSD)

Alex Korchmar написал(а) к Sergey Anohin в Jul 19 22:21:08 по местному времени:

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

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

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

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


> Alex

--- ifmail v.2.15dev5.4

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

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

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

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

учитывая что у mysql как раз block size всегда фиксированный, но ни разу не
128k - есть смысл именно такой и назначить. (только не забывая что для логов
он не подходит, и они должны быть на отдельной fs)


> Alex

--- ifmail v.2.15dev5.4

Slawa Olhovchenkov написал(а) к Eugene Grosbein в Jul 19 22:56:24 по местному времени:

Нello Eugene!

09 Jul 19, Eugene Grosbein writes to Slawa Olhovchenkov:

SO>> я никогда не видел другого механизма, отличного от:
SO>> - для файлов меньше recordsize используется block sizes округленный
SO>> вверх по ashift - для остальных файлов используется block sizes равный
SO>> recordsize

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

контекст в которым это сказал -- был про innodv файлы, т.е. подразумевалось "фиксированный или переменный в пределах файла".
так вот в пределах файла он фиксированный.

... Use the source, Luke (C) Ben (Obi-Wan) Kenobi
--- GoldED+/BSD 1.1.5-b20110223-b20110223