Adaptacyjny mechanizm autovacuum w usłudze Azure Database for PostgreSQL — Serwer elastyczny

W tym artykule opisano parametry adaptive_autovacuum, obsługiwane przez usługę Azure Database for PostgreSQL — serwer elastyczny:

• adaptive_autovacuum.optimize_configurations: umożliwia automatyczne dostrajanie zestawu ustawień autovacuum.
• adaptive_autovacuum.open_transaction_threshold: ustawia próg wieku w sekundach, aby wykryć i ograniczyć stare przygotowane transakcje.

Jak działa każdy parametr

adaptive_autovacuum.optimize_configurations

Po ustawieniu tego parametru na wartość on usługa dostrajania okresowo:

1. Zbiera i agreguje sygnały obciążenia oraz statystyk tabel.
2. Ocenia przepływy pracy reguł.
3. Oblicza proponowane aktualizacje parametrów autovacuum.
4. Stosuje aktualizacje i ponownie ładuje konfigurację silnika.
5. Zapisuje wpisy inspekcji.

Jeśli nie zostaną spełnione żadne warunki reguły, przebieg może zakończyć się bez wprowadzania zmian.

Bieżące parametry dostrajania:

• autovacuum_vacuum_cost_limit
• autovacuum_vacuum_threshold
• autovacuum_vacuum_scale_factor
• autovacuum_vacuum_cost_delay
• autovacuum_analyze_scale_factor

Widoczność i działanie nadpisywania dla dostrojonych parametrów

Gdy ta funkcja zmieni dowolny z pięciu parametrów docelowych (autovacuum_vacuum_cost_limit, autovacuum_vacuum_threshold, , autovacuum_vacuum_scale_factorautovacuum_vacuum_cost_delay, autovacuum_analyze_scale_factor):

• Punkt końcowy Configurations płaszczyzny sterowania (na przykład interfejs API GET Configurations lub grupa poleceń CLI az postgres flexible-server parameter) nie wyświetla tych efektywnych zmian środowiska uruchomieniowego.
• Aby wyświetlić obowiązujące wartości, użyj zapytań płaszczyzny danych względem punktu końcowego PostgreSQL (na przykład SHOW <guc_name> lub SELECT name, setting FROM pg_settings WHERE name IN (...)).

Semantyka nadpisania przez użytkownika:

• Dowolne z tych pięciu parametrów można ustawić bezpośrednio za pośrednictwem portalu, interfejsu API REST, interfejsu wiersza polecenia lub dowolnego z obsługiwanych zestawów SDK.
• Jeśli ustawisz parametr na tę samą wartość, którą obecnie zwraca punkt końcowy konfiguracji płaszczyzny sterowania, operacja jest traktowana jako no-op i nie zostanie zastosowana żadna nowa efektywna zmiana.
• Wartości ustawione przez użytkownika zastępują wartości ustawione przez funkcję w chwili ich zastosowania.
• Jeśli adaptive_autovacuum.optimize_configurations pozostanie włączone, kolejne iteracje dostrajania mogą ponownie zastosować nowe wartości na podstawie oceny reguły.

adaptive_autovacuum.open_transaction_threshold

Ten parametr steruje ograniczeniem ryzyka przygotowanych transakcji oddzielonych:

• Wartość 0 oznacza wyłączoną.
• Wartość większa niż 0 oznacza, że funkcja jest włączona, a próg jest podany w sekundach.

Po włączeniu, jeśli najstarsza przygotowana transakcja przekroczy próg, program obsługi oddzielonych transakcji ocenia uprawnienia i może wycofać stare przygotowane transakcje. Moduł obsługi aktualizuje próg przechowywany w pamięci przy zmianach parametrów, więc jego działanie jest zgodne z najnowszą wartością.

Ważny szczegół dotyczący czasu:

• Funkcja najpierw określa najstarszy przygotowany znacznik czasu transakcji.
• To wykrywanie jest oparte na sondach, a nie ciągłe.
• Sondowanie odbywa się co 1,800 sekund (czyli co 30 minut), więc działania zaradcze mogą się rozpocząć dopiero po tym, jak sondowanie wykryje odpowiednio starą przygotowaną transakcję.

Zachowanie środowiska uruchomieniowego i harmonogramowania

• optimize_configurations Cykl dostrajania jest co 30 minut.
• Po włączeniu opcji optimize_configurations uruchamia się natychmiast proces dostrajania, a następnie odbywają się kolejne zaplanowane uruchomienia.
• Obsługa open_transaction_threshold jest sterowana zdarzeniami na podstawie obserwacji przygotowanych transakcji. Środki zaradcze są uruchamiane tylko wtedy, gdy kontrole wieku przekraczają próg.
• Obserwacja przygotowanej transakcji dla open_transaction_threshold jest odświeżana co 300 sekund.

Kiedy po włączeniu tworzony jest intelligentperformance schemat?

Schemat intelligentperformance jest tworzony w bazie azure_sys danych. Jego utworzenie nie następuje od razu; odpowiada za nie funkcjonalność zapisująca statystyki używane przez adaptacyjne autovacuum, a nie samo początkowe uruchomienie dostrajania. Zazwyczaj schemat jest tworzony w ciągu 0–30 minut po włączeniu funkcji.

Możesz włączyć adaptacyjne automatyczne odkurzanie, ustawiając adaptive_autovacuum.optimize_configurations na on lub konfigurując adaptive_autovacuum.open_transaction_threshold na wartość różną od zera (czyli > 0). Schemat jest tworzony po aktywowaniu funkcji i rozpoczyna zbieranie wymaganych statystyk.

