VPN ద్వారా psql సమయ మాపనం: నెట్వర్క్ నిరీక్షణను క్వెరీ పని నుండి వేరు చేయడం

మీ నివేదిక డేటాబేస్ హోస్ట్పై సుమారు ఒక సెకనులో మరియు VPN ద్వారా నాలుగింటిలో పూర్తవుతుంది, మరియు psql ముద్రించే సంఖ్య నేరుగా డేటాబేస్ వైపు చూపుతుంది. ఆ సంఖ్య క్లయింట్ వైపు స్టాప్వాచ్, సర్వర్ కొలత కాదు. ఇది స్టేట్మెంట్ బయటకు వెళ్లే మార్గం, సమాధానం కోసం నిరీక్షణ మరియు తిరిగి వచ్చే వరుసలను కలిగి ఉంటుంది. ఈ మూడింటిని వేరు చేయడమే ఏ వైపు సర్దుబాటు చేయాలో తెలుసుకోవడానికి ఏకైక మార్గం.

psql టైమర్ నిజంగా ఏమి కొలుస్తుంది

\timing on క్లయింట్ స్టేట్మెంట్ను సాకెట్లో రాయడానికి సరిగ్గా ముందు స్టాప్వాచ్ ప్రారంభించి, ఆ ఫలితం చివరి వరుస చదివినప్పుడు ఆపుతుంది. సర్వర్ యొక్క స్వంత అమలు ఆ విండోలో ఎక్కడో ఉంటుంది, ప్యాకెట్లు టన్నెల్లో గడిపే ప్రతి మిల్లీసెకన్ కూడా అలాగే. అవుట్పుట్లో ఏదీ వాటిని వేరు చేయదు. EXPLAIN కూడా సంఖ్యను ముద్రిస్తుంది, కానీ దానిని సర్వర్ ఉత్పత్తి చేస్తుంది మరియు క్లయింట్ నిరీక్షణను మినహాయిస్తుంది. రెండు సంఖ్యలు, రెండు వేర్వేరు ప్రశ్నలు.

ఒక సెషన్ ప్రారంభించి, సమయ మాపనాన్ని ఆన్లో ఉంచి, మీకు ముఖ్యమైన స్టేట్మెంట్ను దాని లోపలి నుండి అమలు చేయండి. సెషన్ను తిరిగి ఉపయోగించడం కనెక్ట్ ఖర్చును మొదటి కొలత నుండి బయట ఉంచుతుంది.

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

సంఖ్య ఇప్పటికీ ఫలితం యొక్క బదిలీని కలిగి ఉంటుంది, అదే ఇక్కడ మీకు కావాల్సినది. కొత్త పిలుపు జోడించే కనెక్ట్ మరియు ప్రామాణీకరణ మార్పిడిని ఇది ఇకపై కలిగి ఉండదు.

ఒక స్టేట్మెంట్ను మూడు మార్గాల్లో పోల్చండి

అదే స్టేట్మెంట్ను Unix సాకెట్, LAN చిరునామా మరియు VPN హోస్ట్ పేరు ద్వారా అమలు చేసి మూడింటిని పోల్చండి. చివరిది మాత్రమే నెమ్మదిగా ఉంటే, క్వెరీ మారకం కాదు.

ప్రతి పిలుపు మొదట కనెక్ట్ అయి ఆ తర్వాతే స్టేట్మెంట్ను కొలుస్తుంది, కాబట్టి కనెక్ట్ ఖర్చు సంఖ్యకు బయట మరియు బదిలీ లోపల ఉంటాయి. WHERE నిబంధన, వరుసల సంఖ్య మరియు క్లయింట్ మెషీన్ను ఒకేలా ఉంచండి, లేకపోతే మీరు మార్గాలను కాదు, పని భారాలను పోలుస్తున్నారు.

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 లో తేడా సాధారణంగా విస్మరించదగినంత చిన్నది; VPN ద్వారా చాలాసార్లు అలా ఉండదు. మూడు ఫలితాలను క్రమబద్ధీకరించడం ఏ నిరీక్షణపై దాడి చేయాలో తర్వాత చెబుతుంది.

