InnoDB+UFS+SSD

Alex Korchmar написал(а) к Sergey Anohin в Jan 21 15:42:22 по местному времени:

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

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

SA> Если для zfs нашел мануал где более менее все собpано в кучу
innodb_doublewrite=0 - вот с этим поаккуратней. Были сигналы - не чай он там
пьет!

Правда, это про линуксы, у них и aio нарисованный, и вообще все через анус.

Хотя через пару лет выбора уже не будет.

> Alex

--- ifmail v.2.15dev5.4

Alex Korchmar написал(а) к Eugene Grosbein в Jan 21 16:20:23 по местному времени:

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

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

EG> Размер страницы InnoDB и размер блока UFS крайне желательно
EG> иметь одинаковыми и изменить размер страницы однажды созданной базы InnoDB
я, кстати, рекомендую еще разок перечитать вот это из найденной пострадавшим
компилятивной доки:

As discussed above, ZFS LZ4 compression is incredibly fast, so we
should leave compression to ZFS and not use InnoDBs built in page
compression. As an added benefit, leaving compression to ZFS doesnt
disrupt the block alignment. Optimising the storage stack for 16KB
writes and then using compression at InnoDB level would

То есть, если не планируется делать чего-то совсем странного, про страдания с
попаданием в page size можно смело забывать - это in-memory pages, при
записи все будет пожамкано в непредсказуемый размер. Читается оно с prefetch,
поэтому никто от этого особо не страдает.

(Но вот размер записи в логи - насколько я понимаю, фиксированный.)

> Alex

--- ifmail v.2.15dev5.4

Sergey Anohin написал(а) к Alex Korchmar в Jan 21 17:18:46 по местному времени:

Нello, Alex!

SA>> Если для zfs нашел мануал где более менее все собpано в кучу
AK> innodb_doublewrite=0 - вот с этим поаккуратней. Были сигналы - не чай он там
AK> пьет!

Как пишут:
InnoDB использует метод потока файла, названный doublewrite. Перед записью страниц в файлы данных InnoDB сначала пишет их в непрерывную область, названную буфером doublewrite. Только после того, как запись и сброс к буферу doublewrite завершились, InnoDB пишет страницы к их надлежащим позициям в файле с данными. Если есть катастрофический отказ операционной системы, подсистемы хранения или процесса mysqld в середине записи страницы, InnoDB может позже найти хорошую копию страницы из буфера doublewrite во время восстановления катастрофического отказа.
Хотя данные всегда пишутся дважды, буфер doublewrite не требует вдвое большего количества ввода/вывода. Данные написаны в буфер непосредственно как большой последовательный кусок одним вызовом fsync().
Чтобы выключить буфер doublewrite, определите опцию innodb_doublewrite=0 .

AK> Правда, это про линуксы, у них и aio нарисованный, и вообще все через анус.

Так ну типа если будет "катастрофический отказ операционной системы", что на говенном железе вполне может, печально будет, но правда это и про другие ручки можно сказать которые там крутятся )))
Ну тут имеется ввиду нормальные кейзы, так что статью принимать для себя имхо только с учетом своих условий. Ну и да там линукс.
Хотя че говорить если в БСД уже Zol скоро будет наверно по дефолту :)



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

--- wfido

Sergey Anohin написал(а) к Alex Korchmar в Jan 21 17:36:29 по местному времени:

Нello, Alex!

EG>> Размер страницы InnoDB и размер блока UFS крайне желательно
EG>> иметь одинаковыми и изменить размер страницы однажды созданной базы InnoDB
AK> я, кстати, рекомендую еще разок перечитать вот это из найденной пострадавшим
AK> компилятивной доки:
AK> As discussed above, ZFS LZ4 compression is incredibly fast, so we
AK> should leave compression to ZFS and not use InnoDBs built in page
AK> compression. As an added benefit, leaving compression to ZFS doesnt
AK> disrupt the block alignment. Optimising the storage stack for 16KB
AK> writes and then using compression at InnoDB level would
AK> То есть, если не планируется делать чего-то совсем странного, про страдания с
AK> попаданием в page size можно смело забывать - это in-memory pages, при
AK> записи все будет пожамкано в непредсказуемый размер. Читается оно с prefetch,
AK> поэтому никто от этого особо не страдает.

