Ogranicz stopień równoległości (DOP) dostępnej dla dowolnego zapytania

Na Oracle Exadata (11gR2) mamy stosunkowo rozbudowaną bazę danych.

• cpu_count to 24
• równoległe_serwery_instancji to 2
• parallel_threads_per_cpu to 2

Zauważyliśmy, obserwując w Oracle Enterprise Manager (OEM), że wydajność była okropna z powodu seryjnego wykonywania zapytań. Aby rozwiązać ten problem, wszystkie tabele, zmaterializowane widoki i indeksy zostały zmienione, aby wykorzystać równoległość. na przykład:

ALTER TABLE SOME_TABLE PARALLEL (DEGREE DEFAULT INSTANCES DEFAULT);

System został zmieniony, aby włączyć równoległość:

ALTER SYSTEM SET PARALLEL_DEGREE_POLICY = 'AUTO';

Spowodowało to lepszą wydajność, ale od czasu do czasu zauważyliśmy w OEM, że pojedyncze zapytanie wiązałoby DOP 96 (wszystkie dostępne zasoby). Spowodowało to obniżenie poziomu kolejnych zapytań do DOP równego 1 (brak równoległości). Powoduje słabą wydajność, dopóki kwerenda zaczepiania nie zostanie zakończona.

Aby rozwiązać ten problem, próbowaliśmy ograniczyć dostępną DOP do dowolnego zapytania za pomocą:

ALTER SYSTEM SET PARALLEL_DEGREE_LIMIT = 24;

To nie miało wpływu. Często obserwujemy zapytania, które wykorzystają więcej niż limit (zazwyczaj 48 lub 96, ale nie ma rzeczywistego wzorca).

Jak zapobiegamy blokowaniu jednego dostępnego zasobu przez jedno zapytanie?

Zestawy serwerów równoległych: PARALLEL_DEGREE_LIMIT ogranicza stopień równoległości, ale jeśli twoje zapytanie sortuje lub grupuje, liczba równoległych procesów może być dwa razy większa (dwa zestawy serwerów, aby umożliwić równoległość między procesami). To wyjaśnia, dlaczego zobaczysz 48 równoległych procesów, nawet z limitem 24. Zdarza się to również, jeśli używasz menedżera zasobów, aby ograniczyć DOP.

Wskazówki dotyczące równoległości: PARALLEL_DEGREE_LIMIT dotyczy tylko instrukcji, które używają automatycznego stopnia równoległości. Wszelkie instrukcje, które wykorzystują zakodowany stopień lub nawet dowolny typ równoległej wskazówki na poziomie obiektu, zignorują limit. Jeśli masz te wskazówki, może to wyjaśniać, dlaczego czasami widzisz 96.

Kalibruj IO: Być może automatyczny DOP nie jest używany, a zatem limit nie jest przestrzegany, ponieważ IO nie zostało skalibrowane . To zapytanie powie ci, czy IO zostało skalibrowane:

select * from V$IO_CALIBRATION_STATUS;

Widziałem już to powodujące problemy, ale mój obecny system nie jest skalibrowany i wydaje się, że automatyczny DOP działa dobrze. Możesz stwierdzić, czy to naprawdę problem, patrząc na sekcję Notatki w planie wyjaśniania. Jeśli widzisz coś w - automatic DOP: Computed Degree of Parallelism is 2porządku, ale nie chcesz tego widzieć automatic DOP: skipped because of IO calibrate statistics are missing.

Zwiększ PARALLEL_MAX_SERVERS: Zamiast martwić się brakiem serwerów równoległych, zalecam znaczne zwiększenie PARALLEL_MAX_SERVERS. Powinieneś przynajmniej spróbować wrócić do wartości domyślnej PARALLEL_THREADS_PER_CPU x CPU_COUNT x concurrent_parallel_users x 5, między 240 a 960, w zależności od ustawień pamięci.

Te wysokie liczby brzmią absurdalnie dla wielu DBA, ale w rzeczywistości mają sens z następujących powodów:

• Serwery równoległe Oracle są lżejsze niż większość ludzi zakłada. (I mało kto go testuje, po prostu znajduje jedną sytuację, w której duży DOP powoduje problem i zakłada, że ​​wysoki DOP jest zawsze zły).
• Często uruchamia się zapytanie adhoc w narzędziu GUI, które pobiera tylko pierwsze 50 wierszy, ale nadal korzysta z dziesiątek równoległych serwerów. Te zapytania NIE zużywają znaczących zasobów, chyba że PARALLEL_MAX_SERVERS jest zbyt niski. Wtedy ludzie są wyzywani za uruchamianie całkowicie rozsądnych zapytań, które mogą prowadzić do brzydkich sytuacji.
• Bardzo duży DOP dla pojedynczego zapytania nie zawsze jest zły. Wszyscy zakładają, że jeśli będziesz dalej zwiększać DOP, narzut będzie zbyt wysoki, a wydajność znacznie spadnie. Ale w wielu systemach zauważyłem, że nawet absurdalnie wysoki DOP doprowadzi do lepszej wydajności, chociaż zdecydowanie spadają zyski i może być bardzo niesprawiedliwe w stosunku do innych sesji. Ale nie zgaduj, przetestuj; weź zapytanie i uruchom je z wszystkimi rodzajami DOP, nawet do 1000. Możesz być zaskoczony.
• Tak, zbyt duża równoległość może być zła. Ale co gorsza dla systemu, mając nieco więcej niż optymalną liczbę sesji lub zmuszając zapytanie do szeregowania i w zasadzie zabijając ważną pracę? Powinieneś monitorować system przed wprowadzeniem arbitralnych limitów.