psql-tydsmeting oor 'n VPN: netwerkwag en navraagwerk skei

Jou verslag voltooi in omtrent 'n sekonde op die databasisgasheer en vier oor die VPN, en die getal wat psql druk, wys reguit na die databasis. Daardie getal is 'n stopwatch aan die kliëntkant, nie 'n bedienermeting nie. Dit dek die stelling op pad uit, die wag vir 'n antwoord, en die rye op pad terug. Om daardie drie uitmekaar te haal, is die enigste manier om te weet watter kant om in te stel.

Wat die psql-tydhouer werklik meet

\timing on begin 'n stophorlosie net voordat die kliënt die stelling na die sok skryf en stop wanneer die laaste ry van daardie resultaat gelees is. Die bediener se eie uitvoering sit iewers binne daardie venster, en so ook elke millisekonde wat die pakkette in die tonnel deurbring. Niks in die uitset skei hulle nie. EXPLAIN druk ook 'n getal, maar daardie een word deur die bediener geproduseer en sluit die kliënt se wag uit. Twee getalle, twee verskillende vrae.

Begin een sessie, laat tydsmeting aan, en voer die stelling waaroor jy sorg vanuit daardie sessie uit. Om 'n sessie te hergebruik hou die koppelkoste uit die eerste meting.

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

Die syfer sluit steeds die oordrag van die resultaat in, wat dit is wat jy hier wil hê. Dit sluit nie meer die koppel- en verifikasie-uitruiling in wat 'n nuwe oproep sou byvoeg nie.

Vergelyk een stelling oor drie paaie

Voer dieselfde stelling oor die Unix-sok, oor die LAN-adres en oor die VPN-gasheernaam uit, en vergelyk die drie. As net die laaste een stadig is, is die navraag nie die veranderlike nie.

Elke oproep koppel eers en meet dan eers die stelling, so die koppelkoste bly uit die getal terwyl die oordrag binne bly. Hou die WHERE-klousule, die rytelling en die kliëntmasjien identies, anders vergelyk jy werklading eerder as paaie.

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 'n LAN is die verskil gewoonlik klein genoeg om te ignoreer; oor 'n VPN is dit dikwels nie. Om die drie resultate te sorteer, sê dan vir jou watter wag om aan te val.

'n Stadige plaaslike sok beteken bedienerwerk of beplanning. 'n Stadige LAN-resultaat beteken die navraag of die volume wat dit beweeg. Slegs 'n stadige VPN-resultaat beteken latensie, MTU of beskikbare bandwydte op die pad, en geen indeksveranderinge verhelp dit nie.

Kry die bediener se eie uitvoeringstyd

Die bediener kan rapporteer hoeveel tyd hy spandeer het, en daardie syfer is die een om teen die kliënt se syfer te hou. EXPLAIN met ANALYZE voer die stelling uit en druk beplanning- en uitvoeringstyd binne die plan, terwyl BUFFERS kasgedrag byvoeg wat dikwels 'n warm lopie teenoor 'n koue een verduidelik. Moenie dit op skryfstellings rig tensy jy van plan is om te skryf nie. Op 'n lees-alleen-replika is dit die veiligste plek om te begin, en die psql-verwysing dokumenteer die tydhouer se bestek aan die kliëntkant.

Vir stellings wat die toepassing reeds uitvoer, versamel pg_stat_statements bedienerkant-uitvoering sonder om enigiets weer te laat loop. Die rye is per genormaliseerde navraag, so een inskrywing kan verskeie oproepplekke dek.

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

Kolomname verskil per weergawe: PostgreSQL 13 en later bied mean_exec_time, terwyl ouer weergawes dit mean_time noem, so kyk met \d pg_stat_statements as daardie navraag 'n fout gee. Hierdie waardes sluit beplanning uit en sluit die reis na jou kliënt uit. Daardie uitsluiting is juis waarom hulle nuttig is vir die vergelyking.

Tel heen-en-weer-reise, nie net millisekondes nie

'n Verslag wat uit tweehonderd klein afhanklike stellings gebou is, vermenigvuldig watter latensie die pad ook byvoeg met tweehonderd. 'n Enkele stelling wat 'n miljoen rye terugstuur, betaal daardie latensie een keer en betaal dan bandwydte vir 'n lang tyd. Albei lyk identies in 'n kliënttydhouer, en hulle het teenoorgestelde regstellings nodig.

Meet die stellingtelling in plaas daarvan om dit te skat. Lees die totaal, voer die verslag een keer uit, lees dit dan weer en trek af.

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

As die delta groot is en elke stelling op die bediener goedkoop is, is bondeling die regstelling wat betaal. Kombineer afhanklike navrae, gebruik een stelling op versamelingbasis, of dryf die lus vanaf 'n wyser. In interaktiewe psql, \set FETCH_COUNT 1000 laat 'n groot resultaat in bondels aankom en verander hoe die oordrag en die kliëntgeheue optree. Dit verminder nie bedienerwerk nie, so dit sal nie 'n stadige navraag red nie.

Kyk die tonnel na vir herversendings en MTU-stilstande

Wanneer klein stellings vinnig is en groot resultate halfpad vasloop, is die navraag gewoonlik reg en die pad nie. 'n Tonnel wie se MTU laer is as die onderliggende skakel, gekombineer met geblokkeerde ICMP, produseer presies daardie patroon: die eerste pakkette kom aan, die groot ene verdwyn, en die oordrag hang totdat dit weer probeer. Kliëntkant-herversendingstellers wys dit.

Hou die sok en die kerntellers dop terwyl 'n doelbewus stadige oordrag loop. Herversendingtellers is kumulatief, so merk hulle voor en ná eerder as om een monster te lees.

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

Herversendings wat tydens die oordrag klim, saam met 'n ping wat by 1400 grepe slaag maar by 1472 misluk, wys na 'n MTU-probleem eerder as 'n databasisprobleem. Om die tonnelkoppelvlak se MTU te verlaag of MSS by die poort te knyp is die gewone regstelling, en dieselfde drie opdragte bevestig dit daarna. As herversendings plat bly terwyl die oordrag steeds stadig is, kyk na die bandwydte wat die tonnel toegelaat word eerder as na verlies.

'n Kort reeks dek die volgende stadige verslag: vergelyk een stelling plaaslik, op die LAN en oor die VPN; lees bedieneruitvoering uit EXPLAIN of pg_stat_statements; tel oproepe voor en ná 'n enkele lopie; en hou herversendings dop terwyl die groot resultaat beweeg. Elke stap sluit een kant van die pad uit. Nie een daarvan vereis om te raai watter komponent om te herbegin nie.