Считаем процессоры Oracle в TCO

добавлено: 27 сен 13
понравилось:0
просмотров: 2785
комментов: 5

теги:

Автор: ДохтаР

Давно об этом думал , тестировал, анализировал,
было как у той собаки , все понимаю а словами сказать не могу.

Сегодня пообщавшись с коллегами в Оракл разделе форума
пришла идея как на практике формализвать подсчет
эффетивности использования ядер на серверах БД.


Производительность ядра вещь объективная , всем понятно что скорость зависит от тактовой частоты.

Я хочу поделиться мыслями о субъективной составляющей,
Как можно выжать экономию ТСО через гипертрединг и сколько профита от этого можно получить.
14894456
Цитата из форума
Перелом можно угадать по соотношению количества активных сессий оракла
и количества сессий одновременно выполняющихся на процессорах.

Показателем положительного эффекта есть
уменьшение количестова активных ( увеличение респонс тайма от БД)
с одновременным увеличением количестова процессов ОС на процессорах.


Теперь попробую описать окружение, где все это происходит.
Есть некая система живущая в LPAR сервера IBM P770
cat /etc/motd

*******************************************************************************
* *
* *
* Welcome to AIX Version 6.1! *
* *
* *
* Please see the README file in /usr/lpp/bos for information pertinent to *
* this release of the AIX Operating System. *
* *
* *
*******************************************************************************
#oslevel -s
6100-06-02-1044


c 5-ю ядрами IBM POWER7
lsattr -El proc0
lsattr -El proc0
frequency 3108000000 Processor Speed False
smt_enabled true Processor SMT enabled False
smt_threads 4 Processor SMT threads False
state enable Processor state False
type PowerPC_POWER7 Processor type False

и включенным гипертредингом.


И БД Oracle :
sqlplus
Connected to:
Oracle Database 11g Enterprise Edition Release 11.2.0.2.0 - 64bit Production
With the Partitioning, OLAP, Data Mining and Real Application Testing options


Есть некая пользовательская нагрузка на БД.
Тип нагрузки DWH, постоянная вставка записей из разных источников
и селекты с джоинами и груббаями.

Сессии делятся на 2 группы , активные и не активные.

sqlplus
select status , count(*) from v$session group by status;

STATUS COUNT(*)
-------- ----------
INACTIVE 289
ACTIVE 63



Есть процессы в ОС
автор
vmstat 1 10

System configuration: lcpu=20 mem=49152MB

kthr memory page faults cpu
----- ----------- ------------------------ ------------ -----------
r b avm fre re pi po fr sr cy in sy cs us sy id wa
3 0 6369959 3941290 0 0 0 0 0 0 6103 40315 12917 45 10 37 8
2 0 6378945 3932304 0 0 0 0 0 0 4784 36168 9808 44 11 38 7
7 0 6380891 3930358 0 0 0 0 0 0 4635 34108 8571 48 11 35 6
10 0 6382778 3928470 0 0 0 0 0 0 4441 29019 9476 42 8 43 7
9 0 6378291 3932956 0 0 0 0 0 0 2942 34221 6667 48 14 35 4
10 0 6406116 3905129 0 0 0 0 0 0 2916 38008 5278 52 14 27 6
5 0 6396384 3914861 0 0 0 0 0 0 3078 25755 6682 43 9 39 9
10 0 6393230 3918015 0 0 0 0 0 0 3968 38585 8355 51 15 28 6
0 0 6373011 3938233 0 0 0 0 0 0 8103 66279 19533 54 11 28 6
11 0 6336991 3974252 0 0 0 0 0 0 8340 67104 19411 56 19 19 6


Сразу оговорюсь если у вас во второй колонке цифры отличные о НУЛЯ ,
дальше можете не продолжать читать и проверять, не разочаровывайтесь,
считайте что у вас оракловый коэфициет равен вашему коэфициенту умноженному на цифру выделенную красным+1.

Вкратце расскажу суть, цифры во второй колонке говорят, что пользовательсткая сессия готова выполнятся на процессоре ,
но операционка ее туда не пускает , при увеличении цифр во второй колоке у вас будет расти число активных сессий в базе ,
которые сидят без дела. То есть вместо того, что бы отрабатывать деньги заплаченные ораклу за лицензию и вендору за процессор пользовательская сессия тупо чего то ждет.

