IBM AIX with Oracle Database performance: a beginner’s guide

Пока я тут с трудом раз в неделю пишу по 1 посту про Oracle Database on AIX коллеги успевают написать целую статью: IBM AIX with Oracle Database performance: a beginner’s guide. Кстати, и вовсе у не такой и beginner's как скромничает автор - там тебе и примеры с OSWatcher, и Nmon, и Responce Time формула. Главное - это наличие разобранных примеров.
Наверно, можно найти в этом документе какие-то шероховатости, но в целом я очень доволен и рекомендую к изучению.

В качестве демонстрации шероховатостей я захотел придраться вот к этой формуле (стр 3):
"
On Power 7 system performance is degraded when Number of Active Sessions  >  4 x Number of Cores x 3. 
"
4 - это максимально возможное число одновременных потоков для Power 7.
3 - это магическая константа, которую я также долго использовал для определения загруженности процессоров на старых Sun машинах - если на каждый поток приходится больше 3 ожидающих процессов  - значит  процессоры не справляются. Ну по порядку:

0. К сожалению, нет точной цифры сколько пользовательских задач (мы понимаем, что задачи это сессии Oracle)  на thread приводят к его 100% утилизации. Скорее, можно было бы говорить сколько потоков на ядро, но и таких оценок официально нет.  Представляется вероятным, что скорее всего это будет где то между 4 и  8. Другими словами, 4 ядра в режиме SMT OFF у меня выдерживали 32 одновременно работающие задачи (коэфф 8),  и эти же 4 ядра в режиме SMT 4 справлялись с 64 потоками (кoэф 4). Процессор Power 7 вообще потрясающе устойчив к большим загрузкам. 256 ядерная машина может работать в 100% загрузке затрачивая  на ядро порядка 7% (и это при некоторых отягощяющих обстоятельствах)

Есть еще одно обстоятельство: правду о загрузке LPAR дает только команда

lparstat

System configuration: type=Dedicated mode=Capped smt=Off lcpu=256 mem=2020352MB 

%user  %sys  %wait  %idle
----- ----- ------ ------
  0.5   0.7    0.3   98.5 

А правду о загрузке фического ядра дает специальный регистр PURR. Если вы задумаетесь, то поймете, что можно вполне увидеть 4 потока одного ядра загруженные на 100%, это же не значит, что ядро загружено на 400%, так ли  ?


1. Теперь  необходимо убедиться, а сколько действительно  работает потоков - режим smt может быть как выключен, так и включен в 2 и 4.  В AWR на AIX число потоков показывается в колонке CPUs, число ядер - в колонке  Cores -)

Однако, это самый простой случай в мире, когда у нас в нашу LPAR выделены физические ядра и наша LPAR - dedicated. Это значит, что другие задачи в других LPAR не могут претендовать на ресурсы наших ядер (Cores).

Однако весьма распространены ситуации, когда LPAR сделаны как shared , или dedicated donation. Надо быть тут очень внимательным чтобы не попасться в ловушку -)


2.   Average Active Sessions определятся как DB Time/Elapsed Time. Прекрасные ссылки (первая, вторая) из которых можно найти, что в DB Time входят не только время on CPU, но и I/O wait, и время на прочие ожидания.

Если рассмотреть как вырожденный случай, систему в которой сессии постоянно ждут ввода-вывода (db file sequencial read/db file scattered read) DB Time получится высокий и мы сможем прийти к заключению что проблемы с загрузкой процессоров, в то время как они с вводом-выводом.

Повторю - статья мне понравилась, рекомендую. Нормальный баланс между объемом информации и детальностью изложения.