optymalizacja systemu aix pod zastosowania oracle · optymalizacja systemu aix pod zastosowania...

XV Konferencja PLOUG Kościelisko Październik 2009

Optymalizacja systemu AIX pod zastosowania Oracle

Mariusz Czopiński, Maciej Przepiórka IBM Polska Sp. z o.o

[email protected], [email protected] Abstrakt. Tematyka optymalizacji wydajności systemów bazodanowych jest ciągle aktualna a wiedza na ten temat jest bardzo poszuki-wana. Większość DBA, przy strojeniu, ogranicza się do obszaru bazy danych i tam szuka miejsc na ewentualne usprawnienia. Zapomina-ją oni o tym, że prawidłowe zestrojenie środowiska bazodanowego wymaga dobrej współpracy administratora systemu operacyjnego z administratorem bazy danych. DBA powinien poznać funkcjonalności systemu operacyjnego, na którym ma działać baza tak by móc rozmawiać z SA wspólnym językiem. Niniejszy referat prezentuje jak wykorzystać specyficzne funkcjonalności systemu operacyjnego AIX na serwerach IBM Power Sys-tems pod zastosowania ORACLE. Słuchacz zapozna się z takimi technologiami jak simultaneous multithreading, micro-partitioning, DLPAR. Dowie się, w jaki sposób kontrolować zużycie pamięci, w jaki sposób konfigurować podsystemy I/O i wiele innych przydat-nych informacji dotyczących zestrojenia AIX z ORACLE.

Optymalizacja systemu AIX pod zastosowania Oracle 123

1. Optymalizacja pamięci i CPU

1.1. Simultaneous Multi – Threading

SMT to technologia pozwalająca na wykonywanie, przez procesor, instrukcji pochodzących z dwóch wątków w jednym cyklu zegara. Instrukcje dostarczane są dwiema niezależnymi ścież-kami. Każda z nich jest widziana przez system operacyjny, jako oddzielna jednostka przetwarzają-ca. Przykład, AIX uruchomiony na serwer z 4 fizycznymi procesorami z włączonym SMT będzie widział 8 logicznych procesorów. Funkcjonalność, o której mowa jest dostępna na serwerach POWER 5 i POWER 6 z systemem AIX 5.3 i wyższym. Włączanie i wyłączanie tej funkcjonalno-ści odbywa się w sposób dynamiczny i jest konfigurowana niezależnie per LPAR. Do kontroli zachowania SMT służy komenda smtctl.

smtctl [ -m off | on [ -w boot –w now ] ] -m off: wyłączenie trybu SMT -m on: włączenie trybu SMT -w boot: efektywne od następnego restartu partycji -w now: efektywne od razu, ale tylko do restartu partycji

Wzrost wydajności przetwarzania dla systemu OLTP dla Power 5 nawet do 30% dla Power 6 do 50%. Rodzi się pytanie, dlaczego, przy tak imponującym wzroście nie zdecydowano się włą-czyć tej funkcjonalności na stałe? Odpowiedzią są aplikacje jednowątkowe i systemy HPC, dla których włączenie SMT może skutkować degradacją wydajności

Powyższa funkcjonalność jest domyślnie włączona i nie ma wpływu na licencjonowanie baz danych.

Poniżej przedstawione są diagramy wygenerowane z NMON ilustrujące wpływ SMT na wy-dajność systemu POWER z uruchomioną aplikacją ORACLE przy obciążeniu ruchem typu OLTP. Testy były wykonane na identycznej platformie sprzętowej.

Rys. 1. Wykorzystanie CPU w systemie z AIX 5.2 (no SMT)

124 Mariusz Czopiński, Maciej Przepiórka

Rys. 2. Wykorzystanie CPU w systemie z AIX 5.3(włączone SMT)

1.2. Dynamiczne partycjonowanie (DLPAR)

