LGWR priority

Как я обещал, ниже первый пост из серии "как я провел лето".

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