Как я обещал, ниже первый пост из серии "как я провел лето".
В нашей системе, достаточно жесткой OLTP, 256 core, AIX 7, Power 7, сессии испытавали проблемы с событием ожидания log file sync. Сразу скажу, что на 99,99% проблему тут стоит искать в вводе-выводе. Так оно в конце концов и оказалось конечно же.
А пока мы ломали голову над записями в файле
_lgwr_PID.trc
Warning: log write elapsed time 888ms, size 252KB
*** 2011-11-18 01:55:57.286
Warning: log write elapsed time 535ms, size 2529KB
*** 2011-11-18 01:55:57.924
Warning: log write elapsed time 560ms, size 99KB
*** 2011-11-18 01:56:00.852
Warning: log write elapsed time 541ms, size 3688KB
Оказалось, что при превышении timeout одной операции (?) LGWR более чем на 500 ms (есть скрытый параметр определяющий порог, но я не смог его найти во время написания этого поста) Oracle начиная с версии 10.2.0.4 (MOS 601316.1) начинает фиксировать данные события.
Горячие головы на различных форумах предлагают установить событие 10468 чтобы исключить появления этих записей, но на мой взгляд, появления записей однозначно говорит о наличии проблемы и ее необходимо найти.
Не скрою, первое подозрение пало на дисковый массив. Однако проблему удалось найти не в самом дисковом массиве, но в I/O path. Система очень комплексная, очень большое количество вендоров задействовано, и конечно проблемы на стыке были более, чем ожидаемые. Если вы увидите на AIX подобную проблему, свяжитесь со мной, и я смогу понять та же у Вас проблема или нет. Пока не могу рассказать больше деталей.
Но пока мы разбирались с этой проблемой появилась идея, что неплохо бы и помочь LGWR в работе. Процессоров огромное количество в машине, процессов еще больше, и получается, что хотя все сессии ждут LGRW приоритет у него совершенно такой же как у всех остальных процессов. Вы видите на рисунке слева (Tanel Poder, Understanding LGWR, Log File Sync Waits and Commit Performance) что ожидание в очереди процессов LGWR вполне себе входит во время ожидания log file sync.
Оказалось, что в AIX по умолчанию все процессы получают приоритет 60 (
на самом деле base priority 40 и nice 20 = 60).
#ps -ef -o pid,pri,sched,nice,args |egrep 'lgwr' |grep -v grep
PID PRI SCH NI COMMAND
2432232 60 0 20 ora_lgwr_cardway
Казалось бы необходимо воспользоваться nice/renice чтобы получить требуемое. Но на самом деле не все так просто, и, простыми словами, nice = "nice to have", а вовсе не жесткое указание приоритета. К тому же пришлось бы так делать каждый раз после старта БД руками.
Оказывается, что в AIX можно выставить фиксированный приоритет < 40 с помощью системного вызова setpri(). Я уже почти запускал компилятор, когда оказалось, что у Oracle есть скрытый параметр _high_priority_processes с помощью которого можно указать каким процессам мы хотим повысить приоритет:
alter system set "_high_priority_processes"='LGWR|PMON' scope=spfile;
При этом убедитесь пожалуйста что данный запрос также возвращает 1
select a.ksppinm "Parameter",
b.ksppstvl "Session Value",
c.ksppstvl "Instance Value"
from x$ksppi a, x$ksppcv b, x$ksppsv c
where a.indx = b.indx and a.indx = c.indx
and a.ksppinm like '%os_sched%'
И даже это еще не все. У меня все заработало только после того, как я добавил capability CAP_NUMA_ATTACH пользователю Oracle. Хотя возможно, это и не обязательно.
Вот как выглядит теперь правильная картинка: PRI=39, NI="--"
#ps -ef -o pid,pri,sched,nice,args |egrep 'lgwr' |grep -v grep
PID PRI SCH NI COMMAND
3544740 39 2 -- ora_lgwr_cardway
Коллеги со стороны приложения подтвердили, что видят положительный эффект после данного изменения.
Является ли данный метод действенным способом уменьшить событие log file sync во всех случаях ? Если проблема заключается в вводе-выводе в redo logs, то скорее нет. Но после исключения проблем ввода вывода, и если у Вас OLTP, и если у Вас много процессоров - почему бы и не попробовать ?
Поскольку требуется выставлять скрытый параметр, то вам лучше перед его использованием проконсультироваться с Oracle Support. Но они не будут очень возражать, поскольку, как мне кажется, тот же самый механизм используется для выставления приоритета процессу LMS в RAC.
PS Над проектом работала большая команда, поэтому все обнаруженные улучшения/настройки являются коллективным трудом.
Все стало на свои места. Вот почему Ларри так сильно напирал в своей речи на OpenWorld на то, что 10x10 = 100. Он знал что конкуренты догоняют ..
Вообще то предполагалось что все будут слушать про cloud. Но другие сессий были гораздо интереснее. Сначала я слушал про две новые возможности Enterprise Manager 12c - ASH analitics и Real Time Perfomance Diagnostics (RTPD). Whitepaper про них вот здесь. Если коротко, то RTPD это возможность прямого соединения Enterprise Manager с БД, а не только через агента. При этом набор возможностей и собираемых статистик понятно отличается. Сделано это по всей видимости чтобы облегчить диагностику ситуаций когда базе плохо и ждать пока агент что-то там пришлет просто некогда. Удобно. Но рекомендую держать открытую сессию локально на сервере все равно. На всякий случай. Это достаточно существенное изменение в архитектуре, и что интересно, так сразу был сделан Veritas I3. Наверно они нашли документацию по нему и все-таки прочитали -). Презентатор также упоминал, что сам агент существенно переписан и конечно же улучшен.
ASH analitics это возможность достаточно удобного (и говорят настраиваемого) анализа данных. Т.е. теперь прямо в основном окошке закладки Perfomance можно включать вложенные фильтры. Т.е. как бы "проваливаться" вниз по данным. Вы добавляете фильтры в любом порядке пока не достигните нужной степени детализации. 
Сегодня удалось наконец прорваться к демо room Oracle Hardware. Далее со слов специалиста, который отвечал на мои вопросы. На картинке слева видно что там все таки внутри Super Cluster - 6 Exadata Cell для СУБД, ZFS Appliance как shared пространство для серверов. Дальше предлагается из 2 узлов Sun T4-4 собрать два кластера - один на основе Solaris 10 для web серверов, другой на основе Solaris 11 для Database. Также можно заказать карточку и подключить сервера к существующему SAN. На вопрос - только на время миграции или навсегда - помялись, но сказали - что навсегда тоже можно. 
IBM AIX on Power 7 обладает где-то схожей технологией, которую называют intelligent threads, которая помещает потоки на незанятые ядра, достигая максимально возможной производительности. Я создал логический раздел с 4 ядрами в режиме SMT=4. Операционная система видит 16 логических процессоров. Далее я запустил 4 потока, каждый из которых загружает до 100% процессор. Из картинки справа видно, что AIX увидев, что потоков у нас мало, перешел в режим SMT=1 и поместил каждую из моих задача на свое физическое ядро (CPU 0-3 ядро 1, CPU 4-7 ядро 2, CPU 8-11 ядро 3, CPU 12-15 ядро 4). Вы можете попробовать этот тест на своей операционной системе -) 
Для тех, кто уже знает какая лучшая в мире платформа для Oracle BI -) - приводится специальная табличка производительность Power 770 (топовый midrange или нижний hi end как вам больше нравится -)
Сообщения
