Udostępnij za pomocą

Limity w usłudze Azure Database for PostgreSQL

W poniższych sekcjach opisano limity wydajności i funkcjonalności dla wystąpień serwera elastycznego usługi Azure Database for PostgreSQL. Jeśli chcesz dowiedzieć się więcej na temat warstw zasobów (zasobów obliczeniowych, pamięci, magazynu), zobacz artykuły dotyczące zasobów obliczeniowych i magazynu .

Maksymalna liczba połączeń

W poniższej tabeli przedstawiono domyślną maksymalną liczbę połączeń dla każdej warstwy cenowej i konfiguracji rdzeni wirtualnych. Wystąpienie serwera elastycznego usługi Azure Database for PostgreSQL rezerwuje 15 połączeń dla replikacji fizycznej i monitorowania. W związku z tym tabela zmniejsza wartość maksymalnej liczby połączeń użytkowników o 15 z łącznej maksymalnej liczby połączeń.

Nazwa produktu Rdzenie wirtualne Rozmiar pamięci Maksymalna liczba połączeń Maksymalna liczba połączeń użytkowników
Możliwość serii
B1MS 1 2 GiB 50 35
B2s 2 4 GiB 429 414
B2ms 2 8 GiB 859 844
B4ms 100 16 GiB 1,718 1,703
B8ms 8 32 GiB 3,437 3,422
B12ms 12 48 GiB 5,000 4,985
B16ms 16 64 GiB 5,000 4,985
B20ms 20 80 GiB 5,000 4,985
Ogólnego przeznaczenia
D2s_v3/D2ds_v4/D2ds_v5/D2ads_v5 2 8 GiB 859 844
D4s_v3/D4ds_v4/D4ds_v5/D4ads_v5 100 16 GiB 1,718 1,703
D8s_v3/D8ds_V4/D8ds_v5/D8ads_v5 8 32 GiB 3,437 3,422
D16s_v3/D16ds_v4/D16ds_v5/D16ads_v5 16 64 GiB 5,000 4,985
D32s_v3/D32ds_v4/D32ds_v5/D32ads_v5 32 128 GiB 5,000 4,985
D48s_v3/D48ds_v4/D48ds_v5/D48ads_v5 48 192 GiB 5,000 4,985
D64s_v3/D64ds_v4/D64ds_v5/D64ads_v5 64 256 GiB 5,000 4,985
D96ds_v5/D96ads_v5 96 384 GiB 5,000 4,985
Zoptymalizowane pod kątem pamięci
E2s_v3/E2ds_v4/E2ds_v5/E2ads_v5 2 16 GiB 1,718 1,703
E4s_v3/E4ds_v4/E4ds_v5/E4ads_v5 100 32 GiB 3,437 3,422
E8s_v3/E8ds_v4/E8ds_v5/E8ads_v5 8 64 GiB 5,000 4,985
E16s_v3/E16ds_v4/E16ds_v5/E16ads_v5 16 128 GiB 5,000 4,985
E20ds_v4/E20ds_v5/E20ads_v5 20 160 GiB 5,000 4,985
E32s_v3/E32ds_v4/E32ds_v5/E32ads_v5 32 256 GiB 5,000 4,985
E48s_v3/E48ds_v4/E48ds_v5/E48ads_v5 48 384 GiB 5,000 4,985
E64s_v3/E64ds_v4/E64ds_v5/E64ads_v5 64 432 GiB 5,000 4,985
E96ds_v5/E96ads_v5 96 672 GiB 5,000 4,985

Zarezerwowane gniazda połączeń, obecnie na 15, mogą ulec zmianie. Zalecamy regularne weryfikowanie łącznej liczby połączeń zarezerwowanych na serwerze. Tę liczbę oblicza się, sumując wartości parametrów reserved_connections serwera i .superuser_reserved_connections Maksymalna liczba dostępnych połączeń użytkowników to max_connections - (reserved_connections + superuser_reserved_connections).

System oblicza wartość domyślną parametru max_connections serwera podczas aprowizowania wystąpienia elastycznego serwera usługi Azure Database for PostgreSQL, na podstawie nazwy produktu wybranej dla jego mocy obliczeniowej. Wszelkie kolejne zmiany wyboru produktu do obliczeń, które obsługują wystąpienie, nie będą miały żadnego wpływu na wartość domyślną parametru max_connections serwera tego wystąpienia. Zalecamy, aby za każdym razem, gdy zmienisz produkt przypisany do wystąpienia, należy również dostosować wartość max_connections parametru zgodnie z wartościami w poprzedniej tabeli.

