"Нас Атакуют!" Изобличи козни лукавого, запрети диаволу
Использование Interdatabase IORM планов для управления дисковыми операциями в Exadata
Консолидирование и дальнейшее объединение множества баз данных в одну кластерную систему стало почти стандартом в сегодняшних ИТ отделах. В то же время, проблема контроля и распределения общих ресурсов обретает еще большую актуальность.
Эта заметка рассматривает простой способ управления распределенными дисковыми ресурсами кластерной системы. Используется Oracle IORM - новое средство для распределения дисковых операций между множеством баз данных, объединенных на общей платформе Oracle Exadata X2.
Прежде чем мы продолжим, я хотел бы привести строки из Евангелия:
.................. == От Иоанна святое благовествование == ..................... === Глава 3, Стих 16 === 16 Ибо так возлюбил Бог мир, что отдал Сына Своего Единородного, дабы всякий верующий в Него, не погиб, но имел жизнь вечную. 17 Ибо не послал Бог Сына Своего в мир, чтобы судить мир, но чтобы мир спасен был чрез Него. 18 Верующий в Него не судится, а неверующий уже осужден, потому что не уверовал во имя Единородного Сына Божия. 19 Суд же состоит в том, что свет пришел в мир; но люди более возлюбили тьму, нежели свет, потому что дела их были злы; 20 ибо всякий, делающий злое, ненавидит свет и не идет к свету, чтобы не обличились дела его, потому что они злы, 21 а поступающий по правде идет к свету, дабы явны были дела его, потому что они в Боге соделаны.
Нечего добавить к этим строкам из Святого Писания - читай и думай сам. Прошло две недели после Пасхи, вспомним дела свои за это время - к чему они ближе, к свету или к тьме? Идешь ли ты к свету или по-старому блуждаешь во тьме? Светлый праздник Пасхи отогнал тьму от нас - так останемся же во свете пришедшего Христа и будем поступать по правде, делая наши дела в Боге - чтоб не стыдиться их позже.
Лично для вас благая весть - Единородный Сын Божий Иисус Христос любит вас, Он взошел на крест за ваши грехи, был распят и на третий день воскрес, сел одесную Бога и открыл нам дорогу в Царствие Небесное.
Покайтесь, примите Иисуса как вашего Спасителя, ибо наступают последние времена и время близко - стоит Судья у ворот.
Пожалуйста, в своих каждодневных трудах, какими бы занятыми вы себе ни казались - находите время для Бога, Его заповедей и Библии.
На главной странице этого сайта вы найдете программу для чтения Библии в командной строке - буду очень рад если программа окажется полезной. Пожалуйста, читайте Библию, на экране или в печатном виде - вы будете искренне удивлены как много там сказано лично про вас и ваши обстоятельства.
Вернемся к нашим техническим деталям.
Я предполагаю что уважаемый читатель владеет необходимыми знаниями и навыками использования Linux и Oracle, поэтому я буду очень краток. Цель этой заметки изложить простой подход к контролю дисковых ресурсов в кластере и прояснить некоторые детали.
Я также предполагаю, что в наличии имеется Oracle Exadata x2 и система уже работает в вашей серверной комнате. Обсуждаемый здесь сценарий основан на IORM, а он доступен только на Exadata.
Кратко опишем проблему.
Предположим, на нашем Exadata кластере существует множество баз данных, используемых в различных проектах. Разработчики одного из проектов используют базу данных с именем "DBA" для тестирования нового программного продукта, требующего огромного количества дисковых операций. Таким продуктом в нашем случае будет SwingBench. Иногда база данных "DBA" потребляет до 90% всех доступных IOPS системы, существенно замедляя работу другой базы с именем "DBB". Обе базы контролируются разными администраторами, каждый из которых уверен в особой значимости только его проекта. При этом все существующие базы данных используют одну общую ASM группу "DATA_X", включающую в себя все доступные физические диски.
Необходимо ограничить потребление дисковых ресурсов базой "DBA" до 1%, без вовлечения ее администратора, предоставив оставшиеся IOPS для использования базой "DBB". При этом никакие изменения на уровне дисковой организации недопустимы - все базы по-прежнему должны использовать одну общую ASM группу "DATA_X", и эта группа должна включать в себя все физические диски.
Предложим решение.
В такой постановке, задача фактически неразрешима традиционными средствами. Попытка разграничить доступ к индивидуальным дискам нарушит требование использовать всего одну ASM группу. Ограничение числа дисковых операций, доступных программе SwingBench внутри базы данных "DBA" потребует создания планов Oracle Resource Manager и вовлечения администратора. Именно в такой ситуации простое и элегантное решение может быть достигнуто с использованием IORM на уровне "ячеек" - индивидуальных Exadata Storage Servers.
Для демонстрации нашего решения, выполним следующие шаги:
DataPump будет использоваться для подготовки схемы "SOE" для нового запуска SwingBench;
так чтобы база "DBA" не могла получать более 1% от общего доступного числа IOPS;
Используя IORM план на уровне каждой индивидуальной дисковой "ячейки" Exadata, мы можем гарантировать что база "DBA" при любых условиях ее использования не получит более 1% от общего максимально доступного числа IOPS на этой "ячейке". При этом контроль за IORM планом осуществляется администратором Storage Server (root или celladmin), не требует вовлечения администратора баз данных или изменения структуры дисковых групп. Более того, IORM план может быть изменен или отключен в любой момент, на уровне одной "ячейки" или всех Exadata Storage Servers.
Используя Interdatabase IORM, администратор Exadata Storage Server может установить для каждой кластерной базы данных "потолок" на число дисковых операций в секунду (IOPS) потребляемых в сумме всеми instances этой базы с индивидуальной "ячейки".
Первый SwingBench тест, без ограничений числа IOPS
[oracle@x1 sw]$ /u01/app/11.2.0/grid/bin/crsctl status resource -w "TYPE = ora.database.type" -t -------------------------------------------------------------------------------- NAME TARGET STATE SERVER STATE_DETAILS -------------------------------------------------------------------------------- Cluster Resources -------------------------------------------------------------------------------- ora.dba.db 1 ONLINE ONLINE x1 Open 2 ONLINE ONLINE x2 Open 3 ONLINE ONLINE x3 Open 4 ONLINE ONLINE x4 Open ora.dbb.db 1 ONLINE ONLINE x1 Open 2 ONLINE ONLINE x2 Open 3 ONLINE ONLINE x3 Open 4 ONLINE ONLINE x4 Open [oracle@x1 sw]$
На данный момент, все семь "ячеек" раздают свои ресурсы без ограничений, в количестве запрашиваемом базами данных, вплоть то 100%-го истощения запаса числа дисковых операций.
[oracle@x1 bin]$ ./charbench Results will be written to results.xml. Hit Return to Start & Terminate Run... Time Users TPM TPS 2:54:25 PM 20 90766 2003
-- we have limit of 20 sessions max per one SW generator: 1 select inst_id, count(*) 2 from gv$session 3 where username = 'SOE' 4* group by inst_id 14:56:08 SQL> / INST_ID COUNT(*) ---------- ---------- 1 6 2 5 4 6 3 6 4 rows selected. Elapsed: 00:00:00.01 14:56:09 SQL>
IOPS: На уровне дисков "ячейки"
[oracle@x1 ~]$ dcli -g cell_group -l root cellcli -e "list METRICCURRENT GD_IO_RQ_W_SM_SEC, GD_IO_RQ_W_LG_SEC, GD_IO_RQ_R_SM_SEC, GD_IO_RQ_R_LG_SEC where metricObjectName like \'DATA_.*\'" | grep -v "0.0 IO/sec" c1: GD_IO_RQ_W_SM_SEC DATA_X_CD_00_c1 15.2 IO/sec -- c1: GD_IO_RQ_W_SM_SEC DATA_X_CD_01_c1 13.2 IO/sec c1: GD_IO_RQ_W_SM_SEC DATA_X_CD_02_c1 68.4 IO/sec c1: GD_IO_RQ_W_SM_SEC DATA_X_CD_03_c1 14.8 IO/sec c1: GD_IO_RQ_W_SM_SEC DATA_X_CD_04_c1 33.2 IO/sec c1: GD_IO_RQ_W_SM_SEC DATA_X_CD_05_c1 16.8 IO/sec c1: GD_IO_RQ_W_SM_SEC DATA_X_CD_06_c1 64.9 IO/sec c1: GD_IO_RQ_W_SM_SEC DATA_X_CD_07_c1 88.7 IO/sec c1: GD_IO_RQ_W_SM_SEC DATA_X_CD_08_c1 62.9 IO/sec c1: GD_IO_RQ_W_SM_SEC DATA_X_CD_09_c1 196 IO/sec c1: GD_IO_RQ_W_SM_SEC DATA_X_CD_10_c1 59.6 IO/sec c1: GD_IO_RQ_W_SM_SEC DATA_X_CD_11_c1 16.1 IO/sec -- Total: 649.8 c1: GD_IO_RQ_W_LG_SEC DATA_X_CD_03_c1 0.1 IO/sec c1: GD_IO_RQ_W_LG_SEC DATA_X_CD_06_c1 0.4 IO/sec c1: GD_IO_RQ_W_LG_SEC DATA_X_CD_10_c1 0.1 IO/sec c1: GD_IO_RQ_W_LG_SEC DATA_X_CD_11_c1 0.2 IO/sec c1: GD_IO_RQ_R_SM_SEC DATA_X_CD_02_c1 0.2 IO/sec c1: GD_IO_RQ_R_SM_SEC DATA_X_CD_03_c1 1.5 IO/sec c1: GD_IO_RQ_R_SM_SEC DATA_X_CD_05_c1 0.2 IO/sec c1: GD_IO_RQ_R_SM_SEC DATA_X_CD_07_c1 0.1 IO/sec c1: GD_IO_RQ_R_SM_SEC DATA_X_CD_08_c1 0.1 IO/sec c1: GD_IO_RQ_R_SM_SEC DATA_X_CD_09_c1 0.1 IO/sec c1: GD_IO_RQ_R_SM_SEC DATA_X_CD_10_c1 0.2 IO/sec c2: GD_IO_RQ_W_SM_SEC DATA_X_CD_00_c2 71.0 IO/sec -- c2: GD_IO_RQ_W_SM_SEC DATA_X_CD_01_c2 166 IO/sec c2: GD_IO_RQ_W_SM_SEC DATA_X_CD_02_c2 38.8 IO/sec c2: GD_IO_RQ_W_SM_SEC DATA_X_CD_03_c2 60.2 IO/sec c2: GD_IO_RQ_W_SM_SEC DATA_X_CD_04_c2 16.4 IO/sec c2: GD_IO_RQ_W_SM_SEC DATA_X_CD_05_c2 27.4 IO/sec c2: GD_IO_RQ_W_SM_SEC DATA_X_CD_06_c2 60.4 IO/sec c2: GD_IO_RQ_W_SM_SEC DATA_X_CD_07_c2 23.6 IO/sec c2: GD_IO_RQ_W_SM_SEC DATA_X_CD_08_c2 194 IO/sec c2: GD_IO_RQ_W_SM_SEC DATA_X_CD_09_c2 63.0 IO/sec c2: GD_IO_RQ_W_SM_SEC DATA_X_CD_10_c2 23.0 IO/sec c2: GD_IO_RQ_W_SM_SEC DATA_X_CD_11_c2 56.3 IO/sec -- Total: 800.1 c2: GD_IO_RQ_W_LG_SEC DATA_X_CD_01_c2 0.1 IO/sec c2: GD_IO_RQ_W_LG_SEC DATA_X_CD_04_c2 0.1 IO/sec c2: GD_IO_RQ_W_LG_SEC DATA_X_CD_05_c2 0.1 IO/sec c2: GD_IO_RQ_W_LG_SEC DATA_X_CD_07_c2 0.3 IO/sec c2: GD_IO_RQ_W_LG_SEC DATA_X_CD_08_c2 0.2 IO/sec c2: GD_IO_RQ_W_LG_SEC DATA_X_CD_09_c2 0.4 IO/sec c2: GD_IO_RQ_R_SM_SEC DATA_X_CD_00_c2 0.1 IO/sec c2: GD_IO_RQ_R_SM_SEC DATA_X_CD_03_c2 0.1 IO/sec c2: GD_IO_RQ_R_SM_SEC DATA_X_CD_06_c2 0.1 IO/sec c2: GD_IO_RQ_R_SM_SEC DATA_X_CD_07_c2 0.4 IO/sec c2: GD_IO_RQ_R_SM_SEC DATA_X_CD_09_c2 0.3 IO/sec c3: GD_IO_RQ_W_SM_SEC DATA_X_CD_00_c3 14.2 IO/sec -- c3: GD_IO_RQ_W_SM_SEC DATA_X_CD_01_c3 59.3 IO/sec c3: GD_IO_RQ_W_SM_SEC DATA_X_CD_02_c3 16.8 IO/sec c3: GD_IO_RQ_W_SM_SEC DATA_X_CD_03_c3 62.6 IO/sec c3: GD_IO_RQ_W_SM_SEC DATA_X_CD_04_c3 190 IO/sec c3: GD_IO_RQ_W_SM_SEC DATA_X_CD_05_c3 145 IO/sec c3: GD_IO_RQ_W_SM_SEC DATA_X_CD_06_c3 54.8 IO/sec c3: GD_IO_RQ_W_SM_SEC DATA_X_CD_07_c3 17.6 IO/sec c3: GD_IO_RQ_W_SM_SEC DATA_X_CD_08_c3 13.1 IO/sec c3: GD_IO_RQ_W_SM_SEC DATA_X_CD_09_c3 48.0 IO/sec c3: GD_IO_RQ_W_SM_SEC DATA_X_CD_10_c3 58.8 IO/sec c3: GD_IO_RQ_W_SM_SEC DATA_X_CD_11_c3 195 IO/sec -- Total: 875.2 c3: GD_IO_RQ_W_LG_SEC DATA_X_CD_03_c3 0.1 IO/sec c3: GD_IO_RQ_W_LG_SEC DATA_X_CD_06_c3 0.1 IO/sec c3: GD_IO_RQ_W_LG_SEC DATA_X_CD_07_c3 0.2 IO/sec c3: GD_IO_RQ_R_SM_SEC DATA_X_CD_00_c3 0.1 IO/sec c3: GD_IO_RQ_R_SM_SEC DATA_X_CD_01_c3 14.2 IO/sec c3: GD_IO_RQ_R_SM_SEC DATA_X_CD_04_c3 0.3 IO/sec c3: GD_IO_RQ_R_SM_SEC DATA_X_CD_05_c3 0.1 IO/sec c3: GD_IO_RQ_R_SM_SEC DATA_X_CD_06_c3 0.1 IO/sec c3: GD_IO_RQ_R_SM_SEC DATA_X_CD_07_c3 0.2 IO/sec c3: GD_IO_RQ_R_SM_SEC DATA_X_CD_11_c3 0.1 IO/sec c4: GD_IO_RQ_W_SM_SEC DATA_X_CD_00_c4 24.6 IO/sec -- c4: GD_IO_RQ_W_SM_SEC DATA_X_CD_01_c4 61.3 IO/sec c4: GD_IO_RQ_W_SM_SEC DATA_X_CD_02_c4 19.7 IO/sec c4: GD_IO_RQ_W_SM_SEC DATA_X_CD_03_c4 15.8 IO/sec c4: GD_IO_RQ_W_SM_SEC DATA_X_CD_04_c4 161 IO/sec c4: GD_IO_RQ_W_SM_SEC DATA_X_CD_05_c4 65.5 IO/sec c4: GD_IO_RQ_W_SM_SEC DATA_X_CD_06_c4 149 IO/sec c4: GD_IO_RQ_W_SM_SEC DATA_X_CD_07_c4 25.0 IO/sec c4: GD_IO_RQ_W_SM_SEC DATA_X_CD_08_c4 18.4 IO/sec c4: GD_IO_RQ_W_SM_SEC DATA_X_CD_09_c4 13.6 IO/sec c4: GD_IO_RQ_W_SM_SEC DATA_X_CD_10_c4 10.6 IO/sec c4: GD_IO_RQ_W_SM_SEC DATA_X_CD_11_c4 13.6 IO/sec -- Total: 578.1 c4: GD_IO_RQ_W_LG_SEC DATA_X_CD_02_c4 0.1 IO/sec c4: GD_IO_RQ_W_LG_SEC DATA_X_CD_03_c4 0.1 IO/sec c4: GD_IO_RQ_W_LG_SEC DATA_X_CD_04_c4 0.1 IO/sec c4: GD_IO_RQ_W_LG_SEC DATA_X_CD_06_c4 0.2 IO/sec c4: GD_IO_RQ_W_LG_SEC DATA_X_CD_07_c4 0.1 IO/sec c4: GD_IO_RQ_W_LG_SEC DATA_X_CD_09_c4 0.2 IO/sec c4: GD_IO_RQ_W_LG_SEC DATA_X_CD_10_c4 0.1 IO/sec c4: GD_IO_RQ_R_SM_SEC DATA_X_CD_00_c4 0.1 IO/sec c4: GD_IO_RQ_R_SM_SEC DATA_X_CD_01_c4 0.1 IO/sec c4: GD_IO_RQ_R_SM_SEC DATA_X_CD_04_c4 0.1 IO/sec c4: GD_IO_RQ_R_SM_SEC DATA_X_CD_06_c4 0.1 IO/sec c6: GD_IO_RQ_W_SM_SEC DATA_X_CD_00_c6 201 IO/sec -- c6: GD_IO_RQ_W_SM_SEC DATA_X_CD_01_c6 65.0 IO/sec c6: GD_IO_RQ_W_SM_SEC DATA_X_CD_02_c6 63.1 IO/sec c6: GD_IO_RQ_W_SM_SEC DATA_X_CD_03_c6 192 IO/sec c6: GD_IO_RQ_W_SM_SEC DATA_X_CD_04_c6 23.0 IO/sec c6: GD_IO_RQ_W_SM_SEC DATA_X_CD_05_c6 59.1 IO/sec c6: GD_IO_RQ_W_SM_SEC DATA_X_CD_06_c6 42.9 IO/sec c6: GD_IO_RQ_W_SM_SEC DATA_X_CD_07_c6 18.9 IO/sec c6: GD_IO_RQ_W_SM_SEC DATA_X_CD_08_c6 139 IO/sec c6: GD_IO_RQ_W_SM_SEC DATA_X_CD_09_c6 296 IO/sec c6: GD_IO_RQ_W_SM_SEC DATA_X_CD_10_c6 146 IO/sec c6: GD_IO_RQ_W_SM_SEC DATA_X_CD_11_c6 11.9 IO/sec -- Total: 1257.9 c6: GD_IO_RQ_W_LG_SEC DATA_X_CD_01_c6 0.2 IO/sec c6: GD_IO_RQ_W_LG_SEC DATA_X_CD_04_c6 0.1 IO/sec c6: GD_IO_RQ_W_LG_SEC DATA_X_CD_08_c6 0.1 IO/sec c6: GD_IO_RQ_R_SM_SEC DATA_X_CD_01_c6 0.2 IO/sec c6: GD_IO_RQ_R_SM_SEC DATA_X_CD_05_c6 0.1 IO/sec c6: GD_IO_RQ_R_SM_SEC DATA_X_CD_09_c6 14.2 IO/sec c6: GD_IO_RQ_R_SM_SEC DATA_X_CD_11_c6 0.1 IO/sec c7: GD_IO_RQ_W_SM_SEC DATA_X_CD_00_c7 193 IO/sec -- c7: GD_IO_RQ_W_SM_SEC DATA_X_CD_01_c7 63.1 IO/sec c7: GD_IO_RQ_W_SM_SEC DATA_X_CD_02_c7 13.5 IO/sec c7: GD_IO_RQ_W_SM_SEC DATA_X_CD_04_c7 61.7 IO/sec c7: GD_IO_RQ_W_SM_SEC DATA_X_CD_05_c7 106 IO/sec c7: GD_IO_RQ_W_SM_SEC DATA_X_CD_06_c7 23.4 IO/sec c7: GD_IO_RQ_W_SM_SEC DATA_X_CD_07_c7 146 IO/sec c7: GD_IO_RQ_W_SM_SEC DATA_X_CD_08_c7 12.4 IO/sec c7: GD_IO_RQ_W_SM_SEC DATA_X_CD_09_c7 64.5 IO/sec c7: GD_IO_RQ_W_SM_SEC DATA_X_CD_10_c7 66.5 IO/sec c7: GD_IO_RQ_W_SM_SEC DATA_X_CD_11_c7 112 IO/sec -- Total: 862.1 c7: GD_IO_RQ_W_LG_SEC DATA_X_CD_00_c7 0.1 IO/sec ===== Всего на всех дисках всех ячеек: 5023.2 c7: GD_IO_RQ_W_LG_SEC DATA_X_CD_01_c7 0.1 IO/sec c7: GD_IO_RQ_W_LG_SEC DATA_X_CD_03_c7 0.2 IO/sec c7: GD_IO_RQ_W_LG_SEC DATA_X_CD_05_c7 0.1 IO/sec c7: GD_IO_RQ_W_LG_SEC DATA_X_CD_09_c7 0.1 IO/sec c7: GD_IO_RQ_W_LG_SEC DATA_X_CD_11_c7 0.3 IO/sec c7: GD_IO_RQ_R_SM_SEC DATA_X_CD_03_c7 15.0 IO/sec c7: GD_IO_RQ_R_SM_SEC DATA_X_CD_05_c7 0.1 IO/sec c7: GD_IO_RQ_R_SM_SEC DATA_X_CD_06_c7 0.1 IO/sec c7: GD_IO_RQ_R_SM_SEC DATA_X_CD_07_c7 2.0 IO/sec c7: GD_IO_RQ_R_SM_SEC DATA_X_CD_08_c7 6.8 IO/sec c7: GD_IO_RQ_R_SM_SEC DATA_X_CD_11_c7 44.0 IO/sec [oracle@x1 ~]$
Я просуммировал число одно-блоковых записей в секунду (GD_IO_RQ_W_SM_SEC) и получил результаты для каждой "ячейки" и для всего кластера в целом. Как видно, все 7 "ячеек" производят вместе 5023.2 "одно-блоковых" записей в секунду. Это число включает запросы со всех instances всех баз данных в кластере (т.е. "DBA1"-"DBA4" и "DBB1"-"DBB4")
Данные были получены непосредственно с Exadata Storage Servers, используя "cellcli" интерфейс. Метрики с "ячейки" представляют самый нижний уровень мониторинга в Exadata. Те же самые данные можно увидеть "выше" - на уровне ASM файлов и на уровне системной статистики базы данных. Проверим это.
IOPS: На уровне дата файлов
-- check IOPS on datafile level: 1 select distinct systimestamp, sum(SMALL_WRITE_REQS) 2 from V$IOSTAT_FILE 3 where FILE_NO in (select file_no from v$asm_file 4 where GROUP_NUMBER in ( 5 select GROUP_NUMBER from v$asm_diskgroup where name = 'DATA_X') 6* ) 15:37:01 SQL> / SYSTIMESTAMP SUM(SMALL_WRITE_REQS) --------------------------------------------------------------------------- --------------------- 30-APR-11 03.37.02.575398 PM +02:00 17159759 1 row selected. Elapsed: 00:00:04.66 15:37:07 SQL> / SYSTIMESTAMP SUM(SMALL_WRITE_REQS) --------------------------------------------------------------------------- --------------------- 30-APR-11 03.37.24.325819 PM +02:00 17264966 1 row selected. Elapsed: 00:00:02.58 15:37:26 SQL> / SYSTIMESTAMP SUM(SMALL_WRITE_REQS) --------------------------------------------------------------------------- --------------------- 30-APR-11 03.37.45.434398 PM +02:00 17356286 1 row selected. Elapsed: 00:00:02.34 15:37:47 SQL> / SYSTIMESTAMP SUM(SMALL_WRITE_REQS) --------------------------------------------------------------------------- --------------------- 30-APR-11 03.37.55.635259 PM +02:00 17387751 1 row selected. Elapsed: 00:00:02.07 15:37:57 SQL> select (17387751-17159759)/53 from dual; (17387751-17159759)/53 ---------------------- 4301.73585 -- Single Block Writes per Second, зарегистрированных на уровне -- datafiles (ASM), для instance "DBA1". -- Приблизительно совпадает с метриками на Storage Servers. 1 row selected. Elapsed: 00:00:00.00 15:50:01 SQL>
Поскольку кластерное представление "GV$IOSTAT_FILE" не использовалось, 4301 IOPS представляет количество "одно-блоковых" дисковых записей только для первого instance базы данных - "DBA1".
IOPS: На уровне базы данных
-- READS from Storage Server's FlashCache select systimestamp, name, value 2 from v$sysstat 3* where name = 'physical read requests optimized' 15:17:06 SQL> / SYSTIMESTAMP --------------------------------------------------------------------------- NAME VALUE ---------------------------------------------------------------- ---------- 30-APR-11 03.17.07.842583 PM +02:00 physical read requests optimized 183254 1 row selected. Elapsed: 00:00:00.02 15:17:07 SQL> / SYSTIMESTAMP --------------------------------------------------------------------------- NAME VALUE ---------------------------------------------------------------- ---------- 30-APR-11 03.17.11.039970 PM +02:00 physical read requests optimized 183415 1 row selected. Elapsed: 00:00:00.02 15:17:11 SQL> / SYSTIMESTAMP --------------------------------------------------------------------------- NAME VALUE ---------------------------------------------------------------- ---------- 30-APR-11 03.17.20.343953 PM +02:00 physical read requests optimized 183774 1 row selected. Elapsed: 00:00:00.02 15:17:20 SQL> / SYSTIMESTAMP --------------------------------------------------------------------------- NAME VALUE ---------------------------------------------------------------- ---------- 30-APR-11 03.17.35.201467 PM +02:00 physical read requests optimized 184332 1 row selected. Elapsed: 00:00:00.01 15:17:35 SQL> select (184332-183254)/28 from dual; (184332-183254)/28 ------------------ 38.5 -- optimized reads from FlashCache per second 1 row selected. Elapsed: 00:00:00.00 15:18:17 SQL>
Статистика "physical read requests optimized" показывает сколько дисковых операций (чтение) было выполнено из FlashCache на "ячейках", без обращения к физическим дискам. (Также эта статистика имеет отношение к Exadata Storage Index, но мы проигнорируем этот факт)
Теперь взглянем на операции записи (на уровне одного instance базы данных) и сравним их с метриками, полученными непосредственно с "ячеек" выше.
Документация ("Oracle Database Reference 11g Release 2 (11.2)") говорит, что: "physical write total IO requests" - Number of write requests which wrote one or more database blocks from all instance activity including application activity, backup and recovery, and other utilities. The difference between this stat and "physical write total multi block requests" gives the number of single block write requests. То есть, вычитая число "многоблоковых" записей из общего числа всех дисковых записей, мы получим количество "одноблоковых" дисковых операций записи, что нам и необходимо для сравнения с "GD_IO_RQ_W_SM_SEC" на "ячейках":
-- WRITE IOPS on database level, for Single Block
1 select systimestamp, name, value
2 from v$sysstat
3 where name in ('physical write total IO requests',
4 'physical write total multi block requests')
5* order by name
15:27:32 SQL> /
SYSTIMESTAMP
---------------------------------------------------------------------------
NAME VALUE
---------------------------------------------------------------- ----------
30-APR-11 03.27.34.081032 PM +02:00
physical write total IO requests 14571759
30-APR-11 03.27.34.081032 PM +02:00
physical write total multi block requests 19890
2 rows selected.
Elapsed: 00:00:00.02
15:27:34 SQL> /
SYSTIMESTAMP
---------------------------------------------------------------------------
NAME VALUE
---------------------------------------------------------------- ----------
30-APR-11 03.27.38.767172 PM +02:00
physical write total IO requests 14590961
30-APR-11 03.27.38.767172 PM +02:00
physical write total multi block requests 19912
2 rows selected.
Elapsed: 00:00:00.02
15:27:38 SQL> /
SYSTIMESTAMP
---------------------------------------------------------------------------
NAME VALUE
---------------------------------------------------------------- ----------
30-APR-11 03.27.57.362925 PM +02:00
physical write total IO requests 14680257
30-APR-11 03.27.57.362925 PM +02:00
physical write total multi block requests 20018
2 rows selected.
Elapsed: 00:00:00.02
15:27:57 SQL> /
SYSTIMESTAMP
---------------------------------------------------------------------------
NAME VALUE
---------------------------------------------------------------- ----------
30-APR-11 03.28.06.042151 PM +02:00
physical write total IO requests 14718630
30-APR-11 03.28.06.042151 PM +02:00
physical write total multi block requests 20063
2 rows selected.
Elapsed: 00:00:00.02
15:28:06 SQL> select (14718630-14571759)-(20063-19890) from dual;
(14718630-14571759)-(20063-19890)
---------------------------------
146698
1 row selected.
Elapsed: 00:00:00.00
15:28:50 SQL> select 146698/32 from dual;
146698/32
----------
4584.3125 -- Single block writes per second
1 row selected.
Elapsed: 00:00:00.00
15:29:37 SQL>
Учитывая что это число (4584 IOPS) "одноблоковых" записей в секунду только на первом instance базы "DBA", где SwingBench производит большинство транзакций - можно сказать что показания на уровнях системной статистики базы данных, ASM datafiles и метрик Exadata Storage Servers приблизительно совпадают.
Изучим содержание последнего xml файла: -rw-r--r-- 1 oracle oinstall 2.8K Apr 30 15:37 results00002.xml <Results> <Overview> <BenchmarkName>Order Entry (jdbc)</BenchmarkName> <Comment>"Simple Order Entry benchmark using client side jdbc calls"</Comment> <TimeOfRun>Apr 30, 2011 2:33:30 PM</TimeOfRun> <TotalRunTime>1:04:22</TotalRunTime> ----- 1 час <TotalLogonTime>0:00:00</TotalLogonTime> <TotalCompletedTransactions>5997206</TotalCompletedTransactions> <TotalFailedTransactions>173</TotalFailedTransactions> <AverageTransactionsPerSecond>1552.88</AverageTransactionsPerSecond> ---- 1500 TPS <MaximumTransactionRate>104545</MaximumTransactionRate> </Overview> <Configuration> <NumberOfUsers>20</NumberOfUsers> <MinimumThinkTime>0</MinimumThinkTime> <MaximumThinkTime>0</MaximumThinkTime> <ConnectString>//x-scan:1521/DBA</ConnectString> <TimingsIn>miliseconds</TimingsIn> </Configuration> <DMLResults> ---- Transactions volumes <SelectStatements>30322078</SelectStatements> <InsertStatements>10143597</InsertStatements> <UpdateStatements>6216603</UpdateStatements> <DeleteStatements>0</DeleteStatements> <CommitStatements>7632602</CommitStatements> <RollbackStatements>0</RollbackStatements> </DMLResults> <TransactionResults> <Result id="Customer Registration"> <AverageResponse>5</AverageResponse> <MinimumResponse>1</MinimumResponse> <MaximumResponse>2973</MaximumResponse> <TransactionCount>544101</TransactionCount> <FailedTransactionCount>0</FailedTransactionCount> </Result> <Result id="Browse Products"> <AverageResponse>10</AverageResponse> <MinimumResponse>1</MinimumResponse> <MaximumResponse>3040</MaximumResponse> <TransactionCount>1527349</TransactionCount> <FailedTransactionCount>0</FailedTransactionCount> </Result> <Result id="Order Products"> <AverageResponse>33</AverageResponse> <MinimumResponse>6</MinimumResponse> <MaximumResponse>3225</MaximumResponse> <TransactionCount>1091122</TransactionCount> <FailedTransactionCount>173</FailedTransactionCount> </Result> <Result id="Process Orders"> <AverageResponse>9</AverageResponse> <MinimumResponse>1</MinimumResponse> <MaximumResponse>3122</MaximumResponse> <TransactionCount>1307243</TransactionCount> <FailedTransactionCount>0</FailedTransactionCount> </Result> <Result id="Browse Orders"> <AverageResponse>3</AverageResponse> <MinimumResponse>1</MinimumResponse> <MaximumResponse>3180</MaximumResponse> <TransactionCount>1527391</TransactionCount> <FailedTransactionCount>0</FailedTransactionCount> </Result> </TransactionResults> </Results>
Результат первого SwingBench теста: Все вместе наши 20 пользователей производили около 1500 транзакций в секунду, со средним временем отклика 12 миллисекунд. При этом все "ячейки" обеспечивали около 5000 дисковых операций в секунду (IOPS). Первый узел кластера генерировал приблизительно 50% общего числа транзакций, согласно сравнению статистики использования ресурсов процессора на всех узлах кластера.
Первый DataPump import тест, без ограничений
После проведения предыдущего теста, большое количество новых записей было добавлено в таблицы базовой схемы SwingBench (SOE). Перед следующим SwingBench тестом все эти записи надо удалить, чтобы оба теста начинали свою работу в совершенно одинаковых условиях. Самый простой способ привести схему SOE в ее начальное состояние - удалить ее полностью и загрузить заново с помощью DataPump, используя заранее подготовленный "эталонный" dump file.
На каждой "ячейке" план определяет "потолок" в 1% от максимального числа дисковых операций для базы "DBA", и 99% для всех остальных баз. Директива "low_latency" рекомендована для использования в OLTP системах (с которой мы и имеем дело) - эта директива планирует дисковые запросы так, что каждый из них выполняется как можно быстрее.
Команда "cellcli" используется только на Exadata Storage Servers, в отличие от "dcli", используемой чаще всего на узлах кластера.
-------------------- Проверка IORM планов ---------------------------- -- Эти метрики будут использованы: CellCLI> list METRICDEFINITION DB_IO_UTIL_LG, DB_IO_UTIL_SM detail name: DB_IO_UTIL_LG description: "Percentage of disk resources utilized by large requests from this database" -- "много-блоковые" дисковые операции, утилизация в % для каждой кластерной базы metricType: Instantaneous objectType: IORM_DATABASE unit: % name: DB_IO_UTIL_SM description: "Percentage of disk resources utilized by small requests from this database" -- "одно-блоковые" дисковые операции, утилизация в % для каждой кластерной базы metricType: Instantaneous objectType: IORM_DATABASE unit: % CellCLI> -- Подготовим план для использования в будущем, но пока не будем активировать его. [oracle@x1 ~]$ dcli -g cell_group -l root cellcli -e "alter iormplan objective=\'low_latency\'\, dbPlan=\(\(name=\'DBA\',limit=1\),\(name=other,limit=99\)\)" c1: IORMPLAN successfully altered c2: IORMPLAN successfully altered c3: IORMPLAN successfully altered c4: IORMPLAN successfully altered c5: IORMPLAN successfully altered c6: IORMPLAN successfully altered c7: IORMPLAN successfully altered [oracle@x1 ~]$ -- План создан на каждой "ячейке" -- Убедимся что IORM планы не используются: [oracle@x1 ~]$ dcli -g cell_group -l root cellcli -e "list iormplan" c1: c1_IORMPLAN inactive c2: c2_IORMPLAN inactive c3: c3_IORMPLAN inactive c4: c4_IORMPLAN inactive c5: c5_IORMPLAN inactive c6: c6_IORMPLAN inactive c7: c7_IORMPLAN inactive [oracle@x1 ~]$
-- Все IORM метрики должны показывать нули: [oracle@x1 ~]$ dcli -g cell_group -l root cellcli -e "LIST METRICCURRENT DB_IO_UTIL_LG, DB_IO_UTIL_SM, DB_IO_WT_SM_RQ, DB_IO_WT_LG_RQ ATTRIBUTES name, metricObjectName, metricValue where metricObjectName=\'DBA\';" c1: DB_IO_UTIL_LG DBA 0 % -- "много-блоковые" дисковые операции c1: DB_IO_UTIL_SM DBA 0 % -- "одно-блоковые" дисковые операции c1: DB_IO_WT_SM_RQ DBA 0.0 ms/request -- "одно-блоковая" запись c1: DB_IO_WT_LG_RQ DBA 0.0 ms/request -- "много-блоковая" запись c2: DB_IO_UTIL_LG DBA 0 % c2: DB_IO_UTIL_SM DBA 0 % c2: DB_IO_WT_SM_RQ DBA 0.0 ms/request c2: DB_IO_WT_LG_RQ DBA 0.0 ms/request c3: DB_IO_UTIL_LG DBA 0 % c3: DB_IO_UTIL_SM DBA 0 % c3: DB_IO_WT_SM_RQ DBA 0.0 ms/request c3: DB_IO_WT_LG_RQ DBA 0.0 ms/request c4: DB_IO_UTIL_LG DBA 0 % c4: DB_IO_UTIL_SM DBA 0 % c4: DB_IO_WT_SM_RQ DBA 0.0 ms/request c4: DB_IO_WT_LG_RQ DBA 0.0 ms/request c5: DB_IO_UTIL_LG DBA 0 % c5: DB_IO_UTIL_SM DBA 0 % c5: DB_IO_WT_SM_RQ DBA 0.0 ms/request c5: DB_IO_WT_LG_RQ DBA 0.0 ms/request c6: DB_IO_UTIL_LG DBA 0 % c6: DB_IO_UTIL_SM DBA 0 % c6: DB_IO_WT_SM_RQ DBA 0.0 ms/request c6: DB_IO_WT_LG_RQ DBA 0.0 ms/request c7: DB_IO_UTIL_LG DBA 0 % c7: DB_IO_UTIL_SM DBA 0 % c7: DB_IO_WT_SM_RQ DBA 0.0 ms/request c7: DB_IO_WT_LG_RQ DBA 0.0 ms/request [oracle@x1 ~]$
[oracle@x1 ~]$ dcli -g cell_group -l root cellcli -e "LIST METRICCURRENT IORM_MODE;" c1: IORM_MODE c1 0 c2: IORM_MODE c2 0 c3: IORM_MODE c3 0 c4: IORM_MODE c4 0 c5: IORM_MODE c5 0 c6: IORM_MODE c6 0 c7: IORM_MODE c7 0 [oracle@x1 ~]$ (For IORM_MODE: 1 means the cell IORM objective was set to low_latency. 2 means the cell IORM objective was set to balanced. 3 means the cell IORM objective was set to high_throughput. A value in between 1-2 or 2-3 indicates the IORM objective was not the same throughout the metric period, and the value indicates proximity to a given objective. It is also indicative of a constantly-changing mix of workloads. )
-- Test DataPump import: Import: Release 11.2.0.2.0 - Production on Sun May 1 12:11:30 2011 ... Processing object type SCHEMA_EXPORT/TABLE/TABLE_DATA . . imported "SOE"."ORDER_ITEMS":"SYS_P181" 90.47 MB 4193090 rows . . imported "SOE"."ORDER_ITEMS":"SYS_P193" 90.34 MB 4187121 rows . . imported "SOE"."ORDER_ITEMS":"SYS_P185" 90.63 MB 4200389 rows ... . . imported "SOE"."PRODUCT_INFORMATION" 72.67 KB 288 rows . . imported "SOE"."WAREHOUSES" 11.78 KB 191 rows Processing object type SCHEMA_EXPORT/TABLE/INDEX/INDEX Completed 22 INDEX objects in 98 seconds -- запомним это значение ... Job "SYS"."SYS_IMPORT_SCHEMA_03" completed with 2 error(s) at 12:14:36 -- Запомним это значение, весь процесс импорта занял 3 min 6 sec
Запомним время затраченное на создание индексов и время выполнения всего процесса, для сравнения с последующим DataPump тестом.
Активация IORM плана на каждой "ячейке"
Как мы помним, одинаковые IORM планы были созданы на всех "ячейках".
-------------------- Активируем IORM план на всех "ячейках" ---------------- [oracle@x1 ~]$ dcli -g cell_group -l root cellcli -e "alter iormplan active" c1: IORMPLAN successfully altered c2: IORMPLAN successfully altered c3: IORMPLAN successfully altered c4: IORMPLAN successfully altered c5: IORMPLAN successfully altered c6: IORMPLAN successfully altered c7: IORMPLAN successfully altered [oracle@x1 ~]$ dcli -g cell_group -l root cellcli -e "list iormplan" c1: c1_IORMPLAN active c2: c2_IORMPLAN active c3: c3_IORMPLAN active c4: c4_IORMPLAN active c5: c5_IORMPLAN active c6: c6_IORMPLAN active c7: c7_IORMPLAN active
С этого момента абсолютно все дисковые запросы от базы "DBM" будут регистрироваться и становиться в очередь, как только их общая сумма превысит 1% от максимального числа IOPS.
Второй DataPump import тест, с ограниченным числом IOPS
Теперь повторим наш предыдущий импорт схемы "SOE". При этом ожидается что ячейки будут ограничивать количество дисковых операций от базы "DBA", увеличивая длительность создания индексов и всего импорта.
-- IORM Data Pump test: Import: Release 11.2.0.2.0 - Production on Sun May 1 12:21:45 2011 ... . . imported "SOE"."ORDER_ITEMS":"SYS_P181" 90.47 MB 4193090 rows . . imported "SOE"."ORDER_ITEMS":"SYS_P185" 90.63 MB 4200389 rows . . imported "SOE"."ORDER_ITEMS":"SYS_P193" 90.34 MB 4187121 rows ... . . imported "SOE"."PRODUCT_DESCRIPTIONS" 86.67 KB 288 rows . . imported "SOE"."PRODUCT_INFORMATION" 72.67 KB 288 rows . . imported "SOE"."WAREHOUSES" 11.78 KB 191 rows Processing object type SCHEMA_EXPORT/TABLE/INDEX/INDEX Completed 22 INDEX objects in 441 seconds -- было 98 sec ... Job "SYS"."SYS_IMPORT_SCHEMA_03" completed with 2 error(s) at 12:30:35 -- 8 min 50 sec
Как видно, создание индексов заняло в 5 раз дольше и длительность всего импорта возросла в 3 раза. Тем не менее, мы не нагрузили систему достаточно, чтобы увидеть изменения в % IO utilization:
Во время импорта я периодически выполнял такую команду: [oracle@x1 ~]$ dcli -g cell_group -l root cellcli -e "LIST METRICCURRENT DB_IO_UTIL_LG, DB_IO_UTIL_SM, DB_IO_WT_SM_RQ, DB_IO_WT_LG_RQ ATTRIBUTES name, metricObjectName, metricValue where metricObjectName=\'DBA\';" c1: DB_IO_UTIL_LG DBA 0 % c1: DB_IO_UTIL_SM DBA 0 % c1: DB_IO_WT_SM_RQ DBA 4.8 ms/request c1: DB_IO_WT_LG_RQ DBA 0.0 ms/request c2: DB_IO_UTIL_LG DBA 0 % c2: DB_IO_UTIL_SM DBA 0 % c2: DB_IO_WT_SM_RQ DBA 0.0 ms/request c2: DB_IO_WT_LG_RQ DBA 0.0 ms/request c3: DB_IO_UTIL_LG DBA 0 % c3: DB_IO_UTIL_SM DBA 0 % c3: DB_IO_WT_SM_RQ DBA 24.5 ms/request c3: DB_IO_WT_LG_RQ DBA 0.0 ms/request c4: DB_IO_UTIL_LG DBA 0 % c4: DB_IO_UTIL_SM DBA 0 % c4: DB_IO_WT_SM_RQ DBA 0.0 ms/request c4: DB_IO_WT_LG_RQ DBA 0.0 ms/request c5: DB_IO_UTIL_LG DBA 0 % c5: DB_IO_UTIL_SM DBA 0 % c5: DB_IO_WT_SM_RQ DBA 0.0 ms/request c5: DB_IO_WT_LG_RQ DBA 0.0 ms/request c6: DB_IO_UTIL_LG DBA 0 % c6: DB_IO_UTIL_SM DBA 0 % c6: DB_IO_WT_SM_RQ DBA 0.0 ms/request c6: DB_IO_WT_LG_RQ DBA 0.0 ms/request c7: DB_IO_UTIL_LG DBA 0 % c7: DB_IO_UTIL_SM DBA 0 % c7: DB_IO_WT_SM_RQ DBA 180 ms/request c7: DB_IO_WT_LG_RQ DBA 87.8 ms/request [oracle@x1 ~]$ dcli -g cell_group -l root cellcli -e "LIST METRICCURRENT DB_IO_UTIL_LG, DB_IO_UTIL_SM, DB_IO_WT_SM_RQ, DB_IO_WT_LG_RQ ATTRIBUTES name, metricObjectName, metricValue where metricObjectName=\'DBA\';" c1: DB_IO_UTIL_LG DBA 0 % c1: DB_IO_UTIL_SM DBA 0 % c1: DB_IO_WT_SM_RQ DBA 0.0 ms/request c1: DB_IO_WT_LG_RQ DBA 0.0 ms/request c2: DB_IO_UTIL_LG DBA 0 % c2: DB_IO_UTIL_SM DBA 0 % c2: DB_IO_WT_SM_RQ DBA 39.0 ms/request c2: DB_IO_WT_LG_RQ DBA 44.1 ms/request c3: DB_IO_UTIL_LG DBA 0 % c3: DB_IO_UTIL_SM DBA 0 % c3: DB_IO_WT_SM_RQ DBA 15.5 ms/request c3: DB_IO_WT_LG_RQ DBA 0.0 ms/request c4: DB_IO_UTIL_LG DBA 0 % c4: DB_IO_UTIL_SM DBA 0 % c4: DB_IO_WT_SM_RQ DBA 11.5 ms/request c4: DB_IO_WT_LG_RQ DBA 37.3 ms/request c5: DB_IO_UTIL_LG DBA 0 % c5: DB_IO_UTIL_SM DBA 0 % c5: DB_IO_WT_SM_RQ DBA 0.0 ms/request c5: DB_IO_WT_LG_RQ DBA 0.0 ms/request c6: DB_IO_UTIL_LG DBA 0 % c6: DB_IO_UTIL_SM DBA 0 % c6: DB_IO_WT_SM_RQ DBA 0.0 ms/request c6: DB_IO_WT_LG_RQ DBA 0.0 ms/request c7: DB_IO_UTIL_LG DBA 0 % c7: DB_IO_UTIL_SM DBA 0 % c7: DB_IO_WT_SM_RQ DBA 118 ms/request c7: DB_IO_WT_LG_RQ DBA 103 ms/request [oracle@x1 ~]$ dcli -g cell_group -l root cellcli -e "LIST METRICCURRENT DB_IO_UTIL_LG, DB_IO_UTIL_SM, DB_IO_WT_SM_RQ, DB_IO_WT_LG_RQ ATTRIBUTES name, metricObjectName, metricValue where metricObjectName=\'DBA\';" c1: DB_IO_UTIL_LG DBA 0 % c1: DB_IO_UTIL_SM DBA 0 % c1: DB_IO_WT_SM_RQ DBA 0.0 ms/request c1: DB_IO_WT_LG_RQ DBA 0.0 ms/request c2: DB_IO_UTIL_LG DBA 0 % c2: DB_IO_UTIL_SM DBA 0 % c2: DB_IO_WT_SM_RQ DBA 0.0 ms/request c2: DB_IO_WT_LG_RQ DBA 1.7 ms/request c3: DB_IO_UTIL_LG DBA 0 % c3: DB_IO_UTIL_SM DBA 0 % c3: DB_IO_WT_SM_RQ DBA 0.0 ms/request c3: DB_IO_WT_LG_RQ DBA 0.0 ms/request c4: DB_IO_UTIL_LG DBA 0 % c4: DB_IO_UTIL_SM DBA 0 % c4: DB_IO_WT_SM_RQ DBA 44.9 ms/request c4: DB_IO_WT_LG_RQ DBA 0.0 ms/request c5: DB_IO_UTIL_LG DBA 0 % c5: DB_IO_UTIL_SM DBA 0 % c5: DB_IO_WT_SM_RQ DBA 0.0 ms/request c5: DB_IO_WT_LG_RQ DBA 0.0 ms/request c6: DB_IO_UTIL_LG DBA 0 % c6: DB_IO_UTIL_SM DBA 0 % c6: DB_IO_WT_SM_RQ DBA 0.0 ms/request c6: DB_IO_WT_LG_RQ DBA 0.0 ms/request c7: DB_IO_UTIL_LG DBA 0 % c7: DB_IO_UTIL_SM DBA 0 % c7: DB_IO_WT_SM_RQ DBA 157 ms/request -- !!!!! запрос явно был поставлен в очередь c7: DB_IO_WT_LG_RQ DBA 162 ms/request -- !!!!! [oracle@x1 ~]$
Выполним еще один, последний, SwingBench тест в надежде нагрузить систему достаточно до 1% от максимального числа дисковых операций.
Второй SwingBench тест, с ограниченным числом IOPS
Планы на ячейках по-прежнему активны, схема "SOE" создана заново и заполнена "эталонными" данными.
-- Start SwingBench [oracle@x1 bin]$ ./charbench Version : 2.3.0.422 Results will be written to results.xml. Hit Return to Start & Terminate Run... Time Users TPM TPS 12:46:31 PM 20 22820 245
[oracle@x1 ~]$ dcli -g cell_group -l root cellcli -e "LIST METRICCURRENT DB_IO_UTIL_LG, DB_IO_UTIL_SM, DB_IO_WT_SM_RQ, DB_IO_WT_LG_RQ ATTRIBUTES name, metricObjectName, metricValue where metricObjectName=\'DBA\';" c1: DB_IO_UTIL_LG DBA 0 % c1: DB_IO_UTIL_SM DBA 1 % -- !!!! "потолок" достигнут c1: DB_IO_WT_SM_RQ DBA 0.0 ms/request c1: DB_IO_WT_LG_RQ DBA 0.0 ms/request c2: DB_IO_UTIL_LG DBA 0 % c2: DB_IO_UTIL_SM DBA 0 % c2: DB_IO_WT_SM_RQ DBA 19.2 ms/request c2: DB_IO_WT_LG_RQ DBA 149 ms/request c3: DB_IO_UTIL_LG DBA 0 % c3: DB_IO_UTIL_SM DBA 0 % c3: DB_IO_WT_SM_RQ DBA 42.4 ms/request -- !!!! Single block write ... c3: DB_IO_WT_LG_RQ DBA 301 ms/request -- ... and multiblock write c4: DB_IO_UTIL_LG DBA 0 % c4: DB_IO_UTIL_SM DBA 0 % c4: DB_IO_WT_SM_RQ DBA 36.4 ms/request c4: DB_IO_WT_LG_RQ DBA 126 ms/request c5: DB_IO_UTIL_LG DBA 0 % c5: DB_IO_UTIL_SM DBA 0 % c5: DB_IO_WT_SM_RQ DBA 0.0 ms/request c5: DB_IO_WT_LG_RQ DBA 0.0 ms/request c6: DB_IO_UTIL_LG DBA 0 % c6: DB_IO_UTIL_SM DBA 0 % c6: DB_IO_WT_SM_RQ DBA 0.0 ms/request c6: DB_IO_WT_LG_RQ DBA 0.0 ms/request c7: DB_IO_UTIL_LG DBA 0 % c7: DB_IO_UTIL_SM DBA 0 % c7: DB_IO_WT_SM_RQ DBA 0.0 ms/request c7: DB_IO_WT_LG_RQ DBA 0.0 ms/request [oracle@x1 ~]$ [oracle@x1 ~]$ dcli -g cell_group -l root cellcli -e "LIST METRICCURRENT DB_IO_UTIL_LG, DB_IO_UTIL_SM, DB_IO_WT_SM_RQ, DB_IO_WT_LG_RQ ATTRIBUTES name, metricObjectName, metricValue where metricObjectName=\'DBA\';" c1: DB_IO_UTIL_LG DBA 0 % c1: DB_IO_UTIL_SM DBA 1 % c1: DB_IO_WT_SM_RQ DBA 27.8 ms/request c1: DB_IO_WT_LG_RQ DBA 65.0 ms/request c2: DB_IO_UTIL_LG DBA 0 % c2: DB_IO_UTIL_SM DBA 0 % c2: DB_IO_WT_SM_RQ DBA 0.0 ms/request c2: DB_IO_WT_LG_RQ DBA 0.0 ms/request c3: DB_IO_UTIL_LG DBA 0 % c3: DB_IO_UTIL_SM DBA 1 % c3: DB_IO_WT_SM_RQ DBA 18.4 ms/request c3: DB_IO_WT_LG_RQ DBA 272 ms/request c4: DB_IO_UTIL_LG DBA 0 % c4: DB_IO_UTIL_SM DBA 0 % c4: DB_IO_WT_SM_RQ DBA 18.8 ms/request c4: DB_IO_WT_LG_RQ DBA 84.1 ms/request c5: DB_IO_UTIL_LG DBA 0 % c5: DB_IO_UTIL_SM DBA 0 % c5: DB_IO_WT_SM_RQ DBA 0.0 ms/request c5: DB_IO_WT_LG_RQ DBA 0.0 ms/request c6: DB_IO_UTIL_LG DBA 0 % c6: DB_IO_UTIL_SM DBA 1 % c6: DB_IO_WT_SM_RQ DBA 0.0 ms/request c6: DB_IO_WT_LG_RQ DBA 0.0 ms/request c7: DB_IO_UTIL_LG DBA 0 % c7: DB_IO_UTIL_SM DBA 1 % c7: DB_IO_WT_SM_RQ DBA 8.1 ms/request c7: DB_IO_WT_LG_RQ DBA 39.8 ms/request [oracle@x1 ~]$ [oracle@x1 ~]$ dcli -g cell_group -l root cellcli -e "LIST METRICCURRENT DB_IO_UTIL_LG, DB_IO_UTIL_SM, DB_IO_WT_SM_RQ, DB_IO_WT_LG_RQ ATTRIBUTES name, metricObjectName, metricValue where metricObjectName=\'DBA\';" c1: DB_IO_UTIL_LG DBA 0 % c1: DB_IO_UTIL_SM DBA 1 % -- !!!! c1: DB_IO_WT_SM_RQ DBA 1.7 ms/request c1: DB_IO_WT_LG_RQ DBA 79.4 ms/request c2: DB_IO_UTIL_LG DBA 0 % c2: DB_IO_UTIL_SM DBA 1 % -- !!!! c2: DB_IO_WT_SM_RQ DBA 0.0 ms/request c2: DB_IO_WT_LG_RQ DBA 0.0 ms/request c3: DB_IO_UTIL_LG DBA 0 % c3: DB_IO_UTIL_SM DBA 1 % -- !!!! c3: DB_IO_WT_SM_RQ DBA 8.9 ms/request c3: DB_IO_WT_LG_RQ DBA 134 ms/request c4: DB_IO_UTIL_LG DBA 0 % c4: DB_IO_UTIL_SM DBA 1 % -- !!!! c4: DB_IO_WT_SM_RQ DBA 1.9 ms/request c4: DB_IO_WT_LG_RQ DBA 20.8 ms/request c5: DB_IO_UTIL_LG DBA 0 % c5: DB_IO_UTIL_SM DBA 0 % c5: DB_IO_WT_SM_RQ DBA 0.0 ms/request c5: DB_IO_WT_LG_RQ DBA 0.0 ms/request c6: DB_IO_UTIL_LG DBA 0 % c6: DB_IO_UTIL_SM DBA 1 % -- !!!! c6: DB_IO_WT_SM_RQ DBA 0.0 ms/request c6: DB_IO_WT_LG_RQ DBA 0.0 ms/request c7: DB_IO_UTIL_LG DBA 0 % c7: DB_IO_UTIL_SM DBA 1 % -- !!!! c7: DB_IO_WT_SM_RQ DBA 0.0 ms/request c7: DB_IO_WT_LG_RQ DBA 0.0 ms/request [oracle@x1 ~]$
-- Check the overall Small Block IOPS on all cells:
[oracle@x1 ~]$ dcli -g cell_group -l root cellcli -e "list METRICCURRENT GD_IO_RQ_W_SM_SEC
where metricObjectName like \'DATA_.*\'" | grep -v "0.0 IO/sec" |
awk '{x=x+ $4} END{print "Total Single block write IOPS:",x}'
Total Single block write IOPS: 3094.8
[oracle@x1 ~]$
-- On each of the instances, run this and calculate: 13:11:36 SQL> select distinct systimestamp, sum(SMALL_WRITE_REQS) from V$IOSTAT_FILE where FILE_NO in (select file_no from v$asm_file where GROUP_NUMBER in ( select GROUP_NUMBER from v$asm_diskgroup where name = 'DATA_X') ) 13:11:41 SQL> SYSTIMESTAMP SUM(SMALL_WRITE_REQS) --------------------------------------------------------------------------- --------------------- 01-MAY-11 01.11.44.002381 PM +02:00 2362057 1 row selected. Elapsed: 00:00:02.53 13:11:46 SQL> / SYSTIMESTAMP SUM(SMALL_WRITE_REQS) --------------------------------------------------------------------------- --------------------- 01-MAY-11 01.11.50.377955 PM +02:00 2372665 1 row selected. -- This instance (#2) makes 1768 IOPS for single block writes (2372665-2362057)/6). -- Instance #3 makes 604 IOPS, instance #4 makes 751 IOPS. -- There are no swingbench session connected to instance #1: 13:12:06 SQL> select inst_id, count(*) 13:14:19 2 from gv$session 13:14:23 3 where username = 'SOE' 13:14:31 4 group by inst_id; INST_ID COUNT(*) ---------- ---------- 2 7 4 7 3 6 3 rows selected. Elapsed: 00:00:00.01
Как видно, все 20 сессий SwingBench (и все IOPS, потребляемые нашим тестом) распределились между instances 2,3 и 4.
-- Finish SwingBench and check:
-- IOPS on the cells:
[oracle@x1 ~]$ dcli -g cell_group -l root cellcli -e "list METRICCURRENT
GD_IO_RQ_W_SM_SEC where metricObjectName like \'DATA_.*\'" | grep -v "0.0
IO/sec" | awk '{x=x+ $4} END{print "Total Single block write IOPS:",x}'
Total Single block write IOPS: 3.5
Очевидно, что почти все IOPS были результатом работы генератора нагрузки. Обратите внимание, что я рассматриваю только "одно-блоковые" дисковые запросы на запись, поскольку первый тест показал значительное превосходство их числа над всеми другими типами IO.
-- SwingBench result file: -rw-r--r-- 1 oracle oinstall 2.8K May 1 13:20 results00006.xml [oracle@x1 bin]$ cat results00006.xml <Results> <Overview> <BenchmarkName>Order Entry (jdbc)</BenchmarkName> <Comment>"Simple Order Entry benchmark using client side jdbc calls"</Comment> <TimeOfRun>May 1, 2011 12:45:55 PM</TimeOfRun> <TotalRunTime>0:34:34</TotalRunTime> <TotalLogonTime>0:00:00</TotalLogonTime> <TotalCompletedTransactions>1709279</TotalCompletedTransactions> <TotalFailedTransactions>43</TotalFailedTransactions> <AverageTransactionsPerSecond>824.15</AverageTransactionsPerSecond> <MaximumTransactionRate>54720</MaximumTransactionRate> </Overview> <Configuration> <NumberOfUsers>20</NumberOfUsers> <MinimumThinkTime>0</MinimumThinkTime> <MaximumThinkTime>0</MaximumThinkTime> <ConnectString>//x-scan:1521/DBA</ConnectString> <TimingsIn>miliseconds</TimingsIn> </Configuration> <DMLResults> <SelectStatements>8643481</SelectStatements> <InsertStatements>2892938</InsertStatements> <UpdateStatements>1772581</UpdateStatements> <DeleteStatements>0</DeleteStatements> <CommitStatements>2175916</CommitStatements> <RollbackStatements>0</RollbackStatements> </DMLResults> <TransactionResults> <Result id="Customer Registration"> <AverageResponse>11</AverageResponse> <MinimumResponse>2</MinimumResponse> <MaximumResponse>9816</MaximumResponse> <TransactionCount>155277</TransactionCount> <FailedTransactionCount>0</FailedTransactionCount> </Result> <Result id="Browse Products"> <AverageResponse>24</AverageResponse> <MinimumResponse>3</MinimumResponse> <MaximumResponse>5271</MaximumResponse> <TransactionCount>434885</TransactionCount> <FailedTransactionCount>0</FailedTransactionCount> </Result> <Result id="Order Products"> <AverageResponse>60</AverageResponse> <MinimumResponse>10</MinimumResponse> <MaximumResponse>12640</MaximumResponse> <TransactionCount>311317</TransactionCount> <FailedTransactionCount>43</FailedTransactionCount> </Result> <Result id="Process Orders"> <AverageResponse>9</AverageResponse> <MinimumResponse>1</MinimumResponse> <MaximumResponse>6499</MaximumResponse> <TransactionCount>372121</TransactionCount> <FailedTransactionCount>0</FailedTransactionCount> </Result> <Result id="Browse Orders"> <AverageResponse>12</AverageResponse> <MinimumResponse>1</MinimumResponse> <MaximumResponse>18717</MaximumResponse> <TransactionCount>435679</TransactionCount> <FailedTransactionCount>0</FailedTransactionCount> </Result> </TransactionResults> </Results> [oracle@x1 bin]$
Результат второго SwingBench теста
Для сравнения, приведу тут же результаты первого SwingBench теста, без IORM:
Результат налицо - мы решили поставленную задачу по ограничению числа дисковых операций для базы данных "DBA", не изменяя раскладки дисковой системы и без вовлечения ее администратора.
Деактивация IORM плана на каждой "ячейке"
[oracle@x1 ~]$ dcli -g cell_group -l root cellcli -e "alter iormplan inactive" c1: IORMPLAN successfully altered c2: IORMPLAN successfully altered c3: IORMPLAN successfully altered c4: IORMPLAN successfully altered c5: IORMPLAN successfully altered c6: IORMPLAN successfully altered c7: IORMPLAN successfully altered [oracle@x1 ~]$ [oracle@x1 ~]$ dcli -g cell_group -l root cellcli -e "list iormplan" c1: c1_IORMPLAN inactive c2: c2_IORMPLAN inactive c3: c3_IORMPLAN inactive c4: c4_IORMPLAN inactive c5: c5_IORMPLAN inactive c6: c6_IORMPLAN inactive c7: c7_IORMPLAN inactive [oracle@x1 ~]$
Заметьте, что я мог бы выключить IORM план на некоторых ячейках избирательно, а не на всех сразу.
-- To reset IORM plans: cellcli -e ALTER IORMPLAN dbPlan=\"\"\, catPlan=\"\"
Спасибо что зашли,
Будьте благословенны!
Денис
