psql-tiidmjitting oer in VPN: netwurkwach fan fraachwurk skiede

Jo rapport einiget yn sawat in sekonde op de databankhost en yn fjouwer oer de VPN, en it getal dat psql printsje lit rjochtstreeks nei de databank. Dat getal is in stopwatch oan de kliïntkant, net in mjitting fan 'e tsjinner. It beslacht de stelling op 'e wei út, it wachtsjen op in antwurd en de rigen op 'e wei werom. Dy trije útinoar helje is de iennige manier om te witten hokker kant jo ôfstjusterje moatte.

Wat de psql-timer echt mjit

\timing on startet in stopwatch krekt foardat de kliïnt de stelling yn 'e socket skriuwt en stoppet as de lêste rigel fan dat resultaat lêzen is. De útfiering fan 'e tsjinner sels sit earne yn dat finster, en ek elke millisekonde dy't de pakketten yn 'e tunnel trochbringe. Neat yn 'e útfier skiedt se. EXPLAIN printsje ek in getal, mar dat wurdt troch de tsjinner makke en slút it wachtsjen fan 'e kliïnt út. Twa getallen, twa ferskillende fragen.

Begjin ien sesje, lit tiidmjitting oan en fierskriuw de stelling dy't jo oanbelanget fan binnenút. It werbrûken fan in sesje hâldt de ferbinkost bûten de earste mjitting.

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';"

It getal befettet noch de oerdracht fan it resultaat, dat is hjir wat jo wolle. It befettet net mear de ferbin- en ferifikaasje-útwikseling dy't in nije oprop tafoegje soe.

Fergelykje ien stelling oer trije paden

Fierskriuw deselde stelling oer de Unix-socket, oer it LAN-adres en oer de VPN-hostnamme, en fergelykje de trije. As allinne de lêste stadich is, is de fraach net de fariabele.

Elke oprop ferbynt earst en mjit dan pas de stelling, dus de ferbinkost bliuwt bûten it getal wylst de oerdracht binnen bliuwt. Hâld de WHERE-klausule, it rigetal en de kliïntmasine gelyk, oars fergelykje jo wurklêsten ynstee fan paden.

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;"

Op in LAN is it ferskil meastentiids lyts genôch om te negearjen; oer in VPN faak net. It sortearjen fan 'e trije resultaten fertelt jo dan hokker wachtsjen oan te fallen.

In stadige lokale socket betsjut tsjinnerwurk of planning. In stadich LAN-resultaat betsjut de fraach of it folume dat it ferpleatst. Allinnich in stadich VPN-resultaat betsjut fertraging, MTU of beskikbere bânbreedte op it paad, en gjin yndeksferoaring makket dat goed.

Helje de útfieringstiid fan 'e tsjinner sels

De tsjinner kin rapportearje hoefolle tiid er bestege hat, en dat getal is wat jo tsjin dat fan 'e kliïnt oanhâlde moatte. EXPLAIN mei ANALYZE fierskriuwt de stelling en printsje plannings- en útfieringstiid binnen it plan, wylst BUFFERS kachgedrach tafoeget dat faak in waarme run tsjin in kâlde ferklearret. Rjochtsje it net op skriuwende stellingen, útsein as jo fan plan binne te skriuwen. Op in allyks-lêsbere replika is it de feilichste plak om te begjinnen, en de psql-referinsje dokumintearret it berik fan 'e timer oan 'e kliïntkant.

Foar stellingen dy't de applikaasje al fierskriuwt, sammelt pg_stat_statements de útfiering oan 'e tsjinnerkant sûnder eat opnij te draaien. De rigen binne per normalisearre fraach, dus ien ynfier kin ferskate opropplakken dekke.

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

Kolomnammen ferskille per ferzje: PostgreSQL 13 en letter eksponearje mean_exec_time, wylst âldere ferzjes it mean_time neame, dus kontrolearje mei \d pg_stat_statements, as dy fraach in flater jout. Dizze wearden slute planning út en slute de reis nei jo kliïnt út. Krekt dy útsluting makket se nuttich foar de fergeliking.

Tel hinne-en-wer reizen, net allinne millisekonden

In rapport boud út twahûndert lytse ôfhinklike stellingen fermannichfâldiget elke fertraging dy't it paad tafoeget mei twahûndert. Ien stelling dy't in miljoen rigen weromjout betellet dy fertraging ien kear en betellet dan lang bânbreedte. Beide sjogge der itselde út yn in kliïnttimer, en se hawwe tsjinstelde repaazjes nedich.

Mjit it oantal stellingen ynstee fan it te skatten. Lês it totaal, fierskriuw it rapport ien kear, lês it dan wer en lûk ôf.

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

As de delta grut is en elke stelling op 'e tsjinner goedkeap is, is batchferwurking de repaazje dy't betellet. Kombinearje ôfhinklike fragen, brûk ien set-basearre stelling of driuw de lus fan in cursor. Yn ynteraktive psql, \set FETCH_COUNT 1000 lit in grut resultaat yn batches oankomme en feroaret hoe't de oerdracht en it kliïntûnthâld har hâlde en draaie. It ferminderet gjin tsjinnerwurk, dus it sil in stadige fraach net rêde.

Kontrolearje de tunnel op weroerdrachten en MTU-stilstannen

As lytse stellingen fluch binne en grutte resultaten healwei stilsteane, is de fraach meastentiids yn oarder en it paad net. In tunnel waans MTU leger is as de ûnderlizzende keppeling, kombinearre mei blokkearre ICMP, produsearret krekt dat patroan: de earste pakketten komme oan, de grutte ferdwine, en de oerdracht hinget oant it wer besiket. Weroerdrachtstellers oan 'e kliïntkant litte it sjen.

Hâld de socket en de kearntellers yn 'e gaten wylst in bewust stadige oerdracht rint. Weroerdrachtsommen binne kumulatityf, dus notearje se foar en nei ynstee fan ien proef te lêzen.

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

Weroerdrachten dy't ûnder de oerdracht omheech geane, tegearre mei in ping dy't by 1400 byte slagget mar by 1472 mislearret, wize op in MTU-probleem ynstee fan in databankprobleem. It ferleegjen fan 'e MTU fan 'e tunnelinterface of it knypen fan MSS by de gateway is de gewoane repaazje, en deselde trije opdrachten befêstigje it dêrnei. As weroerdrachten flak bliuwe wylst de oerdracht noch stadich is, sjoch dan nei de bânbreedte dy't de tunnel tastien is ynstee fan nei ferlies.

In koarte sekwinsje dekt it folgjende stadige rapport: fergelykje ien stelling lokaal, op it LAN en oer de VPN; lês tsjinnerútfiering út EXPLAIN of pg_stat_statements; tel oproppen foar en nei ien run; en hâld weroerdrachten yn 'e gaten wylst it grutte resultaat beweecht. Elke stap slút ien kant fan it paad út. Gjin fan allegear freget om te rieden hokker komponint werstarten moat.