Partycja logiczna w systemach IBM Power to wydzielony zasób sprzętowy, na którym można osadzić system operacyjny. Od modelu POWER4, systemy IBM Power wspierają dynamiczny przydział zasobów dla partycji logicznej w ramach całego sprzętu. Ta funkcjonalność daje wielkie możliwości dla użytkownika pozwalając na przegrupowanie zasobów do partycji, które ich naj-bardziej potrzebują bez wpływu na dostępność partycji.

Baza danych Oracle, począwszy od wersji 9i jest wyposażony w funkcjonalność dynamicznego za-rządzania pamięcią, która w połączeniu z funkcjonalnością DLPAR znacznie rozszerza możliwo-ści rekonfiguracyjne bazy. Dynamiczne zarządzanie pamięcią w Oracle konfiguruje się w oparciu o następujące parametry:

• SGA_MAX_SIZE (parametr statyczny)

• SGA_TARGET (parametr dyanmiczy)

• MEMORY_TARGER (11g parametr statyczny)

• MEMORY_MAX_TARGET (11g parametr dynamiczny)

DLPAR zezwala na rekonfigurację dostępnej pamięci w obszarze zdefiniowanym podczas two-rzenia logicznej partycji. Administrator może przydzielić dowolną wartość RAM z zakresu ograni-czonego parametrami MAXIMUM_MEMORY, DESIRED_MEMORY i MINIMUM_MEMORY.

Aby zilustrować możliwości drzemiące w tej technologii prześledźmy poniższy przypadek. Ba-za danych działa na partycji z ustawieniami:

• MAXIMUM_MEMORY=16 GB

• DESIRED_MEMORY=9 GB

• MINIMUM_MEMORY=1 GB

Na partycji zainstalowany jest AIX wersja 5.3 i baza danych Oracle wersja 10g z ustawieniami pamięci jak na poniższym listingu


NAME TYPE VALUE ------------------------------------ ----------- ----------------------------- lock_sga boolean FALSE pre_page_sga boolean FALSE sga_max_size big integer 12000M sga_target big integer 6000M

System operacyjny uruchomił się z wartością pamięci na poziomie zdefiniowanym przez DE-SIRED_MEMORY czyli 9 GB. Jak widać z powyższego listingu SGA_MAX_SIZE jest ustawio-ny znacznie poza wartość dostępną w systemie operacyjnym. Taki manewr może być wykonany tylko przy LOCK_SGA ustawionym na FALSE. Nie musimy się obawiać o prawidłowe działanie bazy jak długo sga_target jest ustawiony poniżej 9 GB.

Mamy już naszkicowany obraz naszej konfiguracji. Przyjmijmy, że z jakiś powodów Oracle tuning advisory rekomenduje zwiększenie SGA do 10 GB, czyli poza obszar aktualnie dostępny w systemie operacyjnym. Korzystając z DLPAR zwiększamy pamięć dla systemu operacyjnego do 15 GB. Możemy tę operację wykonać, gdyż poruszamy się we wcześniej zdefiniowanym dopusz-czalnym zakresie zmian. Po upewnieniu się, że zmiany zostały zaakceptowane przez system, ko-mendą:

$ prtconf |grep "Memory Size" Memory Size: 29696 MB Good Memory Size: 29696 MB

I teraz możemy spokojnie zmienić wartość SGA_TARGET na proponowaną, czyli 10GB. alter system set sga_target=10000M scope=both;

Funkcjonalność DLPAR również steruje dynamicznym przydziałem CPU do partycji. Gdy par-tycji zaczyna brakować mocy obliczeniowej to w prosty sposób, o ile mamy jeszcze niewykorzy-stane zasoby sprzętowe, można zaspokoić jej potrzeby. Oracle począwszy od wersji 10g jest w sta-nie rozpoznać zmianę ilości CPU i wykorzystać tę informację na przykład przy optymalizacji wy-konywania zapytań. Zmienna CPU_COUNT odzwierciedla, widzianą przez Oracle liczbę proceso-rów. Jest to zmienna dynamiczna, która ulega modyfikacji wraz ze zmianą liczby CPU w systemie. Oracle przy zarejestrowaniu zmiany w konfiguracji CPU umieszcza następujący komunikat w alert logu:

