د 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 یا شته بډوېت معنا لري، او هېڅ د فهرست بدلون هغه نه سموني۔

د سرور خپل اجرا وخت را وباسئ

سرور کولی شي راپور ورکړي چې څومره وخت یې تېر کړ، او د کلاینټ له شمېرې سره د پرتلو وړ شمېره هماغه ده۔ EXPLAIN د ANALYZE سره بیان چلوي او د پلان په داخل کې د پلان او اجرا وخت چاپوي، پداسې حال کې چې 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

د لېږد په جریان کې لوړېدونکې بیا لېږنې، د ping سره چې په 1400 بایټ کې بریالي او په 1472 کې ناکام وي، د ډیټابیس ستونزې نه بلکې د MTU ستونزې ته اشاره کوي۔ د تونل انټرفیس MTU ټیټول یا په ګیټوې کې MSS غونځول معمول سمون دی، او هماغه درې حکمونه یې وروسته تاییدوي۔ که لېږد لا هم ورو وي او بیا لېږنې هوارې پاتې شي، د زیان پر ځای د تونل د اجازې ورکړل شوې بډوېت ته وګورئ۔

لنډ ترتیب بله ورو راپور پوښي: یو بیان په سیمه ییز ډول، په LAN او د VPN له لارې پرتله کړئ؛ د سرور اجرا له EXPLAIN یا pg_stat_statements څخه ولولئ؛ د یو ځل چلولو مخکې او وروسته غږونه وشمېرئ؛ او کله چې لویه پایله ځای په ځای کیږي بیا لېږنې وګورئ۔ هره پښه د لارې یوه خوا بېلوي۔ له دوی څخه هیڅ یو دا نه غواړي چې اټکل کړئ کوم برخه بیا پیل کړئ۔