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

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

07 июля 2019, воскресенье, в 19:23 NOVT, Alex Korchmar написал(а):

EG>> Только вот массированное копирование данных это вовсе не чтение
EG>> в произвольном порядке и перед таким копированием prefetch
EG>> лучше бы включить. Не говоря уже о том, что хранение сжимаемых
AK> ему не поможет из-за cache metadata only. Оно в этом случае работает так:
AK> prefetch читает страйпом, ARC напарывается на primarycache=metadata -
AK> удивляется, роняет прочитанное на пол, потому что сохранять его невелено.
AK> На следующем блоке все повторяется. Удивительно, но тесты это подтверждают.
AK> включать prefetch имеет смысл только вместе с arc для данных, он по другому
AK> не умеет.

Само собой, я это и имел в виду.

AK> кстати, это можно на ходу переключать, в отличие от сжатия и размера блока.
AK> Со сжатием все сложно - оно теоретически - должно работать хорошо
AK> и быстро, а практически тупит в непонятных местах, жрет память и
AK> не работает. С abd_scatter off - крэшится. При сжатии 1.16 я бы выключал
AK> всю эту музыку вместе, пользы от блоков переменного размера innodb около нуля.

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

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

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

07 июля 2019, воскресенье, в 19:34 NOVT, Alex Korchmar написал(а):

AK>>> если ВСЕ хотят свалить - то дело, конечно же, в этих всех, ага.
^^^^^^^^^^^^^^^
EG>> Угу, а ещё все хотят свалить с линукса и с винды.
AK> кто эти "все"? Вчерашний выпуск школы? Куда их на работу-то берут?

Ну ты понял.

AK>>> Других применений фре помимо роутеров из г-на и палок с нулевой
AK>>> производительностью - не наблюдается уже десять лет.
EG>> У тебя не наблюдается. У меня на фряхах и highload PPPoE,
EG>> и мониторинг, и MySQL, и почта, и SMS-шлюзы и ещё куча всего.
AK> троллейбусизбуханки.jpg

С добрым утром. Бизнес, который живёт на свои деньги - всегда их считает.

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

Slawa Olhovchenkov написал(а) к Alex Korchmar в Jul 19 21:44:54 по местному времени:

Нello Alex!

07 Jul 19, Alex Korchmar writes to Eugene Grosbein:

AK> Со сжатием все сложно - оно теоретически - должно работать хорошо
AK> и быстро, а практически тупит в непонятных местах, жрет память и
AK> не работает. С abd_scatter off - крэшится. При сжатии 1.16 я бы выключал

крэшится только на лялихе

... Тебе пpавду сказать? Или как все было на самом деле?
--- GoldED+/BSD 1.1.5-b20110223-b20110223

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

Нello Eugene!

07 Jul 19, Eugene Grosbein writes to Alex Korchmar:

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

ты читал неправильно

... В споре рождается истина. Пропади она пропадом!
--- GoldED+/BSD 1.1.5-b20110223-b20110223

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

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

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

https://docs.oracle.com/cd/E19120-01...fgv/index.html

The recordsize Property

Specifies a suggested block size for files in the file system.

This property is designed solely for use with database workloads
that access files in fixed-size records. ZFS automatically adjust
block sizes according to internal algorithms optimized for typical
access patterns. For databases that create very large files
but access the files in small random chunks, these algorithms
may be suboptimal.

Specifying a recordsize greater than or equal to the record size
of the database can result in significant performance gains.
Use of this property for general purpose file systems is strongly discouraged,
and may adversely affect performance. The size specified must be
a power of two greater than or equal to 512 and less than or equal to
128 Kbytes. Changing the file system's recordsize only affects
files created afterward. Existing files are unaffected.

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

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

Нello Eugene!

08 Jul 19, Eugene Grosbein writes to Slawa Olhovchenkov:

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

EG> 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 according to internal algorithms optimized for typical
EG> access patterns. For databases that create very large files
EG> but access the files in small random chunks, these algorithms
EG> may be suboptimal.

EG> Specifying a recordsize greater than or equal to the record size
EG> of the database can result in significant performance gains.
EG> Use of this property for general purpose file systems is strongly
EG> discouraged, and may adversely affect performance. The size specified must
EG> be a power of two greater than or equal to 512 and less than or equal
EG> to 128 Kbytes. Changing the file system's recordsize only affects files
EG> created afterward. Existing files are unaffected.

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

... Не все ври, что знаешь.
--- GoldED+/BSD 1.1.5-b20110223-b20110223

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

Нello, Alex!

SA>> Честно не помню, но сжатие вроде я пользовал выборочно, типа на /usr/src
AK> такому сжатию arc compress необязателен, а вреда от него довольно много.
SA>> но надо посвежее сверить:
SA>> https://www.percona.com/blog/2017/12...fs-with-mysql/
AK> это можешь сразу выкрасить и выбросить - они там поместили весь активный
AK> dataset в l2arc и рапортуют об охрененных достижениях. Что делать тем, у кого
AK> он не уместится в l2arc - скромно умалчивают.