నెమ్మదైన స్థానిక సాకెట్ అంటే సర్వర్ పని లేదా ప్రణాళిక. నెమ్మదైన LAN ఫలితం అంటే క్వెరీ లేదా అది కదిలించే పరిమాణం. VPN ఫలితం మాత్రమే నెమ్మదిగా ఉండటం అంటే మార్గంలో ఆలస్యం, MTU లేదా అందుబాటులో ఉన్న బ్యాండ్విడ్త్, మరియు ఏ ఇండెక్స్ మార్పు దానిని సరిచేయదు.

సర్వర్ యొక్క స్వంత అమలు సమయాన్ని తీయండి

సర్వర్ ఎంత సమయం గడిపిందో నివేదించగలదు, మరియు క్లయింట్ సంఖ్యతో పోల్చవలసిన సంఖ్య అదే. ANALYZE తో EXPLAIN స్టేట్మెంట్ను అమలు చేసి ప్రణాళిక లోపల ప్రణాళిక మరియు అమలు సమయాన్ని ముద్రిస్తుంది, BUFFERS వెచ్చని పరుగును చల్లని పరుగు నుండి వివరించే కాష్ ప్రవర్తనను జోడిస్తుంది. రాయాలని ఉద్దేశం లేకపోతే దానిని రాత స్టేట్మెంట్ల వైపు తిప్పవద్దు. చదవడానికి మాత్రమే ఉన్న ప్రతిలో ప్రారంభించడానికి అత్యంత సురక్షితమైన స్థలం అదే, మరియు psql సూచన టైమర్ యొక్క క్లయింట్ వైపు పరిధిని నమోదు చేస్తుంది.

అప్లికేషన్ ఇప్పటికే అమలు చేసే స్టేట్మెంట్లకు, pg_stat_statements ఏదీ తిరిగి అమలు చేయకుండా సర్వర్ వైపు అమలును సేకరిస్తుంది. వరుసలు సాధారణీకరించిన క్వెరీకి, కాబట్టి ఒక ఎంట్రీ అనేక పిలుపు స్థలాలను ఆవరించగలదు.

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

నిలువు వరుసల పేర్లు విడుదల ప్రకారం మారుతాయి: PostgreSQL 13 మరియు తర్వాత mean_exec_time చూపుతాయి, పాత సంస్కరణలు దానిని mean_time అని పిలుస్తాయి, కాబట్టి తనిఖీ చేయండి \d pg_stat_statements తో, ఆ క్వెరీ లోపం ఇస్తే. ఈ విలువలు ప్రణాళికను మినహాయిస్తాయి మరియు మీ క్లయింట్ వరకు ప్రయాణాన్ని కూడా మినహాయిస్తాయి. ఆ మినహాయింపే వాటిని పోలికకు ఉపయోగకరంగా చేస్తుంది.

వెళ్లి-వచ్చే ప్రయాణాలను లెక్కించండి, మిల్లీసెకన్లు మాత్రమే కాదు

రెండు వందల చిన్న ఆధారిత స్టేట్మెంట్లతో నిర్మించిన నివేదిక మార్గం జోడించే ఏ ఆలస్యాన్నైనా రెండు వందలతో గుణిస్తుంది. పది లక్షల వరుసలను తిరిగి ఇచ్చే ఒక స్టేట్మెంట్ ఆ ఆలస్యాన్ని ఒకసారి చెల్లించి తర్వాత చాలాకాలం బ్యాండ్విడ్త్ చెల్లిస్తుంది. రెండూ క్లయింట్ టైమర్లో ఒకేలా కనిపిస్తాయి, రెండింటికీ వ్యతిరేక సరిదిద్దులు అవసరం.

స్టేట్మెంట్ల సంఖ్యను అంచనా వేయకుండా కొలవండి. మొత్తాన్ని చదవండి, నివేదికను ఒకసారి అమలు చేయండి, తర్వాత మళ్లీ చదివి తీసివేయండి.

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

