= Сообщение: 9077 из 10753 ===================================== RU.UNIX.BSD = От : Eugene Grosbein 2:5006/1 07 Jul 19 23:46:20 Кому : Alex Korchmar 07 Jul 19 23:46:20 Тема : Re: Еще одна причина уйти с ZFS FGHI : area://RU.UNIX.BSD?msgid=grosbein.net+a161a65c На : area://RU.UNIX.BSD?msgid=ddt.demos.su+46c7fe77 = Кодировка сообщения определена как: IBM866 ================================= Ответ: area://RU.UNIX.BSD?msgid=2:5030/500+5d223dfd ============================================================================== 07 июля 2019, воскресенье, в 19:23 NOVT, Alex Korchmar написал(а):
EG>> Только вот массированное копирование данных это вовсе не чтение EG>> в произвольном порядке и перед таким копированием prefetch EG>> лучше бы включить. Hе говоря уже о том, что хранение сжимаемых AK> ему не поможет из-за cache metadata only. Оно в этом случае работает так: AK> prefetch читает страйпом, ARC напарывается на primarycache=metadata - AK> удивляется, роняет прочитанное на пол, потому что сохранять его невелено. AK> Hа следующем блоке все повторяется. Удивительно, но тесты это подтверждают. AK> включать prefetch имеет смысл только вместе с arc для данных, он по другому AK> не умеет.
Само собой, я это и имел в виду.
AK> кстати, это можно на ходу переключать, в отличие от сжатия и размера блока. AK> Со сжатием все сложно - оно _теоретически_ - должно работать хорошо AK> и быстро, а практически тупит в непонятных местах, жрет память и AK> не работает. С abd_scatter off - крэшится. При сжатии 1.16 я бы выключал AK> всю эту музыку вместе, пользы от блоков переменного размера innodb около нуля.
При 16% экономии сжатие не нужно независимо от размера блоков. И вроде бы я читал, что recordsize лишь ограничивает размер блока, он может быть и меньше - независимо от включения компрессии.
Eugene -- Поэты - страшные люди. У них все святое. --- slrn/1.0.3 (FreeBSD) * Origin: RDTC JSC (2:5006/1@fidonet)
