Zarządzanie zasobami bazodanowymi – strojenie I/O

Jadwiga Gnybek

Strojenie wydajności serwera bazodanowego to proces skomplikowany. Niemniej jednak z radością witamy każdy nowy parametr, na wydajność którego administratorzy motoru bazy mają wpływ. Oracle Database 11g do listy tych parametrów dołączył wykorzystanie zasobów I/O.

Wprawdzie galopująca technologia sprawiła, że prędkość komunikacji motoru bazy z dyskami nie jest już najbardziej kluczowym elementem wydajności serwera bazy danych, niemniej jednak przy bazie pracującej na potrzeby wielu procesów biznesowych, sterowanie dostępem do mechanizmów zapisu i odczytu (I/O) może okazać się bardzo przydatne.

W poprzednich wersjach bazy zarządzanie zasobami mogło kontrolować jedynie wykorzystanie CPU. Przyjrzyjmy się bliżej temu mechanizmowi. Rozpocząć warto od tego, że aby coś stroić, trzeba najpierw zidentyfikować problem i określić cel jaki chcemy osiągnąć. Do kalibracji urządzeń I/O wykorzystamy procedury pakietu DBMS_RESOURCE_MANAGER, które umożliwią nam przetestowanie wydajności poszczególnych dysków poprzez wyliczenie ilości operacji I/O wykonywanych w czasie sekundy (IOPS), liczby megabajtów transmitowanych w czasie jednej sekundy (MBps) oraz czas oczekiwania na operacje wejścia/wyjścia (I/O latency). Procedurę tę uruchomić można w dwojaki sposób: z konsoli Performance pakietu Oracle Enterprise Manager lub klasycznie z linii poleceń SQL:

DBMS_RESOURCE_MANAGER.CALIBRATE_IO (
    num_physical_disks    IN PLS_INTEGER DEFAULT 1,
    max_latency IN PLS_INTEGER DEFAULT 20,
    max_iops OUT PLS_INTEGER,
    max_mbps OUT PLS_INTEGER,
    actual_latency OUT PLS_INTEGER);

Jak widać, procedura ta ma dwa parametry wejściowe: pierwszym z nich jest fizyczny numer dysku NUM_PHYSICAL_DISKS, drugim zaś MAX_LATENCY, czyli maksymalny czas oczekiwania na operację I/O podany w milisekundach. Na wyjściu z procedury otrzymujemy trzy liczby: MAX_IOPS – maksymalna liczba operacji I/O realizowana w czasie jednej sekundy, MAX_MBPS – maksymalna liczba megabajtów przetransferowanych w czasie jednej sekundy oraz ACTUAL_LATENCY – rzeczywisty czas oczekiwania na operacje I/O uzyskany podczas testu. Status testu kalibracji odczytać możemy z perspektywy V$IO_CALIBRATION_STATUS, natomiast rezultaty testu dostępne są w perspektywie DBA_RSRC_IO_CALIBRATE. Pamiętać też warto o tym, że przed uruchomieniem procedury CALIBRATE_IO należy ustawić parameter TIMED_STATISTICS na TRUE oraz uruchamiać procedurę ze schematu użytkownika posiadającego przywileje SYSDBA.

Limitowanie I/O dla sesji

W poprzednich wersjach Oracle Database, administrator mógł sprecyzować maksymalny okres czasu, przez jaki sesja mogła trwać. Jeśli wyznaczony limit czasu został przekroczony, fatalna sesja mogła zostać zamknięta. Podobny mechanizm możemy teraz zaimplementować w obszarze strojenia I/O. Zdefiniować możemy dwa parametry powodujące zamknięcie sesji: maksymalną liczbę operacji I/O lub maksymalną liczbę megabajtów przetransferowanych przez daną sesję. Tę właściwość mechanizmów strojenia wykorzystujemy w dwóch przypadkach: do identyfikowania i zatrzymywania zapytań generujących ponadnormatywny ruch I/O lub do przesuwania zadań obciążających mechanizmy I/O do grup użytkowników posiadających niższy priorytet dostępu do zasobów serwera bazy danych. Oto przykład ustawienia takich limitów:

BEGIN
    DBMS_RESOURCE_MANAGER.create_plan_directive (
        plan => 'JGN_plan',
        group_or_subplan => 'VIP_group',
        comment => 'automatyczne przełaczanie z VIP do standard',
        mgmt_p1 => 70,
        switch_group => 'standard_group',
        switch_time => 240,
        switch_io_reqs => 5000,
        switch_io_megabytes => 2048,
        switch_for_call => TRUE);
    END;

JGN_plan określa limity I/O bieżącego wywołania sesji na wartości 240 sekund lub 5000 odwołań do operacji I/O, albo też 2048 MB przetransferowanych na dysk danych. Przekroczenie któregokolwiek z tych limitów spowoduje przesunięcie tego wywołania z grupy VIP_group do grupy standard_group, która – jak łatwo się domyślić – ma nieco mniejsze przywileje w temacie przydziału zasobów maszyny. Oczywiście limitów tych nie można „wziąć z sufitu”. Muszą one odzwierciedlać średnie zapotrzebowania poszczególnych operacji na zasoby I/O. Wiedzę taką pozyskać możemy z szeregu perspektyw – na przykład z V$IOSTAT_FILE, która wyświetla statystyki I/O dla poszczególnych plików bazodanowych. V$IOSTAT_FUNCTION wyświetla statystyki I/O dla procesów drugoplanowych – takich, jak LGWR, DBWR itd. Wreszcie V$IOSTAT_CONSUMER_GROUP pokazuje te same statystyki przez pryzmat grup użytkowników.

Oczywiście, perspektyw pokazujących dane statystyczne przydatne do strojenia motoru bazy jest znacznie więcej. Sztuka w tym, aby umieć znaleźć tam te dane, które podpowiedzą nam optymalne nastawy. Życzę powodzenia!