Вроде как речь о l2arc в разделе optional features, нет?

AK> с отключением double write осторожнее, mysql может иногда при этом превращать
AK> базу в тыкву.

самое труевое :)

https://wiki.freebsd.org/ZFSTuningGuide


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

--- wfido

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

Нello, Alex!

SA>> Компрессию включил. Тестим тупое копирование.
AK> теперь надо переписать все данные заново - она включилась, но твои базы так
AK> и остались как были, с сектором 128k.
AK> А надо было - 16 (или крутить настройки innodb, но это чревато). А, да - логи
AK> пишутся линейно, их трогать не надо.

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

SA>> (pts/2)[root@server:~]# sysctl vfs.zfs.prefetch_disable
SA>> vfs.zfs.prefetch_disable: 1
AK> и вот - зачем? (нет, при cache=metadata оно только вредит, но это тоже неясно,
AK> зачем было надо)

я конечно не эксперт, но выглядит утверждение логичным:

База данных осуществляет чтение в произвольном порядке, который нельзя предсказать.
Отключение префетча позволяет избежать ненужных операций чтения. Добавим в /boot/loader.conf строку
vfs.zfs.prefetch_disable=1
ZFS кэширует данные в ARC, используя свободную оперативную память. Поскольку страницы InnoDB уже кэшируются в буфер пуле, отключим кэширование файлов данных InnoDB:
# zfs set primarycache=metadata data/mysql/ibdata

или тут нелогично?

SA>> zroot/var/db/mysql compressratio 1.00x -
AK> естественно
SA>> NAME PROPERTY VALUE SOURCE
SA>> zroot/var/db/mysql/ibdata compressratio 1.16x -
AK> не особо, что-то несжимаемое у тебя там лежит, это необычно

тут надо передеывать, ибо там как оказалось мало полезного, потому что
у меня innodbfile_pertable=1; это значит что 16k надо было включать уровнем повыше.

AK> в общем, выключай сжатие, arc compress и abd. Для последнего, наверное,
AK> придется пересобрать ведро - смотри в abd.h

или сразу с портов zol собрать...


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

--- wfido

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

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

Sergey Anohin <Sergey.Anohin@p1.f10.n5034.z2.fidonet.org> wrote:
AK>> А надо было - 16 (или крутить настройки innodb, но это чревато). А, да -
AK>> логи
AK>> пишутся линейно, их трогать не надо.
SA> короче стопим mysql копируем, удаляем, заливаем обратно?
можно не заливать а перемонтировать клон вместо основного сразу.
по дороге выставив ему блок в 16

SA> База данных осуществляет чтение в произвольном порядке, который нельзя
SA> предсказать.
а диск у нас -круглый, и данные обычно стараются раскладыватьлинейно методом preallocate.
Причем чтение большошго страйпа гораздо быстрее чем позиционирование голов
и люыбе другие действия с диском - поэтому читаем мы - страйп, и в arc помещаем
весь - он уже прочитан, чего его на пол-то кидать
Дальше он либо при заполнении улетает при lru, либо, куда более вероятно, за ним приходят, а его читать уже не надо.
При линейном копировании - сам понимаешь.

SA> ZFS кэширует данные в ARC, используя свободную оперативную память. Поскольку
SA> страницы InnoDB уже кэшируются в буфер пуле, отключим кэширование файлов данных
SA> InnoDB:
SA> # zfs set primarycache=metadata data/mysql/ibdata
SA> или тут нелогично?
учитывая что префетч можно запретить только глобально - нелогично.
если тольк у тебя не один mysql
(и вот копировать его ты тоже не планируешь, только clone)

SA> тут надо передеывать, ибо там как оказалось мало полезного, потому что
SA> у меня innodbfile_pertable=1; это значит что 16k надо было включать уровнем
они и должны сжимать, это повторяющиеся данные.
Да 16 при этом включать не надо, сжатие использует блоки переменной длинны.

> Alex

--- ifmail v.2.15dev5.4

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

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

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

EG>>> Угу, а ещё все хотят свалить с линукса и с винды.
AK>> кто эти "все"? Вчерашний выпуск школы? Куда их на работу-то берут?
EG> Ну ты понял.
ну я примерно так себе континхент и представляю

AK>> троллейбусизбуханки.jpg
EG> С добрым утром. Бизнес, который живёт на свои деньги - всегда их считает.
бизнес который живет на свои деньги - нонсенс, обычные бизнесы живут на деньги
которые где-то украли или заняли.
Считать, впрочем, обычно умеют плохо что те, что другие - потому
что купить нормальное оборудование и уволить самоучку без мотора
обойдется дешевле прямо сейчас, и в разы дешевле - когда тот
обидится/устанет/просто сдохнет, и придется срочно искать ему замену,
толком не понимая даже, что у той спрашивать из знаний и как проверять
умения.

> Alex

--- ifmail v.2.15dev5.4