Scenariusze użycia magazynu zapytań — Azure Database for PostgreSQL — serwer elastyczny

DOTYCZY: Azure Database for PostgreSQL — serwer elastyczny

Magazyn zapytań można używać w wielu różnych scenariuszach, w których śledzenie i utrzymywanie przewidywalnej wydajności obciążenia ma kluczowe znaczenie. Rozważ następujące przykłady:

• Identyfikowanie i dostrajanie najdroższych zapytań.
• Testowanie A/B.
• Utrzymanie stabilności wydajności podczas uaktualniania.
• Identyfikowanie i ulepszanie improwizowanych obciążeń.

Identyfikowanie i dostrajanie kosztownych zapytań

Identyfikowanie najdłużej działających zapytań

Użyj widoków magazynu zapytań w bazie danych azure_sys serwera, aby szybko zidentyfikować najdłużej działające zapytania. Te zapytania zwykle zużywają większość zasobów. Optymalizacja najdłużej działających zapytań może zwiększyć wydajność, zwalniając zasoby używane przez inne zapytania uruchomione w systemie.

Zapytania docelowe ze różnicami wydajności

Magazyn zapytań dzieli dane wydajności na okna czasowe, dzięki czemu można śledzić wydajność zapytania w czasie. Ułatwia to zidentyfikowanie dokładnie, które zapytania przyczyniają się do zwiększenia ogólnego czasu spędzonego. W rezultacie można wykonać ukierunkowane rozwiązywanie problemów z obciążeniem.

Dostrajanie kosztownych zapytań

Po zidentyfikowaniu zapytania z nieoptymalną wydajnością akcja, którą podejmujesz, zależy od charakteru problemu. Niektóre z tych akcji mogą być następujące:

• Upewnij się, że statystyki są aktualne dla bazowych tabel używanych przez zapytanie.
• Rozważ ponowne zapisywanie kosztownych zapytań. Na przykład skorzystaj z parametryzacji zapytań i zmniejsz użycie dynamicznego języka SQL. Zaimplementuj optymalną logikę podczas odczytywania danych, takich jak stosowanie filtrowania danych po stronie bazy danych, zamiast wykonywać je po stronie aplikacji.

Testowanie A/B:

Użyj magazynu zapytań, aby porównać wydajność obciążenia przed i po zmianie aplikacji, którą planujesz wprowadzić lub przed i po migracji. Przykładowe scenariusze używania magazynu zapytań do oceny wpływu zmian wydajności obciążenia:

• Migrowanie między głównymi wersjami bazy danych PostgreSQL.
• Wdrażanie nowej wersji aplikacji.
• Modyfikowanie ilości zasobów przyznanych serwerowi.
• Zmiana dowolnych parametrów serwera, które wpływają na zachowanie serwera.
• Tworzenie brakujących indeksów w tabelach, do których odwołuje się kosztowne zapytania.
• Migrowanie z pojedynczego serwera usługi Azure Database for PostgreSQL do serwera elastycznego usługi Azure Database for PostgreSQL.

W każdym z tych scenariuszy zastosuj następujący przepływ pracy:

1. Uruchom obciążenie z magazynem zapytań przed planowaną zmianą, aby wygenerować punkt odniesienia wydajności.
2. Zastosuj żądane zmiany w kontrolowanym momencie w czasie.
3. Kontynuuj uruchamianie obciążenia, wystarczająco długo, aby wygenerować obraz wydajności systemu po zmianie.
4. Porównaj wyniki z przed i po zmianie.
5. Zdecyduj, czy zmiana ma być zachowana, czy wycofana.

Identyfikowanie i ulepszanie improwizowanych obciążeń

Niektóre obciążenia nie mają dominujących zapytań, które można dostosować, aby poprawić ogólną wydajność aplikacji. Te obciążenia są zwykle charakteryzujące się stosunkowo dużą liczbą unikatowych zapytań, z których każda zużywa część zasobów systemowych. Każde unikatowe zapytanie jest wykonywane rzadko, więc indywidualne użycie środowiska uruchomieniowego nie ma krytycznego znaczeniu. Z drugiej strony, biorąc pod uwagę, że aplikacja generuje nowe zapytania przez cały czas, znaczna część zasobów systemowych jest poświęcana na kompilację zapytań, która nie jest optymalna. Zazwyczaj taka sytuacja występuje, jeśli aplikacja generuje zapytania (zamiast używać procedur składowanych lub sparametryzowanych zapytań) lub jeśli opiera się na strukturach mapowania obiektów, które domyślnie generują zapytania.

Jeśli kontrolujesz kod aplikacji, możesz rozważyć ponowne zapisanie warstwy dostępu do danych w celu użycia procedur składowanych lub sparametryzowanych zapytań. Można jednak poprawić tę sytuację bez zmian aplikacji, wymuszając parametryzacja zapytań dla całej bazy danych (wszystkich zapytań) lub dla poszczególnych szablonów zapytań z tym samym skrótem zapytania.

Następny krok