вот что по этому поводу говрит мануал :
man vmstat
r
Average number of runnable kernel threads over the sampling
interval. Runnable threads consist of the threads that are ready
but still waiting to run, and the threads that are already
running.
b
Average number of kernel threads placed in the Virtual Memory
Manager (VMM) wait queue (awaiting resource, awaiting
input/output) over the sampling interval.




Ну продолжим
вот нашлась картинка еще красивее:
vmstat
vmstat 1 100

System configuration: lcpu=20 mem=49152MB

kthr memory page faults cpu
----- ----------- ------------------------ ------------ -----------
r b avm fre re pi po fr sr cy in sy cs us sy id wa
10 0 6739255 2315160 0 0 0 0 0 0 5577 57860 17596 56 18 19 7
7 0 6731286 2323129 0 0 0 0 0 0 5027 44059 16592 54 17 20 9
9 1 6733776 2320637 0 0 0 0 0 0 5818 41116 14522 53 14 23 10
12 0 6743515 2310898 0 0 0 0 0 0 6380 52482 17705 59 15 18 8
11 0 6742144 2312268 0 0 0 0 0 0 6393 52187 19101 62 16 14 8
15 0 6738982 2315430 0 0 0 0 0 0 4894 52353 18274 66 15 14 5
15 0 6753054 2301356 0 0 0 0 0 0 4856 54335 18329 65 15 13 6
12 0 6768961 2285447 0 0 0 0 0 0 5711 59453 18788 65 15 14 6
18 0 6771177 2283228 0 0 0 0 0 0 5423 49724 16042 60 15 17 8
11 0 6768599 2285802 0 0 0 0 0 0 5205 44320 15330 58 15 20 6
10 0 6766212 2288188 0 0 0 0 0 0 4940 57207 16861 64 15 15 6
10 0 6766221 2288178 0 0 0 0 0 0 4774 58688 17695 65 16 14 5
15 0 6764380 2290017 0 0 0 0 0 0 4622 46549 16368 66 16 13 5
9 0 6777490 2276906 0 0 0 0 0 0 5443 40556 14790 65 14 15 7
14 0 6780993 2273402 0 0 0 0 0 0 5689 57840 16329 68 14 13 5
0 0 6765817 2288578 0 0 0 0 0 0 5252 51334 17211 61 16 17 6
21 0 6789367 2265027 0 0 0 0 0 0 4609 53653 17786 62 15 15 8

при тех же 60 активных сессиях в БД .

vmstat нам показывает 20 логических процессоров
Oracle показывает 20 логических процессоров на 5 ядрах :
sqlplus
SQL> select
2 cpu_count as cpu#,
3 cpu_core_count as core#,
4 cpu_socket_count as socket#,
5 cpu_count_hwm as cpu_hwm,
6 cpu_core_count_hwm as core_hwm,
7 cpu_socket_count_hwm as socket_hwm
8 from sys.x$ksull;

CPU# CORE# SOCKET# CPU_HWM CORE_HWM SOCKET_HWM
---------- ---------- ---------- ---------- ---------- ----------
20 5 0 20 5 0




Давайте проведем эксеперемент

и уменьшим количество нитей гипертрединга с 4-х до 2 -х

автор
#smtctl -t 2
smtctl: SMT is now enabled. It will persist across reboots if
you run the bosboot command before the next reboot.


Посмотрим что поменялось
sqlplus
SQL> select status , count(*) from v$session group by status;

STATUS COUNT(*)
-------- ----------
INACTIVE 259
ACTIVE 85

SQL> select status , count(*) from v$session group by status;

STATUS COUNT(*)
-------- ----------
INACTIVE 259
ACTIVE 85

SQL> select
2 cpu_count as cpu#,
3 cpu_core_count as core#,
4 cpu_socket_count as socket#,
5 cpu_count_hwm as cpu_hwm,
6 cpu_core_count_hwm as core_hwm,
7 cpu_socket_count_hwm as socket_hwm
8 from sys.x$ksull
9 ;

CPU# CORE# SOCKET# CPU_HWM CORE_HWM SOCKET_HWM
---------- ---------- ---------- ---------- ---------- ----------
10 5 0 20 5 0



Количество логических процессров уменьшось до 10
А количество активных сессий выросло с 63 до 85 , при соизмеримой транзакционной нагрузке.
Нагрузка на процессор выросла за счет системной .

vmstat
vmstat 1 100

System configuration: lcpu=10 mem=49152MB

