Dostrajanie automatycznego czyszczenia w usłudze Azure Database for PostgreSQL — serwer elastyczny
DOTYCZY: 
Azure Database for PostgreSQL — serwer elastyczny
Ten artykuł zawiera omówienie funkcji automatycznego czyszczenia dla elastycznego serwera usługi Azure Database for PostgreSQL oraz przewodniki rozwiązywania problemów funkcji, które są dostępne do monitorowania wydmuchania bazy danych, bloków automatycznego czyszczenia. Zawiera również informacje o tym, jak daleko baza danych pochodzi z sytuacji awaryjnej lub zawijania.
Co to jest autovacuum
Autovacuum to proces w tle postgreSQL, który automatycznie czyści martwe krotki i aktualizuje statystyki. Ułatwia utrzymanie wydajności bazy danych przez automatyczne uruchamianie dwóch kluczowych zadań konserwacji:
- VACUUM — zwalnia miejsce na dysku, usuwając martwe krotki.
- ANALYZE — zbiera statystyki ułatwiające optymalizatorowi postgreSQL wybieranie najlepszych ścieżek wykonywania zapytań.
Aby zapewnić prawidłowe działanie automatycznego czyszczenia, parametr serwera automatycznego czyszczenia powinien być zawsze ustawiony na wartość WŁĄCZONE. Po włączeniu baza danych PostgreSQL automatycznie decyduje o tym, kiedy należy uruchomić narzędzie VACUUM lub ANALYZE w tabeli, zapewniając, że baza danych pozostaje wydajna i zoptymalizowana.
Wewnętrzne elementy automatycznej wyvacuum
Autovacuum odczytuje strony szukające martwych krotek, a jeśli żadna z nich nie zostanie znaleziona, funkcja automatycznego czyszczenia odrzuci stronę. Gdy autovacuum znajdzie martwe krotki, usuwa je. Koszt jest oparty na:
| Parametr | Opis |
|---|---|
vacuum_cost_page_hit |
Koszt odczytu strony, która jest już w udostępnionych i nie wymaga odczytu dysku. Wartość domyślna jest ustawiona na 1. |
vacuum_cost_page_miss |
Koszt pobierania strony, która nie znajduje się w udostępnionych. Wartość domyślna jest ustawiona na 10. |
vacuum_cost_page_dirty |
Koszt zapisu na stronie, gdy w niej znajdują się martwe krotki. Wartość domyślna jest ustawiona na 20. |
Ilość pracy wykonywanej automatycznie czyszczenia zależy od dwóch parametrów:
| Parametr | Opis |
|---|---|
autovacuum_vacuum_cost_limit |
Ilość pracy autovacuum działa w jednym miejscu. |
autovacuum_vacuum_cost_delay |
Liczba milisekund śpi po osiągnięciu limitu kosztów określonego autovacuum_vacuum_cost_limit przez parametr . |
We wszystkich obecnie obsługiwanych wersjach bazy danych Postgres wartość autovacuum_vacuum_cost_limit domyślna to 200 (wartość domyślna to -1, co sprawia, że jest równa wartości zwykłej vacuum_cost_limit, która domyślnie wynosi 200).
Jeśli chodzi o autovacuum_vacuum_cost_delayparametr , w wersji Postgres w wersji 11 domyślnie jest to 20 milisekund, podczas gdy w wersji Postgres w wersji 12 i powyżej domyślnie jest to 2 milisekundy.
Autovacuum budzi się 50 razy (50*20 ms=1000 ms) co sekundę. Za każdym razem, gdy się budzi, funkcja automatycznego czyszczenia odczytuje 200 stron.
Oznacza to, że w jednej sekundzie funkcja automatycznego czyszczenia może wykonywać następujące czynności:
- ~80 MB/s [ (200 stron/
vacuum_cost_page_hit) * 50 * 8 KB na stronę] jeśli wszystkie strony ze martwymi krotkami znajdują się w udostępnionych. - ~8 MB/s [ (200 stron/
vacuum_cost_page_miss) * 50 * 8 KB na stronę], jeśli wszystkie strony ze martwych krotki są odczytywane z dysku. - ~4 MB/s [ (200 stron/
vacuum_cost_page_dirty) * 50 * 8 KB na stronę] automatyczne czyszczenie może zapisywać do 4 MB/s.
Monitorowanie automatycznego czyszczenia
Użyj następujących zapytań do monitorowania automatycznego czyszczenia:
select schemaname,relname,n_dead_tup,n_live_tup,round(n_dead_tup::float/n_live_tup::float*100) dead_pct,autovacuum_count,last_vacuum,last_autovacuum,last_autoanalyze,last_analyze from pg_stat_all_tables where n_live_tup >0;
Poniższe kolumny pomagają określić, czy autovacuum nadrabia zaległości w działaniu tabeli:
| Parametr | Opis |
|---|---|
dead_pct |
Procent martwych krotki w porównaniu do żywych krotki. |
last_autovacuum |
Data ostatniej godziny, w których tabela została automatycznie wywatowana. |
last_autoanalyze |
Data ostatniej analizy tabeli. |
Wyzwalanie automatycznego czyszczenia
Akcja automatycznego czyszczenia ( ANALYZE lub VACUUM) wyzwala, gdy liczba martwych krotek przekracza określoną liczbę zależną od dwóch czynników: łączną liczbę wierszy w tabeli oraz stały próg. Funkcja ANALYZE domyślnie wyzwala, gdy zmienia się 10% tabeli oraz 50 wierszy, a funkcja VACUUM wyzwala 20% tabeli oraz 50 wierszy. Ponieważ próg PRÓŻNI jest dwa razy większy niż próg ANALIZY, funkcja ANALYZE zostaje wyzwolona wcześniej niż PRÓŻNIA. W przypadku wersji >PG =13; Funkcja ANALIZUJ domyślnie jest wyzwalana, gdy 20% tabeli plus 1000 wstawień wierszy.
Dokładne równania dla każdej akcji to:
- Autoanaliza = autovacuum_analyze_scale_factor * krotki + autovacuum_analyze_threshold lub autovacuum_vacuum_insert_scale_factor * krotki + autovacuum_vacuum_insert_threshold (w przypadku wersji >PG = 13)
- Autovacuum = autovacuum_vacuum_scale_factor * krotki + autovacuum_vacuum_threshold
Jeśli na przykład mamy tabelę z 100 wierszami. Poniższe równanie zawiera następnie informacje na temat wyzwalaczy analizy i próżni:
W przypadku aktualizacji/usuwania: Autoanalyze = 0.1 * 100 + 50 = 60
Autovacuum = 0.2 * 100 + 50 = 70
Wyzwalacze analizy po zmianie 60 wierszy w tabeli i wyzwalacza próżni po zmianie 70 wierszy w tabeli.
W przypadku wstawiania: Autoanalyze = 0.2 * 100 + 1000 = 1020
Analizowanie wyzwalaczy po wstawieniu 1020 wierszy w tabeli
Oto opis parametrów używanych w równaniu:
| Parametr | Opis |
|---|---|
autovacuum_analyze_scale_factor |
Procent wstawiania/aktualizacji/usuwania, który wyzwala analizę w tabeli. |
autovacuum_analyze_threshold |
Określa minimalną liczbę krotki wstawionych/zaktualizowanych/usuniętych do analizy tabeli. |
autovacuum_vacuum_insert_scale_factor |
Procent wstawiania wyzwalających ANLYZE w tabeli. |
autovacuum_vacuum_insert_threshold |
Określa minimalną liczbę krotki wstawionych do tabeli ANALYZE. |
autovacuum_vacuum_scale_factor |
Procent aktualizacji/usuwania, który wyzwala próżnię w tabeli. |
Użyj następującego zapytania, aby wyświetlić listę tabel w bazie danych i zidentyfikować tabele, które kwalifikują się do procesu automatycznego czyszczenia:
SELECT *
,n_dead_tup > av_threshold AS av_needed
,CASE
WHEN reltuples > 0
THEN round(100.0 * n_dead_tup / (reltuples))
ELSE 0
END AS pct_dead
FROM (
SELECT N.nspname
,C.relname
,pg_stat_get_tuples_inserted(C.oid) AS n_tup_ins
,pg_stat_get_tuples_updated(C.oid) AS n_tup_upd
,pg_stat_get_tuples_deleted(C.oid) AS n_tup_del
,pg_stat_get_live_tuples(C.oid) AS n_live_tup
,pg_stat_get_dead_tuples(C.oid) AS n_dead_tup
,C.reltuples AS reltuples
,round(current_setting('autovacuum_vacuum_threshold')::INTEGER + current_setting('autovacuum_vacuum_scale_factor')::NUMERIC * C.reltuples) AS av_threshold
,date_trunc('minute', greatest(pg_stat_get_last_vacuum_time(C.oid), pg_stat_get_last_autovacuum_time(C.oid))) AS last_vacuum
,date_trunc('minute', greatest(pg_stat_get_last_analyze_time(C.oid), pg_stat_get_last_autoanalyze_time(C.oid))) AS last_analyze
FROM pg_class C
LEFT JOIN pg_namespace N ON (N.oid = C.relnamespace)
WHERE C.relkind IN (
'r'
,'t'
)
AND N.nspname NOT IN (
'pg_catalog'
,'information_schema'
)
AND N.nspname !~ '^pg_toast'
) AS av
ORDER BY av_needed DESC ,n_dead_tup DESC;
Uwaga
Zapytanie nie bierze pod uwagę, że automatyczne czyszczenie można skonfigurować dla poszczególnych tabel przy użyciu polecenia DDL "alter table".
Typowe problemy z automatycznym czyszczeniem
Zapoznaj się z poniższą listą możliwych typowych problemów z procesem automatycznego czyszczenia.
Nie nadążanie za zajętym serwerem
Proces automatycznego czyszczenia szacuje koszt każdej operacji we/wy, akumuluje sumę dla każdej wykonywanej operacji i wstrzymuje się po osiągnięciu górnego limitu kosztów. autovacuum_vacuum_cost_delay i autovacuum_vacuum_cost_limit to dwa parametry serwera, które są używane w procesie.
Domyślnie autovacuum_vacuum_cost_limit jest ustawiona wartość –1, co oznacza, że limit kosztów automatycznego czyszczenia jest taką samą wartością jak parametr vacuum_cost_limit, który domyślnie wynosi 200. vacuum_cost_limit jest kosztem ręcznego czyszczenia.
Jeśli autovacuum_vacuum_cost_limit jest ustawiona -1wartość , funkcja automatycznego czyszczenia używa parametru vacuum_cost_limit , ale jeśli autovacuum_vacuum_cost_limit sam parametr jest ustawiony na większy niż -1 autovacuum_vacuum_cost_limit parametr, jest brany pod uwagę.
W przypadku, gdy funkcja automatycznego czyszczenia nie utrzymuje się, można zmienić następujące parametry:
| Parametr | Opis |
|---|---|
autovacuum_vacuum_cost_limit |
Wartość domyślna: 200. Limit kosztów może zostać zwiększony. Użycie procesora CPU i we/wy w bazie danych powinno być monitorowane przed wprowadzeniem zmian i po ich wprowadzeniu. |
autovacuum_vacuum_cost_delay |
Postgres w wersji 11 — ustawienie domyślne: 20 ms. Parametr może zostać zmniejszony do 2-10 ms.Postgres w wersji 12 lub nowszej — ustawienie domyślne: 2 ms. |
Uwaga
- Wartość
autovacuum_vacuum_cost_limitjest dystrybuowana proporcjonalnie między uruchomionymi procesami roboczymi automatycznego czyszczenia, więc jeśli istnieje więcej niż jeden, suma limitów dla każdego procesu roboczego nie przekracza wartości parametruautovacuum_vacuum_cost_limit. autovacuum_vacuum_scale_factorjest innym parametrem, który może wyzwalać próżnię w tabeli na podstawie martwej akumulacja krotki. Ustawienie domyślne:0.2, Dozwolony zakres:0.05 - 0.1. Współczynnik skalowania jest specyficzny dla obciążenia i powinien być ustawiany w zależności od ilości danych w tabelach. Przed zmianą wartości zbadaj obciążenie i poszczególne woluminy tabeli.
Funkcja automatycznego czyszczenia stale działa
Ciągłe uruchamianie automatycznego czyszczenia może mieć wpływ na wykorzystanie procesora CPU i operacji we/wy na serwerze. Oto niektóre z możliwych powodów:
maintenance_work_mem
Demon autovacuum używa autovacuum_work_mem , który jest domyślnie ustawiony na -1 znaczenie autovacuum_work_mem będzie miał taką samą wartość jak parametr maintenance_work_mem. W tym dokumencie przyjęto założenie autovacuum_work_mem , że -1 jest ustawiona wartość i maintenance_work_mem jest używana przez demona automatycznego czyszczenia.
Jeśli maintenance_work_mem jest niska, może zostać zwiększona do 2 GB na serwerze elastycznym usługi Azure Database for PostgreSQL. Ogólną regułą jest przydzielenie 50 MB na maintenance_work_mem każdy 1 GB pamięci RAM.
Duża liczba baz danych
Funkcja automatycznego czyszczenia próbuje uruchomić proces roboczy w każdej bazie danych co autovacuum_naptime sekundy.
Jeśli na przykład serwer ma 60 baz danych i autovacuum_naptime jest ustawiony na 60 sekund, proces roboczy automatycznego czyszczenia uruchamia się co sekundę [autovacuum_naptime/liczba baz danych].
Dobrym pomysłem jest zwiększenie liczby autovacuum_naptime baz danych w klastrze. Jednocześnie proces automatycznego czyszczenia może być bardziej agresywny przez zwiększenie i zmniejszenie autovacuum_cost_delay parametrów oraz zwiększenie autovacuum_cost_limit autovacuum_max_workers wartości domyślnej od 3 do 4 lub 5.
Błędy braku pamięci
Zbyt agresywne maintenance_work_mem wartości mogą okresowo powodować błędy braku pamięci w systemie. Przed zmianą parametru maintenance_work_mem ważne jest zrozumienie dostępnej pamięci RAM na serwerze.
Automatyczne wyczyszczenie jest zbyt destrukcyjne
Jeśli automatyczne czyszczenie zużywa więcej zasobów, można wykonać następujące czynności:
Parametry automatycznego czyszczenia
Oceń parametry autovacuum_vacuum_cost_delay, , autovacuum_vacuum_cost_limitautovacuum_max_workers. Nieprawidłowe ustawienie parametrów automatycznego czyszczenia może prowadzić do scenariuszy, w których automatyczna vacuum staje się zbyt destrukcyjna.
Jeśli automatyczne czyszczenie jest zbyt destrukcyjne, rozważ następujące działania:
- Zwiększ
autovacuum_vacuum_cost_delayi zmniejszautovacuum_vacuum_cost_limit, jeśli ustawiono wartość wyższą niż wartość domyślna 200. - Zmniejsz liczbę wartości w przypadku ustawienia wyższego
autovacuum_max_workersniż wartość domyślna 3.
Zbyt wiele procesów roboczych automatycznego czyszczenia
Zwiększenie liczby procesów roboczych automatycznego czyszczenia nie zwiększa szybkości próżni. Posiadanie dużej liczby procesów automatycznego czyszczenia nie jest zalecane.
Zwiększenie liczby procesów roboczych automatycznego czyszczenia powoduje większe zużycie pamięci, a w zależności od wartości parametru maintenance_work_mem może spowodować obniżenie wydajności.
Każdy proces roboczy automatycznego czyszczenia pobiera tylko (1/autovacuum_max_workers) całkowitej autovacuum_cost_limitliczby procesów roboczych, więc duża liczba procesów roboczych powoduje, że każdy z nich działa wolniej.
Jeśli liczba pracowników zostanie zwiększona, autovacuum_vacuum_cost_limit należy również zwiększyć i/lub autovacuum_vacuum_cost_delay zmniejszyć, aby proces próżniowy był szybszy.
Jeśli jednak ustawimy parametr na poziomie autovacuum_vacuum_cost_delay tabeli lub autovacuum_vacuum_cost_limit parametrów, procesy robocze uruchomione w tych tabelach nie będą uwzględniane w algorytmie równoważenia [autovacuum_cost_limit/autovacuum_max_workers].
Ochrona przed automatycznym przetwarzaniem transakcji (TXID)
Gdy baza danych przechodzi do ochrony identyfikatora transakcji wraparound, można zaobserwować komunikat o błędzie podobny do następującego:
Database isn't accepting commands to avoid wraparound data loss in database 'xx'
Stop the postmaster and vacuum that database in single-user mode.
Uwaga
Ten komunikat o błędzie oznacza długotrwały nadzór. Zazwyczaj nie trzeba przełączać się w tryb jednego użytkownika. Zamiast tego możesz uruchomić wymagane polecenia VACUUM i wykonać dostrajanie, aby polecenie VACUUM działało szybko. Chociaż nie można uruchomić żadnego języka manipulowania danymi (DML), nadal można uruchomić program VACUUM.
Problem zawijania występuje, gdy baza danych nie jest opróżniona lub istnieje zbyt wiele martwych krotek, które nie zostały usunięte przez automatyczne czyszczenie.
Możliwe przyczyny tego problemu mogą być następujące:
Duże obciążenie
Obciążenie może spowodować zbyt wiele utraconych krotek w krótkim okresie, co utrudnia autovacuum nadrobienie zaległości. Martwe krotki w systemie sumuje się w okresie, co prowadzi do pogorszenia wydajności zapytań i prowadzi do sytuacji zawijania. Jedną z przyczyn wystąpienia tej sytuacji może być to, że parametry automatycznego czyszczenia nie są odpowiednio ustawione i nie są zgodne z serwerem zajętym.
Długotrwałe transakcje
Każda długotrwała transakcja w systemie nie zezwala na usuwanie martwych krotek podczas automatycznego czyszczenia. Są one blokerem do procesu próżniowego. Usunięcie długotrwałych transakcji zwalnia martwe krotki do usunięcia po uruchomieniu automatycznego czyszczenia.
Długotrwałe transakcje można wykryć przy użyciu następującego zapytania:
SELECT pid, age(backend_xid) AS age_in_xids,
now () - xact_start AS xact_age,
now () - query_start AS query_age,
state,
query
FROM pg_stat_activity
WHERE state != 'idle'
ORDER BY 2 DESC
LIMIT 10;
Przygotowane instrukcje
Jeśli istnieją przygotowane instrukcje, które nie zostały zatwierdzone, uniemożliwiłyby usunięcie martwych krotki.
Następujące zapytanie pomaga znaleźć niezatwierdzone przygotowane instrukcje:
SELECT gid, prepared, owner, database, transaction
FROM pg_prepared_xacts
ORDER BY age(transaction) DESC;
Użyj instrukcji COMMIT PREPARED lub ROLLBACK PRZYGOTOWANY do zatwierdzenia lub wycofania tych instrukcji.
Nieużywane miejsca replikacji
Nieużywane miejsca replikacji uniemożliwiają automatyczne wyczyszczanie martwych krotek. Następujące zapytanie pomaga zidentyfikować nieużywane miejsca replikacji:
SELECT slot_name, slot_type, database, xmin
FROM pg_replication_slots
ORDER BY age(xmin) DESC;
Użyj pg_drop_replication_slot() polecenia , aby usunąć nieużywane miejsca replikacji.
Gdy baza danych przechodzi do ochrony zawijania transakcji identyfikatora transakcji, sprawdź wszystkie blokery, jak wspomniano wcześniej, i usuń blokady ręcznie, aby automatyczne czyszczenie było kontynuowane i ukończone. Możesz również zwiększyć szybkość automatycznego czyszczenia, ustawiając autovacuum_cost_delay wartość na 0 i zwiększając wartość do większej autovacuum_cost_limit niż 200. Jednak zmiany tych parametrów nie mają zastosowania do istniejących procesów automatycznego czyszczenia. Uruchom ponownie bazę danych lub ręcznie zabij istniejących procesów roboczych, aby zastosować zmiany parametrów.
Wymagania specyficzne dla tabeli
Parametry automatycznego czyszczenia mogą być ustawiane dla poszczególnych tabel. Jest to szczególnie ważne w przypadku małych i dużych tabel. Na przykład w przypadku małej tabeli zawierającej tylko 100 wierszy funkcja automatycznego czyszczenia wyzwala operację VACUUM, gdy zmienia się 70 wierszy (zgodnie z obliczeniami wcześniej). Jeśli ta tabela jest często aktualizowana, mogą pojawić się setki operacji automatycznego czyszczenia dziennie, co uniemożliwia automatyczne czyszczenie danych z obsługi innych tabel, w których procent zmian nie jest tak znaczący. Alternatywnie tabela zawierająca miliard wierszy musi zmienić 200 milionów wierszy, aby wyzwolić operacje automatycznego czyszczenia. Ustawienie parametrów automatycznego czyszczenia odpowiednio uniemożliwia takie scenariusze.
Aby ustawić ustawienie automatycznego czyszczenia dla tabeli, zmień parametry serwera jako następujące przykłady:
ALTER TABLE <table name> SET (autovacuum_analyze_scale_factor = xx);
ALTER TABLE <table name> SET (autovacuum_analyze_threshold = xx);
ALTER TABLE <table name> SET (autovacuum_vacuum_scale_factor = xx);
ALTER TABLE <table name> SET (autovacuum_vacuum_threshold = xx);
ALTER TABLE <table name> SET (autovacuum_vacuum_cost_delay = xx);
ALTER TABLE <table name> SET (autovacuum_vacuum_cost_limit = xx);
Obciążenia tylko do wstawiania
W wersjach bazy danych PostgreSQL <= 13 funkcja automatycznego czyszczenia nie jest uruchamiana w tabelach z obciążeniem tylko do wstawiania, ponieważ nie ma martwych krotek i nie ma wolnego miejsca, które należy odzyskać. Jednak autoanalizowanie przebiegów dla obciążeń tylko do wstawiania, ponieważ istnieją nowe dane. Wady tego są następujące:
- Mapa widoczności tabel nie jest aktualizowana, a w związku z tym wydajność zapytań, szczególnie w przypadku skanowania tylko indeksu, zaczyna cierpieć w czasie.
- Baza danych może napotkać ochronę wraparound identyfikatora transakcji.
- Bity wskazówek nie są ustawione.
Rozwiązania
Wersje <bazy danych Postgres = 13
Za pomocą rozszerzenia pg_cron można skonfigurować zadanie cron w celu zaplanowania okresowej analizy próżni w tabeli. Częstotliwość zadania cron zależy od obciążenia.
Aby uzyskać szczegółowe wskazówki dotyczące korzystania z pg_cron, zapoznaj się z tematem Rozszerzenia.
Wersje bazy danych Postgres 13 i nowszych
Automatyczne czyszczenie jest uruchamiane w tabelach z obciążeniem tylko do wstawiania. Dwa nowe parametry autovacuum_vacuum_insert_threshold serwera i autovacuum_vacuum_insert_scale_factor pomoc w kontrolowaniu, kiedy automatyczne czyszczenie może być wyzwalane w tabelach tylko do wstawiania.
Przewodniki rozwiązywania problemów
Korzystając z przewodników rozwiązywania problemów z funkcją, które są dostępne w portalu serwera elastycznego usługi Azure Database for PostgreSQL, można monitorować wzdęcie na poziomie bazy danych lub poszczególnych schematów oraz identyfikować potencjalne blokady w procesie automatycznego czyszczenia. Dwa przewodniki rozwiązywania problemów są dostępne jako pierwsze to monitorowanie automatycznego czyszczenia, które może służyć do monitorowania wzdęć na poziomie bazy danych lub pojedynczego schematu. Drugi przewodnik rozwiązywania problemów to blokery automatycznego czyszczenia i zawijanie, co pomaga zidentyfikować potencjalne blokery automatycznego czyszczenia. Zawiera również informacje na temat tego, jak daleko bazy danych na serwerze pochodzą z zawijania lub sytuacji awaryjnej. Przewodniki rozwiązywania problemów udostępniają również zalecenia, aby rozwiązać potencjalne problemy. Jak skonfigurować przewodniki rozwiązywania problemów, aby ich używać, postępuj zgodnie z przewodnikami rozwiązywania problemów z konfiguracją.
Zalecenia usługi Azure Advisor
Rekomendacje usługi Azure Advisor to proaktywny sposób identyfikowania, czy serwer ma wysoki współczynnik wzdęć, lub serwer zbliża się do scenariusza zawijania transakcji. Możesz również utworzyć alerty usługi Azure Advisor dla zaleceń.
Zalecenia są następujące:
Wysoki współczynnik wzdęć: Wysoki współczynnik wzdęć może wpływać na wydajność serwera na kilka sposobów. Jednym z znaczących problemów jest to, że optymalizator aparatu PostgreSQL może mieć trudności z wybraniem najlepszego planu wykonania, co prowadzi do obniżenia wydajności zapytań. W związku z tym zalecenie jest wyzwalane, gdy procent wzdęć na serwerze osiągnie określony próg, aby uniknąć takich problemów z wydajnością.
Zawijanie transakcji: ten scenariusz jest jednym z najpoważniejszych problemów, które może napotkać serwer. Gdy serwer znajduje się w tym stanie, może przestać akceptować kolejne transakcje, co powoduje, że serwer stanie się tylko do odczytu. W związku z tym zalecenie jest wyzwalane, gdy zobaczymy, że serwer przekracza próg 1 mld transakcji.
Podziel się swoimi sugestiami i usterkami z zespołem produktu usługi Azure Database for PostgreSQL.