Tempa mezuro de psql tra VPN: apartigi retan atendo de la laboro de la konsulto

psql raportas unu pasintan nombron por ĉiu ordono, do malrapida VPN ŝveligas ĝin. Apartigu konektan, plenumadan, transadan kaj reiran tempon antaŭ ol agordi ajnan flankon.

Via raporto finiĝas post proksimume unu sekundo sur la datenbaza gastiganto kaj post kvar tra la VPN, kaj la nombro, kiun psql presas, montras rekte al la datenbazo. Tiu nombro estas haltigilo ĉe la klienta flanko, ne mezuro de la servilo. Ĝi kovras la ordonon survoje eksteren, la atendon por respondo, kaj la vicojn survoje reen. Apartigi tiujn tri estas la sola maniero scii, kiun flankon agordi.

Kion la tempomezurilo de psql vere mezuras

\timing on startigas haltigilon ĝuste antaŭ ol la kliento skribas la ordonon al la ingo kaj haltigas ĝin, kiam la lasta vico de tiu rezulto estas legita. La propra plenumo de la servilo troviĝas ie ene de tiu fenestro, kaj same ĉiu milisekundo, kiun la pakaĵoj pasigas en la tunelo. Nenio en la eligo apartigas ilin. EXPLAIN ankaŭ presas nombron, sed tiun produktas la servilo kaj ĝi ekskludas la atendon de la kliento. Du nombroj, du malsamaj demandoj.

Startigu unu seancon, lasu la tempomezuron ŝaltita, kaj plenumu la ordonon, kiu gravas al vi, de interne de ĝi. Reuzi seancon tenas la konektan koston ekster la unua mezuro.

psql "host=db.internal port=5432 dbname=appdb user=app" \
  -c "\timing on" \
  -c "select count(*) from orders where created_at > now() - interval '1 day';"

La nombro ankoraŭ inkluzivas la transdonon de la rezulto, kio estas tio, kion vi volas ĉi tie. Ĝi jam ne inkluzivas la konektan kaj aŭtentigajn interŝanĝojn, kiujn aldoniĝus de nova voko.

Komparu unu ordonon laŭ tri vojoj

Plenumu la saman ordonon tra la Unix-ingo, tra la LAN-adreso kaj tra la VPN-gastnomo, kaj komparu la tri. Se nur la lasta malrapidas, la konsulto ne estas la variablo.

Ĉiu voko unue konektiĝas kaj nur poste mezuras la ordonon, do la konekta kosto restas ekster la nombro dum la transdono restas ene. Tenu la WHERE-klaŭzon, la vicokalkulon kaj la klientan maŝinon samaj, alie vi komparas laborŝarĝojn anstataŭ vojojn.

psql -h /var/run/postgresql -U app -d appdb -c "\timing on" -c "select count(*) from orders;"
psql -h 10.40.0.12 -U app -d appdb -c "\timing on" -c "select count(*) from orders;"
psql -h db.vpn.internal -U app -d appdb -c "\timing on" -c "select count(*) from orders;"

En LAN la diferenco kutime estas sufiĉe malgranda por ignori; tra VPN ofte ne. Ordigi la tri rezultojn poste diras al vi, kiun atendon ataki.

Malrapida loka ingo signifas servilan laboron aŭ planadon. Malrapida LAN-rezulto signifas la konsulton aŭ la volumon, kiun ĝi movas. Nur malrapida VPN-rezulto signifas malfruon, MTU aŭ haveblan bendlarĝon sur la vojo, kaj neniuj indeksaj ŝanĝoj tion riparas.

Elprenu la propran plenumadan tempon de la servilo

La servilo povas raporti, kiom da tempo ĝi pasigis, kaj ĝuste tiu nombro estas tenenda kontraŭ la klienta. EXPLAIN kun ANALYZE plenumas la ordonon kaj presas planadan kaj plenumadan tempon ene de la plano, dum BUFFERS aldonas kaŝmemoran konduton, kiu ofte klarigas varman kuron kontraŭ malvarma. Ne direktu ĝin al skribaj ordonoj, se vi ne intencas skribi. Sur nurlegebla kopio ĝi estas la plej sekura loko por komenci, kaj la psql-referenco dokumentas la klientflankan amplekson de la tempomezurilo.

