GoldenLine
Zaloguj się
Aleksander Mathias

Aleksander Mathias Oracle DBA

Temat: mały rozmiar buffer cache'a

Cześć,
ostatnio doskwiera mi pewna baza (11.2.0.2 na Red Hacie), otóż cierpi czasem na braki I/O, ale rozmiar buffer cache'a wydaje się być zbyt mały. Ustawione jest memory target na 60G (automatyczne zarządzanie pamięcią) a buffer cache z tego bierze sobie jedynie 5G (już nawet shared pool jest prawie 2 razy większy!). Wyprowadźcie mnie z błędu, ale wydaje mi się, że nawet jeżeli zapytania wczytają bloki do bufora i nie zostaną one do niczego więcej użyte, to i tak powinny sobie tam leżeć aż miejsca w SGA zacznie brakować - wtedy stare dane wypadają a wczytywane są nowe (chyba, że idą update'y to wtedy nieaktualne dane wypadają z bufora). Macie jakieś doświadczenia z takim, wg mnie dziwnym, automatycznym rozmiarowaniem SGA?
Z góry dzięki za wszelkie sugestie.
Link do wypowiedziLink

konto usunięte

Temat: mały rozmiar buffer cache'a

Aleksander Mathias:
Z góry dzięki za wszelkie sugestie.

60G na mem_target to jakaś tragedia. Za problemy z I/O może w tym przypadku odpowiadać mnóstwo czynników, począwszy od źle skonfigurowanego OS'a a skończywszy na idiotycznych zapytaniach jak i modyfikacjach, np. aplikacja nie używa tzw. "bind variables" ...
Link do wypowiedziLink
Kamil Stawiarski

Kamil Stawiarski Oracle Certified
Master | Oracle ACE

Temat: mały rozmiar buffer cache'a

Krzysiek ma rację... A wogóle to zrezygnowałbym z memory_target - wykorzystuje posixową implementację zarządzania pamięcią współdzieloną i kiepsko współgra z huge pages.
Link do wypowiedziLink
Adam B.

Adam B. Oracle Certified
Master

Temat: mały rozmiar buffer cache'a

Kamil Stawiarski:
Krzysiek ma rację... A wogóle to zrezygnowałbym z memory_target - wykorzystuje posixową implementację zarządzania pamięcią współdzieloną i kiepsko współgra z huge pages.
Potwierdzam i popieram w całej rozciągłości i 60GB to jest sporo...
Nie wiem czy nie dużo za dużo no ale to już trzeba było by spojrzeć na baze..
Link do wypowiedziLink

konto usunięte

Temat: mały rozmiar buffer cache'a

Krzysztof P.:
Aleksander Mathias:
Z góry dzięki za wszelkie sugestie.

60G na mem_target to jakaś tragedia. Za problemy z I/O może w tym przypadku odpowiadać mnóstwo czynników, począwszy od źle skonfigurowanego OS'a a skończywszy na idiotycznych zapytaniach jak i modyfikacjach, np. aplikacja nie używa tzw. "bind variables" ...

I w sumie to zapuściłbym tracing żeby zobaczyć co tam lata i co powoduje najwięcej IO. Odnośnie przytoczonych wyżej przez kolegę zmiennych bindowanych , można zastosować odpowiednie ustawienie cursor_sharing ( na FORCE) który załatwi sprawę nawet jeśli aplikacja nie korzysta ze zmiennych bindowanych.Andrzej K. edytował(a) ten post dnia 04.06.12 o godzinie 23:41
Link do wypowiedziLink

konto usunięte

Temat: mały rozmiar buffer cache'a

Andrzej K.:
kolegę zmiennych bindowanych , można zastosować odpowiednie ustawienie cursor_sharing ( na FORCE) który załatwi sprawę nawet jeśli aplikacja nie korzysta ze zmiennych bindowanych.

:)

Ale po tej zmianie dojdzie "intensywne poszukiwanie znanych bug'ów" ...
Link do wypowiedziLink
Kamil Stawiarski

Kamil Stawiarski Oracle Certified
Master | Oracle ACE

Temat: mały rozmiar buffer cache'a

Krzysztof P.:

Ale po tej zmianie dojdzie "intensywne poszukiwanie znanych bug'ów" ...
Ano tys prowda... np.: http://www.goldenline.pl/forum/2801280/library-cache-m...
Link do wypowiedziLink
Andrzej W.

Andrzej W. Oracle Database
Developer

Temat: mały rozmiar buffer cache'a

Zawsze można ustawić wyższą wartość dla parametru DB_CACHE_SIZE (powyżej tych 5GB). Wtedy przy AMM będzie to minimalna ilość pamięci przydzielona na buffer cache.
Link do wypowiedziLink
Aleksander Mathias