Для innodb prefetch все рекомендуют отключать :) В той же доке
Since InnoDB does it’s own prefetching, we can disable ZFS’ own prefetching (since it is redundant in this specific usage) by setting the kernel module paramter zfsprefetchdisable=1. This is especially important in environments where disk I/O is heavily constrained and provisioning more IOPS is expensive (e.g. in cloud environments).

AK> (Но вот размер записи в логи - насколько я понимаю, фиксированный.)

Ну тут доверяй но проверяй, кейзы разные всегда, вот например есть такой пример,

zroot/var/db/mysql recordsize 8k
zroot/var/db/mysql/ibdata recordsize 16k
zroot/var/db/mysql/iblogs recordsize 128k

только при innodbpertable=1 или как его там он все равно хранит где попало в /var/db/mysql/<dbname>/.ibd
то есть в моем случае надо и на
zroot/var/db/mysql 16k recordsize

Или вот еще про ZFS кеш, что типа InnoDB свой имеет кеш и нет смысла all кешировать, кешируется только metadata.
Все бы ничего если бы InnoDB bufferpool влезал в раму как рекомендуется.
Я пока пробую в ARC metadata в L2ARC all хз, ну я б не сказал что MySQL полетел прямо как будто от на SSD диске сидит :)

# zfs get all zroot/var/db/mysql
NAME PROPERTY VALUE SOURCE
zroot/var/db/mysql type filesystem -
zroot/var/db/mysql creation пт марта 16 22:18 2018 -
zroot/var/db/mysql used 16,5G -
zroot/var/db/mysql available 1,33T -
zroot/var/db/mysql referenced 15,8G -
zroot/var/db/mysql compressratio 1.65x -
zroot/var/db/mysql mounted yes -
zroot/var/db/mysql quota none default
zroot/var/db/mysql reservation none default
zroot/var/db/mysql recordsize 16K local
zroot/var/db/mysql mountpoint /var/db/mysql inherited from zroot/var
zroot/var/db/mysql sharenfs off default
zroot/var/db/mysql checksum fletcher4 inherited from zroot
zroot/var/db/mysql compression lz4 local
zroot/var/db/mysql atime off local
zroot/var/db/mysql devices on default
zroot/var/db/mysql exec off inherited from zroot/var/db
zroot/var/db/mysql setuid off inherited from zroot/var/db
zroot/var/db/mysql readonly off default
zroot/var/db/mysql jailed off default
zroot/var/db/mysql snapdir hidden default
zroot/var/db/mysql aclmode discard default
zroot/var/db/mysql aclinherit restricted default
zroot/var/db/mysql createtxg 11403386 -
zroot/var/db/mysql canmount on default
zroot/var/db/mysql xattr off temporary
zroot/var/db/mysql copies 1 default
zroot/var/db/mysql version 5 -
zroot/var/db/mysql utf8only off -
zroot/var/db/mysql normalization none -
zroot/var/db/mysql casesensitivity sensitive -
zroot/var/db/mysql vscan off default
zroot/var/db/mysql nbmand off default
zroot/var/db/mysql sharesmb off default
zroot/var/db/mysql refquota none default
zroot/var/db/mysql refreservation none default
zroot/var/db/mysql guid 13227566777127831999 -
zroot/var/db/mysql primarycache metadata local
zroot/var/db/mysql secondarycache all local
zroot/var/db/mysql usedbysnapshots 0 -
zroot/var/db/mysql usedbydataset 15,8G -
zroot/var/db/mysql usedbychildren 704M -
zroot/var/db/mysql usedbyrefreservation 0 -
zroot/var/db/mysql logbias throughput local
zroot/var/db/mysql dedup off default
zroot/var/db/mysql mlslabel -
zroot/var/db/mysql sync disabled local
zroot/var/db/mysql dnodesize legacy default
zroot/var/db/mysql refcompressratio 1.64x -
zroot/var/db/mysql written 15,8G -
zroot/var/db/mysql logicalused 26,9G -
zroot/var/db/mysql logicalreferenced 25,7G -
zroot/var/db/mysql volmode default default
zroot/var/db/mysql filesystem_limit none default
zroot/var/db/mysql snapshot_limit none default
zroot/var/db/mysql filesystem_count none default
zroot/var/db/mysql snapshot_count none default
zroot/var/db/mysql redundant_metadata all default

