Sdružování připojení je jednoduchý, ale účinný způsob, jak zlepšit výkon vašich aplikací a snížit zatížení vašich serverů PostgreSQL. Čtěte dále a zjistěte více o používání PgBouncer ke sdružování připojení PostgreSQL.
Proč sdružování připojení?
PostgreSQL má poměrně těžkou architekturu zpracování připojení. Pro každé příchozí spojení postmaster (hlavní démon Postgres) rozdělí nový proces (konvenčně nazývaný backend ), abyste to zvládli. I když tento design poskytuje lepší stabilitu a izolaci, nečiní jej zvláště účinným při manipulaci s krátkodobými spoji. Nové připojení klienta Postgres zahrnuje nastavení TCP, vytvoření procesu a inicializaci backendu – to vše je nákladné z hlediska času a systémových zdrojů.
To je samozřejmě problém pouze v případě, že jsou připojení vytvářena příliš často a zahazována bez opětovného použití. Bohužel není neobvyklé mít shluk webových uzlů s aplikacemi napsanými v PHP nebo jiných podobných jazycích, které se potřebují připojit k databázi jednou za načtení stránky. Časté jsou také dávkové úlohy, které rychle vytvářejí spoustu spojení v rychlém sledu. Používání sdružování připojení v takových scénářích může drasticky snížit zatížení vašeho PostgreSQLserveru a dramaticky zlepšit latence dotazů.
Pomocí sdružování připojení se klienti připojují k proxy serveru, který udržuje sadu přímých připojení ke skutečnému serveru PostgreSQL. Klienti si obvykle neuvědomují (a neměli by si uvědomovat, že jsou připojeni k proxy serveru spíše než ke skutečnému serveru). Proxy může běžet na stejném uzlu jako klient (například na každém webovém uzlu), v takovém případě se klienti mohou připojit k proxy přes unixové doménové sokety, které mají velmi nízkou režii připojení. I když je proxy na jiném uzlu a klient potřebuje TCP připojení k dosažení proxy, lze se vyhnout režii nového backendu Postgres.
Co je PgBouncer?
PgBouncer je open-source, odlehčený, jediný binární fond připojení pro PostgreSQL. Může sdružovat připojení k jedné nebo více databázím (na případně různých serverech) a obsluhovat klienty přes TCP a Unix doménové sokety.
PgBouncer udržuje fond připojení pro každého jedinečného uživatele, databázový pár. Obvykle je nakonfigurován tak, aby předal jedno z těchto připojení novému příchozímu připojení klienta a vrátil jej zpět do fondu, když se klient odpojí. PgBouncer můžete nakonfigurovat tak, aby sdružoval agresivněji, takže může nabírat a vracet připojení k fondu na hranicích transakcí nebo příkazů, nikoli na hranicích připojení. Existují však některé potenciálně nežádoucí důsledky.
Měli byste být schopni nainstalovat PgBouncer pomocí správce balíčků vašeho distra:
# RedHat/CentOS/..
$ sudo yum install pgbouncer
# Debian/Ubuntu/..
$ sudo apt-get install pgbouncerJe také k dispozici ve standardních repozitářích Postgres APT a YUM, které lze použít, pokud jsou balíčky vašeho distra staré nebo rozbité.
PgBouncer se spoléhá na hlavní konfigurační soubor, obvykle uložený jako/etc/pgbouncer/pgbouncer.ini . Můžete vyvolat pgbouncer jako službu systemd nebo jej jednoduše spustit i bez oprávnění superuživatele s cestou k tomuto konfiguračnímu souboru.
Abychom to mohli otočit, vytvořte na našem serveru databázi db1 a uživatele user1:
$ sudo -u postgres psql
psql (10.6 (Debian 10.6-1.pgdg90+1))
Type "help" for help.
postgres=# create user user1 password 'user1pass';
CREATE ROLE
postgres=# create database db1 owner user1;
CREATE DATABASE
postgres=#
Klienti se připojí k databázi db1 s uživatelským jménem user1 andpassword user1pass . Naším cílem je přimět klienty, aby se připojili k PgBouncer, který bude proxy a sdružuje připojení ke skutečnému serveru.
Nyní vytvoříme soubor (kdekoli) s tímto obsahem:
[databases]
db1 = host=localhost dbname=db1
[pgbouncer]
listen_addr = 127.0.0.1
listen_port = 16432
auth_file = userlist.txtPotřebujeme také vytvořit soubor „userlist.txt“ ve stejném adresáři s uživatelským jménem a (hašovanými) hesly uživatelů, kterým PgBouncer umožní připojení. Vytvořte „userlist.txt“ s následujícím obsahem:
"user1" "md5638b81c77071ea624d1ad4adb1433540"Druhá hodnota je MD5 „user1passuser1“ s předponou „md5“. Toto je obvyklá konvence Postgres.
Nyní spustíme PgBouncer v popředí:
$ /usr/sbin/pgbouncer pgbouncer.ini
2019-02-05 11:46:18.011 10033 LOG file descriptor limit: 1024 (H:1048576), max_client_conn: 100, max fds possible: 130
2019-02-05 11:46:18.012 10033 LOG listening on 127.0.0.1:16432
2019-02-05 11:46:18.013 10033 LOG listening on unix:/tmp/.s.PGSQL.16432
2019-02-05 11:46:18.014 10033 LOG process up: pgbouncer 1.9.0, libevent 2.0.21-stable (epoll), adns: c-ares 1.12.0, tls: OpenSSL 1.1.0j 20 Nov 2018
Nyní jsme spustili PgBouncer, který naslouchá na 127.0.0.1 TCP portu 16432 a také na soketu domény Unix /tmp/.s.PGSQL.16432 . Jediná „databáze“ dostupná na tomto proxy serveru je db1 . Jediný uživatel, který se může připojit k tomuto serveru, je user1 . Zkusme se připojit pomocí psql :
$ psql -U user1 -p 16432 -h localhost db1
Password for user user1:
psql (10.6 (Debian 10.6-1.pgdg90+1))
Type "help" for help.
db1=> select inet_server_addr(), inet_server_port();
inet_server_addr | inet_server_port
------------------+------------------
127.0.0.1 | 5432
(1 row)
db1=>Klient (psql) se úspěšně připojí k localhost:16432, ale můžete vidět, že připojení je ve skutečnosti přesměrováno na localhost:5432.
Můžete se pokusit několikrát odpojit a znovu připojit a poté zkontrolovat, kolik připojení je na skutečném serveru stále k dispozici:
postgres=# select count(*) from pg_stat_activity
postgres-# where datname='db1' and usename='user1';
count
-------
1
(1 row)PgBouncer neodpojí skutečné připojení, když se klient odpojí. Minimální, maximální a rezervovaná připojení, která bude PgBouncer udržovat pro každý fond, můžete nakonfigurovat v konfiguračním souboru.
Nasazení PgBouncer
Kde instalujete a spouštíte PgBouncer? Existují různé odpovědi s různými výhodami:
- Na uzlu serveru Postgres :Můžete jej nainstalovat vedle samotného PostgreSQLserveru na stejný uzel. Klienti se připojují k portu PgBouncer spíše než k portu Postgres. To má za následek „vylepšený“ Postgres, který interně sdružuje připojení. Musíte také udržovat pouze jednu kopii konfiguračních souborů pro PgBouncer. Na druhou stranu to ve skutečnosti obnáší spouštění něčeho jiného také na uzlu serveru PostgreSQL, což nemusí být snadné nebo povolené (firewally, politiky) nebo dokonce možné (AWSRDS).
- Na klientských uzlech :PgBouncer můžete nainstalovat do každého klientského uzlu, například každý webový uzel běží na Apache a PHP a PHP skripty se připojují k localPgBouncer. To má výhodu v tom, že nemusíte narušovat nastavení serveru a konfiguraci fondu lze použít k tomu, aby bylo zatížení serveru předvídatelné. Na druhou stranu, pokud je počet klientských uzlů velký nebo se může hodně lišit v závislosti na zatížení/ provozu, může být server rychle přetížen.
- Jako samostatný cluster :Třetí možnost mít shluk nezávislých, bezstavových uzlů PgBouncer, před nimiž stojí nástroj pro vyrovnávání zatížení TCP, jako je HAProxy. Toto nastavení, přestože je složitější než ostatní dvě možnosti, poskytuje maximální kontrolu a konfigurovatelnost.
Administrace
PgBouncer umožňuje uživatelům označeným jako správci připojit se k virtuální databázi s názvem „pgbouncer“ a vydávat příkazy k ovládání serveru a prohlížení statistik. Chcete-li to zkusit, nejprve označte „user1“ jako správce úpravou souboru pgbouncer.ini:
[databases]
db1 = host=localhost dbname=db1
[pgbouncer]
listen_addr = 127.0.0.1
listen_port = 16432
auth_file = userlist.txt
admin_users = user1Nyní se uživatel1 může připojit k databázi s názvem „pgbouncer“:
$ psql -U user1 -p 16432 -h localhost pgbouncer
Password for user user1:
psql (10.6 (Debian 10.6-1.pgdg90+1), server 1.9.0/bouncer)
Type "help" for help.
pgbouncer=#Odtud můžete dělat různé věci, jako je povolení nebo zakázání konkrétní databáze, kontrola a opětovné načtení konfigurace a další:
pgbouncer=# RELOAD;
RELOAD
pgbouncer=# DISABLE db1;
DISABLE
pgbouncer=# ENABLE db1;
ENABLE
pgbouncer=# SHOW FDS;
fd | task | user | database | addr | port | cancel | link | client_encoding | std_strings | datestyle | timezone | pa
----+--------+-------+----------+-----------+-------+----------------+------+-----------------+-------------+-----------+-----------+---
6 | pooler | | | 127.0.0.1 | 16432 | 0 | 0 | | | | |
7 | pooler | | | unix | 16432 | 0 | 0 | | | | |
9 | server | user1 | db1 | 127.0.0.1 | 5432 | 45404395804679 | 0 | UTF8 | on | ISO, MDY | localtime |
(3 rows)Monitorování
Existují také příkazy pro zobrazení různých statistik o PgBouncer, včetně:
- Statistiky pro jednotlivé databáze o délce dotazu, době čekání klienta, využití sítě, počtech transakcí
- Statistiky na fond o počtu aktivních a čekajících klientů, nečinných a použitých připojení k serveru
Statistiky se načítají pomocí příkazů stylu „SHOW xyz“, jako je tento pro načítání statistik souvisejících s fetchpoolem:
pgbouncer=# SHOW POOLS;
-[ RECORD 1 ]---------
database | db1
user | user1
cl_active | 0
cl_waiting | 0
sv_active | 0
sv_idle | 0
sv_used | 1
sv_tested | 0
sv_login | 0
maxwait | 0
maxwait_us | 0
pool_mode | session
-[ RECORD 2 ]---------
database | pgbouncer
user | pgbouncer
cl_active | 1
cl_waiting | 0
sv_active | 0
sv_idle | 0
sv_used | 0
sv_tested | 0
sv_login | 0
maxwait | 0
maxwait_us | 0
pool_mode | statementDalší čtení
Domovská stránka PgBouncer obsahuje více podrobností o všech různých funkcích a možnostech konfigurace PgBouncer.
- Domovská stránka PgBouncer
- Úložiště PgBouncer GitHub
- Postgres Wiki má informace o sdružování připojení
- Pgpool je další možností pro sdružování připojení