Aleksander Mathias Oracle DBA

Temat: mały rozmiar buffer cache'a

Krzysztof, dlaczego 60g to tragedia? Osobnym tematem sa zapytania (juz troche podrasowane i niestety czesc nie uzywa bond variables) ale tak czy tak problemy z i/o (tak mi sie wydaje) zmalalyby gdyby w buffer cachu ladowalo wiecej danych. Kamil,dzieki zasugestie, rozwaze pozbycie sie parametru memory%. Andrzej,wlasnia najbardziej sie sklaniam do twojej sugestii. Choc wciaz nie moge pojac z zego takie zachowanie bazy wynika.
Wybaczcie brak polskich znakow ale pisze to na komorce .
Link do wypowiedziLink
Paweł Grzegorz Kwiatkowski

Paweł Grzegorz Kwiatkowski Architekt
oprogramowania,
Ericsson

Temat: mały rozmiar buffer cache'a

Aleksander Mathias:
Cześć,
ostatnio doskwiera mi pewna baza (11.2.0.2 na Red Hacie), otóż cierpi czasem na braki I/O, ale rozmiar buffer cache'a wydaje się być zbyt mały.

Co to znaczy braki I/O ? Co na ten temat mówi advisor w raporcie AWRowym ? Jak zwiększysz pamięć o X% to o ile zmaleje I/O ? A może rozmiar buffer cachea nie będzie miał znaczenia bo masz pełno operacji direct path ?

Dobrze byłoby taki raport zobaczyć i zmniejszyć pole do zgadywania ;-)
Link do wypowiedziLink
Aleksander Mathias

Aleksander Mathias Oracle DBA

Temat: mały rozmiar buffer cache'a

Przez brak i/o rozumiem duze oczekiwania na np db file sequential read. advisor mowi,ze jesli zwieksze cache size o dwa razy to zyskam okolo 20% no ale dlaczego baza sama nie zmieni rozmiaru skoro ma baaardzo duzo wolnej pamieci?
Link do wypowiedziLink

konto usunięte

Temat: mały rozmiar buffer cache'a

Aleksander Mathias:
Krzysztof, dlaczego 60g to tragedia? Osobnym tematem sa zapytania (juz troche podrasowane i niestety czesc nie uzywa bond variables) ale tak czy tak problemy z i/o (tak mi sie wydaje) zmalalyby gdyby w buffer cachu ladowalo wiecej danych.

Jeśli możesz dać bazie 60G to zapewne masz serwer "na RedHacie" z minimum 80-128G ? Dobrze się domyślam, że jest to sprzęt zakupiony w ciągu ostatnich 2 lat ?

A jeśli piszesz o wersji 11.2.0.2 to zapewne przemigrowałeś bazę na tą wersję w ciągu ostatniego roku ?

Jeśli teraz piszesz o problemach z I/O nawet pomimo teoretycznie nowego sprzętu i ostatnich wersji softu to czy mogę się domyślać że w środku jest aplikacja, którą napisano "dawno ale to bardzo dawno", baza się rozrosła od tamtego czasu i gdzieś powstał "korek", który powoduje problemy z I/O ?

Nie pozwól się domyślać :) Opisz trochę środowisko :)

Wrzuć też na początek init.ora/spfile.ora, jeśli baza była migrowana z wersji 9/10g to może uda się się w nim znaleźć parę ciekawostek.
Link do wypowiedziLink
Aleksander Mathias

Aleksander Mathias Oracle DBA

Temat: mały rozmiar buffer cache'a

Krzysztof,postaram sie opisac srodowisko jak tylko znajde wygodniejszy sposob komunikacji. Jednak nawet duzy przyrost danych nie uzasadnia dziwnego wymiarowania pamieci przez baze.
Link do wypowiedziLink
Kamil Stawiarski

Kamil Stawiarski Oracle Certified
Master | Oracle ACE

Temat: mały rozmiar buffer cache'a

Aleksander Mathias:
Przez brak i/o rozumiem duze oczekiwania na np db file sequential read. advisor mowi,ze jesli zwieksze cache size o dwa razy to zyskam okolo 20% no ale dlaczego baza sama nie zmieni rozmiaru skoro ma baaardzo duzo wolnej pamieci?

db file sequential read to odczyty pojedynczych bloków - najczęściej spotykane przy index range scan albo index full scan, ale zdarza się, że i przy full table scanach się pojawiają, zwłaszcza przy dużych tabelach o wielkości ekstentów, nie będących wielokrotnością db_file_multiblock_read_count... Możesz przyjrzeć się stanowi indeksów i rozkładowi ekstentów w tabelach, możesz też pokusić się o przebudowę indeksów do przestrzeni tabel o większym bloku danych niż masz w tej chwili...

