د الیکسي لیسوفسکي د 2015 راپور نقل "د PostgreSQL داخلي احصایو کې ژور ډوب"
د راپور د لیکوال څخه انکار: زه یادونه کوم چې دا راپور د نومبر 2015 نیټه ده - له 4 څخه ډیر کلونه تیر شوي او ډیر وخت تیر شوی. په راپور کې بحث شوی 9.4 نسخه نور ملاتړ نه کوي. په تیرو 4 کلونو کې ، 5 نوي ریلیزونه خپاره شوي چې د احصایې په اړه ډیری نوښتونه ، اصلاحات او بدلونونه شتون لري او ځینې مواد زاړه او اړوند ندي. لکه څنګه چې زه بیاکتنه کوم، ما هڅه وکړه چې دا ځایونه په نښه کړم ترڅو لوستونکی ګمراه نه کړي. ما دا عبارتونه بیا نه دي لیکلي، ډیری یې شتون لري او پایله به یې یو بشپړ مختلف راپور وي.
د PostgreSQL DBMS یو لوی میکانیزم دی، او دا میکانیزم ډیری فرعي سیسټمونه لري، د همغږۍ عملیات چې مستقیم د DBMS فعالیت اغیزه کوي. د عملیاتو په جریان کې ، د اجزاو عملیاتو په اړه احصایې او معلومات راټول شوي ، کوم چې تاسو ته اجازه درکوي د PostgreSQL اغیزمنتوب ارزونه وکړئ او د فعالیت ښه کولو لپاره اقدامات وکړئ. په هرصورت، پدې کې ډیری معلومات شتون لري او دا په ساده بڼه وړاندې کیږي. د دې معلوماتو پروسس کول او تشریح کول ځینې وختونه په بشپړ ډول غیر معمولي کار دی، او د وسیلو او اسانتیاوو "ژوبڼ" کولی شي په اسانۍ سره حتی پرمختللي DBA ګډوډ کړي.
بعد له غرمه مو پخیر زما نوم الکسي دی. لکه څنګه چې الیا وویل، زه به د PostgreSQL احصایې په اړه وغږیږم.
د PostgreSQL فعالیت احصایې. PostgreSQL دوه احصایې لري. د فعالیت احصایې چې به پرې بحث وشي. او د ډیټا ویشلو په اړه د مهالویش احصایې. زه به په ځانګړي ډول د PostgreSQL فعالیت احصایو په اړه وغږیږم، کوم چې موږ ته اجازه راکوي د فعالیت قضاوت وکړو او یو څه یې ښه کړو.
زه به تاسو ته ووایم چې څنګه په اغیزمنه توګه د احصایې کارولو لپاره د مختلفو ستونزو حل کولو لپاره چې تاسو یې لرئ یا لرئ.
په راپور کې به څه نه وي؟ په راپور کې به زه د مهالویش احصایو ته لاس ورنکړم ، ځکه چې ... دا د جلا راپور لپاره جلا موضوع ده چې په ډیټابیس کې ډاټا څنګه ذخیره کیږي او څنګه د پوښتنې پالن جوړونکي د دې معلوماتو کیفیت او کمیتي ځانګړتیاوو په اړه نظر ترلاسه کوي.
او د وسیلې بیاکتنې به نه وي، زه به یو محصول د بل سره پرتله نه کړم. هیڅ اعلان به نه وي. راځئ چې دا یو طرف ته واچوو.
زه غواړم تاسو ته وښیم چې د احصایې کارول ګټور دي. دا ضروري ده. دا د کارولو لپاره خوندي دی. ټول هغه څه چې موږ ورته اړتیا لرو منظم SQL او د SQL لومړنۍ پوهه ده.
او راځئ چې د ستونزو د حل لپاره د کومې احصایې غوره کولو په اړه وغږیږو.
که موږ PostgreSQL ته وګورو او د پروسو لیدلو لپاره په عملیاتي سیسټم کې کمانډ چلوو، موږ به یو "تور بکس" وګورو. موږ به ځینې پروسې وګورو چې یو څه کوي، او د نوم څخه موږ کولی شو تصور وکړو چې دوی هلته څه کوي، دوی څه کوي. مګر، په اصل کې، دا یو تور بکس دی؛ موږ نشو کولی دننه وګورو.
موږ کولی شو د CPU بار دننه وګورو top، موږ کولی شو د ځینې سیسټم اسانتیاو لخوا د حافظې کارول وګورو ، مګر موږ به نشو کولی د PostgreSQL دننه وګورو. د دې لپاره موږ نورو وسایلو ته اړتیا لرو.
او په دوام ورکولو سره، زه به تاسو ته ووایم چې وخت چیرته تیریږي. که موږ د داسې ډیاګرام په بڼه PostgreSQL تصور کړو، نو موږ کولی شو ځواب ورکړو چې وخت چیرته مصرف شوی. دا دوه شیان دي: دا د غوښتنلیکونو څخه د پیرودونکي غوښتنې پروسس کوي او د شالید دندو چې PostgreSQL د ځان د چلولو لپاره ترسره کوي.
که موږ د پورتنۍ ښي کونج ته کتل پیل کړو، موږ کولی شو وګورو چې د پیرودونکي غوښتنې څنګه پروسس کیږي. غوښتنه د غوښتنلیک څخه راځي او د نور کار لپاره د مراجعینو ناسته پرانستل کیږي. غوښتنه مهالویش ته لیږل کیږي. مهالویش کونکی د پوښتنې پلان جوړوي. د اور وژنې لپاره یې لیږي. د جدولونو او شاخصونو سره تړلي یو ډول بلاک ډیټا ان پټ/آؤټ پوټ شتون لري. اړین معلومات د ډیسکونو څخه حافظې ته په ځانګړي ساحه "شریک بفر" کې لوستل کیږي. د غوښتنې پایلې، که دوی تازه وي، حذف شوي وي، په WAL کې د لیږد په لاګ کې ثبت شوي. ځینې احصایوي معلومات په لاګ یا احصایې راټولونکي کې پای ته رسیږي. او د غوښتنې پایله بیرته پیرودونکي ته لیږل کیږي. له هغې وروسته پیرودونکی کولی شي هرڅه د نوي غوښتنې سره بیا تکرار کړي.
د شاليد دندو او شاليد پروسو په اړه څه؟ موږ ډیری پروسې لرو چې ډیټابیس ساتي او په نورمال عملیاتي حالت کې پرمخ وړي. دا پروسې به په راپور کې هم وڅیړل شي: آٹوواکوم، چیک پوینټر، د نقل پورې اړوند پروسې، د شالید لیکوال. زه به د دوی هر یو سره اړیکه ونیسم لکه څنګه چې زه راپور ورکوم.
د احصایې سره کومې ستونزې شتون لري؟
- ډیر معلومات شتون لري. PostgreSQL 9.4 د احصایې ډیټا لیدو لپاره 109 میټریک چمتو کوي. په هرصورت، که چیرې ډیټابیس ډیری میزونه، سکیما، ډیټابیسونه ذخیره کړي، نو دا ټول میټریکونه باید د ورته میزونو، ډیټابیسونو شمیر سره ضرب شي. دا دی، حتی ډیر معلومات شتون لري. او په دې کې ډوب کول خورا اسانه دي.
- بله ستونزه دا ده چې احصایې د شمیرونکو لخوا استازیتوب کیږي. که موږ دې احصایو ته وګورو، نو موږ به په دوامداره توګه د شمیرو شمیر زیات کړو. او که چیرې د احصایې له تنظیم کولو څخه ډیر وخت تیر شو ، نو موږ به په ملیاردونو کې ارزښتونه وګورو. او دوی موږ ته هیڅ نه وایی.
- کیسه نشته. که تاسو یو ډول ناکامي درلوده، یو څه 15-30 دقیقې مخکې راوتلی، تاسو به نشئ کولی احصایې وکاروئ او وګورئ چې 15-30 دقیقې مخکې څه پیښ شوي. دا ستونزه ده.
- په PostgreSQL کې جوړ شوي وسیلې نشتوالی یوه ستونزه ده. د کرنل پراختیا کونکي هیڅ ډول ګټه نه ورکوي. دوی داسې څه نه لري. دوی په ساده ډول په ډیټابیس کې احصایې چمتو کوي. هغه وکاروئ، غوښتنه وکړئ، هر څه چې غواړئ هغه وکړئ.
- څرنګه چې په PostgreSQL کې هیڅ وسیله شتون نلري، دا د بلې ستونزې لامل کیږي. د دریمې ډلې ډیری وسیلې. هر شرکت چې لږ یا لږ مستقیم لاسونه لري هڅه کوي خپل برنامه ولیکي. او د پایلې په توګه، ټولنه ډیری وسایل لري چې د احصایې سره کار کولو لپاره کارول کیدی شي. او ځینې وسایل ځینې وړتیاوې لري، نورې وسیلې نورې وړتیاوې نلري، یا ځینې نوي وړتیاوې لري. او یو حالت رامینځته کیږي چې تاسو اړتیا لرئ دوه، درې یا څلور وسیلې وکاروئ چې یو له بل سره تیریږي او مختلف دندې لري. دا ډیر ناخوښ دی.
له دې څخه څه تعقیب کیږي؟ دا مهمه ده چې په مستقیم ډول د احصایې اخیستلو توان ولرئ، ترڅو په برنامو پورې اړه ونلري، یا په یو ډول دا پروګرامونه پخپله ښه کړي: د خپلې ګټې ترلاسه کولو لپاره ځینې دندې اضافه کړئ.
او تاسو د SQL لومړني پوهه ته اړتیا لرئ. د احصایو څخه ځینې ډاټا ترلاسه کولو لپاره، تاسو اړتیا لرئ چې د SQL پوښتنو رامینځته کړئ، د بیلګې په توګه تاسو اړتیا لرئ پوه شئ چې څنګه انتخاب او یوځای کول تالیف شوي.
احصایې موږ ته څو شیان وایی. دوی په کټګوریو ویشل کیدی شي.
- لومړۍ کټګورۍ هغه پیښې دي چې په ډیټابیس کې پیښیږي. دا هغه وخت دی کله چې په ډیټابیس کې ځینې پیښې واقع کیږي: غوښتنه، میز ته لاسرسی، آٹوواکوم، ژمنې، بیا دا ټولې پیښې دي. د دې پیښو اړوند شمیرونکي ډیر شوي. او موږ کولی شو دا پیښې تعقیب کړو.
- دویمه کټګوري د شیانو ملکیتونه دي لکه میزونه او ډیټابیسونه. دوی ملکیتونه لري. دا د میزونو اندازه ده. موږ کولی شو د جدولونو وده او د شاخصونو وده تعقیب کړو. موږ کولی شو په متحرکاتو کې بدلونونه وګورو.
- او دریمه کټګوري هغه وخت دی چې په پیښه کې مصرف شوي. غوښتنه یوه پیښه ده. دا د خپل وخت ځانګړی اندازه لري. دلته پیل شو، دلته ختم شو. موږ کولی شو دا تعقیب کړو. یا هم هغه وخت چې دا د ډیسک څخه د بلاک لوستلو یا لیکلو وخت نیسي. دا ډول شیان هم څارل کیږي.
د احصایې سرچینې په لاندې ډول وړاندې کیږي:
- په شریکه حافظه کې (شریک بفرونه) د جامد ډیټا ذخیره کولو لپاره یوه برخه شتون لري ، داسې کاونټرونه هم شتون لري چې په دوامداره توګه وده کوي کله چې ځینې پیښې رامینځته کیږي ، یا د ډیټابیس په عملیاتو کې ځینې شیبې رامینځته کیږي.
- دا ټول کاونټرونه د کارونکي لپاره د لاسرسي وړ ندي او حتی مدیر ته د لاسرسي وړ ندي. دا د ټیټې کچې شیان دي. دوی ته د لاسرسي لپاره، PostgreSQL د SQL دندو په بڼه یو انٹرفیس چمتو کوي. موږ کولی شو د دې فنکشنونو په کارولو سره انتخاب غوره کړو او یو ډول میټریک (یا د میټریک سیټ) ترلاسه کړو.
- په هرصورت، د دې دندو کارول تل اسانه ندي، نو افعال د لیدونو اساس دی (VIEWs). دا مجازی میزونه دي چې په یو ځانګړي فرعي سیسټم کې احصایې چمتو کوي، یا په ډیټابیس کې د پیښو یو ټاکلی سیټ باندې.
- دا سرایت شوي لیدونه (VIEWs) د احصایو سره کار کولو لپاره لومړني کارونکي انٹرفیس دي. دوی د ډیفالټ لخوا پرته له کوم اضافي ترتیباتو شتون لري ، تاسو کولی شئ سمدلاسه یې وکاروئ ، دوی وګورئ او له دوی څخه معلومات واخلئ. او بیا هلته مرستې شتون لري. مرستې رسمي دي. تاسو کولی شئ د postgresql-contrib بسته نصب کړئ (د مثال په توګه، postgresql94-contrib)، په ترتیب کې اړین ماډل پورته کړئ، د دې لپاره پیرامیټونه مشخص کړئ، PostgreSQL بیا پیل کړئ او تاسو یې کارولی شئ. (یادونه. د توزیع پورې اړه لري، په وروستیو نسخو کې د مرستې کڅوړه د اصلي کڅوړې برخه ده).
- او غیر رسمي مرستې شتون لري. دوی په معیاري PostgreSQL ویش کې شامل ندي. دوی باید د کتابتون په توګه تالیف یا نصب شي. اختیارونه خورا متفاوت کیدی شي ، پدې پورې اړه لري چې د دې غیر رسمي مرستې پراختیا کونکي څه سره راغلي.
دا سلایډ ټول هغه لیدونه او ځینې دندې وړاندې کوي چې په PostgreSQL 9.4 کې شتون لري. لکه څنګه چې موږ ګورو، ډیری یې شتون لري. او دا خورا اسانه ده چې مغشوش شئ که تاسو د لومړي ځل لپاره ورسره مخ شئ.
په هرصورت، که موږ پخوانی انځور واخلو Как тратится время на PostgreSQL او د دې لیست سره مطابقت لري، موږ دا انځور ترلاسه کوو. موږ کولی شو هر لید (VIEWs) یا هر فنکشن د یوې موخې یا بل هدف لپاره وکاروو ترڅو اړونده احصایې ترلاسه کړو کله چې PostgreSQL روان وي. او موږ دمخه د فرعي سیسټم د عملیاتو په اړه ځینې معلومات ترلاسه کولی شو.
لومړی شی چې موږ به یې وګورو pg_stat_database. لکه څنګه چې موږ لیدلی شو، دا یو فعالیت دی. په دې کې ډیر معلومات شتون لري. تر ټولو متنوع معلومات. او دا زموږ په ډیټابیس کې څه پیښیږي خورا ګټور پوهه ورکوي.
کوم ګټور شیان موږ کولی شو له هغه ځایه واخلو؟ راځئ چې د ساده شیانو سره پیل وکړو.
select
sum(blks_hit)*100/sum(blks_hit+blks_read) as hit_ratio
from pg_stat_database;لومړی شی چې موږ یې ګورو د کیچ هټ فیصده ده. د کیچ هټ نرخ یو ګټور میټریک دی. دا تاسو ته اجازه درکوي اټکل وکړئ چې څومره معلومات د شریک بفر کیچ څخه اخیستل کیږي او څومره د ډیسک څخه لوستل کیږي.
دا روښانه ده څومره چې د کیچ هیټونه موږ ولرو، ښه. موږ دا میټریک د فیصدي په توګه اندازه کوو. او، د مثال په توګه، که زموږ د دې کیچ هټ فیصده له 90٪ څخه زیاته وي، نو دا ښه دی. که دا د 90٪ څخه ښکته شي، دا پدې مانا ده چې موږ په حافظه کې د ډیټا ګرم سر ساتلو لپاره کافي حافظه نلرو. او د دې ډیټا کارولو لپاره ، PostgreSQL ډیسک ته لاسرسي ته اړ ایستل کیږي او دا د هغه په پرتله ورو دی که چیرې ډیټا له حافظې لوستل شوې وي. او تاسو اړتیا لرئ د حافظې د زیاتوالي په اړه فکر وکړئ: یا شریک بفرونه زیات کړئ، یا د هارډویر حافظه (RAM) زیاته کړئ.
select
datname,
(xact_commit*100)/(xact_commit+xact_rollback) as c_ratio,
deadlocks, conflicts,
temp_file, pg_size_pretty(temp_bytes) as temp_size
from pg_stat_database;تاسو د دې فعالیت څخه نور څه ترلاسه کولی شئ؟ تاسو کولی شئ په ډیټابیس کې بې نظمۍ وګورئ. دلته څه ښودل شوي؟ ژمنې، رول بیکونه، د لنډمهاله فایلونو جوړول، د دوی اندازه، ځنډول او شخړې شتون لري.
موږ کولی شو دا غوښتنه وکاروو. دا SQL خورا ساده دی. او موږ کولی شو دا ډاټا دلته وګورو.
او دلته د حد ارزښتونه دي. موږ د ژمنو او رول بیکونو تناسب ته ګورو. ژمنې د راکړې ورکړې بریالۍ تایید دی. رول بیکس یو رول بیک دی، د بیلګې په توګه یو لیږد یو څه کار کړی، ډیټابیس فشار کړی، یو څه محاسبه کړي، او بیا ناکامي رامنځته کیږي او د لیږد پایلې رد شوي. هغه دی د رول بیکونو شمیر په دوامداره توګه ډیریږي خراب دی. او تاسو باید یو څه له دوی څخه مخنیوی وکړئ ، او کوډ ترمیم کړئ ترڅو دا پیښ نشي.
شخړې د نقل سره تړاو لري. او له دوی څخه هم باید ډډه وشي. که تاسو ځینې پوښتنې لرئ چې په عکس کې اجرا کیږي او شخړې رامینځته کیږي ، نو تاسو اړتیا لرئ دا شخړې حل کړئ او وګورئ چې څه پیښیږي. جزئیات په لاګونو کې موندل کیدی شي. او د شخړې حالتونه له منځه یوسي ترڅو د غوښتنلیک غوښتنې پرته له خطا کار وکړي.
بندونه هم یو بد حالت دی. کله چې غوښتنې د سرچینو لپاره مبارزه کوي، یوې غوښتنې یوې سرچینې ته لاس رسی ترلاسه کړ او تالا یې واخیست، دویمې غوښتنې دویمې سرچینې ته لاسرسۍ وکړ او قفل یې هم واخیست، او بیا دواړه غوښتنې د یو بل سرچینو ته لاسرسۍ او بندې شوې پداسې حال کې چې ګاونډی د تالاشۍ خوشې کولو انتظار کوي. دا هم یو ستونزمن حالت دی. دوی اړتیا لري د غوښتنلیکونو بیا لیکلو او سرچینو ته د لاسرسي سریال کولو په کچه په ګوته شي. او که تاسو وګورئ چې ستاسو بندونه په دوامداره توګه مخ په ډیریدو دي، تاسو اړتیا لرئ په لاګونو کې توضیحات وګورئ، هغه شرایط تحلیل کړئ چې رامینځته کیږي او وګورئ چې ستونزه څه ده.
لنډمهاله فایلونه (temp_files) هم خراب دي. کله چې د کاروونکي غوښتنه د عملیاتي، لنډمهاله معلوماتو د ځای په ځای کولو لپاره کافي حافظه نلري، دا په ډیسک کې فایل رامینځته کوي. او ټول هغه عملیات چې دا کولی شي په لنډمهاله بفر کې په حافظه کې ترسره کړي په ډیسک کې ترسره کیږي. دا سست دی. دا د پوښتنو اجرا کولو وخت زیاتوي. او هغه پیرودونکی چې PostgreSQL ته یې غوښتنه لیږلې یو څه وروسته به ځواب ترلاسه کړي. که دا ټول عملیات په حافظه کې ترسره شي، پوسټګریس به ډیر چټک ځواب ورکړي او پیرودونکي به لږ انتظار وکړي.
Pg_stat_bgwriter - دا لید د دوه PostgreSQL پس منظر فرعي سیسټمونو عملیات بیانوي: دا checkpointer и background writer.
لومړی، راځئ چې د کنټرول ټکي وګورو، چې ورته ویل کیږي. checkpoints. د کنټرول ټکي څه دي؟ پوسته د راکړې ورکړې په لاګ کې یو موقعیت دی چې دا په ګوته کوي چې په لاګ کې ثبت شوي ټول ډیټا بدلونونه په ډیسک کې د ډیټا سره په بریالیتوب سره همغږي شوي. پروسه، د کار بار او ترتیباتو پورې اړه لري، کیدای شي اوږد وي او ډیری یې په ډیسک کې د ډیټا فایلونو سره په شریک بفرونو کې د خندا پاڼو همغږي کول شامل دي. دا د څه لپاره دی؟ که PostgreSQL په دوامداره توګه ډیسک ته لاسرسی ولري او له هغه ځایه ډیټا ترلاسه کړي ، او په هر لاسرسي کې ډیټا لیکي ، نو دا به ورو وي. له همدې امله ، PostgreSQL د حافظې برخه لري چې اندازه یې په ترتیب کې تنظیماتو پورې اړه لري. پوسټګریس په دې حافظه کې ژوندی معلومات د وروسته پروسس یا پوښتنو لپاره ذخیره کوي. د معلوماتو د بدلولو غوښتنې په صورت کې، دا بدلیږي. او موږ د معلوماتو دوه نسخې ترلاسه کوو. یو زموږ په حافظه کې دی، بل یې په ډیسک کې دی. او په دوره توګه تاسو اړتیا لرئ دا ډاټا همغږي کړئ. موږ اړتیا لرو هغه څه همغږي کړو چې په حافظه کې ډیسک ته بدل شوي. د دې لپاره تاسو پوستې ته اړتیا لرئ.
پوسته د ګډو بفرونو له لارې تیریږي، خندا پاڼې په نښه کوي چې دوی د پوستې لپاره اړین دي. بیا دا د شریک بفرونو له لارې دوهم پاس پیلوي. او هغه پاڼې چې د پوستې لپاره په نښه شوي، دا دمخه دوی همغږي کوي. پدې توګه ډاټا د ډیسک سره همغږي کیږي.
دوه ډوله پوستې شتون لري. یوه پوسته د وخت په تیریدو سره اجرا کیږي. دا پوسته ګټوره او ښه ده - checkpoint_timed. او د غوښتنې سره سم پوستې شتون لري - checkpoint required. دا پوسته واقع کیږي کله چې موږ د ډیټا خورا لوی ریکارډ لرو. موږ د راکړې ورکړې ډیری لاګ ثبت کړل. او PostgreSQL باور لري چې دا باید ژر تر ژره دا ټول همغږي کړي، پوسته جوړه کړي او حرکت وکړي.
او که تاسو احصایې ته وګورئ pg_stat_bgwriter او هغه څه ولیدل چې تاسو یې لرئ checkpoint_req د checkpoint_timed په پرتله خورا لوی دی، نو دا خراب دی. ولې بد؟ دا پدې مانا ده چې PostgreSQL د دوامداره فشار لاندې وي کله چې ډیسک ته ډیټا لیکلو ته اړتیا لري. د مهال ویش پوسته لږ فشار لري او د داخلي مهال ویش سره سم ترسره کیږي او د وخت په تیریدو سره خپریږي. PostgreSQL د دې وړتیا لري چې کار ودروي او د ډیسک فرعي سیسټم فشار نه کړي. دا د PostgreSQL لپاره ګټور دی. او هغه پوښتنې چې د پوستې په جریان کې اجرا کیږي د دې حقیقت څخه فشار نه تجربه کوي چې د ډیسک فرعي سیسټم بوخت دی.
او د پوستې تنظیم کولو لپاره درې پیرامیټونه شتون لري:
-
сheckpoint_segments. -
сheckpoint_timeout. -
сheckpoint_competion_target.
دوی تاسو ته اجازه درکوي د کنټرول پوائنټونو عملیات تنظیم کړئ. مګر زه به په دوی کې پاتې نه شم. د دوی نفوذ یوه جلا موضوع ده.
پاملرنه: په راپور کې بحث شوی 9.4 نسخه نور اړونده نه ده. د PostgreSQL په عصري نسخو کې پیرامیټر checkpoint_segments د پیرامیټونو لخوا بدل شوی min_wal_size и max_wal_size.
راتلونکی فرعي سیسټم د شالید لیکوال دی - background writer. هغه څه کوي؟ دا په دوامداره توګه په نه ختمیدونکي لوپ کې تیریږي. مخونه په شریک بفرونو کې سکین کوي او ناپاک پاڼې ډمپ کوي چې دا ډیسک ته ومومي. په دې توګه، دا د پوستې سره مرسته کوي چې د پوستې اجرا کولو په وخت کې لږ کار وکړي.
بل څه ته اړتیا ده؟ دا په شریک بفرونو کې د خالي پاڼو اړتیا چمتو کوي که چیرې دوی ناڅاپه اړتیا وي (په لوی مقدار کې او سمدلاسه) د معلوماتو ځای په ځای کولو لپاره. فرض کړئ چې یو حالت رامینځته شوی کله چې خالي پاڼې د غوښتنې بشپړولو لپاره اړین وې او دوی دمخه په شریک بفرونو کې وو. Postgresive backend هغه یوازې دوی اخلي او کاروي، هغه اړتیا نلري چې پخپله پاک کړي. مګر که ناڅاپه داسې پاڼې شتون ونلري، پس منظر کار ودروي او د پاڼو لټون پیل کړي ترڅو په ډیسک کې ډوب کړي او د خپلو اړتیاو لپاره یې واخلي - کوم چې د اوسني اجرایوي غوښتنې په وخت منفي اغیزه کوي. که تاسو وګورئ چې تاسو یو پیرامیټر لرئ maxwritten_clean لوی، دا پدې مانا ده چې د شالید لیکوال خپله دنده نه ترسره کوي او تاسو اړتیا لرئ چې پیرامیټونه زیات کړئ bgwriter_lru_maxpages، ترڅو هغه وکولای شي په یوه دوره کې ډیر کار وکړي، نورې پاڼې پاکې کړي.
او بل ډیر ګټور شاخص دی buffers_backend_fsync. بیکینډونه نه جوړیږي ځکه چې ورو دی. دوی د IO سټیک چیک پوسټر fsync تیریږي. د چیک پوائنټر خپل قطار لري، دا په دوره توګه د fsync پروسس کوي او په ډیسک کې د فایلونو سره په حافظه کې پاڼې همغږي کوي. که چیرې په پوسته کې کتار لوی او ډک وي، نو بیا بیک انډ مجبور دی چې پخپله fsync وکړي او دا د بیک انډ کار ورو کوي.، د بیلګې په توګه پیرودونکی به وروسته له هغه ځواب ترلاسه کړي چې کیدی شي. که تاسو وګورئ چې ستاسو ارزښت له صفر څخه ډیر دی، نو دا لا دمخه یوه ستونزه ده او تاسو اړتیا لرئ د شالید لیکوال تنظیماتو ته پاملرنه وکړئ او د ډیسک فرعي سیسټم فعالیت هم ارزوئ.
پاملرنه: _ لاندې متن د احصایوي نظریاتو تشریح کوي چې د نقل سره تړاو لري. د ډیری لید او فعالیت نومونه په پوسټګریس 10 کې بدل شوي. د نوم بدلولو جوهر دا و چې ځای په ځای شي. xlog په wal и location په lsn په فعالیت / لید نومونو کې، او داسې نور. ځانګړی مثال، فعالیت pg_xlog_location_diff() په نوم بدل شو pg_wal_lsn_diff()._
موږ دلته هم ډیر شیان لرو. مګر موږ یوازې د موقعیت پورې اړوند توکو ته اړتیا لرو.
که موږ وګورو چې ټول ارزښتونه مساوي دي، نو دا یو مثالی اختیار دی او نقل د ماسټر څخه وروسته نه پاتې کیږي.
دا د هیکساډیسیمل موقعیت دلته د راکړې ورکړې لاګ کې موقعیت دی. دا په دوامداره توګه وده کوي که چیرې په ډیټابیس کې کوم فعالیت شتون ولري: داخلول ، حذف کول ، او داسې نور.
сколько записано xlog в байтах
$ select
pg_xlog_location_diff(pg_current_xlog_location(),'0/00000000');
лаг репликации в байтах
$ select
client_addr,
pg_xlog_location_diff(pg_current_xlog_location(), replay_location)
from pg_stat_replication;
лаг репликации в секундах
$ select
extract(epoch from now() - pg_last_xact_replay_timestamp());که دا شیان توپیر ولري، نو یو ډول ځنډ شتون لري. Lag د نقل او ماسټر تر مینځ وقفه ده، د بیلګې په توګه ډاټا د سرورونو ترمنځ توپیر لري.
د ځنډ لپاره درې لاملونه شتون لري:
- دا ډیسک فرعي سیسټم نشي کولی د ثبت کولو فایل ترکیب سره مقابله وکړي.
- دا د شبکې احتمالي تېروتنې دي، یا د شبکې اوورلوډ، کله چې ډاټا نقل ته د رسیدو لپاره وخت نلري او دا نشي کولی بیا تولید کړي.
- او پروسیسر. پروسیسر خورا نادره قضیه ده. او ما دا دوه یا درې ځله ولیدل، مګر دا هم کیدی شي.
او دلته درې پوښتنې دي چې موږ ته د احصایې کارولو اجازه راکوي. موږ اټکل کولی شو چې موږ د راکړې ورکړې په لاګ کې څومره ثبت کړي دي. داسې فعالیت شتون لري pg_xlog_location_diff او موږ کولی شو د نقل کولو ځنډ په بایټس او ثانیو کې اټکل کړو. موږ د دې لپاره د دې لید (VIEWs) ارزښت هم کاروو.
نوټ: د pg_xlog_location پرځاید diff() فنکشن کولی شي د فرعي آپریټر څخه کار واخلي او یو ځای له بل څخه کم کړي. آرامي.
د وقفې سره یو ټکی شتون لري، کوم چې په ثانیو کې دی. که چیرې په ماسټر کې هیڅ فعالیت شتون ونلري، لیږد شاوخوا 15 دقیقې دمخه شتون درلود او هیڅ فعالیت شتون نلري، او که موږ په نقل کې دا وقفه وګورو، نو موږ به د 15 دقیقو ځنډ وګورو. دا د یادولو وړ ده. او دا کیدی شي مغشوش شي کله چې تاسو دا ځنډ وګورئ.
Pg_stat_all_tables یو بل ګټور لید دی. دا په میزونو کې احصایې ښیې. کله چې موږ په ډیټابیس کې میزونه ولرو، هلته یو څه فعالیت، ځینې کړنې، موږ کولی شو دا معلومات له دې لید څخه ترلاسه کړو.
select
relname,
pg_size_pretty(pg_relation_size(relname::regclass)) as size,
seq_scan, seq_tup_read,
seq_scan / seq_tup_read as seq_tup_avg
from pg_stat_user_tables
where seq_tup_read > 0 order by 3,4 desc limit 5;لومړی شی چې موږ یې ګورو د میز په اوږدو کې ترتیب شوي سکینونه دي. د دې تیریدو وروسته شمیره اړینه نده چې خرابه وي او دا شاخص ندی چې موږ یو څه کولو ته اړتیا لرو.
په هرصورت، یو دویم میټریک شتون لري - seq_tup_read. دا د ترتیب شوي سکین څخه راستانه شوي قطارونو شمیر دی. که اوسط شمیر له 1, 000, 10, 000 څخه ډیر وي، نو دا دمخه یو شاخص دی چې شاید تاسو اړتیا لرئ یو شاخص جوړ کړئ ترڅو پوښتنې د شاخص پراساس وي، یا دا ممکنه وي چې هغه پوښتنې اصلاح کړئ چې داسې ترتیب شوي سکینونه کاروي. چې داسې نه کیږي.
یو ساده مثال - راځئ چې د لوی OFFSET او LIMIT لګښتونو سره غوښتنه وکړو. د مثال په توګه، په یوه جدول کې 100 قطارونه سکین شوي او له هغې وروسته 000 اړین قطارونه اخیستل کیږي، او پخوانۍ سکین شوي قطارونه رد شوي. دا هم یوه ناوړه قضیه ده. او دا ډول پوښتنې باید اصلاح شي. او دلته یو ساده SQL پوښتنه ده چیرې چې تاسو کولی شئ دا وګورئ او د پایلې شمیرې ارزونه وکړئ.
select
relname,
pg_size_pretty(pg_total_relation_size(relname::regclass)) as
full_size,
pg_size_pretty(pg_relation_size(relname::regclass)) as
table_size,
pg_size_pretty(pg_total_relation_size(relname::regclass) -
pg_relation_size(relname::regclass)) as index_size
from pg_stat_user_tables
order by pg_total_relation_size(relname::regclass) desc limit 10;د جدول اندازه هم د دې جدول په کارولو او د اضافي افعالاتو په کارولو سره ترلاسه کیدی شي pg_total_relation_size(), pg_relation_size().
په عموم کې، میټا کمانډونه شتون لري dt и di، کوم چې په PSQL کې کارول کیدی شي او د میزونو او شاخصونو اندازه هم وګورئ.
په هرصورت، د فنکشن کارول موږ سره مرسته کوي چې د میزونو اندازه وګورو، حتی د حساب شاخصونو په پام کې نیولو سره، یا د حساب شاخصونو په پام کې نیولو پرته، او دمخه د ډیټابیس د ودې پراساس ځینې اټکلونه جوړوو، د بیلګې په توګه دا څنګه وده کوي، په کوم شدت سره، او د اندازې اصلاح کولو په اړه ځینې پایلې راوباسئ.
د فعالیت ثبتول. ریکارډ څه شی دی؟ راځئ چې عملیات وګورو UPDATE - په جدول کې د قطارونو تازه کولو عملیات. په حقیقت کې، تازه کول دوه عملیات دي (یا حتی ډیر). دا د قطار نوې نسخه داخلوي او د قطار زوړ نسخه د متروک په توګه په نښه کوي. په تعقیب ، آټوواکوم به راشي او د لینونو دا پخوانۍ نسخې پاکې کړي ، دا ځای به د بیا کارونې لپاره شتون په توګه په نښه کړي.
سربیره پردې ، تازه کول یوازې د میز تازه کولو په اړه ندي. دا هم د شاخص تازه دی. که تاسو په میز کې ډیری شاخصونه لرئ، نو د تازه کولو په وخت کې ټول شاخصونه چې په پوښتنلیک کې تازه شوي ساحې پکې شامل دي باید تازه شي. دا شاخصونه به د قطارونو زاړه نسخې هم ولري چې پاکولو ته به اړتیا ولري.
select
s.relname,
pg_size_pretty(pg_relation_size(relid)),
coalesce(n_tup_ins,0) + 2 * coalesce(n_tup_upd,0) -
coalesce(n_tup_hot_upd,0) + coalesce(n_tup_del,0) AS total_writes,
(coalesce(n_tup_hot_upd,0)::float * 100 / (case when n_tup_upd > 0
then n_tup_upd else 1 end)::float)::numeric(10,2) AS hot_rate,
(select v[1] FROM regexp_matches(reloptions::text,E'fillfactor=(\d+)') as
r(v) limit 1) AS fillfactor
from pg_stat_all_tables s
join pg_class c ON c.oid=relid
order by total_writes desc limit 50;او د دې نوي ډیزاین له امله، تازه کول د درنو وزن عملیات دي. مګر دوی کولی شي اسانه کړي. خوړل hot updates. دوی د PostgreSQL نسخه 8.3 کې راڅرګند شول. او دا څه شی دی؟ دا یو سپک وزن تازه دی چې د شاخصونو د بیا جوړولو لامل نه کیږي. دا دی، موږ ریکارډ تازه کړ، مګر یوازې په پاڼه کې ریکارډ (کوم چې په میز پورې اړه لري) تازه شوی، او شاخصونه لاهم په پاڼه کې ورته ریکارډ ته اشاره کوي. یو څه په زړه پوري عملیاتي منطق شتون لري: کله چې خلا راشي ، دا زنځیرونه رامینځته کوي hot بیا رغونه کوي او هرڅه د شاخصونو تازه کولو پرته کار ته دوام ورکوي ، او هرڅه د سرچینو لږ ضایع کیدو سره پیښیږي.
او تاسو کله n_tup_hot_upd لوی، نو دا خورا ښه دی. دا پدې مانا ده چې د سپک وزن تازه معلومات غالب دي او دا زموږ لپاره د سرچینو له مخې ارزانه دي او هرڅه سم دي.
ALTER TABLE table_name SET (fillfactor = 70);د حجم زیاتولو څرنګوالی hot updateاو؟ موږ کولی شو وکاروو fillfactor. دا د خوندي شوي خالي ځای اندازه ټاکي کله چې د INSERTs په کارولو سره په میز کې پاڼه ډکوي. کله چې داخلونه په میز کې اضافه شي، دوی په بشپړه توګه پاڼه ډکوي او هیڅ خالي ځای نه پریږدي. بیا یوه نوې پاڼه روښانه کیږي. معلومات بیا ډک شوي. او دا د ډیفالټ چلند دی، ډکونکی = 100٪.
موږ کولی شو ډکونکی 70٪ جوړ کړو. دا، د داخلولو په جریان کې، یوه نوې پاڼه روښانه شوې وه، مګر یوازې 70٪ پاڼه ډکه شوې وه. او موږ د ریزرو په توګه 30٪ پاتې یو. کله چې تاسو تازه کولو ته اړتیا لرئ، دا به ډیری احتمال په ورته پاڼه کې واقع شي، او د کرښې نوې نسخه به په ورته پاڼه کې فټ شي. او hot_update به ترسره شي. دا په میزونو لیکل اسانه کوي.
select c.relname,
current_setting('autovacuum_vacuum_threshold') as av_base_thresh,
current_setting('autovacuum_vacuum_scale_factor') as av_scale_factor,
(current_setting('autovacuum_vacuum_threshold')::int +
(current_setting('autovacuum_vacuum_scale_factor')::float * c.reltuples))
as av_thresh,
s.n_dead_tup
from pg_stat_user_tables s join pg_class c ON s.relname = c.relname
where s.n_dead_tup > (current_setting('autovacuum_vacuum_threshold')::int
+ (current_setting('autovacuum_vacuum_scale_factor')::float * c.reltuples));د Autovacuum کتار. Autovacuum یو فرعي سیسټم دی د کوم لپاره چې په PostgreSQL کې خورا لږ احصایې شتون لري. موږ یوازې په pg_stat_activity کې په جدولونو کې لیدلی شو چې دا مهال موږ څومره خلا لرو. په هرصورت، دا خورا ستونزمن کار دی چې پوه شي چې څومره میزونه په کتار کې دي.
نوټ: د پوسټګریس 10 سره پیل کول، د واتوواک تعقیب سره وضعیت خورا ښه شوی - د pg_stat_progress لید څرګند شویخلا، کوم چې د موټر خلا د څارنې مسله د پام وړ ساده کوي.
موږ کولی شو دا ساده پوښتنه وکاروو. او موږ کولی شو وګورو چې کله خلا باید رامینځته شي. مګر څنګه او کله باید خلا پیل شي؟ دا د هغو لینونو میراثي نسخې دي چې ما مخکې په اړه خبرې کولې. تازه شو، د کرښې نوې نسخه داخل شوه. د تار یوه پخوانۍ نسخه ښکاره شوه. په میز کې pg_stat_user_tables داسې پیرامیټر شتون لري n_dead_tup. دا د "مړ" لینونو شمیر ښیې. او هرڅومره ژر چې د مړو قطارونو شمیر د یو ټاکلي حد څخه ډیر شي ، یو اوټوواکوم به میز ته راشي.
او دا حد څنګه محاسبه کیږي؟ دا په جدول کې د ټولو قطارونو شمیر خورا مشخص سلنه ده. یو پیرامیټر شتون لري autovacuum_vacuum_scale_factor. دا سلنه ټاکي. راځئ چې ووایو 10٪ + د 50 لینونو اضافي اساسي حد شتون لري. او څه کیږي؟ کله چې موږ په جدول کې د ټولو قطارونو "10٪ + 50" څخه ډیر مړه قطارونه ولرو، نو بیا موږ میز په اتوماتیک کې کیښودو.
select c.relname,
current_setting('autovacuum_vacuum_threshold') as av_base_thresh,
current_setting('autovacuum_vacuum_scale_factor') as av_scale_factor,
(current_setting('autovacuum_vacuum_threshold')::int +
(current_setting('autovacuum_vacuum_scale_factor')::float * c.reltuples))
as av_thresh,
s.n_dead_tup
from pg_stat_user_tables s join pg_class c ON s.relname = c.relname
where s.n_dead_tup > (current_setting('autovacuum_vacuum_threshold')::int
+ (current_setting('autovacuum_vacuum_scale_factor')::float * c.reltuples));په هرصورت، یو ټکی شتون لري. د پیرامیټونو لپاره بنسټیز حد av_base_thresh и av_scale_factor په انفرادي توګه ټاکل کیدی شي. او، په وینا، حد به نړیوال نه وي، مګر د میز لپاره انفرادي. له همدې امله، د محاسبې لپاره، تاسو اړتیا لرئ چې چلونه او چلونه وکاروئ. او که تاسو علاقه لرئ ، نو تاسو کولی شئ د Avito څخه زموږ د همکارانو تجربه وګورئ (په سلایډ کې لینک غلط دی او په متن کې تازه شوی).
دوی لپاره لیکلي ، کوم چې دا شیان په پام کې نیسي. هلته دوه پاڼی پښه ده. مګر دا په سمه توګه محاسبه کوي او په اغیزمنه توګه موږ ته اجازه راکوي چې ارزونه وکړو چیرې چې موږ د میزونو لپاره ډیری خلا ته اړتیا لرو چیرې چې لږ شتون لري.
موږ د هغې په اړه څه کولی شو؟ که موږ لوی کتار ولرو او آٹوواکوم نشي کولی مقابله وکړي، نو موږ کولی شو د ویکیوم کارګرانو شمیر زیات کړو، یا په ساده ډول خلا نوره جارحه کړو.د دې لپاره چې دا مخکې پیل شي، میز په کوچنیو ټوټو کې پروسس کوي. او په دې توګه به قطار کم شي. - دلته اصلي شی په ډیسکونو کې د بار څارنه ده ، ځکه چې ... خلا یو وړیا شی ندی ، که څه هم د SSD/NVMe وسیلو په راتګ سره ستونزه لږ د پام وړ شوې.
Pg_stat_all_indexes د شاخصونو احصایې دي. هغه لویه نه ده. او موږ کولی شو دا د شاخصونو کارولو په اړه د معلوماتو ترلاسه کولو لپاره وکاروو. او د مثال په توګه، موږ کولی شو معلومه کړو چې کوم شاخصونه موږ اضافي لرو.
لکه څنګه چې ما مخکې وویل، تازه کول نه یوازې د میزونو تازه کول دي، دا د شاخصونو تازه کول هم دي. په دې اساس، که موږ په میز کې ډیری شاخصونه لرو، نو کله چې په جدول کې قطارونه تازه کوو، د شاخص شوي ساحو شاخصونه هم باید تازه شي، او که موږ غیر استعمال شوي شاخصونه ولرو د کوم لپاره چې د شاخص سکین شتون نلري، نو دوی د بالسټ په توګه ځړول کیږي. او موږ باید له دوی څخه ځان خلاص کړو. د دې لپاره موږ یو ډګر ته اړتیا لرو idx_scan. موږ په ساده ډول د شاخص سکینونو شمیر ګورو. که چیرې شاخصونه د احصایې ذخیره کولو نسبتا اوږدې مودې (لږترلږه 2-3 اونیو) کې صفر سکین ولري، نو ډیری احتمال دا خراب شاخصونه دي، موږ باید له دوی څخه ځان خلاص کړو.
نوټ: کله چې د سټرینګ نقل کلسترونو په قضیه کې د نه کارول شوي شاخصونو لټون کول ، تاسو اړتیا لرئ ټول کلستر نوډونه چیک کړئ ، ځکه چې احصایې نړیوال ندي، او که چیرې شاخص په ماسټر کې نه کارول کیږي، نو بیا دا په نقلونو کې کارول کیدی شي (که چیرې هلته بار وي).
دوه لینکونه:
دا د غیر استعمال شوي شاخصونو د کتلو څرنګوالي په اړه د پوښتنو پرمختللي مثالونه دي.
دوهم لینک یو په زړه پوری غوښتنه ده. دلته یو ډیر غیر معمولی منطق شتون لري. زه یې د حوالې لپاره وړاندیز کوم.
د شاخصونو په کارولو سره نور څه د خلاصولو ارزښت لري؟
-
نه کارول شوي شاخصونه خراب دي.
-
دوی ځای نیسي.
-
د تازه کولو عملیات ورو کړئ.
-
د خلا لپاره اضافي کار.
که موږ نه کارول شوي شاخصونه لرې کړو، موږ به یوازې ډیټابیس ښه کړو.
راتلونکی پریزنټشن دی pg_stat_activity. دا د افادیت یو انلاګ دی ps، یوازې په PostgreSQL کې. که psاو بیا تاسو په عملیاتي سیسټم کې پروسې ته ګورئ pg_stat_activity دا به تاسو ته د PostgreSQL دننه فعالیت وښیې.
کوم ګټور شیان موږ کولی شو له هغه ځایه واخلو؟
select
count(*)*100/(select current_setting('max_connections')::int)
from pg_stat_activity;موږ کولی شو عمومي فعالیت وګورو، په ډیټابیس کې څه پیښیږي. موږ کولی شو یو نوی ځای پرځای کړو. دلته هرڅه چاودلي، نوې اړیکې نه منل کیږي، په غوښتنلیک کې تېروتنې راځي.
select
client_addr, usename, datname, count(*)
from pg_stat_activity group by 1,2,3 order by 4 desc;موږ کولی شو د دې په څیر یوه پوښتنه پرمخ یوسو او د اتصالاتو سلنه د اعظمي پیوستون حد سره اړونده وګورو او وګورو چې څوک ډیری اړیکې لري. او پدې ورکړل شوي حالت کې موږ هغه کارن ګورو cron_role 508 اړیکې پرانیستل شوې. او هلته ورته یو څه پیښ شول. موږ اړتیا لرو چې ورسره معامله وکړو او وګورو. او دا خورا ممکنه ده چې دا د اړیکو یو ډول غیر معمولي شمیر وي.
که موږ د OLTP کاري بار ولرو، پوښتنې باید ګړندۍ وي، خورا ګړندۍ او باید اوږدې پوښتنې نه وي. که څه هم، که اوږدې پوښتنې راپورته شي، نو په لنډ وخت کې د اندیښنې لپاره هیڅ شی نشته، مګر په اوږد مهال کې، اوږدې پوښتنې ډیټابیس ته زیان رسوي؛ دوی د میزونو د بلیټ اغیز زیاتوي کله چې د میز ټوټه ټوټه کیږي. تاسو اړتیا لرئ چې د خولې او اوږدې پوښتنو څخه ځان خلاص کړئ.
select
client_addr, usename, datname,
clock_timestamp() - xact_start as xact_age,
clock_timestamp() - query_start as query_age,
query
from pg_stat_activity order by xact_start, query_start;مهرباني وکړئ په یاد ولرئ: د دې غوښتنې سره موږ کولی شو اوږدې پوښتنې او لیږدونه وپیژنو. موږ فنکشن کاروو clock_timestamp() د عملیاتي وخت ټاکلو لپاره. اوږدې پوښتنې چې موږ وموندلې، موږ کولی شو هغه په یاد ولرو، پوره کړو explain، پلانونه وګورئ او یو څه اصلاح کړئ. موږ اوسنۍ اوږدې غوښتنې په نښه کوو او د خپل ژوند سره حرکت کوو.
select * from pg_stat_activity where state in
('idle in transaction', 'idle in transaction (aborted)';بدې راکړې ورکړې په بې کاره معامله کې او په راکړه ورکړه کې بې کاره (فسق) حالت دی.
دا څه معنی ورکوي؟ راکړه ورکړه څو ریاستونه لري. او د دې ریاستونو څخه یو په هر وخت کې فرض کیدی شي. د دولتونو تعریف کولو لپاره یو ډګر شتون لري state په دې پریزنټشن کې. او موږ یې د دولت د ټاکلو لپاره کاروو.
select * from pg_stat_activity where state in
('idle in transaction', 'idle in transaction (aborted)';او، لکه څنګه چې ما پورته وویل، دا دوه دولتونه په راکړه ورکړه کې بې کاره او په راکړه ورکړه کې بې کاره (فسخ شوی) بد دي. دا څه شی دی؟ دا هغه وخت دی چې غوښتنلیک یوه معامله پرانستله، ځینې کړنې یې ترسره کړې او خپل سوداګرۍ ته لاړ. راکړه ورکړه خلاصه پاتې ده. دا ځړیږي ، پدې کې هیڅ نه پیښیږي ، دا پیوستون اخلي ، په بدل شوي قطارونو کې لاک کوي او په احتمالي توګه د نورو میزونو بلیټ زیاتوي ، د پوسټرجس لیږد انجن جوړښت له امله. او دا ډول راکړې ورکړې هم باید وغورځول شي، ځکه چې په هر حالت کې، دوی عموما زیانمنونکي دي.
که تاسو وګورئ چې تاسو په خپل ډیټابیس کې له 5-10-20 څخه ډیر لرئ، نو تاسو اړتیا لرئ اندیښنه وکړئ او د دوی سره یو څه پیل کړئ.
دلته موږ د محاسبې وخت لپاره هم کاروو clock_timestamp(). موږ راکړې ورکړې ډزې کوو او غوښتنلیک اصلاح کوو.
لکه څنګه چې ما پورته وویل، بلاک کول هغه وخت دي چې دوه یا ډیر لیږدونه د یوې یا یوې ډلې سرچینې لپاره جګړه کوي. د دې لپاره موږ یو ډګر لرو waiting د بولین ارزښت سره true او یا false.
ریښتیا - دا پدې مانا ده چې پروسه پاتې ده، یو څه باید ترسره شي. کله چې یوه پروسه انتظار کوي، دا پدې مانا ده چې هغه پیرودونکي چې دا پروسه یې پیل کړې هم انتظار کوي. پیرودونکی په براوزر کې ناست دی او انتظار هم کوي.
پاملرنه: _ د پوسټګریس نسخه 9.6 ساحې څخه پیل کول waiting لیرې شوي او پر ځای یې دوه نور معلوماتي ساحې اضافه شوي wait_event_type и wait_event._
زه باید څه وکړم؟ که تاسو د اوږدې مودې لپاره ریښتیا وګورئ، دا پدې مانا ده چې تاسو اړتیا لرئ د داسې غوښتنو څخه ځان خلاص کړئ. موږ په ساده ډول دا ډول راکړې ورکړې راکموو. موږ پراختیا کونکو ته لیکو چې دوی اړتیا لري یو څه اصلاح کړي ترڅو د سرچینو لپاره سیالي شتون ونلري. او بیا پراختیا کونکي غوښتنلیک غوره کوي ترڅو دا پیښ نشي.
او خورا سخت، مګر احتمالي غیر وژونکي قضیه ده د بندیدو واقع کیدل. دوه معاملې دوه سرچینې تازه کړې، بیا یې بیا لاس رسی، دا ځل مخالف سرچینو ته. پدې حالت کې ، PostgreSQL معامله پخپله وژني ترڅو بل کار ته دوام ورکړي. دا یو مړ پای حالت دی او هغه نشي کولی دا پخپله ومومي. له همدې امله، PostgreSQL اړ دی چې خورا سخت ګامونه واخلي.
او دلته دوه پوښتنې دي چې تاسو ته اجازه درکوي بلاک کول تعقیب کړئ. موږ لید کاروو pg_locks، کوم چې تاسو ته اجازه درکوي درانه لاکونه تعقیب کړئ.
او لومړی لینک د غوښتنې متن پخپله دی. دا خورا اوږد دی.
او دوهم لینک د لاکونو په اړه مقاله ده. لوستل یې ګټور دي، ډېر په زړه پورې دي.
نو موږ څه وینو؟ موږ دوه غوښتنې ګورو. سره معامله ALTER TABLE د بندولو معامله ده. دا پیل شوی، مګر بشپړ شوی نه دی، او هغه غوښتنلیک چې دا معامله یې ثبت کړې په بل ځای کې نور کارونه کوي. او دوهمه غوښتنه تازه ده. هغه د بدلون میز پای ته رسیدو ته انتظار باسي مخکې لدې چې هغه خپل کار ته دوام ورکړي.
دا څنګه موږ کولی شو معلومه کړو چې څوک څوک بندوي، څوک یې نیسي، او موږ کولی شو نور ورسره معامله وکړو.
راتلونکی ماډل دی pg_stat_statements. لکه څنګه چې ما وویل، دا یو ماډل دی. د دې کارولو لپاره ، تاسو اړتیا لرئ د دې کتابتون په ترتیب کې پورته کړئ ، PostgreSQL بیا پیل کړئ ، ماډل نصب کړئ (د یوې کمانډ سره) او بیا به موږ یو نوی لید ولرو.
Cреднее время запроса в милисекундах
$ select (sum(total_time) / sum(calls))::numeric(6,3)
from pg_stat_statements;
Самые активно пишущие (в shared_buffers) запросы
$ select query, shared_blks_dirtied
from pg_stat_statements
where shared_blks_dirtied > 0 order by 2 desc;موږ له هغه ځایه څه کولی شو؟ که موږ د ساده شیانو په اړه وغږیږو، موږ کولی شو د اوسط پوښتنې اعدام وخت واخلو. وخت وده کوي، دا پدې مانا ده چې PostgreSQL ورو ورو ځواب ورکوي او موږ باید یو څه وکړو.
موږ کولی شو په ډیټابیس کې د لیکلو خورا فعال لیږدونه وګورو چې په شریک بفرونو کې ډاټا بدلوي. وګورئ چې څوک هلته ډیټا تازه کوي یا حذف کوي.
او موږ کولی شو په ساده ډول د دې غوښتنو لپاره مختلف احصایې وګورو.
موږ یو pg_stat_statements موږ دا د راپورونو جوړولو لپاره کاروو. موږ په ورځ کې یو ځل احصایې بیا تنظیموو. راځئ چې دا جمع کړو. مخکې له دې چې بل ځل احصایې بیا تنظیم کړئ، راځئ چې یو راپور جوړ کړو. دلته د راپور لینک دی. تاسو کولی شئ دا وګورئ.
موږ څه کوو؟ موږ د ټولو غوښتنو لپاره عمومي احصایې محاسبه کوو. بیا، د هرې غوښتنې لپاره، موږ په دې عمومي احصایو کې د هغې انفرادي ونډې حسابوو.
او موږ څه لیدلی شو؟ موږ کولی شو د نورو ټولو غوښتنو شالید په مقابل کې د یو ځانګړي ډول ټولو غوښتنو ټول اجرا کولو وخت وګورو. موږ کولی شو د عمومي عکس په پرتله د CPU او I/O سرچینې کارول وګورو. او دمخه د دې پوښتنو اصلاح کول. موږ د دې راپور پراساس غوره پوښتنې رامینځته کوو او دمخه د فکر کولو لپاره خواړه ترلاسه کوو چې څه باید اصلاح کړو.
موږ د پردې شاته څه پاتې یو؟ لاهم یو څو سپارښتنې پاتې دي چې ما په پام کې نه دي نیولي ځکه چې وخت محدود دی.
موجود دي pgstattuple د معیاري مرستو کڅوړې څخه یو اضافي ماډل هم دی. دا تاسو ته اجازه درکوي چې ارزونه وکړي bloat میزونه، په نوم یادیږي د میز ټوټې کول. او که چیرې ډیری ټوټې شتون ولري ، نو تاسو اړتیا لرئ هغه لرې کړئ او مختلف وسیلې وکاروئ. او فعالیت pgstattuple د اوږدې مودې لپاره کار کوي. او هرڅومره چې میزونه شتون ولري ، هومره به دا کار وکړي.
راتلونکی مرسته ده pg_buffercache. دا تاسو ته اجازه درکوي چې شریک بفر معاینه کړئ: څومره په شدت او د کوم میز بفر پاڼې کارول کیږي. او دا په ساده ډول تاسو ته اجازه درکوي چې شریک شوي بفرونو ته وګورئ او ارزونه وکړئ چې هلته څه پیښیږي.
راتلونکی ماډل دی pgfincore. دا د سیسټم کال له لارې د ټیټې کچې میز عملیاتو ته اجازه ورکوي mincore()، د بیلګې په توګه دا تاسو ته اجازه درکوي یو میز په شریک بفرونو کې پورته کړئ، یا یې پورته کړئ. او دا اجازه ورکوي، د نورو شیانو په منځ کې، د عملیاتي سیسټم پاڼې کیچ معاینه کړي، د بیلګې په توګه، میز څومره ځای لري د پاڼې کیچ کې، په شریک بفرونو کې، او په ساده ډول موږ ته اجازه راکوي چې د میز د کار بار ارزونه وکړو.
بل ماډل - pg_stat_kcache. دا د سیسټم کال هم کاروي getrusage(). او دا د غوښتنې اجرا کیدو دمخه او وروسته اجرا کوي. او په پایله کې احصایې کې، دا موږ ته اجازه راکوي چې اټکل وکړو چې زموږ غوښتنې په ډیسک I/O کې څومره مصرف شوي، د بیلګې په توګه، د فایل سیسټم سره عملیات او د پروسیسر کارولو ته ګوري. په هرصورت، ماډل ځوان دی (د ټوخي ټوخی) او د دې د عملیاتو لپاره دا PostgreSQL 9.4 او pg_stat_statements ته اړتیا لري، کوم چې ما مخکې یادونه وکړه.
-
د احصایو کارولو څرنګوالي پوهیدل ګټور دي. تاسو د دریمې ډلې برنامو ته اړتیا نلرئ. تاسو کولی شئ دننه شئ، وګورئ، یو څه وکړئ، یو څه ترسره کړئ.
-
د احصایو کارول ستونزمن ندي، دا یوازې منظم SQL دی. تاسو غوښتنې راټولې کړې، تالیف یې کړې، لیږلی یې، وګورئ.
-
احصایې د پوښتنو ځوابونو کې مرسته کوي. که تاسو پوښتنې لرئ، تاسو احصایو ته مخه کوئ - وګورئ، پایلې راوباسئ، پایلې تحلیل کړئ.
-
او تجربه. ډیری غوښتنې شتون لري، ډیری معلومات. تاسو کولی شئ تل موجوده پوښتنې اصلاح کړئ. تاسو کولی شئ د غوښتنې خپله نسخه جوړه کړئ چې تاسو ته د اصلي څخه ډیر مناسب وي او وکاروئ.
مرجع
مناسب لینکونه چې په مقاله کې موندل شوي، د موادو پر بنسټ، په راپور کې وو.
لیکوال نور هم لیکي
(eng)
د احصایې راټولونکی
د سیسټم ادارې دندې
مرسته موډلونه
د SQL استعمال او د sql کوډ مثالونه
ستاسو د پاملرنې څخه مننه!
سرچینه: www.habr.com