Kupima muda wa psql kupitia VPN: kutenganisha kusubiri kwa mtandao na kazi ya hoja

psql huripoti namba moja ya muda uliopita kwa kila taarifa, kwa hivyo VPN polepole huiongeza. Tenganisha muda wa kuunganisha, utekelezaji, uhamishaji na kwenda na kurudi kabla ya kurekebisha upande wowote.

Ripoti yako inakamilika kwa takriban sekunde moja kwenye mwenyeji wa hifadhidata na kwa nne kupitia VPN, na namba ambayo psql huchapisha inaelekeza moja kwa moja kwenye hifadhidata. Namba hiyo ni saa ya kusimamisha kwa upande wa mteja, si kipimo cha seva. Inashughulikia taarifa ikiwa njiani kwenda nje, kusubiri jibu na safu zinazorudi. Kutenganisha hizi tatu ndiyo njia pekee ya kujua upande gani wa kurekebisha.

Kipima muda cha psql hupima nini hasa

\timing on huanzisha saa ya kusimamisha kabla mteja kuandika taarifa kwenye soketi na huacha pale safu ya mwisho ya matokeo hayo inaposomwa. Utekelezaji wa seva yenyewe uko mahali fulani ndani ya dirisha hilo, na pia kila milisekunde ambayo pakiti hutumia kwenye handaki. Hakuna chochote kwenye matokeo kinachowatenganisha. EXPLAIN pia huchapisha namba, lakini hiyo huizalishwa na seva na huondoa kusubiri kwa mteja. Namba mbili, maswali mawili tofauti.

Anzisha kipindi kimoja, acha upimaji muda ukiwa umewashwa, na endesha taarifa unayojali kutoka ndani yake. Kutumia tena kipindi huweka gharama ya kuunganisha nje ya kipimo cha kwanza.

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

Namba bado inajumuisha uhamishaji wa matokeo, ambayo ndiyo unayotaka hapa. Haijumuishi tena mabadilishano ya kuunganisha na uthibitishaji ambayo wito mpya ungeongeza.

Linganisha taarifa moja kwenye njia tatu

Endesha taarifa hiyo hiyo kupitia soketi ya Unix, anwani ya LAN na jina la mwenyeji wa VPN, na linganisha zote tatu. Ikiwa ya mwisho pekee ni polepole, hoja si kigezo.

Kila wito huunganisha kwanza na kisha hupima taarifa, kwa hivyo gharama ya kuunganisha hubaki nje ya namba wakati uhamishaji hubaki ndani. Weka kifungu cha WHERE, idadi ya safu na mashine ya mteja sawa, vinginevyo unalinganisha mizigo ya kazi badala ya njia.

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

Kwenye LAN tofauti kawaida ni ndogo vya kutosha kupuuzwa; kupitia VPN mara nyingi sivyo. Kupanga matokeo matatu kisha hukuambia ni kusubiri gani kushambulia.

Soketi ya ndani polepole inamaanisha kazi ya seva au upangaji. Matokeo ya LAN polepole inamaanisha hoja au kiasi inachohamisha. Matokeo ya VPN pekee kuwa polepole inamaanisha ucheleweshaji, MTU au bandwidth inayopatikana kwenye njia, na hakuna mabadiliko ya index yanayorekebisha hilo.

Toa muda wa utekelezaji wa seva yenyewe

Seva inaweza kuripoti ilitumia muda gani, na namba hiyo ndiyo ya kusawazisha na ya mteja. EXPLAIN pamoja na ANALYZE huendesha taarifa na huchapisha muda wa upangaji na utekelezaji ndani ya mpango, wakati BUFFERS huongeza tabia ya akiba ambayo mara nyingi hueleza mbio za joto dhidi ya baridi. Usiielekeze kwenye taarifa za kuandika isipokuwa unakusudia kuandika. Kwenye nakala ya kusoma tu ndipo mahali salama pa kuanzia, na marejeleo ya psql hutia hati wigo wa kipima muda kwa upande wa mteja.