Zmienianie wartości max_connections

Po pierwszym skonfigurowaniu wystąpienia serwera elastycznego usługi Azure Database for Postgres automatycznie decyduje o największej liczbie połączeń, które może obsługiwać współbieżnie. Konfiguracja serwera określa tę liczbę i nie można jej zmienić.

Można jednak użyć max_connections tego ustawienia, aby dostosować liczbę dozwolonych połączeń w danym momencie. Po zmianie tego ustawienia należy ponownie uruchomić serwer, aby nowy limit zaczął działać.

Uwaga

Chociaż można zwiększyć wartość max_connections poza ustawieniem domyślnym, zalecamy jej zwiększenie.

Wystąpienia mogą napotkać trudności, gdy obciążenie rozszerza się i wymaga większej ilości pamięci. Wraz ze wzrostem liczby połączeń użycie pamięci również rośnie. Wystąpienia z ograniczoną ilością pamięci mogą napotykać problemy, takie jak awarie lub duże opóźnienia. Chociaż wyższa wartość może max_connections być akceptowalna, gdy większość połączeń jest bezczynna, może to prowadzić do poważnych problemów z wydajnością po ich aktywowania.

Jeśli potrzebujesz więcej połączeń, sugerujemy, aby zamiast tego używać narzędzia PgBouncer, wbudowanego rozwiązania platformy Azure do zarządzania pulą połączeń. Użyj go w trybie transakcji. Aby rozpocząć, zalecamy użycie konserwatywnych wartości przez pomnożenie rdzeni wirtualnych w zakresie od 2 do 5. Następnie dokładnie monitoruj wykorzystanie zasobów i wydajność aplikacji, aby zapewnić płynną operację. Aby uzyskać szczegółowe informacje na temat narzędzia PgBouncer, zobacz PgBouncer w usłudze Azure Database for PostgreSQL.

W przypadku przekroczenia limitu połączeń może zostać wyświetlony następujący błąd:

FATAL: sorry, too many clients already.

Podczas korzystania z elastycznego wystąpienia serwera usługi Azure Database for PostgreSQL dla bazy danych obciążonej dużą liczbą współbieżnych połączeń, może wystąpić znaczne obciążenie zasobów systemowych. To obciążenie może spowodować wysokie wykorzystanie procesora CPU, zwłaszcza gdy wiele połączeń jest nawiązywanych jednocześnie i gdy połączenia mają krótki czas trwania (mniej niż 60 sekund). Te czynniki mogą negatywnie wpłynąć na ogólną wydajność bazy danych, zwiększając czas spędzony na przetwarzaniu połączeń i rozłączeń.

Każde połączenie w elastycznym serwerze usługi Azure Database dla PostgreSQL, niezależnie od tego, czy jest bezczynne, czy aktywne, zużywa znaczne zasoby z bazy danych. To użycie może prowadzić do problemów z wydajnością poza wysokim użyciem procesora CPU, takich jak rywalizacja o dyski i blokadę. W artykule Liczba połączeń baz danych na Wiki PostgreSQL zagłębiono się w szczegóły tego tematu. Aby dowiedzieć się więcej, zobacz Identyfikowanie i rozwiązywanie problemów z wydajnością połączenia w usłudze Azure Postgres.

Ograniczenia funkcjonalne

W poniższych sekcjach wymieniono rozważania dotyczące tego, co jest obsługiwane, a co nie jest w przypadku instancji elastycznego serwera usługi Azure Database for PostgreSQL.

Operacje skalowania

  • W tej chwili skalowanie w górę magazynu serwera wymaga ponownego uruchomienia serwera.
  • Magazyn serwera można skalować tylko w 2 razy. Aby uzyskać szczegółowe informacje, zobacz Pamięć .
  • Obecnie nie obsługujemy zmniejszania rozmiaru pamięci serwera. Jedynym sposobem wykonania tej operacji jest zrzut i przywrócenie go do nowego wystąpienia serwera elastycznego usługi Azure Database for PostgreSQL.