Wed Jul 15 06:11:10 2009-08-12 Detected change in CPU count to 3

i ustawia CPU_COUNT na prawidłową, nową wartość.

1.3 Virtual Memory Manager (VMM)

Virtual Memory Manager obsługuje żądania dostępu do pamięci pochodzące z systemu opera-cyjnego bądź różnego typu aplikacji. Segmenty pamięci wirtualne są podzielone na jednostki o stałym rozmiarze zwane stronami. Od wersji 5.3 AIX może zaadresować strony w rozmiarach 4KB, 64KB, 16MB i 16GB.

Strony mogą się znajdować w dwóch miejscach. W fizycznej pamięci RAM bądź też na dysku fizycznym. AIX używa pamięci wirtualnej, aby móc zaadresować większy obszar pamięci niż ma fizycznie dostępne w RAM. Pozostały obszar adresowy znajduje się na dysku. Czas dostępu do stron, które znajdują się na dysku jest milion razy większy niż czas dostępu do stron w pamięci fizycznej. Gdyby strony z SGA z jakiś powodów były przetrzymywane na dysku spowodowałoby to znaczący spadek wydajności bazy. Z powyższego powodu optymalizacja VMM będzie polegała na zminimalizowaniu prawdopodobieństwa wystąpienia takiego przypadku.


Pamięć w systemie AIX możemy podzielić na cztery obszary, tak jak to przedstawiono na rys. 3. Pierwszy z nich to „file cache”, który służy, jako pamięć podręczna dla plików. AIX po prze-czytaniu pliku z dysku przetrzymuje go przez jakiś czas w pamięci by móc go dostarczyć bardzo szybko, gdy znów będzie potrzebny. Kolejny obszar tzw. „computational memory” zawiera strony, które są wykorzystywane przez pliki wykonywalne, czy też przez procesy, jako pamięć tymcza-sowa. Trzeci obszar „aix kernel” przeznaczony na potrzeby kernela. No i na koniec obszar ze stro-nami, które nie zostały jeszcze przydzielone.

File cache

Free memory

Computational memory

Aix kernel

Rys. 3. Struktura pamięci w AIX

Przy intensywnym ruchu I/O cześć określona, jako pamięć podręczna dla plików zaczyna się rozrastać, konsumując wolną pamięć. Po skonsumowaniu wolnego obszaru dochodzi do walki z obszarem zajmowanym przez kod wykonywalny („computational pages”) o strony pamięci. W tym obszarze rezyduje SGA i PGA. Chcemy, więc chronić ten obszar przed wywłaszczeniem. Wykorzystamy VMM w tym celu. Sparametryzujemy go tak, aby algorytm, który odpowiada za przydział stron pamięci zwalniał strony z obszaru przeznaczonego na pamięć podręczną systemu plików. Sugerowane ustawienia parametrów VMM dla systemu, na którym działa baza danych Oracle wyglądają tak:

• lru_file_repage = 0 (domyślnie jest ustawione na 1 dla AIX 5.2/5.3 i 0 dla AIX 6.1) – ten parametr mówi o tym czy ilość odwołań do strony pamięci będzie brana pod uwagę przy wyborze typu strony pamięci do zwolnienia.

• minperm%=3 – jeżeli obszar zajmowany przez pamięć podręczną plików spadnie poniżej MINPERM to zarówno „computational pages” jak i „file pages” będą umieszczane w obsza-rze stronicowania. W tym wypadku będzie to 3% całej dostępnej pamięci.

• maxperm%=90 – jeżeli obszar zajmowanej przez pamięć podręczną plików wzrośnie powy-żej MAXPERM to do obszaru stronicowania będą przerzucane tylko „file pages”

• maxclient%=90 – parametr o działaniu takim jak MAXPERM tyle, że dla plików udostęp-nianych przez SMB lub NFS.

Komendy systemowe, które ustawią nam powyższe parametry na oczekiwane wartości wyglą-dają tak:

vmo -p -o maxclient%=90 vmo -p -o maxperm%=90 vmo -p -o minperm%=3 vmo -p -o lru_file_repage=0