# zfs get all zroot/var/db/mysql/iblogs
NAME PROPERTY VALUE SOURCE
zroot/var/db/mysql/iblogs type filesystem -
zroot/var/db/mysql/iblogs creation пт марта 16 22:20 2018 -
zroot/var/db/mysql/iblogs used 325M -
zroot/var/db/mysql/iblogs available 1,33T -
zroot/var/db/mysql/iblogs referenced 325M -
zroot/var/db/mysql/iblogs compressratio 1.58x -
zroot/var/db/mysql/iblogs mounted yes -
zroot/var/db/mysql/iblogs quota none default
zroot/var/db/mysql/iblogs reservation none default
zroot/var/db/mysql/iblogs recordsize 128K local
zroot/var/db/mysql/iblogs mountpoint /var/db/mysql/iblogs inherited from zroot/var
zroot/var/db/mysql/iblogs sharenfs off default
zroot/var/db/mysql/iblogs checksum fletcher4 inherited from zroot
zroot/var/db/mysql/iblogs compression lz4 inherited from zroot/var/db/mysql
zroot/var/db/mysql/iblogs atime off inherited from zroot/var/db/mysql
zroot/var/db/mysql/iblogs devices on default
zroot/var/db/mysql/iblogs exec off inherited from zroot/var/db
zroot/var/db/mysql/iblogs setuid off inherited from zroot/var/db
zroot/var/db/mysql/iblogs readonly off default
zroot/var/db/mysql/iblogs jailed off default
zroot/var/db/mysql/iblogs snapdir hidden default
zroot/var/db/mysql/iblogs aclmode discard default
zroot/var/db/mysql/iblogs aclinherit restricted default
zroot/var/db/mysql/iblogs createtxg 11403407 -
zroot/var/db/mysql/iblogs canmount on default
zroot/var/db/mysql/iblogs xattr off temporary
zroot/var/db/mysql/iblogs copies 1 default
zroot/var/db/mysql/iblogs version 5 -
zroot/var/db/mysql/iblogs utf8only off -
zroot/var/db/mysql/iblogs normalization none -
zroot/var/db/mysql/iblogs casesensitivity sensitive -
zroot/var/db/mysql/iblogs vscan off default
zroot/var/db/mysql/iblogs nbmand off default
zroot/var/db/mysql/iblogs sharesmb off default
zroot/var/db/mysql/iblogs refquota none default
zroot/var/db/mysql/iblogs refreservation none default
zroot/var/db/mysql/iblogs guid 2433669013503756839 -
zroot/var/db/mysql/iblogs primarycache metadata inherited from zroot/var/db/mysql
zroot/var/db/mysql/iblogs secondarycache all inherited from zroot/var/db/mysql
zroot/var/db/mysql/iblogs usedbysnapshots 0 -
zroot/var/db/mysql/iblogs usedbydataset 325M -
zroot/var/db/mysql/iblogs usedbychildren 0 -
zroot/var/db/mysql/iblogs usedbyrefreservation 0 -
zroot/var/db/mysql/iblogs logbias latency local
zroot/var/db/mysql/iblogs dedup off default
zroot/var/db/mysql/iblogs mlslabel -
zroot/var/db/mysql/iblogs sync disabled local
zroot/var/db/mysql/iblogs dnodesize legacy default
zroot/var/db/mysql/iblogs refcompressratio 1.58x -
zroot/var/db/mysql/iblogs written 325M -
zroot/var/db/mysql/iblogs logicalused 512M -
zroot/var/db/mysql/iblogs logicalreferenced 512M -
zroot/var/db/mysql/iblogs volmode default default
zroot/var/db/mysql/iblogs filesystem_limit none default
zroot/var/db/mysql/iblogs snapshot_limit none default
zroot/var/db/mysql/iblogs filesystem_count none default
zroot/var/db/mysql/iblogs snapshot_count none default
zroot/var/db/mysql/iblogs redundant_metadata all default

