ru.unix.bsd

Hello, Eugene! EG> Дело тут вовсе не в переводе, а в оригинальном утверждении о том, EG> что LZ4 невероятно быстро сжимает. Из этого не следует, EG> что работа с файлами на такой fs реально будет невероятно быстрой, EG> моя практика показывает, что не будет. Может имелось ввиду в сравнении с gz? Ну типа побыстрее чем другие. С наилучшими пожеланиями, Sergey Anohin.

From: Alex Korchmar Sergey Anohin wrote: SA> это проблема резервирования имхо, нет. это проблема невнимательного чтения чужих малограмотных построений. SA> Сама фс не плоха наверно, не стали бы ее всякие нетфликсы и яндексы коммиты SA> спонсировать бы :) нетфликса не спонсирует zfs. Ей не нужно. А те кто спонсировали - либо уже всьо, либо это те самые ребята, которые предпочитают чтобы их спонсировал дельфикс, а они только клиентов окучивали на халяву. Что клиенты плюнут и synology вместо их поделки купят, а те что побогаче - уйдут на кластеры и sds - до их топ-топов, как обычно, дойдет, в момент автораскрытия золотого парашутика. А рабы - кто их вообще вспомнит. Утонут вместе с галерой - да и хрен с ними. SA> где-то видел статью, о том как zfs+gfs2 дружили на линуксе+Zol безумству храбрых. Мне вполне хватило презентации от redhat, где gluster развернут поверх hardware raid6. И на нем, разумеется, xfs. > Alex

From: Alex Korchmar Eugene Grosbein wrote: EG> Вот это "incredibly fast" бездумно перепечатывают все подряд, а на практике это звиздежь, угу. Hо самое главное - что это ведет к порождениям сна разума вокруг compressed arc (интересно, надолго ли у нас еще остался uncompressed - с учетом что его уже раз порывались выпилить) EG> зависит от каких-то ещё условий. То есть, я вполне верю, EG> что на синтетических бенчмарках и топовых процессорах скорее на чем-то что жмется 1:5. А не 1:1.5, как в показанном выхлопе. Hу и учтите, что ветку кода с uncompressed не тестируют, похоже, уже лет пять. AK>> should leave compression to ZFS and not use InnoDBs built in page AK>> compression. EG> Я не вижу тут сравнительных результатов тестирования EG> и не склонен доверять таким утверждениям априори. я бы заподозрил обратное. Hо учитываем, что zfs comression это не только потери на сжатие, но и variable block length. EG> Hепредсказуемый размер для базы данных - плохо. Отказать. Оне так работают. Я хз что будет, если выключить оба. Опять же, вероятнее всего, никто уже не тестирует innodb в другом режиме. EG> prefetch на уровне файловой системы сам по себе вовсе не является EG> абсолютным добром, особенно когда дело касается баз данных, EG> если у тебя пропускная способность I/O конечна: она не то чтобы бесконечна, но при размере блока 16k точно ни на что не повлияет. Hо я бы голосовал опять же за innodbшный префетч. Кстати, все помнят тутубалинский прикол с cache=metadata и префетчем? ;-) > Alex

14 янв. 2021, четверг, в 14:06 NOVT, Sergey Anohin написал(а): EG>> Hепредсказуемый размер для базы данных - плохо. Отказать. 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: подтверждаю

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

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> записи все будет пожамкано в непредсказуемый размер. Hепредсказуемый размер для базы данных - плохо. Отказать. AK> Читается оно с prefetch, поэтому никто от этого особо не страдает. prefetch на уровне файловой системы сам по себе вовсе не является абсолютным добром, особенно когда дело касается баз данных, если у тебя пропускная способность I/O конечна: https://dadv.livejournal.com/204385.html То есть, лишний prefetch, в зависимости от конкретных задач, может быть и злом. Eugene

Hello, Alex! SA>> Как пишут: AK> промтом переводили? хз, нашел в таком виде AK> Короче, краткий перевод с промта на русский: это дополнительный журнал данных. AK> Который тебе очень пригодится, если крэшнется сервер или вся система, а AK> существенной нагрузки на диски не создает (к zfs не относится, но лучше AK> лишняя нагрузка чем невосстановимо битая innodb) это проблема резервирования имхо, в продакшне, если уж там мускуль и зфс, что мало вероятно, это при условии нормального железа еще маловероятнее :) SA>> Хотя че говорить если в БСД уже Zol скоро будет наверно по дефолту :) AK> уже точно. Увы. AK> Я окончательно похоронил идею использования zfs как основы для хранилок. Сама фс не плоха наверно, не стали бы ее всякие нетфликсы и яндексы коммиты спонсировать бы :) AK> Кластеры из г-на наше всьо. Там, хотя бы, можно потом местами что-то починить. где-то видел статью, о том как zfs+gfs2 дружили на линуксе+Zol С наилучшими пожеланиями, Sergey Anohin.

From: Alex Korchmar Sergey Anohin wrote: SA> Как пишут: промтом переводили? Короче, краткий перевод с промта на русский: это дополнительный журнал данных. Который тебе очень пригодится, если крэшнется сервер или вся система, а существенной нагрузки на диски не создает (к zfs не относится, но лучше лишняя нагрузка чем невосстановимо битая innodb) SA> Хотя че говорить если в БСД уже Zol скоро будет наверно по дефолту :) уже точно. Увы. Я окончательно похоронил идею использования zfs как основы для хранилок. Кластеры из г-на наше всьо. Там, хотя бы, можно потом местами что-то починить. > Alex

From: Alex Korchmar Sergey Anohin 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 на чтение ведь пашет? Hу может какой-то профит от него есть для Да. Hо, учитывая какими лапами или что это у них такое написана arc compression - я бы первым делом выключил ее. Поскольку есть некоторые сомнения, что при включенной L2ARC вообще работает нормально. Следующим ходом я бы отправил нахер abd scatter. И только после этого стал бы экспериментировать с размерами блока. > Alex

Hello, 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 zfs_prefetch_disable=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> (Hо вот размер записи в логи - насколько я понимаю, фиксированный.) Ну тут доверяй но проверяй, кейзы разные всегда, вот например есть такой пример, zroot/var/db/mysql recordsize 8k zroot/var/db/mysql/ibdata recordsize 16k zroot/var/db/mysql/iblogs recordsize 128k только при innodb_per_table=1 или как его там он все равно хранит где попало в /var/db/mysql//.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 innodb_data_home_dir=/var/db/mysql/ibdata innodb_log_group_home_dir = /var/db/mysql/iblogs Кеш L2ARC на чтение ведь пашет? Ну может какой-то профит от него есть для MySQL, не очень глазу заметнй С наилучшими пожеланиями, Sergey Anohin.