Пока я тут с трудом раз в неделю пишу по 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 получится высокий и мы сможем прийти к заключению что проблемы с загрузкой процессоров, в то время как они с вводом-выводом.
Повторю - статья мне понравилась, рекомендую. Нормальный баланс между объемом информации и детальностью изложения.
Сообщения