1.4. Pinning SGA Shared Memory

AIX wspólnie z Oracle dostarcza mechanizm pozwalający na „przypięcie” obszaru SGA, by żadna jego strona nie została umieszczona w obszarze stronicowania. W dobrze zestrojonych śro-dowiskach nie ma potrzeby sięgania po ten mechanizm, gdyż będzie nikła szansa, że SGA zostanie przerzucone do obszaru stronicowania. Ten mechanizm jest środkiem doraźnym łagodzącym błędy konfiguracyjne.

Włączenie tej funkcjonalności odbywa się w następujący sposób:

• Po stronie AIX:

vmo –p –o v_pinshm = 1


utrzymujemy maxpin% na poziomie domyślnym, czyli 80

• Po stronie Oracle:

ALTER SYSTEM SET LOCK_SGA=TRUE;

i startujemy bazę

2. Optymalizacja I/O

2.1. AIX LVM

Podsystem dyskowy to obszar, który najbardziej wpływa na wydajność Oracle. Przy niewła-ściwej konfiguracji nasza aplikacja będzie marnowała czas CPU oczekując na I/O. Żadne stroje-nie parametrów Oracle nie pomogą w uzyskaniu znaczącego wzrostu wydajności.

Podstawową zasadą i jednocześnie najbardziej ogólną jest planowanie konfiguracji dyskowej tak by ruch I/O był równomiernie rozłożony na wszystkie dostępne dyski. Im jest ich więcej tym lepiej. Dostęp do danych będzie realizowany przez większą ilość ramion dyskowych minimalizu-jąc czas dostępu do miejsca na dysku. Zarządzanie rozmiarem woluminu i poziomem zabezpie-czenia danych, w warstwie sprzętowej, dokonujemy wybierając odpowiedni poziom RAID.

Od strony softwarowej, czyli AIX-a, Zarządzania przestrzenią dyskową odbywa się przy po-mocy LVM ( Logical Volume Manager). Przy pierwszym kontakcie z tą technologią, może się ona wydawać bardziej skomplikowana niż klasyczne partycje dyskowe. Jednakże przy odrobinie tre-ningu okaże się, że jest to rozwiązanie bardzo elastyczne i łatwe w zarządzaniu. Z LVM łączy się kilka pojęć. Najważniejsze z nich to:

• PV (physical volumes) – fizyczne woluminy widziane pod AIX jako hdisk-i, mogą to być dyski fizyczne bądź też LUN-y (Logical Unit Number) wystawione z macierzy

• VG (volume groups) – grupy woluminów tworzą PV, wielkość grupy woluminów jest okre-ślona sumą wszystkich woluminów wchodzących w skład grupy

• LV (logical volumes) – woluminy logiczne są obszarami wydzielonymi z VG, w których tworzone są systemy plików

Rys. 4. Struktura LVM

LVM ma możliwość wykonania software-owego złączenia dysków (tzw. stripe). Dzięki czemu, z poziomu AIX, mamy możliwość rozrzucenia ruchu I/O po wszystkich hdisk-ach.


Rys. 5. Striping sprzętowy i softwarowy

AIX LVM wspiera dwie techniki złączeń dyskowych:

• PP Spreading

• LVM Striping

PP Spreading jest definiowany przy tworzeniu logicznego wolumenu. Przy tej technice partycje logiczne są rozrzucone po wszystkich dyskach zdefiniowanych w grupie woluminów (VG). Przy czym pierwsza partycja logiczna na pierwszym hdisk-u, druga na drugim hdisk-u, trzecia na trze-cim hdisk-u itp. Taki logiczny wolumin możemy stworzyć wykonując poniższe polecenie.

mklv –y datalv –e x datavg

Ponieważ ta technika daje najlepsze rezultaty to nie będę opisywał LVM Striping-u. Zaznaczę tylko, że polega on na umieszczeniu części każdej partycji w wszystkich PP dostępnych w ramach grupy wolumenów. Poniżej możemy zobaczyć jak rozkłada się obciążenie na dyskach przy PP spreading kontra system bez LVM Striping.