డెల్టా పెద్దగా ఉండి సర్వర్లో ప్రతి స్టేట్మెంట్ చవకగా ఉంటే, బ్యాచింగ్ ఫలితమిచ్చే సరిదిద్దు. ఆధారిత క్వెరీలను కలపండి, ఒక సెట్ ఆధారిత స్టేట్మెంట్ ఉపయోగించండి, లేదా కర్సర్ నుండి లూప్ నడపండి. ఇంటరాక్టివ్ psql లో, \set FETCH_COUNT 1000 పెద్ద ఫలితం బ్యాచ్లుగా రావడానికి అనుమతించి బదిలీ మరియు క్లయింట్ మెమరీ ప్రవర్తనను మారుస్తుంది. ఇది సర్వర్ పనిని తగ్గించదు, కాబట్టి నెమ్మదైన క్వెరీని కాపాడదు.

టన్నెల్ను పునఃప్రసారాలు మరియు MTU ఆగుడుల కోసం తనిఖీ చేయండి

చిన్న స్టేట్మెంట్లు వేగంగా ఉండి పెద్ద ఫలితాలు సగం దారిలో ఆగిపోయినప్పుడు, క్వెరీ సాధారణంగా బాగానే ఉంటుంది, మార్గం కాదు. ప్రాథమిక లింక్ కంటే MTU తక్కువ ఉన్న టన్నెల్, నిరోధించిన ICMP తో కలిసి అదే నమూనాను ఉత్పత్తి చేస్తుంది: మొదటి ప్యాకెట్లు వస్తాయి, పెద్దవి మాయమవుతాయి, బదిలీ మళ్లీ ప్రయత్నించే వరకు వేలాడుతుంది. క్లయింట్ వైపు పునఃప్రసార కౌంటర్లు దానిని చూపుతాయి.

ఉద్దేశపూర్వకంగా నెమ్మదైన బదిలీ నడుస్తున్నప్పుడు సాకెట్ మరియు కెర్నల్ కౌంటర్లను గమనించండి. పునఃప్రసార మొత్తాలు సంచితం, కాబట్టి ఒక నమూనా చదవడం కంటే ముందు మరియు తర్వాత నమోదు చేయండి.

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

బదిలీ సమయంలో పెరిగే పునఃప్రసారాలు, 1400 బైట్లో విజయవంతమై 1472 లో విఫలమయ్యే ping తో కలిసి, డేటాబేస్ సమస్య కాదు MTU సమస్యను సూచిస్తాయి. టన్నెల్ ఇంటర్ఫేస్ MTU ను తగ్గించడం లేదా గేట్వేలో MSS ను బిగించడం సాధారణ సరిదిద్దు, మరియు అదే మూడు ఆదేశాలు తర్వాత దానిని నిర్ధారిస్తాయి. బదిలీ ఇంచుమించు నెమ్మదిగా ఉన్నప్పుడు పునఃప్రసారాలు సమతలంగా ఉంటే, నష్టం వైపు కాదు టన్నెల్కు అనుమతించిన బ్యాండ్విడ్త్ వైపు చూడండి.

చిన్న క్రమం తదుపరి నెమ్మదైన నివేదికను ఆవరిస్తుంది: ఒక స్టేట్మెంట్ను స్థానికంగా, LAN లో మరియు VPN ద్వారా పోల్చండి; EXPLAIN లేదా pg_stat_statements నుండి సర్వర్ అమలును చదవండి; ఒకసారి అమలు చేయడానికి ముందు మరియు తర్వాత పిలుపులను లెక్కించండి; మరియు పెద్ద ఫలితం కదులుతున్నప్పుడు పునఃప్రసారాలను గమనించండి. ప్రతి అడుగు మార్గంలో ఒక వైపును మినహాయిస్తుంది. వాటిలో ఏదీ ఏ భాగాన్ని పునఃప్రారంభించాలో ఊహించమని అడగదు.