Tímamæling psql um VPN: aðgreina netbið frá vinnu fyrirspurnarinnar

Skýrslan þín klárast á um það bil sekúndu á gagnagrunnsþjóninum og fjórum yfir VPN, og talan sem psql prentar bendir beint á gagnagrunninn. Sú tala er skeiðklukka á biðlaranum, ekki mæling þjónsins. Hún nær yfir skipunina á leið út, biðina eftir svari og raðirnar á leið til baka. Að skilja þessar þrjár að er eina leiðin til að vita hvora hliðina á að stilla.

Hvað tímamælir psql mælir í raun

\timing on ræsir skeiðklukku rétt áður en biðlarinn skrifar skipunina í sætið og stöðvar hana þegar síðasta röð þeirrar niðurstöðu hefur verið lesin. Keyrsla þjónsins sjálfs er einhvers staðar innan þessa glugga, og líka hver millisekúnda sem pakkarnir eyða í göngunum. Ekkert í úttakinu aðskilur þær. EXPLAIN prentar líka tölu, en hana framleiðir þjónninn og hún útilokar bið biðlarans. Tvær tölur, tvær ólíkar spurningar.

Byrjaðu eina setu, hafðu tímamælinguna á og keyrðu skipunina sem þér er amt um innan úr henni. Endurnotkun setu heldur tengikostnaðinum utan við fyrstu mælinguna.

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

Talan inniheldur enn flutning niðurstöðunnar, sem er það sem þú vilt hér. Hún inniheldur ekki lengur tengi- og auðkenningarskiptin sem nýtt kall myndi bæta við.

Berðu saman eina skipun á þremur leiðum

Keyrðu sömu skipun um Unix-sætið, um LAN-vistfangið og um VPN-þjónsheitið og berðu saman þrjár. Ef aðeins sú síðasta er hæg, er fyrirspurnin ekki breytan.

Hvert kall tengist fyrst og mælir skipunina aðeins eftir það, svo tengikostnaðurinn helst utan við töluna á meðan flutningurinn helst inni. Hafðu WHERE-skilyrðið, fjölda raða og biðlaravélina óbreytt, annars ertu að bera saman vinnuálag en ekki leiðir.

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

Á LAN er munurinn venjulega nógu lítill til að hunsa; yfir VPN er hann það oft ekki. Að raða þremur niðurstöðunum segir þér svo hvaða bið á að ráðast á.

Hægur staðbundin sæti þýðir vinnu þjónsins eða skipulagningu. Hæg LAN-niðurstaða þýðir fyrirspurnina eða rúmmálið sem hún færir. Aðeins hæg VPN-niðurstaða þýðir seinkun, MTU eða tiltækt bandvídd á leiðinni, og engar vísitölubreytingar laga það.

Dragðu út keyrslutíma þjónsins sjálfs

Þjónninn getur tilkynnt hve miklum tíma hann eyddi, og það er talan sem á að bera saman við tölu biðlarans. EXPLAIN með ANALYZE keyrir skipunina og prentar skipulagningar- og keyrslutíma innan áætlunarinnar, en BUFFERS bætir við skyndiminnishegðun sem útskýrir oft heita keyrslu gegn kaldri. Beindu því ekki að skrifskipunum nema þú ætlir að skrifa. Á leseinungis eftirriti er það öruggasti staðurinn til að byrja, og psql-tilvísun skjalfestir umfang tímamælisins á biðlarahlið.

Fyrir skipanir sem forritið keyrir þegar, safnar pg_stat_statements keyrslu á þjónshlið án þess að keyra nokkuð aftur. Raðirnar eru fyrir hverja staðlaða fyrirspurn, svo ein færsla getur náð yfir nokkra kallsstaði.

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

Dálkanöfn eru mismunandi eftir útgáfu: PostgreSQL 13 og nýrri sýna mean_exec_time, en eldri útgáfur kalla það mean_time, svo athugaðu með \d pg_stat_statements ef þessi fyrirspurn gefur villu. Þessi gildi útiloka skipulagningu og útiloka ferðina til biðlarans þíns. Einmitt sú útilokun gerir þau gagnleg fyrir samanburðinn.

Teldu ferðir fram og til baka, ekki bara millisekúndur

Skýrsla byggð úr tvö hundruð litlum háðum skipunum margfaldar hvaða seinkun sem leiðin bætir við með tvö hundruð. Ein skipun sem skilar milljón röðum borgar þá seinkun einu sinni og borgar svo bandvídd í langan tíma. Báðar líta eins út í skeiðklukku biðlara, og þær þurfa gagnstæðar lagfæringar.

Mældu fjölda skipana í stað þess að áætla hann. Lestu heildina, keyrðu skýrsluna einu sinni, lestu hana svo aftur og dragðu frá.

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

Ef deltan er stór og hver skipun er ódýr á þjóninum, er hópunin lagfæringin sem borgar sig. Sameinaðu háðar fyrirspurnir, notaðu eina skipun byggða á mengjum eða keyrðu lykkjuna úr bendli. Í gagnvirku psql, \set FETCH_COUNT 1000 kemur stór niðurstaða í hópum og breytir því hvernig flutningurinn og minni biðlarans hegða sér. Það dregur ekki úr vinnu þjónsins, svo það bjargar ekki hægri fyrirspurn.

Athugaðu göngin fyrir endursendingar og MTU-stopp

Þegar litlar skipanir eru hraðar og stórar niðurstöður stöðvast hálfa leið, er fyrirspurnin venjulega í lagi og leiðin ekki. Göng þar sem MTU er lægra en undirliggjandi tenging, ásamt blokkuðu ICMP, framleiða nákvæmlega þetta mynstur: fyrstu pakkarnir koma, þeir stóru hverfa og flutningurinn hangir þar til hann reynir aftur. Endursendingateljarar á biðlarahlið sýna það.

Fylgstu með sætinu og teljurum kjarnans á meðan viljandi hægur flutningur gengur. Endursendingasummur eru uppsafnaðar, svo skráðu þær fyrir og eftir í stað þess að lesa eitt sýnishorn.

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

Endursendingar sem hækka meðan á flutningnum stendur, ásamt pingi sem heppnast við 1400 bæti en mistekst við 1472, benda til MTU-vandamáls en ekki gagnagrunnsvandamáls. Að lækka MTU gangatengingarinnar eða herða MSS við gáttina er venjulega lagfæringin, og sömu þrjár skipanir staðfesta hana síðan. Ef endursendingar haldast flatar á meðan flutningurinn er enn hægur, skoðaðu bandvíddina sem göngunum er leyfð frekar en tap.

Stutt röð nær yfir næstu hægu skýrslu: berðu saman eina skipun staðbundið, á LAN og yfir VPN; lestu keyrslu þjónsins úr EXPLAIN eða pg_stat_statements; teldu köll fyrir og eftir eina keyrslu; og fylgstu með endursendingum á meðan stóra niðurstaðan hreyfist. Hvert skref útilokar aðra hlið leiðarinnar. Ekkert þeirra krefst þess að giska á hvaða hluta á að endurræsa.