Monday, December 19, 2011

Oracle Database Appliance

Итак, we have Oracle Database Appliance.
ODA contains: Oracle 11.2.0.2 EE RAC.

Let we calibrate IO:

SQL> ed

  1  DECLARE
  2    lat  INTEGER;
  3    iops INTEGER;
  4    mbps INTEGER;
  5  BEGIN
  6  -- DBMS_RESOURCE_MANAGER.CALIBRATE_IO (<DISKS>, <MAX_LATENCY>, iops, mbps, lat);
  7     DBMS_RESOURCE_MANAGER.CALIBRATE_IO (20, 10, iops, mbps, lat);
  8    DBMS_OUTPUT.PUT_LINE ('max_iops = ' || iops);
  9    DBMS_OUTPUT.PUT_LINE ('latency  = ' || lat);
 10    dbms_output.put_line('max_mbps = ' || mbps);
 11* end;
SQL>
SQL>
SQL> set serveroutput on
SQL> /

max_iops = 13230
latency  = 11
max_mbps = 2335

Итак, 13К IOPS - неплохо для 20 шпинделей.

Однако, как-то слишком много.
Если один шпиндель заявлен на сайте seagate.com как 3мс, то он способен обеспечить не более 330 IOPS. Следовательно, 20 дисков = 20 * 330 = 6600 IOPS - это теоретический максимум, который можно ожидать от такой системы. Однако мы имеем ровно в два раза больше !
Одно из объяснений - диски находятся под RAID-контроллером с 512Мб памяти, а на втором узле - второй контроллер со своими 512Мб. Возможно, причина в этом.

Гипотеза об SSD не нашла подтверждения. SSD диски в данной процедуре не включаются, потому что на SSD лежат только redo log files. Поэтому, даный ввод-вывод - исключительно с шпинделей. Это можно доказать, с помощью lsof:

SQL> !ps
  PID TTY          TIME CMD
23178 pts/1    00:00:00 bash
27465 pts/1    00:00:00 ps
32699 pts/1    00:00:00 sqlplus

[root@ODA01-pub1 ~]# ps -ef|grep 32699
root     31357 17543  0 14:38 pts/3    00:00:00 grep 32699
oracle   32699 23178  0 13:35 pts/1    00:00:00 sqlplus   as sysdba
oracle   32700 32699  0 13:35 ?        00:00:00 oracleODA01DB1 (DESCRIPTION=(LOCAL=YES)(ADDRESS=(PROTOCOL=beq)))

[root@ODA01-pub1 ~]# lsof -p 32700|less
...
oracle  32700 oracle  256u   BLK  253,68                24412 /dev/mapper/HDD_E1_S06_984565747p1
oracle  32700 oracle  257u   BLK  253,59                23574 /dev/mapper/HDD_E0_S01_984620575p1
oracle  32700 oracle  258u   BLK  253,46                23379 /dev/mapper/HDD_E0_S04_984667927p1
oracle  32700 oracle  259u   BLK  253,36                23233 /dev/mapper/HDD_E1_S03_984701491p1
oracle  32700 oracle  260u   BLK  253,34                23208 /dev/mapper/HDD_E1_S15_979832135p1
oracle  32700 oracle  261u   BLK  253,48                23396 /dev/mapper/HDD_E0_S12_979857635p1
oracle  32700 oracle  262u   BLK  253,42                23340 /dev/mapper/HDD_E0_S17_979676671p1
oracle  32700 oracle  263u   BLK  253,70                24974 /dev/mapper/HDD_E1_S10_984691531p1
oracle  32700 oracle  264u   BLK  253,57                23554 /dev/mapper/HDD_E0_S05_984692403p1
oracle  32700 oracle  265u   BLK  253,29                23133 /dev/mapper/HDD_E1_S19_979811875p1

Итак, видно, что процесс открыл только 10 дисков.
Причем, для lgwr показываются SSD диски:

oracle  24544 oracle  256u   BLK             253,57                23554 /dev/mapper/HDD_E0_S05_984692403p1
oracle  24544 oracle  257u   BLK             253,32                23169 /dev/mapper/HDD_E1_S11_984698091p1
oracle  24544 oracle  258u   BLK             253,29                23133 /dev/mapper/HDD_E1_S19_979811875p1
oracle  24544 oracle  259u   BLK             253,40                23274 /dev/mapper/HDD_E0_S00_984624147p1
oracle  24544 oracle  260u   BLK             253,43                23353 /dev/mapper/HDD_E0_S08_984624267p1
oracle  24544 oracle  261u   BLK             253,59                23574 /dev/mapper/HDD_E0_S01_984620575p1
oracle  24544 oracle  262u   BLK             253,46                23379 /dev/mapper/HDD_E0_S04_984667927p1
oracle  24544 oracle  263u   BLK             253,34                23208 /dev/mapper/HDD_E1_S15_979832135p1
oracle  24544 oracle  264u   BLK             253,68                24412 /dev/mapper/HDD_E1_S06_984565747p1
oracle  24544 oracle  265u   BLK             253,67                24339 /dev/mapper/SSD_E0_S20_805674689p1
oracle  24544 oracle  266u   BLK             253,31                23144 /dev/mapper/SSD_E1_S22_805674773p1
oracle  24544 oracle  267u   BLK             253,28                23110 /dev/mapper/SSD_E1_S23_805674697p1
oracle  24544 oracle  268u   BLK             253,54                23468 /dev/mapper/SSD_E0_S21_805674938p1


