Добрый день,

Наблюдаю более 1K записей в секунду в активные логи средствами мониторинга DB2.

При этом записей в базу происходит всего лишь около 200 в секунду, т.е. в активные логи пишется в 5 и более раз интенсивнее,
чем каталоги данных. Соответственно на хранилище вся эта нагрузка ложится в первую очередь на SLOG общего ZFS пула и потом раскидывается по дискам пула каждые 5 секунд. При этом утилизация HDD иногда поднимается почти до 100%.

Но какой смысл писать относительно небольшие активные логи на HDD да еще и за**рать ими L2ARC?

Наверно, нужно создать небольшой пул ZFS всего из одного зеркала nvRAM и целиков отдать его под активные логи?

Утилизация nvRAM очень низкая. Как мне кажется это очень сильно должно разгрузить основной пул ZFS, в т.ч. перестанет засорять его L2ARC.

Проблема только в том, как снэпшотить?

Ни разу не снэпшотил несколько датасетов одновременно.

Как думаете, можно ли после write suspend снэпшотить данные в двух разных пулах?

спрашиваю это на символичном:

S0006999.LOG

:)

недавно DB2 подвисла на логе S0006666.LOG



интересно, с чем это связано?



да, и кстати у нас нагрузка на DB2 выросла за последние месяцы в несколько раз, если не на порядок, по крайне мере судя по объему данных при синхронизации ZFS

и запас зеркалированного nvRAM в десятки раз превышает объем всех первичных и вторичных активных логов

lspci | grep -i mem
08:00.0 Non-Volatile memory controller: Intel Corporation Device 0953 (rev 01)
0c:00.0 Non-Volatile memory controller: Intel Corporation Device 0953 (rev 01)

Intel DC 3700

почему никто не дает советы в эту ветку?
неужели не пробовали?
может это нонсенс так делать
или такие рецепты только для небесплатных приватных клиентов?

может быть, у DB2 есть какой-то специальный режим подключения SSD кэш?

Какие существуют еще методики для повышения производительности именно за счет разнесения отдельных частей базы по разным хранилищам?

Т.е. какие еще каталоги базы можно расбросать по разным хранилищам и это бы дало профит в виде прироста производительности?

mitekтемпы на отдельные fs/lv/vg/raid

темпы - это что-то связанное с временными таблицами?

mitekнет, но можно поиграться с multitemperature storage, если DB2 версии V10.1 и выше

V9.7

mitekdbtwoshnickКакие существуют еще методики для повышения производительности именно за счет разнесения отдельных частей базы по разным хранилищам?

Т.е. какие еще каталоги базы можно расбросать по разным хранилищам и это бы дало профит в виде прироста производительности?

стандартная рекомендация : логи/storage path's/темпы на отдельные fs/lv/vg/raid

а каким транспортом их лучше цеплять?

NFS/iSCSI?

так даже полоса гигабитного ethernet не заполняется

mitekdbtwoshnickа каким транспортом их лучше цеплять?

NFS/iSCSI?
FC :)

в смысле Fibre Channel?

mitekdbtwoshnickв смысле Fibre Channel?
да

так ведь FC - это протокол внизу стэка под TCP/IP?
или хранилища по нему напрямую и работают без TCP/IP?

а поверх TCP/IP какой протокол посоветуете для каталогов DB2?
например, из этих двух: iSCSI или NFS?

mitekто выбрал бы NFS на .... Netapp СХД :)

потому что Netapp знаменит быстрым синхронным NFS для ESX?

mitekdbtwoshnickпотому что Netapp знаменит быстрым синхронным NFS для ESX?
потому что в этом случае для своих БД мне бы хотелось иметь нечто более надежное и предсказуемое чем ZFS на Linux-сервере ;-)

а где ZFS достаточно надежен кроме солярки?

Перенес активный лог DB2 на NVRAM SSD, максимальная скорость обмена данными в каталоге активных логов теперь ограничена только гигабитным каналом.

В разы упала утилизация HDD, примерно во столько же увеличилась скорость ZFS репликации со вторым хранилищем.

Мне теперь кажется, что размещение активного лога на SSD зеркале (пром. enterprise для датацентров) - это один из самых простых способов увеличения производительности DB2.

серые waiting хвосты в htop на хосте DB2 исчезли
да и вообще теперь большая часть ядер простаивает
наверно, потому что быстро выполняют свою работу и не ждут хранилища

по словам пользователей, теперь комплекс летает :) в рабочее время под нагрузкой
и это при падении утилизации HDD (всего лишь ЧЕТЫРЕХ HDD причем под управлением ZFS on Linux) в несколько раз!

только непонятно все же что делать с реорганизацией :(

база растет, а количество прокачиваемых за ночь IOPs-ов в сторону HDD по понятным причинам не растет ...
и кроме как добавлением количества шпинделей навряд ли можно решить эту задачу
ну или в режиме sync=disabled с огромным кол-вом оперативки, но уж проще наверно увеличить количество HDD?

в качестве ZFS сервера используется железяка 10 летней давности с немного увеличенным RAM, новыми дисками и добавленными PCI SSD (пара в зеркале)

Что любопытно, в других регионах с ночной реорганизацией НЕ справляются даже ультрасовременные супер дорогие хранилища IBM, это когда база в 4 раза больше нашей. Шпинделей на таких хранилищах раз в 5-10 больше, чем на моем ZFS хранилище.

Если бы на таком железе запустить ZFS, то наверно бы вообще никаких проблем не было...

mitekdbtwoshnickа где ZFS достаточно надежен кроме солярки?
Не в курсе
Есть же, например, NexentaStor, которая по слухам волне себе enterprise ready (и community-версия на 18ТБ есть). Чего бы ее не взять раз так хочется ZFS ?

Во первых конечно же потому, что линукс привычнее и комфортнее администировать

Во вторых потому что ZOL очень динамично развивает свой уровень портирования на Linux, а остальная часть кода OpenZFS скорее всего одинаковая хоть в открытой солярке, FreeBSD, Linux. OpenZFS он и есть OpenZFS ...

В третьих на форумах есть упоминания преимуществ использования ZOL:
например, если не ошибаюсь ashift=13 для SSD,
и вроде бы что-то связанное с ECC RAM или какими то другими проверками правильности работы железа

а NexentaStor последняя версия от лета 2015 ?

а в ZOL тем временем уже и баг фикс репликации holebirth недавно включили в релиз ...

Nexenta я пробовал еще лет 8 назад, но солярка незнакомая, привык я к линуксу, а лишнего времени на изучение нету

еще есть napp it, smart os, фрюха, freenas, только зачем все это когда есть ZOL

еще понимаю, Oracle Solaris можно было бы использовать, если бы они гарантировали выплатить 100500 компенсаций в случае неспособности их инженеров оживить ороклячий пул