Por ordonoj, kiujn la aplikaĵo jam plenumas, pg_stat_statements kolektas la plenumadon ĉe la servila flanko sen relanĉi ion. La vicoj estas por normaligita konsulto, do unu enskribo povas kovri plurajn voklokojn.

select calls, round(mean_exec_time::numeric, 2) as mean_ms, rows
from pg_stat_statements
order by mean_exec_time desc
limit 5;

Kolumnomaj nomoj varias laŭ eldono: PostgreSQL 13 kaj pli novaj montras mean_exec_time, dum pli malnovaj versioj nomas ĝin mean_time, do kontrolu per \d pg_stat_statements, se tiu konsulto donas eraron. Ĉi tiuj valoroj ekskludas planadon kaj ekskludas la vojaĝon al via kliento. Ĝuste tiu ekskludo igas ilin utilaj por la komparo.

Kalkulu reirojn, ne nur milisekundojn

Raporto konstruita el ducent malgrandaj dependaj ordonoj multiplikas ajnan malfruon, kiun la vojo aldonas, per ducent. Unu sola ordono, kiu redonas milionon da vicoj, pagas tiun malfruon unufoje kaj poste pagas bendlarĝon longe. Ambaŭ aspektas idente en klienta tempomezurilo, kaj ili bezonas kontraŭajn riparojn.

Mezuru la ordonokalkulon anstataŭ taksi ĝin. Legu la totalon, plenumu la raporton unufoje, poste legu ĝin denove kaj subtrahu.

select sum(calls) as calls from pg_stat_statements;
-- run the report here
select sum(calls) as calls from pg_stat_statements;

Se la delta estas granda kaj ĉiu ordono estas malmultekosta sur la servilo, grupigo estas la ripato, kiu pagas. Kombinu dependajn konsultojn, uzu unu aron-bazitan ordonon, aŭ pelu la buklon el kursoro. En interaga psql, \set FETCH_COUNT 1000 igas grandan rezulton alveni en aroj kaj ŝanĝas kiel kondutas la transdono kaj la klienta memoro. Ĝi ne reduktas servilan laboron, do ĝi ne savos malrapidan konsulton.

Kontrolu la tunelon pri reelsendoj kaj MTU-haltaĵoj

Kiam malgrandaj ordonoj estas rapidaj kaj grandaj rezultoj haltas duone, la konsulto kutime estas en ordo kaj la vojo ne. Tunelo, kies MTU estas pli malalta ol la suba ligilo, kombinita kun blokita ICMP, produktas ĝuste tiun ŝablonon: la unuaj pakaĵoj alvenas, la grandaj malaperas, kaj la transdono pendas ĝis ĝi reprovas. Reelsendaj nombriloj ĉe la klienta flanko montras tion.

Observu la ingon kaj la kernajn nombrilojn dum intence malrapida transdono funkcias. Reelsendaj sumoj estas akumulaj, do notu ilin antaŭ kaj poste anstataŭ legi unu specimenon.

ss -tin dst 10.40.0.12
netstat -s | grep -iE "retransmit|segments retransmitted"
ping -M do -s 1400 -c 3 10.40.0.12

Reelsendoj, kiuj kreskas dum la transdono, kune kun ping, kiu sukcesas je 1400 bajtoj sed malsukcesas je 1472, indikas MTU-problemon anstataŭ datenbazan problemon. Malaltigi la MTU de la tunela interfaco aŭ krampi MSS ĉe la pordego estas la kutima ripato, kaj la samaj tri komandoj konfirmas ĝin poste. Se reelsendoj restas plataj dum la transdono ankoraŭ malrapidas, rigardu la bendlarĝon permesitan al la tunelo anstataŭ la perdon.

Mallonga sinsekvo kovras la sekvan malrapidan raporton: komparu unu ordonon loke, en LAN kaj tra VPN; legu la servilan plenumadon el EXPLAIN aŭ pg_stat_statements; kalkulu vokojn antaŭ kaj post unu kuro; kaj observu reelsendojn dum la granda rezulto moviĝas. Ĉiu paŝo ekskludas unu flankon de la vojo. Neniu postulas diveni, kiun komponanton restartigi.

Rilataj artikoloj