Наткнулся на некий новый процесс CS :

[root@ODA01-pub1 ~]# ps -ef|grep ora_cs
oracle   13805     1  2 15:08 ?        00:00:08 ora_cs00_ODA01DB1
oracle   13807     1  2 15:08 ?        00:00:08 ora_cs01_ODA01DB1
oracle   13810     1  2 15:08 ?        00:00:08 ora_cs02_ODA01DB1
oracle   13812     1  2 15:08 ?        00:00:08 ora_cs03_ODA01DB1
oracle   13814     1  2 15:08 ?        00:00:08 ora_cs04_ODA01DB1
oracle   13816     1  2 15:08 ?        00:00:08 ora_cs05_ODA01DB1
oracle   13818     1  2 15:08 ?        00:00:07 ora_cs06_ODA01DB1
oracle   13820     1  2 15:08 ?        00:00:07 ora_cs07_ODA01DB1
oracle   13822     1  2 15:08 ?        00:00:07 ora_cs08_ODA01DB1
oracle   13824     1  2 15:08 ?        00:00:07 ora_cs09_ODA01DB1
oracle   13826     1  2 15:08 ?        00:00:07 ora_cs0a_ODA01DB1
oracle   13828     1  2 15:08 ?        00:00:07 ora_cs0b_ODA01DB1
oracle   13830     1  2 15:08 ?        00:00:06 ora_cs0c_ODA01DB1
oracle   13832     1  2 15:08 ?        00:00:06 ora_cs0d_ODA01DB1
oracle   13834     1  2 15:08 ?        00:00:06 ora_cs0e_ODA01DB1
oracle   13836     1  2 15:08 ?        00:00:06 ora_cs0f_ODA01DB1
oracle   13838     1  2 15:08 ?        00:00:06 ora_cs0g_ODA01DB1
oracle   13840     1  2 15:08 ?        00:00:06 ora_cs0h_ODA01DB1
oracle   13843     1  2 15:08 ?        00:00:05 ora_cs0i_ODA01DB1
oracle   13848     1  2 15:08 ?        00:00:05 ora_cs0j_ODA01DB1
oracle   13851     1  2 15:08 ?        00:00:06 ora_cs0k_ODA01DB1
oracle   13854     1  2 15:08 ?        00:00:06 ora_cs0l_ODA01DB1
oracle   13857     1  2 15:08 ?        00:00:05 ora_cs0m_ODA01DB1
oracle   13865     1  2 15:08 ?        00:00:05 ora_cs0n_ODA01DB1

Как оказалось, это некий новый "I/O Calibration Process":
"CSnn slave processes are started on execution of the DBMS_RESOURCE_MANAGER.CALIBRATE_IO() procedure. There is one slave process per CPU on each node of the database."

http://docs.oracle.com/cd/E11882_01/server.112/e24448/bgprocesses.htm

Причем, процесс калибрации выполняется на двух узлах кластера одновременно.


5 comments:

  1. в ODA вроде как нет кэшей на контроллерах,
    она их не может синхронизовать.

    ReplyDelete
  2. Делаем, lspci, и видим :

    0d:00.0 Serial Attached SCSI controller: LSI Logic / Symbios Logic SAS2008 PCI-Express Fusion-MPT SAS-2 [Falcon] (rev 03)

    1f:00.0 Serial Attached SCSI controller: LSI Logic / Symbios Logic SAS2008 PCI-Express Fusion-MPT SAS-2 [Falcon] (rev 03)

    ReplyDelete
  3. это хорошо :)
    http://nocoug.org/download/2011-11/Alex_Gorbachev_Oracle_Database_Appliance.pdf
    с.59
    Two LSI SAS9211-8i SAS HBAs No Cache
    Cannot use any cache because of shared storage
    I.e. must go to disk every read or write because of another node

    Естественно, невозможно синхронизировать кэши на контроллерах
    в разных узлах кластера, поэтому в ODA этих кэшей и нету.

    ReplyDelete
  4. Согласен, нет кеша на контроллере :)

    ReplyDelete
  5. видимо, калибрация как раз и просуммировалась на 2-х узлах,
    вот и получилось 13000 вместо 6600.
    а у меня на Sparc T3-1 калибрация по ходу и не идет из-за этих удивительных процессов, которых "process per CPU on each node of the database" слишком много -128 (16 ядер Х 8 нитей).

    ReplyDelete

Note: Only a member of this blog may post a comment.

Exadata Scrubbing

  1. Появление сбойных секторов на диске автоматически запускает дополнительный scrubbing: 8.2.4 Adaptive Scrubbing Schedule In release 12.1...