Pozdrawiam,
Kamil
Link do wypowiedziLink
Paweł Grzegorz Kwiatkowski

Paweł Grzegorz Kwiatkowski Architekt
oprogramowania,
Ericsson

Temat: mały rozmiar buffer cache'a

Aleksander Mathias:
Przez brak i/o rozumiem duze oczekiwania na np db file sequential read. advisor mowi,ze jesli zwieksze cache size o dwa razy to zyskam okolo 20% no ale dlaczego baza sama nie zmieni rozmiaru skoro ma baaardzo duzo wolnej pamieci?

Pokaż parametry startowe, to przynajmniej będą jakieś przesłanki do wyciągania wniosków :)

Czy redukcja fizycznego I/O o 20% rozwiązuje Twój problem? Czy np. I/O jest gdzie indziej wykorzystywane?
Link do wypowiedziLink
Marcin Przepiórowski

Marcin Przepiórowski Oracle ACE

Temat: mały rozmiar buffer cache'a

Krzysztof P.:
Andrzej K.:
kolegę zmiennych bindowanych , można zastosować odpowiednie ustawienie cursor_sharing ( na FORCE) który załatwi sprawę nawet jeśli aplikacja nie korzysta ze zmiennych bindowanych.

:)

Ale po tej zmianie dojdzie "intensywne poszukiwanie znanych bug'ów" ...

;) oj tak - FORCE to juz ostatecznosc.

A teraz zapytam przewrotnie czemu uwazasz ze buffer cache masz za maly ?
Analiza wydajnosci powinna rozpaczac sie od znalezienia "waskiego gardla" ( jakos to dziwnie brzmi po polsku i rodzi pewne skojarzania ) a potem juz po prostu trzeba znalesc rozwiazanie problemu.

Od 11g full table scan moga uzywac direct read path co w niektorych sytuacjach uzasadnia ustawienie malego buffer cacha na rzecz PGA. Memory target wlasnie miesza miedzy SGA i PGA i moje doswiadczenie mowi mi ze nie dziala dobrze dla duzych wartosci.
Juz lepiej ustawic sga_target i HugePages.

Co oznacza duze oczekiwanie na "db file sequential read" ? jesli to wartosc miedzy 1 a 5 ms to jest to normalne ( przy czym okolice 1 ms to czytanie bloku z cache dysku / kontrolera / systemu ) a okolice 5 ms to czytanie z fizycznego dysku ( no chyba ze mamy macierz na SSD ).

Mozesz wkleic poczatek raportu AWR ?

pozdrawiam,
Marcin
Link do wypowiedziLink
Aleksander Mathias

Aleksander Mathias Oracle DBA

Temat: mały rozmiar buffer cache'a

Marcin, zakładałem, że nawet jak zmienię DB_CACHE_SIZE na jakiś duży, to i tak mi to nic nie da, bo "chodzi o coś innego" tylko nie mogłem wyczaić dlaczego akurat takie są rozmiary pamięci i Twoje przewrotne pytanie mnie w tym utwierdziło, a jak wspomniałeś jeszcze o PGA, to myślę, że właśnie to jest klucz! W przyszłym tygodniu będę mógł to sprawdzić więc dam wam znać (przy okazji podrzucę parametry instancji i początek z AWRa).
Akurat tutaj sprawa parametrów wydaje mi się być drugorzędna, bo nie odpowiada na pytanie o rozmiar SGA, a domysły Marcina wydają mi się wielce prawdopodobne.
Krzysztof, co do historii systemu to dobrze kombinujesz, maszyna nie stara, migracja też była robiona, ale nie przeze mnie więc szczegółów nie znam (obstawiam, że robione było to przez exp/expdp a na tej maszynie wersja bazy nie była podnoszona tylko od razu postawiona teraźniejsza). Problemy z wydajnością oczywiście biorą się z ilości danych przetwarzanych, a w niektóre dni miesiąca, to robi się wręcz system raportowy.

Swoją drogą wyraźcie proszę swoją opinię o ustawieniu "_db_file_noncontig_mblock_read_count"=0, który ostatnio ustawiłem jako workaround na ORA-00600 a teraz zastanawiam się czy nie robi więcej szkód niż korzyści.

Dzięki panowie za rozjaśnienie mi tematu!
Link do wypowiedziLink
« Wróć do tematów
Odpowiedz

Podobne tematy


Następna dyskusja:

Jaki rozmiar ma backup bazy...




Wyślij zaproszenie do
Anuluj