Magazyn

  • Po skonfigurowaniu rozmiaru magazynu nie można go zmniejszyć. Musisz utworzyć nowy serwer o żądanym rozmiarze magazynu, wykonać ręczną operację zrzutu i przywracania oraz przeprowadzić migrację baz danych na nowy serwer.
  • Gdy użycie magazynu osiągnie 95% lub jeśli dostępna pojemność jest mniejsza niż 5 GiB (w zależności od tego, co jest większe), system automatycznie przełącza serwer w tryb tylko do odczytu, aby uniknąć błędów związanych z sytuacjami pełnymi dyskowymi. W rzadkich przypadkach, jeśli szybkość wzrostu danych przewyższa czas przełączenia się do trybu tylko do odczytu, serwer może nadal zabraknąć miejsca do magazynowania. Możesz włączyć automatyczne zwiększanie magazynu, aby uniknąć tych problemów i automatycznie skalować magazyn na podstawie wymagań dotyczących obciążeń.
  • Zalecamy ustawienie reguł alertów dla storage used lub storage percent przekroczenia określonych progów, aby można było aktywnie podjąć działania, takie jak zwiększenie rozmiaru magazynu. Można na przykład ustawić alert, jeśli wartość procentowa magazynu przekroczy 80% użycia.
  • Jeśli używasz replikacji logicznej, musisz usunąć miejsce replikacji logicznej na serwerze podstawowym, jeśli odpowiedni subskrybent już nie istnieje. W przeciwnym razie pliki rejestrowania z wyprzedzeniem zapisu (WAL) gromadzą się w magazynie podstawowym i wypełniają magazyn. Jeśli przestrzeń dyskowa przekroczy określony próg i jeśli gniazdo replikacji logicznej nie jest używane (z powodu niedostępnego subskrybenta), serwer elastyczny usługi Azure Database for PostgreSQL automatycznie usuwa nieużywane gniazdo replikacji logicznej. Ta akcja zwalnia skumulowane pliki WAL i zapobiega niedostępności serwera, ponieważ magazyn zapełnia się.
  • Nie obsługujemy tworzenia przestrzeni tabel. Jeśli tworzysz bazę danych, nie podaj nazwy przestrzeni tabel. Wystąpienie serwera elastycznego usługi Azure Database for PostgreSQL używa domyślnej przestrzeni tabel dziedziczonej przez bazę danych szablonów. Nie jest to niebezpieczne, aby zapewnić przestrzeń tabel, taką jak tymczasową, ponieważ nie możemy zagwarantować, że takie obiekty pozostaną trwałe po wystąpieniu zdarzeń, takich jak ponowne uruchomienie serwera i przejście w tryb failover o wysokiej dostępności (HA).
  • Oddzielone pliki danych i rozbieżności użycia dysku: w rzadkich przypadkach baza danych PostgreSQL może pozostawić oddzielone pliki danych na dysku — pliki, które nie mają już odpowiednich wpisów w katalogu systemowym bazy danych (który śledzi wszystkie tabele i dane). Może się tak zdarzyć, jeśli tabela zostanie utworzona i wypełniona w ramach transakcji, która nie powiedzie się pomyślnie (np. z powodu awarii serwera lub przerwy), co spowoduje niezgodność między rozmiarem zgłoszonym przez bazę danych a rzeczywistym użyciem dysku. To zachowanie pochodzi z bazy kodu społeczności postgreSQL i nie jest specyficzne dla platformy Azure. Społeczność postgreSQL zdaje sobie sprawę z problemu i bada ulepszenia automatycznego czyszczenia w przyszłych wersjach. Aby uzyskać więcej informacji, zobacz: PostgreSQL: Oddzielone pliki w usłudze PostgreSQL. Może to prowadzić do nieoczekiwanego wysokiego zużycia dysku lub przestrzeni magazynowej.
    • Instrukcje wykrywania: porównanie rozmiaru zgłaszanego przez bazę danych (przy użyciu zapytań, takich jak SELECT pg_database_size('your_database')) z metrykami witryny Azure Portal w celu rzeczywistego użycia dysku. Jeśli występuje znaczna rozbieżność, oddzielone pliki mogą być przyczyną. Jeśli tak:
      • Uruchom VACUUM FULL w tabelach dotkniętych problemem, aby odzyskać miejsce (uwaga: proces intensywnie korzysta z zasobów, wymaga blokady tabeli, i może wymagać przestoju).
      • Alternatywnie użyj narzędzi, takich jak pg_repack lub pg_squeeze rozszerzenia do reorganizacji bez przestojów, ale najpierw przetestuj je w środowisku nieprodukcyjnym.
      • Monitoruj za pomocą metryk w Azure Portal progi użycia dysku. Jeśli problem będzie się powtarzać lub nie masz pewności, skontaktuj się z pomocą techniczną platformy Azure, aby uzyskać pomoc.
    • Jak zapobiegać: upewnij się, że transakcje są prawidłowo zarządzane w aplikacjach, aby zminimalizować niekompletne operacje. Regularnie monitoruj użycie dysku za pomocą metryk witryny Azure Portal. Uaktualnienie do najnowszej obsługiwanej wersji bazy danych PostgreSQL może obejmować poprawki społeczności w przypadku powiązanych problemów.