Rys. 6. Wykorzystanie dysków z opcją PP Spreading i bez niej

2.2. Asynchroniczne I/O

Asynchroniczne I/O znacznie przyspiesza komunikację aplikacji z podsystemem dyskowym zdejmując z aplikacji obowiązek oczekiwania na potwierdzenie zapisu danych na dysk. W syste-mie z wyłączonym AIO każda operacja zapisu musi zostać potwierdzona. Proces oczekujący na potwierdzenie zużywa czas procesora, który może zostać wykorzystany do bardziej produktyw-nych operacji. W procesie asynchronicznym (rys. 7) aplikacja przekazuje dane do kolejki AIO, po


czym przechodzi do innych operacji. W tym czasie serwery AIO pobierają dane z kolejki i zapisu-ją je na dysk. Dzięki takiemu podejściu zostaje wyeliminowana najwolniejsza część procesu zapi-su danych, czyli dostęp do dysku przez aplikację.

Rys. 7. Proces asynchronicznego zapisu danych

Aix zezwala na sterowanie rozmiarem kolejki (parametr MAXREQS) i liczbą serwerów AIO (parametry MINSERVER i MAXSERVER), które obsługują żądania. Zmiany wartości parame-trów wykonujemy poleceniem:

#chdev –l aio0 –P –a nazwa_parametru=wartość

Zaleca się ustawienie następujących wartości:

• AIX 5.1 i wcześniejszy: MAXSERVERS = (logical_disk * 10)

• AIX 5.2 i nowszy: MAXSERVERS = (logical_disk * 10 / CPU)

Te zalecenia dotyczą ustawień początkowych, które prawdopodobnie ulegną zmianie po obser-wacji zachowania produkcyjnego systemu.

2.3. Direct I/O i Concurrent I/O

W rozdziale opisującym VMM wymieniony został obszar przeznaczony na pamięć podręczną systemu plików. Bazy danych w tym także Oracle nie potrzebują tego obszaru, gdyż same decydu-ją, jakie dane umieścić w pamięci i kiedy je stamtąd usunąć. Równoległe przetrzymywanie tych samych danych w buforze podręcznym systemu i bazy danych jest bezcelowe i wnosi jedynie do-datkowy narzut i dodatkową konsumpcję CPU. Przy każdym dostępie do pliku, jest on czytany najpierw z dysku do bufora podręcznego systemu a później kopiowane z bufora systemowego do bufora aplikacji.

Używając direct I/O omijamy pamięć podręczną systemu plików pompując dane bezpośrednio z dysku do bufora aplikacji. Direct I/O jest dostępny zarówno w JFS jak i JFS2. Aby skorzystać z tej funkcjonalności wystarczy podmontować zasób w trybie dio komendą:

#mount –o dio /oradata

Direct I/O nie zapobiega dostępu sekwencyjnego do pliku. Dopiero funkcjonalność concurrent I/O która jest rozszerzeniem direct I/O zezwala na dostęp do tego samego pliku przez wiele proce-sów piszących. Funkcjonalność concurrent I/O dostępna jest tylko w JFS2. Jej włączenie następuje przy zamontowaniu systemu plików z opcjo cio. Wydajność tak podmontowanego systemu plików jest porównywalna z wydajnością woluminów surowych.

Aplikacja kolejka

AIO serwery AIO 2

3 4 1


Rys. 8. Wydajność systemów przy montowaniu różnym trybie dostępu do danych

Bibliografia

[HJL+05] Hayashi K., Jl K., Lascu O., Plenaar H., Schreitmuller S., Tarquinio T., Thompson J.: “AIX 5L Practical Performance Tools and Tuning Guide” redbook 2005

[R08] Rubic D.: “Oracle Architecture and Tuning on AIX” IBM Oracle technical brief 2008

[DGI+03] Darmawan B, Groenewald G., Irwing A. :Database Performance Tuning on AIX redbook (SG245511, 2003)

optymalizacja systemu aix pod zastosowania oracle · optymalizacja systemu aix pod zastosowania...

Documents