# zfs get all zroot/var/db/mysql/ibdata
NAME PROPERTY VALUE SOURCE
zroot/var/db/mysql/ibdata type filesystem -
zroot/var/db/mysql/ibdata creation пт марта 16 22:20 2018 -
zroot/var/db/mysql/ibdata used 379M -
zroot/var/db/mysql/ibdata available 1,33T -
zroot/var/db/mysql/ibdata referenced 379M -
zroot/var/db/mysql/ibdata compressratio 2.36x -
zroot/var/db/mysql/ibdata mounted yes -
zroot/var/db/mysql/ibdata quota none default
zroot/var/db/mysql/ibdata reservation none default
zroot/var/db/mysql/ibdata recordsize 16K local
zroot/var/db/mysql/ibdata mountpoint /var/db/mysql/ibdata inherited from zroot/var
zroot/var/db/mysql/ibdata sharenfs off default
zroot/var/db/mysql/ibdata checksum fletcher4 inherited from zroot
zroot/var/db/mysql/ibdata compression lz4 inherited from zroot/var/db/mysql
zroot/var/db/mysql/ibdata atime off inherited from zroot/var/db/mysql
zroot/var/db/mysql/ibdata devices on default
zroot/var/db/mysql/ibdata exec off inherited from zroot/var/db
zroot/var/db/mysql/ibdata setuid off inherited from zroot/var/db
zroot/var/db/mysql/ibdata readonly off default
zroot/var/db/mysql/ibdata jailed off default
zroot/var/db/mysql/ibdata snapdir hidden default
zroot/var/db/mysql/ibdata aclmode discard default
zroot/var/db/mysql/ibdata aclinherit restricted default
zroot/var/db/mysql/ibdata createtxg 11403406 -
zroot/var/db/mysql/ibdata canmount on default
zroot/var/db/mysql/ibdata xattr off temporary
zroot/var/db/mysql/ibdata copies 1 default
zroot/var/db/mysql/ibdata version 5 -
zroot/var/db/mysql/ibdata utf8only off -
zroot/var/db/mysql/ibdata normalization none -
zroot/var/db/mysql/ibdata casesensitivity sensitive -
zroot/var/db/mysql/ibdata vscan off default
zroot/var/db/mysql/ibdata nbmand off default
zroot/var/db/mysql/ibdata sharesmb off default
zroot/var/db/mysql/ibdata refquota none default
zroot/var/db/mysql/ibdata refreservation none default
zroot/var/db/mysql/ibdata guid 12007562024988368572 -
zroot/var/db/mysql/ibdata primarycache metadata inherited from zroot/var/db/mysql
zroot/var/db/mysql/ibdata secondarycache all inherited from zroot/var/db/mysql
zroot/var/db/mysql/ibdata usedbysnapshots 0 -
zroot/var/db/mysql/ibdata usedbydataset 379M -
zroot/var/db/mysql/ibdata usedbychildren 0 -
zroot/var/db/mysql/ibdata usedbyrefreservation 0 -
zroot/var/db/mysql/ibdata logbias throughput inherited from zroot/var/db/mysql
zroot/var/db/mysql/ibdata dedup off default
zroot/var/db/mysql/ibdata mlslabel -
zroot/var/db/mysql/ibdata sync disabled local
zroot/var/db/mysql/ibdata dnodesize legacy default
zroot/var/db/mysql/ibdata refcompressratio 2.36x -
zroot/var/db/mysql/ibdata written 379M -
zroot/var/db/mysql/ibdata logicalused 738M -
zroot/var/db/mysql/ibdata logicalreferenced 738M -
zroot/var/db/mysql/ibdata volmode default default
zroot/var/db/mysql/ibdata filesystem_limit none default
zroot/var/db/mysql/ibdata snapshot_limit none default
zroot/var/db/mysql/ibdata filesystem_count none default
zroot/var/db/mysql/ibdata snapshot_count none default
zroot/var/db/mysql/ibdata redundant_metadata all default


