Pojedynczy serwer PostgreSQL predzej czy pozniej przestaje wystarczac - pokazujemy jak polaczyc pgBouncer i HAProxy w spojna architekture skalowania, ktora realnie dziala pod obciazeniem.
Z tego artykułu dowiesz się:
- dlaczego duża ilość połączeń do PostgreSQL jest niekorzystna,- w jaki sposób pgBouncer pomaga nam zmniejszyć ilość połączeń do PostgreSQL.
[ Do realizacji przykładów z tego rozdziału potrzebujemy hostów - 1,2,3,4. Należy je przygotować według instrukcji. Na hostach 1-3 powinien stać klaster patroni, konfigurację kopii zapasowych możemy pominąć dla tego przykładu. Jeżeli chcemy skonfigurować backupy, potrzebujemy również host nr 5. Na hoście 4 postawimy pgbouncer i haproxy ].
PostgreSQL dla każdej sesji tworzy dedykowany proces w systemie operacyjnym. Z tego powodu każde rozpoczęte połączenie, zarówno aktywne jak i nieaktywne, wykorzystuje część z dostępnych zasobów, pamięć oraz CPU. Dlatego nagły wzrost otwartych połączeń w bazie może prowadzić do znacznego obciążenia procesora spowodowanego planowaniem i przełączaniem kontekstów. Szczególnie, kiedy liczba aktywnych sesji znacznie przekracza liczbę dostępnych CPU na serwerze. Dlatego też zaleca się - ustawieniem max_connections jest ilość CPU * 2. Bardzo często jest to nierealne ustawienie, dlatego w przypadkach, kiedy większość transakcji jest bardzo krótka, można liczbę - połączeń zwiększyć do ilości CPU x5, x10 lub nawet x20. Nadal jednak jest to często zbyt mała liczba połączeń dla aplikacji, a jeżeli chcielibyśmy za każdym razem zamknąć i otworzyć połączenie z postgresem na nowo, wydajność takiej instancji też może znacznie spaść, ponieważ otwieranie nowego połączenia to operacja dość kosztowna. Przez zbytnie ograniczenie liczby dostępnych połączeń możemy zacząć widywać w logach błędy "FATAL: - sorry, too many clients already". Z kolei ustawienie limitu zbyt wysoko i pozwalanie na ustanawianie zbyt wielu połączeń, nawet jeżeli w większości są "idle", też nie jest najlepszym pomysłem, ponieważ każde połączenie, nawet idle, wykorzystuje trochę zasobów systemowych CPU i RAM. W izolowanych środowisku testowym, na wirtualnej maszynie z 2 vCPU i 8GB RAM, otwarcie 1000 połączeń, wykonanie na nich "DISCARD ALL" i pozostawienie ich jako "idle" generuje użycie około 1.5GB pamięci oraz powoduje spadek liczby transakcji na sekundę o 8%.
Dla wszystkich wyżej opisanych problemów istnieje wspólne rozwiązanie, kolejkowanie połączeń. Jednym z narzędzi umożliwiających kolejkowanie jest pgBouncer. Pozwala on na wykorzystanie ograniczonej liczby połączeń do obsługi znacznie większej ilości klientów niż byłby w stanie obsłużyć sam PostgreSQL wymagając przy tym bardzo niewielkiej ilości zasobów.