kthr memory page faults cpu
----- ----------- ------------------------ ------------ -----------
r b avm fre re pi po fr sr cy in sy cs us sy id wa
8 0 6729038 1608314 0 0 0 0 0 0 5496 41476 10857 64 18 4 14
11 0 6723127 1614223 0 0 0 0 0 0 5984 44959 12767 66 16 6 11
18 1 6730267 1607083 0 0 0 0 0 0 6209 44080 11633 62 17 6 15
17 0 6725751 1611598 0 0 0 0 0 0 7638 58715 14851 65 18 6 10
19 0 6720865 1616514 0 0 0 0 0 0 7075 64361 14603 69 21 4 6
16 0 6701669 1635678 0 0 0 0 0 0 6269 53871 12673 68 19 4 9
0 0 6713160 1606266 0 0 0 0 0 0 6811 63349 14007 67 23 4 6
26 0 6708755 1590959 0 0 0 0 0 0 6936 57282 13630 64 25 5 6
28 0 6719906 1558520 0 0 0 0 0 0 7383 50886 12322 63 26 3 8
23 0 6724961 1536441 0 0 0 0 0 0 7252 45787 13484 63 24 4 9
25 1 6706224 1538355 0 0 0 0 0 0 6627 49848 12815 65 24 4 6
15 0 6697853 1524699 0 0 0 0 0 0 5587 39734 9494 63 23 4 9
14 0 6707198 1494254 0 0 0 0 0 0 6398 54751 14011 66 24 4 6
24 0 6720230 1456873 0 0 0 0 0 0 7511 50938 13741 60 27 5 9
12 1 6727720 1429806 0 0 0 0 0 0 8095 49873 14034 61 26 3 10


Ключиевые показатели сравнения для выводов:
1 Возростание количества активных сессий .
2. Уменьшение idle CPU.


Вывод: гипертединг позволяет получить запас под пиковую производительность.


Если есть какие либо замечания, оставляете в каментах,
надеюсь на конструктивную дискуссию.

ps Я не выключал гипертрединг полностью, просто уменьшил количество нитей с 4-х до 2,
система всетаки продуктивная, а то может появиться много вопросов, на которые придется отвечать
вместо того, что бы дальше размышлять на тему оптимизации использования ресурсов.

Комментарии


  • "Теперь попробую описать окружение, где все это происходит.Есть некая система с определенным количестов ядер и БД оракл.Есть некая пользовательская нагрузка на БД."
    И HT оказывает некое воздействие на производительность.
    А надо:
    - точное указание модели CPU
    - описание версий OS, Oracle и типа нагрузки на базу (OLTP или OLAP)
    - предупреждение, что все дальнейшее описание имеет смысл только для конкректной модели процессора, операционной системы и версии Оракла
    - далее уже идет описание тестов

  • Sergei.Agalakov , Спасибо за отзыв, добавил интересующую Вас ниформацию.

    Я думаю, еще рано говорить о том, что я провел тесты на которые можно полагаться и махать флагами, я попытался формализовать мысли и метрики для тестов, получить результаты в первом приближении.

  • Покритикую. Цифры в колонках r и b

  • Покритикую. Цифры в колонках r и b в выводе vmstat обозначают следующее:

    r - количество тредов, которые могут быть поставлены диспетчером на выполнение на процессор (или уже поставлено)
    b - количество тредов, которые не могут быть поставлены диспетчером на выполнение на процессор, т.к. треды ожидают окончания какой-то блокирующей выполнение операции (обычно это синхронный ввод-вывод).

    Эти состояния треда определяются флагами в соответствующей структуре ядра (kthread_t в Solaris, что там в AIX, я не знаю) и не связаны напрямую со значением v$session.status, т.ч. говорить об активных/неактивных сессиях Oracle, рассматривая эти две колонки vmstat - некорректно.

    Тот факт, что после отключения половины тредов увеличилось потребление ядром ОС вычислительных ресурсов и одновременно выросло количество активных сессий, говорит, скорее, о том, что в ядре ОС имеется значительная в количественном смысле конкуренция за разделяемые ресурсы, индуцируемая прикладной нагрузкой (межпроцессное взаимодействие - первый кандидат). Кстати, нагрузка у Вас не очень равномерная, я бы смотрел/усреднял vmstat за бОльший период, сопоставимый с периодом генерации снапшотов в statspack/AWR.

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



Необходимо войти на сайт, чтобы оставлять комментарии