Как я обещал, ниже первый пост из серии "как я провел лето".
В нашей системе, достаточно жесткой 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 Над проектом работала большая команда, поэтому все обнаруженные улучшения/настройки являются коллективным трудом.
Сообщения