Tworzenie może zostać opóźnione lub pominięte, jeśli nie zostaną spełnione pewne wymagania wstępne.

Ograniczenia i wymagania wstępne

Oba mechanizmy kontroli podlegają następującym wymaganiom:

• Instancja musi być instancją główną.
• Usługa PostgreSQL nie jest w trybie odzyskiwania.
• Zasoby obliczeniowe serwera obejmują co najmniej 4 rdzenie wirtualne.
• Serwer jest zwykłym serwerem elastycznym, a nie klastrem elastycznym. Ta funkcja nie jest obsługiwana w klastrach elastycznych.
• adaptive_autovacuum.optimize_configurations jest obsługiwane w głównych wersjach 14 i nowszych.
• adaptive_autovacuum.open_transaction_threshold jest obsługiwane w głównych wersjach 13 i nowszych.

Inspekcja i obserwowanie

System rejestruje akcje obu kontrolek w widoku inspekcji o nazwie intelligentperformance.adaptive_tuning_events.

Schemat widoku

Oczekiwany kształt logiczny:

• intelligentperformance.adaptive_tuning_events
  • szczegóły wydarzenia
  • optimizer_type
  • applied_at

Wykonywanie zapytań dotyczących ostatnich działań

Aby wykonywać zapytania dotyczące ostatnich działań, użyj następujących zapytań:

SELECT
    applied_at,
    optimizer_type,
    event_details
FROM intelligentperformance.adaptive_tuning_events
ORDER BY applied_at DESC
LIMIT 100;

SELECT
    optimizer_type,
    COUNT(*) AS events
FROM intelligentperformance.adaptive_tuning_events
WHERE applied_at >= now() - interval '7 days'
GROUP BY optimizer_type
ORDER BY events DESC;

Typy zdarzeń i interpretacja

Kolumna optimizer_type wskazuje źródło akcji.

zmieniono_konfigurację_adaptacyjnego_autovacuum

Źródło:

• optimize_configurations ścieżka dostrajania.

Kształt ładunku:

• Tablica JSON rekordów zmiany parametrów, zazwyczaj w tym:
  • server_parameter_name
  • poprzednia_wartość
  • zaktualizowana_dostrojona_wartość

Interpretacja:

• Wskazuje, że dostrajanie funkcji autovacuum zmieniło ustawienia serwera.
• Pozytywne, gdy kolejne metryki obciążenia wskazują poprawę (presja związana z martwymi krotkami, częstotliwość odkurzania, opóźnienia, CPU/WE/WY).
• Potencjalnie ujemne, gdy zmiany są częste i oscylacyjne i następują regresje.

SELECT
    applied_at,
    elem->>'server_parameter_name' AS parameter_name,
    elem->>'previous_value' AS previous_value,
    elem->>'updated_tuned_value' AS updated_value
FROM intelligentperformance.adaptive_tuning_events e
CROSS JOIN LATERAL jsonb_array_elements(e.event_details) AS elem
WHERE e.optimizer_type = 'adaptive_autovacuum_configuration_changed'
ORDER BY applied_at DESC;

wycofanie osieroconej transakcji

Źródło:

• open_transaction_threshold ścieżka łagodzenia.

Kształt ładunku:

• Obiekt JSON z kluczami będącymi nazwami baz danych, zawierający szczegóły wyniku wycofania (na przykład informacje o próbach i pomyślnych wycofaniach GID).

{
    "<example-database-name>": {
        "Timestamp": "2026-03-22T18:20:22.0000000Z", 
        "RollbackGids": ["<example-global-identifier-one>", "<example-global-identifier-two>"], 
        "OperationSuccessful": true
    }
}

Interpretacja:

• Wskazuje, że przygotowane transakcje zostały przymusowo wycofane po przekroczeniu progu.
• Sporadyczne zachowania mogą stanowić zdrowe zachowania ochronne.
• Częste zdarzenia zwykle wskazują problemy z cyklem życia transakcji aplikacji, które należy zbadać.

SELECT
    applied_at,
    jsonb_pretty(event_details) AS rollback_details
FROM intelligentperformance.adaptive_tuning_events
WHERE optimizer_type = 'orphan_transaction_rollback'
ORDER BY applied_at DESC
LIMIT 50;

Określanie, czy wpływ jest pozytywny, czy negatywny

Dla optimize_configurations:

1. Zidentyfikuj znaczniki czasu zmian z adaptive_autovacuum_configuration_changed.
2. Porównaj okna 30-, 60-, 90- i 120-minutowe po zmianie pod kątem liczby martwych krotek, częstotliwości wykonywania VACUUM/ANALYZE, opóźnień oraz użycia CPU i operacji we/wy.

Dla open_transaction_threshold:

1. Zidentyfikuj zdarzenia orphan_transaction_rollback.
2. Sprawdź, czy częstotliwość wycofań jest niska i czy się stabilizuje.
3. Zbadaj zachowanie aplikacji, jeśli zdarzenia wycofywania są trwałe.

SELECT
    applied_at,
    optimizer_type,
    event_details
FROM intelligentperformance.adaptive_tuning_events
WHERE applied_at >= now() - interval '7 days'
ORDER BY applied_at DESC;

Retencja i porządkowanie

Mechanizm porządkowania usuwa starsze wpisy z magazynu audytu, stosując stały, niekonfigurowalny okres przechowywania wynoszący 90 dni.

Do długoterminowej analizy trendów wyeksportuj wiersze audytu do własnego magazynu danych obserwowalności.

Treści powiązane

• Inteligentne dostrajanie.