innodbdata_homedir=/var/db/mysql/ibdata
innodblog_group_homedir = /var/db/mysql/iblogs

Кеш L2ARC на чтение ведь пашет? Ну может какой-то профит от него есть для MySQL, не очень глазу заметнй

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

--- wfido

Alex Korchmar написал(а) к Sergey Anohin в Jan 21 21:04:29 по местному времени:

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

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

SA> Для innodb prefetch все рекомендуют отключать :) В той же доке
это половые проблемы трахающихся с zfs
Для ufs он должен быть включен, и кэш тоже.

SA> zroot/var/db/mysql recordsize 8k
это какая-то херня времен myisam, найух ненужно
SA> zroot/var/db/mysql/ibdata recordsize 16k
SA> zroot/var/db/mysql/iblogs recordsize 128k
я бы вот это 128k перепроверил бы, если бы на самом деле было что оптимизировать
Есть мнение, что это тоже какая-то сомнительная блажь.
Жаль что проверить, видимо, нет инструмента попроще чем dtrace.

SA> Кеш L2ARC на чтение ведь пашет? Ну может какой-то профит от него есть для
Да.
Но, учитывая какими лапами или что это у них такое написана arc compression -
я бы первым делом выключил ее. Поскольку есть некоторые сомнения, что при
включенной L2ARC вообще работает нормально.

Следующим ходом я бы отправил нахер abd scatter.

И только после этого стал бы экспериментировать с размерами блока.


> Alex

--- ifmail v.2.15dev5.4

Alex Korchmar написал(а) к Sergey Anohin в Jan 21 22:39:01 по местному времени:

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

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

SA> Как пишут:
промтом переводили?

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


SA> Хотя че говорить если в БСД уже Zol скоро будет наверно по дефолту :)
уже точно. Увы.

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


> Alex

--- ifmail v.2.15dev5.4

Sergey Anohin написал(а) к Alex Korchmar в Jan 21 23:10:54 по местному времени:

Нello, Alex!

SA>> Как пишут:
AK> промтом переводили?

хз, нашел в таком виде

AK> Короче, краткий перевод с промта на русский: это дополнительный журнал данных.
AK> Который тебе очень пригодится, если крэшнется сервер или вся система, а
AK> существенной нагрузки на диски не создает (к zfs не относится, но лучше
AK> лишняя нагрузка чем невосстановимо битая innodb)

это проблема резервирования имхо, в продакшне, если уж там мускуль и зфс, что мало вероятно,
это при условии нормального железа еще маловероятнее :)

SA>> Хотя че говорить если в БСД уже Zol скоро будет наверно по дефолту :)
AK> уже точно. Увы.
AK> Я окончательно похоронил идею использования zfs как основы для хранилок.

Сама фс не плоха наверно, не стали бы ее всякие нетфликсы и яндексы коммиты спонсировать бы :)

AK> Кластеры из г-на наше всьо. Там, хотя бы, можно потом местами что-то починить.

где-то видел статью, о том как zfs+gfs2 дружили на линуксе+Zol

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

--- wfido

Eugene Grosbein написал(а) к Alex Korchmar в Jan 21 13:56:28 по местному времени:

13 янв. 2021, среда, в 16:20 NOVT, Alex Korchmar написал(а):