Sieć

  • Obecnie nie obsługujemy przenoszenia do i z sieci wirtualnej.
  • Obecnie nie obsługujemy łączenia dostępu publicznego z wdrożeniem w sieci wirtualnej.
  • Sieci wirtualne nie obsługują reguł zapory. Zamiast tego można użyć sieciowych grup zabezpieczeń.
  • Serwery baz danych dostępu publicznego mogą łączyć się z publicznym Internetem; na przykład za pośrednictwem postgres_fdw. Nie można ograniczyć tego dostępu. Serwery w sieciach wirtualnych mogą mieć ograniczony dostęp wychodzący za pośrednictwem sieciowych grup zabezpieczeń.

Wysoka dostępność

Strefy dostępności

  • Obecnie nie obsługujemy ręcznego przenoszenia serwerów do innej strefy dostępności. Jednak przy użyciu preferowanej strefy dostępności jako strefy rezerwowej można włączyć wysoką dostępność. Po ustanowieniu strefy rezerwowej możesz przejść do niej w tryb failover, a następnie wyłączyć wysoką dostępność.

Aparat Postgres, rozszerzenia i narzędzie PgBouncer

  • Elastyczne wystąpienie serwera bazy danych Azure dla PostgreSQL obsługuje wszystkie funkcje silnika PostgreSQL, w tym partycjonowanie, replikację logiczną i opakowania na dane obce.
  • Elastyczne wystąpienie serwera Azure Database dla PostgreSQL obsługuje wszystkie rozszerzenia contrib i nie tylko. Aby uzyskać więcej informacji, zobacz Rozszerzenia PostgreSQL.
  • Serwery burstable nie mają obecnie dostępu do wbudowanego poolingu połączeń PgBouncer.

Operacje zatrzymywania/uruchamiania

  • Po zatrzymaniu wystąpienia serwera elastycznego usługi Azure Database for PostgreSQL zostanie ono automatycznie uruchomione po siedmiu dniach.

Konserwacja zaplanowana

  • Niestandardowe okno obsługi można zmienić na dowolny dzień/godzinę tygodnia. Jednak wszelkie zmiany wprowadzone po otrzymaniu powiadomienia o konserwacji nie będą miały wpływu na następną konserwację. Zmiany obowiązują tylko z następującą miesięczną zaplanowaną konserwacją.

Kopie zapasowe serwera

  • System zarządza kopiami zapasowymi. Obecnie nie można ręcznie uruchamiać kopii zapasowych. Zalecamy użycie pg_dump zamiast tego.

  • Pierwsza migawka to pełna kopia zapasowa, a kolejne migawki to różnicowe kopie zapasowe. Różnicowe kopie zapasowe są kopiami zapasowymi tylko zmienionymi danymi od czasu utworzenia ostatniej kopii zapasowej migawki.

    Jeśli na przykład rozmiar bazy danych wynosi 40 GB, a przydzielony magazyn wynosi 64 GB, pierwsza kopia zapasowa migawki to 40 GB. Teraz, jeśli zmienisz 4 GB danych, następny różnicowy rozmiar kopii zapasowej migawki będzie wynosić tylko 4 GB. Dzienniki transakcji (dzienniki zapisu z wyprzedzeniem) są oddzielone od pełnych i różnicowych kopii zapasowych i są archiwizowane w sposób ciągły.

Przywracanie serwera

  • W przypadku korzystania z funkcji przywracania do punktu w czasie (PITR) system tworzy nowy serwer z taką samą konfiguracją obliczeniową i pamięci masowej, jak serwer, na którym jest on oparty.
  • System przywraca serwery baz danych w sieciach wirtualnych do tych samych sieci wirtualnych podczas przywracania z kopii zapasowej.
  • Nowy serwer utworzony podczas przywracania nie ma reguł zapory, które istniały na oryginalnym serwerze. Należy utworzyć reguły zapory oddzielnie dla nowego serwera.
  • Nie obsługujemy przywracania do innej subskrypcji. Aby obejść ten problem, możesz przywrócić serwer w ramach tej samej subskrypcji, a następnie przeprowadzić migrację przywróconego serwera do innej subskrypcji.

Zabezpieczenia

  • Postgres 14 i nowsze wersje wyłączają skróty MD5, a system skraca natywne hasła Postgres, używając tylko metody SCRAM-SHA-256.

Powiązana zawartość

  • Last updated on