Подарок на новый год

Сделайте себе подарок на новый год - купите Oracle Core, by Jonathan Lewis.  Не соглашусь, что эта книга прямо вот для каждого разработчика или DBA, никаких магических советов как ускорить производительность там нет, как и примеров как лучше писать код pl/sql. Там есть вдумчивый, тщательно сбалансированный между доступностью и количеством деталей рассказ,  как работает Oracle Database. В одной книге.  Она требует времени, внимания, это книга больше для души -)), а не для работы. Здесь еще до 25 декабря действует промокод SNOW11.  Я купил в электронном варианте, но теперь даже немного жалею, что не купил бумажный вариант.  Сделайте себе подарок.






Ну а мне в лучшим подарком в уходящем  году были вот эти семинары. Единственные, про то, как на самом деле будет работать ваше приложение в  коробке на заднем плане -) 



C наступающим Вас !

PS Не могу обещать. что смогу быстро акцептовать ваши комментарии, но они все точно появятся на сайте. 


Читать дальше...

SMT4

Предыдущий пост здесь.  Приобретая систему с 256 ядрами заказчик конечно же захотел использовать SMT в Power 7 на полную катушку, те включить режим SMT4 и получить в общей сложности 1000 процессоров в одной LPAR.  Однако Best Practice на сегодняшний день - это использование в таких конфигурациях SMT2. Этому есть несколько объяснений, в том числе и то, что Oracle Dev не имеет доступа к таким машинам, а значит не имеет возможности нормально протестировать код.  Ну а раз нет возможности протестировать, то и найти возможные проблемы с масштабируемостью (как в Oracle, так в AIX) тоже удается только по факту их возникновения.  Ничего личного, это просто текущее положение вещей. Вот и мы, для  временного обхода одной из проблем в AIX,  решили попробовать перейти в режим SMT OFF.

Конечно возник вопрос а как это скажется на производительности ? Процессоров то станет меньше.  На основе просмотра статистики, стало ясно, что можно выключить  SMT без ущерба для производительности в данном конкретном случае. Детали вы найдете в моей презентации, но если коротко - в системе не находилось одновременно более 256 работающих процессов. А если процессов меньше, чем ядер, AIX умеет распознавать эту ситуацию, и помещает каждый процесс на отдельное ядро, те фактически автоматически переводит систему в наиболее оптимальный  режим SMT. Но а если вы  точно знаете что происходит, то лучше сделать это самому. Магия SMT настолько велика, что пришлось даже немного поспорить с заказчиком  (и в конечном счете выиграть-), что переключение не приведет к ухудшению производительности приложения в целом. 

Было принято  решение делать это "на ходу", чтобы избежать простоя системы. У меня не было опыта,  как отработают 256 ядер переключаясь из одного режима в другой, но к удивлению, после примерно 10 минут повышенной активности sys все успокоилось.

Несмотря на то, что изменение конфигурации SMT возможно на ходу с помощью команды smtctl в больших системах рекомендуют этого не делать, а поменяв конфигурацию перегрузить систему. Я не знаю объяснения последнему факту, но верю инженерам IBM, и рекомендую следовать этой практике,  особенно  для случая когда в одну  LPAR выделены сотни (!)  ядер.

Другая опасность состояла в том, как переживет Oracle потерю половины процессоров (Oracle видит каждый thread как отдельный процессор). Но тут тоже все обошлось.   В Oracle на самом деле достаточно много внутренних структур и распределение памяти  на старте системы зависит от кол-во процессоров:
- working data set per buffer pool
- число latches защищающих library cache
- число redo copy latches
- число public redo treads
- число database writers и некоторые другие параметры,  которые можно выставить и самому

И хотя все эти структуры создаются на старте экземпляра, и не меняются после изменения кол-во процессоров "на лету", может так оказаться, что само изменение числа процессоров приведет не к оптимальной работе БД. Теоретически.

В 11.2 появился скрытый параметр _disable_cpu_check который похоже предназначен для таких ситуации. Вы ставите нужный вам cpu_count, и  _disable_cpu_check = TRUE (FALSE по умолчанию), и больше не будете зависеть от кол-ва процессоров (еще сам это не проверил)  

Ну и напоследок небольшой анекдот:

Я привык пользоваться командой vmstat для мониторинга кол-ва активных процессов ожидающих процессора (колонка r). Тут интересная деталь. Я всегда считал,  что там фиксируется кол-во процессов, именно  ожидающих процессора. И это так для  Linux
"The number of processes waiting for run time".  Однако для AIX оказалось, что: "Runnable threads consist of the threads that are ready but still waiting to run, and the threads that are already running"

Вместо заключения: хорошо ли SMT4,   или SMT2, или лучше вообще выключить зависит от задачи. Надеюсь я вас этим не удивил. В большинстве систем можно включить SMT4 и AIX сам сделает как надо. И только в очень больших системах лучше сначала подумать и собрать несложную статистику.  На картинке, интересный скриншот, сравнение с помощью rperf Power5/Power6 с SMT4 Power 7. Очень важно, что это capacity сравнение, не сравнение по скорости. Наверно более подробно, в следующей серии -)

PS Над проектом работала большая команда, поэтому все обнаруженные улучшения/настройки являются коллективным трудом.


Читать дальше...

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


Читать дальше...

I'm back

Долгое время  я не писал, был занят в достаточно интересном проекте по внедрению Oracle Database on Power P795. Сейчас кажется появилось время и я постараюсь опубликовать несколько постов про полученный опыт.  Проект был не простой,  и  мне просто повезло, что  удалось пообщаться с dev team как IBM, так и Oracle.   

Поскольку работы проводились большей частью из дома или на площадке заказчика я был  долгое время вне офиса. А тут приехал - стоит, красавица,  даже еще и пленочку не сняли -). В близжайшее ее  время запустят и конечно же первым делом я попрошу  сертифицировать 1C - ведь я очень ценю  хороший юмор -) 

Заодно и узнаем, что было правдой, а что нет вот в этих постах.


Читать дальше...