EG>> Размер страницы InnoDB и размер блока UFS крайне желательно
EG>> иметь одинаковыми и изменить размер страницы однажды созданной базы InnoDB
AK> я, кстати, рекомендую еще разок перечитать вот это из найденной пострадавшим
AK> компилятивной доки:
AK> As discussed above, ZFS LZ4 compression is incredibly fast

Вот это "incredibly fast" бездумно перепечатывают все подряд,
но на практике я этого вовсе не ощущаю, либо оно таки сильно
зависит от каких-то ещё условий. То есть, я вполне верю,
что на синтетических бенчмарках и топовых процессорах
оно incredibly fast, но на моём реальном железе (вовсе не топовом)
и на моих каталогах с кучей метаданных и невозможностью
засосать всё необходимое в ARC, латентность не просто видна
невооруженным взглядом, а оно таки хуже UFS+gjournal.

AK> so we
AK> should leave compression to ZFS and not use InnoDBs built in page
AK> compression.

Я не вижу тут сравнительных результатов тестирования
и не склонен доверять таким утверждениям априори.

AK> То есть, если не планируется делать чего-то совсем странного, про страдания с
AK> попаданием в page size можно смело забывать - это in-memory pages, при
AK> записи все будет пожамкано в непредсказуемый размер.

Непредсказуемый размер для базы данных - плохо. Отказать.

AK> Читается оно с prefetch, поэтому никто от этого особо не страдает.

prefetch на уровне файловой системы сам по себе вовсе не является
абсолютным добром, особенно когда дело касается баз данных,
если у тебя пропускная способность I/O конечна:

https://dadv.livejournal.com/204385.html

То есть, лишний prefetch, в зависимости от конкретных задач,
может быть и злом.

Eugene
--- slrn/1.0.3 (FreeBSD)

Sergey Anohin написал(а) к Eugene Grosbein в Jan 21 14:06:09 по местному времени:

Нello, Eugene!

EG> Непредсказуемый размер для базы данных - плохо. Отказать.

Вроде не плохо если верить переводчику?

Как обсуждалось выше, сжатие ZFS LZ4 невероятно быстрое, поэтому мы должны оставить сжатие ZFS и не использовать встроенное сжатие страниц InnoDB. В качестве дополнительного преимущества оставление сжатия ZFS не нарушает выравнивание блоков. Оптимизация стека хранилища для записи 16 КБ, а затем использование сжатия на уровне InnoDB значительно изменит эту оптимизацию. Поскольку размер записи ZFS относится к необработанному несжатому размеру (он может сжиматься до размера всего одного сектора / увеличения), это не нарушает выравнивание стека хранилища.

Или я тонкости перевода не пойму?

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

--- wfido

Eugene Grosbein написал(а) к Sergey Anohin в Jan 21 20:01:39 по местному времени:

14 янв. 2021, четверг, в 14:06 NOVT, Sergey Anohin написал(а):

EG>> Непредсказуемый размер для базы данных - плохо. Отказать.
SA> Вроде не плохо если верить переводчику?
SA> Как обсуждалось выше, сжатие ZFS LZ4 невероятно быстрое, поэтому мы должны
SA> оставить сжатие ZFS и не использовать встроенное сжатие страниц InnoDB. В
SA> качестве дополнительного преимущества оставление сжатия ZFS не нарушает
SA> выравнивание блоков. Оптимизация стека хранилища для записи 16 КБ, а затем
SA> использование сжатия на уровне InnoDB значительно изменит эту оптимизацию.
SA> Поскольку размер записи ZFS относится к необработанному несжатому размеру (он
SA> может сжиматься до размера всего одного сектора / увеличения), это не нарушает
SA> выравнивание стека хранилища.
SA> Или я тонкости перевода не пойму?

Дело тут вовсе не в переводе, а в оригинальном утверждении о том,
что LZ4 невероятно быстро сжимает. Из этого не следует,
что работа с файлами на такой fs реально будет невероятно быстрой,
моя практика показывает, что не будет.

Eugene
--
Enter old password: xxx
Enter new password: yyy
Confirm password: подтверждаю
--- slrn/1.0.3 (FreeBSD)