Kwa taarifa ambazo programu tayari huendesha, pg_stat_statements hukusanya utekelezaji wa upande wa seva bila kuendesha chochote tena. Safu ni kwa kila hoja iliyosanifishwa, kwa hivyo ingizo moja linaweza kufunika maeneo kadhaa ya wito.

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

Majina ya safu wima hutofautiana kwa toleo: PostgreSQL 13 na baadaye hufichua mean_exec_time, wakati matoleo ya zamani huiita mean_time, kwa hivyo angalia kwa \d pg_stat_statements ikiwa hoja hiyo inatoa hitilafu. Thamani hizi huondoa upangaji na huondoa safari hadi kwa mteja wako. Kuondoa hilo ndiko kunazifanya ziwe na manufaa kwa ulinganisho.

Hesabu safari za kwenda na kurudi, si milisekunde pekee

Ripoti iliyojengwa kwa taarifa mia mbili ndogo zinazotegemeana huzidisha ucheleweshaji wowote unaoongezwa na njia kwa mia mbili. Taarifa moja inayorudisha safu milioni moja hulipa ucheleweshaji huo mara moja kisha hulipa bandwidth kwa muda mrefu. Zote mbili zinaonekana sawa kwenye kipima muda cha mteja, na zinahitaji marekebisho kinyume.

Pima idadi ya taarifa badala ya kuikadiria. Soma jumla, endesha ripoti mara moja, kisha isome tena na uondoe.

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

Ikiwa delta ni kubwa na kila taarifa ni nafuu kwenye seva, kuweka kwa makundi ndio marekebisho yanayolipa. Unganisha hoja zinazotegemeana, tumia taarifa moja inayotegemea seti, au endesha mzunguko kutoka kwa kielekezi. Katika psql shirikishi, \set FETCH_COUNT 1000 matokeo makubwa huja kwa makundi na hubadilisha tabia ya uhamishaji na kumbukumbu ya mteja. Haipunguzi kazi ya seva, kwa hivyo haitaokoa hoja polepole.

Kagua handaki kwa utumaji upya na vituo vya MTU

Wakati taarifa ndogo ni za haraka na matokeo makubwa yanakwama katikati ya njia, hoja kawaida iko sawa na njia haiko. Handaki ambalo MTU yake ni ndogo kuliko kiungo cha chini, pamoja na ICMP iliyozuiwa, huzalisha mtindo huo hasa: pakiti za kwanza hufika, kubwa hutoweka, na uhamishaji huning'inia hadi ujaribu tena. Vihesabu vya utumaji upya vya upande wa mteja vinaonyesha hilo.

Angalia soketi na vihesabu vya kernel wakati uhamishaji wa makusudi polepole unaendelea. Jumla za utumaji upya ni za kukusanywa, kwa hivyo zirekodi kabla na baada badala ya kusoma sampuli moja.

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

Utumaji upya unaopanda wakati wa uhamishaji, pamoja na ping inayofanikiwa kwa baiti 1400 lakini kushindwa kwa 1472, unaonyesha tatizo la MTU na si tatizo la hifadhidata. Kupunguza MTU ya kiolesura cha handaki au kukaza MSS kwenye lango ndio marekebisho ya kawaida, na amri hizo tatu huthibitisha baadaye. Ikiwa utumaji upya unabaki tambarare wakati uhamishaji bado ni polepole, angalia bandwidth inayoruhusiwa handaki badala ya upotevu.

Mfululizo mfupi hufunika ripoti polepole ijayo: linganisha taarifa moja kwa ndani, kwenye LAN na kupitia VPN; soma utekelezaji wa seva kutoka EXPLAIN au pg_stat_statements; hesabu wito kabla na baada ya mbio moja; na angalia utumaji upya wakati matokeo makubwa yanasonga. Kila hatua huondoa upande mmoja wa njia. Hakuna hata moja inayohitaji kukisia sehemu gani ya kuanzisha upya.

Makala zinazohusiana