Kiedy wprowadzać zmiany do progu kosztów dla równoległości

Podczas badania problemu z wydajnością zauważyłem napływ CXPACKETS, co sugeruje, że muszę przyjrzeć się progowi kosztów dla równoległości i być może MAXDOP.

Przed wprowadzeniem jakichkolwiek drastycznych zmian w MAXDOP mam do czynienia z radą wielu innych, w tym @mrdenny w odpowiedzi na CXPACKET Waits dostrajanie wydajności dla SQL Server 2008 i odpowiedź @ aron-Bertrand z Dealing with CXPACKET czeka - ustawienie progu kosztów dla równoległości . Dodałem do konserwacji, aby w pełni aktualizować statystyki co noc. To wydaje się rozsądnym ruchem.

Jednak modyfikowanie progu kosztów wciąż mnie dręczy.

W którym momencie należy zmienić próg kosztów dla równoległości? Czy ktoś ma przykład, gdzie (po zbadaniu kosztów swoich zapytań i obciążenia) wprowadził zmiany do tego kosztu?

Przeprasza, jeśli na to pytanie odpowiedziano w poprzednim pytaniu.

Dzięki!

Użycie MAXDOP = 1 może być pomocne, ale to duża broń. Być może faktycznym problemem jest przydatność indeksów. Być może nowy lub inny indeks rozwiązałby problem.

Czy po komentarzach Denny'ego i Aarona Bertranda odkryłeś, jakie inne oczekiwania w związku z tym mogły być przyczyną oczekiwania CXPACKET?

Jonathan Kehayias zasugerował zapytanie, które może pomóc ci ocenić twoje doświadczenie równoległości i podjąć bardziej przemyślaną decyzję. Ale powinieneś także przeczytać rozmowę Jonathana i Paula White'a.

https://www.sqlskills.com/blogs/jonathan/tuning-cost-threshold-for-parallelism-from-the-plan-cache/

Proponuję najpierw zajrzeć do ustawień MAXDOP, ponieważ domyślne ustawienie 0 (użyj wszystkich dostępnych wątków) może być niebezpieczne, ponieważ niekontrolowane zapytanie zajmujące wszystkie dostępne wątki doprowadzi do głodu wątku.

Zapoznaj się z moją odpowiedzią tutaj, aby obliczyć ustawienie MAXDOP dla instancji serwera.

Próg kosztu równoległości odnosi się do minimalnego kosztu zapytania, zanim optymalizator rozważy równoległość.

Pamiętaj, że CXPACKET czeka tylko symptomy z powodu czegoś złego związanego z zapytaniem - nieaktualnych statystyk lub brakującego indeksu skutkującego złym lub innym planem.

Możesz użyć sys.dm_exec_cached_plansi sys.dm_exec_query_planDMV do wydobywania informacji z pamięci podręcznej planu, jak opisano w Dostrajanie „progu kosztu równoległości” z pamięci podręcznej planu Jonathana i Próg kosztu równoległości .

Sugerowałbym pozostawienie cost threshold for parallelismdomyślnego ustawienia, chyba że wyczerpałeś kwerendy dostrajania zasobów, przeprowadzania konserwacji indeksów i statystyk, a także sprawdzania, czy nie masz żadnych brakujących indeksów, które mogłyby przynieść korzyści dla zapytania.

Uwaga: Ustawienie Maxdop można również zastosować na poziomie zapytania, za pomocą OPTION (MAXDOP n)którego zastąpi ono ustawienie całego serwera.