Добро пожаловать, Гость. Пожалуйста авторизуйтесь здесь.
FGHIGate на GaNJa NeTWoRK ST@Ti0N - Просмотр сообщения в эхоконференции RU.UNIX.BSD
Введите FGHI ссылку:


Присутствуют сообщения из эхоконференции RU.UNIX.BSD с датами от 18 Jan 11 22:51:00 до 18 Jan 24 18:16:22, всего сообщений: 10753
Ответить на сообщение К списку сообщений Предыдущее сообщение Следующее сообщение
= Сообщение: 10083 из 10753 ==================================== RU.UNIX.BSD =
От   : Eugene Grosbein                  2:5006/1           14 Jan 21 13:56:28
Кому : Alex Korchmar                                       14 Jan 21 13:56:28
Тема : Re: InnoDB+UFS+SSD
FGHI : area://RU.UNIX.BSD?msgid=grosbein.net+1d7114ee
На   : area://RU.UNIX.BSD?msgid=ddt.demos.su+46c809bf
= Кодировка сообщения определена как: IBM866 =================================
Ответ: area://RU.UNIX.BSD?msgid=2:5034/10.1+c0017dc6
Ответ: area://RU.UNIX.BSD?msgid=<1187514818@ddt.demos.su>+9cc21d4a
==============================================================================
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
--- slrn/1.0.3 (FreeBSD)
* Origin: RDTC JSC (2:5006/1@fidonet)

К главной странице гейта
Powered by NoSFeRaTU`s FGHIGate
Открытие страницы: 0.094279 секунды