Alexey Lesovsky پاران 2015 جي رپورٽ جو ٽرانسڪرپشن "پوسٽ گري ايس ايس ايل جي اندروني انگن اکرن ۾ ڊيپ ڊيو"
رپورٽ جي مصنف کان رد ڪرڻ: مان نوٽ ڪريان ٿو ته اها رپورٽ نومبر 2015 جي آهي - 4 سالن کان وڌيڪ گذري چڪو آهي ۽ گهڻو وقت گذري چڪو آهي. رپورٽ ۾ بحث ڪيل نسخو 9.4 هاڻي سپورٽ ناهي. گذريل 4 سالن دوران، 5 نوان رليز جاري ڪيا ويا آهن، جن ۾ انگن اکرن جي حوالي سان ڪافي جدت، سڌارا ۽ تبديليون نظر آيون آهن، ۽ ڪجهه مواد پراڻو ۽ لاڳاپيل ناهي. جيئن مون جائزو ورتو، مون ڪوشش ڪئي ته انهن جڳهن کي نشان لڳايو ته جيئن توهان پڙهندڙن کي گمراهه نه ڪري. مون انهن پاسن کي ٻيهر نه لکيو آهي، انهن مان تمام گهڻا آهن ۽ نتيجو هڪ مڪمل طور تي مختلف رپورٽ ٿيندو.
PostgreSQL DBMS هڪ وڏو ميکانيزم آهي، ۽ هي ميکانيزم ڪيترن ئي سبسسٽمن تي مشتمل آهي، جنهن جو گڏيل ڪم سڌو سنئون DBMS جي ڪارڪردگي تي اثر انداز ٿئي ٿو. آپريشن دوران، اجزاء جي آپريشن بابت انگ اکر ۽ معلومات گڏ ڪئي ويندي آهي، جيڪا توهان کي PostgreSQL جي اثرائتي جو جائزو وٺڻ ۽ ڪارڪردگي کي بهتر ڪرڻ لاء قدم کڻڻ جي اجازت ڏئي ٿي. تنهن هوندي به، هن معلومات جو تمام گهڻو آهي ۽ ان کي هڪ بدران آسان فارم ۾ پيش ڪيو ويو آهي. هن معلومات کي پروسيس ڪرڻ ۽ ان جي تشريح ڪرڻ ڪڏهن ڪڏهن هڪ مڪمل طور تي غير معمولي ڪم آهي، ۽ اوزار ۽ افاديت جو "زو" آساني سان هڪ ترقي يافته DBA کي به پريشان ڪري سگهي ٿو.
منجهند جو سلام منهنجو نالو Aleksey آهي. جيئن اليا چيو، مان پوسٽ گري ايس ايس ايل جي انگن اکرن بابت ڳالهائيندس.
PostgreSQL سرگرمي جا انگ اکر. PostgreSQL جا ٻه انگ اکر آهن. سرگرمي جا انگ اکر، جن تي بحث ڪيو ويندو. ۽ ڊيٽا جي ورڇ بابت شيڊولر شماريات. مان خاص طور تي PostgreSQL سرگرمي جي انگن اکرن بابت ڳالهائيندس، جيڪي اسان کي ڪارڪردگي جو فيصلو ڪرڻ ۽ ڪنهن به طرح ان کي بهتر ڪرڻ جي اجازت ڏين ٿيون.
مان توهان کي ٻڌايان ٿو ته انگن اکرن کي ڪيئن مؤثر طريقي سان استعمال ڪجي مختلف مسئلن کي حل ڪرڻ لاءِ جيڪي توهان وٽ آهن يا ٿي سگهي ٿي.
رپورٽ ۾ ڇا نه هوندو؟ رپورٽ ۾، مان شيڊولر جي انگن اکرن تي رابطو نه ڪندس، ڇاڪاڻ ته. هي هڪ الڳ موضوع آهي هڪ الڳ رپورٽ لاءِ ته ڪيئن ڊيٽا کي ڊيٽابيس ۾ محفوظ ڪيو وڃي ٿو ۽ ڪيئن پڇا ڳاڇا ڪرڻ وارو هن ڊيٽا جي معيار ۽ مقدار جي خاصيتن بابت هڪ خيال حاصل ڪري ٿو.
۽ ڪو به اوزار جائزو نه ٿيندو، مان هڪ پراڊڪٽ ٻئي سان موازنہ نه ڪندس. ڪو به اشتهار نه هوندو. اچو ته هن کي ڇڏي ڏيو.
مان توهان کي ڏيکارڻ چاهيان ٿو ته انگ اکر استعمال ڪرڻ مفيد آهي. اهو ضروري آهي. ان کي بي خوف استعمال ڪريو. اسان کي صرف سادو SQL ۽ SQL جي بنيادي ڄاڻ جي ضرورت آھي.
۽ اسان ان بابت ڳالهائينداسين ته ڪهڙا انگ اکر چونڊڻ لاء مسئلا حل ڪرڻ لاء.
جيڪڏهن اسان PostgreSQL تي نظر وجهون ٿا ۽ عمل کي ڏسڻ لاءِ آپريٽنگ سسٽم تي ڪمانڊ هلون ٿا، اسان کي هڪ ”ڪارو باڪس“ نظر ايندو. اسان ڪجھ عملن کي ڏسندا سين جيڪي ڪجھ ڪندا آھن، ۽ نالي سان اسين تقريبا تصور ڪري سگھون ٿا ته اھي اتي ڇا ڪري رھيا آھن، اھي ڇا ڪري رھيا آھن. پر، حقيقت ۾، هي هڪ ڪارو باڪس آهي، اسان اندر نه ٿا ڏسي سگهون.
اسان ڏسي سگهون ٿا سي پي يو لوڊ ان ۾ top، اسان ڪجھ سسٽم يوٽيلٽيز ذريعي ياداشت جي استعمال کي ڏسي سگھون ٿا، پر اسان PostgreSQL اندر ڏسڻ جي قابل نه ھونداسين. ان لاءِ اسان کي ٻين اوزارن جي ضرورت پوندي.
۽ اڳتي وڌندي، مان توهان کي ٻڌائيندس ته وقت ڪٿي گذاريو ويو آهي. جيڪڏهن اسان اهڙي اسڪيم جي صورت ۾ PostgreSQL جي نمائندگي ڪريون ٿا ته پوءِ اهو جواب ڏيڻ ممڪن ٿيندو ته وقت ڪٿي خرچ ڪيو وڃي. اهي ٻه شيون آهن: اهو ايپليڪيشنن کان ڪلائنٽ جي درخواستن جي پروسيسنگ ۽ پس منظر جي ڪمن جو آهي جيڪو PostgreSQL ان کي هلائڻ لاء انجام ڏئي ٿو.
جيڪڏهن اسان مٿي کاٻي ڪنڊ ۾ ڏسڻ شروع ڪريون ٿا، اسان ڏسي سگهون ٿا ته ڪئين ڪلائنٽ جي درخواستن تي عمل ڪيو وڃي. درخواست ايپليڪيشن کان اچي ٿي ۽ وڌيڪ ڪم لاءِ ڪلائنٽ سيشن کوليو ويو آهي. درخواست شيڊيولر ڏانهن منتقل ڪئي وئي آهي. منصوبه بندي ڪندڙ هڪ سوال جو منصوبو ٺاهي ٿو. ان کي اڳتي وڌڻ لاءِ موڪلي ٿو. ٽيبل ۽ انڊيڪس سان لاڳاپيل ڪجهه قسم جي بلاڪ I / O ڊيٽا آهي. ضروري ڊيٽا ڊسڪ کان ميموري ۾ پڙهي ويندي آهي خاص علائقي ۾ "شيئر بفرز" سڏيو ويندو آهي. سوال جا نتيجا، جيڪڏھن اھي اپڊيٽ آھن، ڊليٽ ڪيا ويا آھن، WAL ۾ ٽرانزيڪشن لاگ ۾ رڪارڊ ٿيل آھن. ڪجھ شمارياتي معلومات لاگ يا شماريات ڪليڪٽر ۾ وڃي ٿي. ۽ درخواست جو نتيجو واپس ڪلائنٽ ڏانهن ڏنو ويو آهي. ان کان پوء، ڪلائنٽ هر شيء کي نئين درخواست سان ورجائي سگھي ٿو.
اسان وٽ ڇا آهي پس منظر جي ڪمن ۽ پس منظر جي عملن سان؟ اسان وٽ ڪيترائي عمل آھن جيڪي ڊيٽابيس کي جاري رکندا آھن ۽ عام آپريٽنگ موڊ ۾ ھلندا آھن. اهي عمل پڻ رپورٽ ۾ شامل ڪيا ويندا: اهي آٽو ويڪيوم، چيڪ پوائنٽر، پروسيس سان لاڳاپيل، پس منظر ليکڪ. مان انهن مان هر هڪ تي رابطو ڪندس جيئن آئون رپورٽ ڪندس.
شماريات جا مسئلا ڪهڙا آهن؟
- تمام گھڻي ڄاڻ. PostgreSQL 9.4 انگن اکرن کي ڏسڻ لاءِ 109 ميٽرڪ مهيا ڪري ٿو. بهرحال، جيڪڏهن ڊيٽابيس ڪيترن ئي جدولن، اسڪيما، ڊيٽابيسن کي ذخيرو ڪري ٿو، ته پوء انهن سڀني ميٽرڪس کي ٽيبل، ڊيٽابيس جي لاڳاپيل انگ سان ضرب ڪرڻو پوندو. اهو آهي، اڃا به وڌيڪ معلومات آهي. ۽ ان ۾ غرق ٿيڻ بلڪل آسان آهي.
- ايندڙ مسئلو اهو آهي ته انگ اکر شمار ڪندڙن جي نمائندگي ڪن ٿا. جيڪڏهن اسان انهن انگن اکرن تي نظر رکون ٿا، اسان ڏسندا سين ته مسلسل وڌندڙ ڳڻپيوڪر. ۽ جيڪڏهن انگن اکرن کي ري سيٽ ٿيڻ کان گهڻو وقت گذري چڪو آهي، اسان ڏسنداسين اربين قدر. ۽ اهي اسان کي ڪجهه به نه ٻڌايو.
- ڪا به تاريخ ناهي. جيڪڏهن توهان وٽ ڪجهه قسم جي ناڪامي آهي، ڪجهه 15-30 منٽ اڳ ٿي ويو، توهان انگ اکر استعمال ڪرڻ جي قابل نه هوندا ۽ ڏسو ته 15-30 منٽ اڳ ڇا ٿيو. هي مسئلو آهي.
- PostgreSQL ۾ ٺهيل اوزار جي کوٽ هڪ مسئلو آهي. ڪنيل ڊولپرز ڪا به افاديت مهيا نه ڪندا آهن. هنن وٽ اهڙي ڪا به ڳالهه ناهي. اهي صرف ڊيٽابيس ۾ انگ اکر ڏين ٿا. ان کي استعمال ڪريو، ان کي درخواست ڏيو، جيڪو توهان چاهيو، پوء اهو ڪريو.
- جيئن ته ڪو به اوزار PostgreSQL ۾ ٺهيل نه آهي، اهو هڪ ٻيو مسئلو آهي. ٽئين پارٽي جا ڪيترائي اوزار. هر ڪمپني جيڪا وڌيڪ يا گهٽ سڌي هٿ آهي ڪوشش ڪري رهي آهي پنهنجي پروگرام لکڻ جي. ۽ نتيجي طور، ڪميونٽي وٽ ڪيترائي اوزار آھن جيڪي توھان استعمال ڪري سگھوٿا شماريات سان ڪم ڪرڻ لاءِ. ۽ ڪجھ اوزارن ۾ ڪجھ خاصيتون آھن، ٻين اوزارن ۾ ٻيون خاصيتون نه آھن، يا ڪجھ نيون خاصيتون آھن. ۽ هڪ صورتحال پيدا ٿئي ٿي ته توهان کي ٻه، ٽي، يا چار اوزار استعمال ڪرڻ جي ضرورت آهي جيڪي هڪ ٻئي کي اوورليپ ڪن ٿا ۽ مختلف افعال آهن. هي تمام گهڻو پريشان ڪندڙ آهي.
ان مان ڇا ٿو نڪري؟ اهو ضروري آهي ته سڌو سنئون انگ اکر کڻڻ جي قابل ٿي وڃن ته جيئن پروگرامن تي انحصار نه ڪيو وڃي، يا ڪنهن به طرح انهن پروگرامن کي پاڻ بهتر ڪريو: توهان جي فائدي حاصل ڪرڻ لاء ڪجهه فنڪشن شامل ڪريو.
۽ توهان کي SQL جي بنيادي ڄاڻ جي ضرورت آهي. انگن اکرن مان ڪجهه ڊيٽا حاصل ڪرڻ لاء، توهان کي SQL سوالن ٺاهڻ جي ضرورت آهي، يعني توهان کي ڄاڻڻ جي ضرورت آهي ته ڪيئن چونڊيو، شامل ڪيو وڃي.
انگ اکر اسان کي ڪيتريون ئي شيون ٻڌائي ٿو. اهي ڀاڱا ۾ تقسيم ڪري سگهجي ٿو.
- پهريون درجو ڊيٽابيس ۾ ٿيندڙ واقعن جو آهي. اهو آهي جڏهن ڊيٽابيس ۾ ڪجهه واقعا ٿئي ٿي: هڪ سوال، هڪ ٽيبل جي رسائي، آٽو ويڪيوم، ڪميٽس، پوء اهي سڀئي واقعا آهن. انهن واقعن سان لاڳاپيل ڳڻپيوڪر وڌائي رهيا آهن. ۽ اسان انهن واقعن کي ٽريڪ ڪري سگهون ٿا.
- ٻيو درجو آهي شيون جا خاصيتون جهڙوڪ ٽيبل، ڊيٽابيس. انهن وٽ خاصيتون آهن. هي ٽيبل جي سائيز آهي. اسان جدولن جي ترقي، انڊيڪس جي واڌ کي ٽريڪ ڪري سگھون ٿا. اسان dynamics ۾ تبديليون ڏسي سگهو ٿا.
- ۽ ٽيون درجي واقعي تي خرچ ٿيل وقت آهي. درخواست هڪ واقعو آهي. ان جي مدت جي پنهنجي مخصوص ماپ آهي. هتي شروع ٿيو، هتي ختم ٿيو. اسان ان کي ٽريڪ ڪري سگهون ٿا. يا ته ڊسڪ کان بلاڪ پڙهڻ جو وقت يا لکڻ. اهي شيون پڻ ٽريڪ ٿيل آهن.
انگن اکرن جا ذريعا هن ريت پيش ڪيا ويا آهن:
- مشترڪه ميموري (شيئر بفرز) ۾ جامد ڊيٽا رکڻ لاءِ هڪ ڀاڱو هوندو آهي، اتي اهي ڪائونٽر به هوندا آهن جيڪي مسلسل وڌندا ويندا آهن جڏهن ڪجهه واقعا ٿين ٿا، يا ڊيٽابيس جي آپريشن ۾ ڪجهه لمحا پيدا ٿين ٿا.
- اهي سڀئي ڳڻپيوڪر صارف لاءِ دستياب نه آهن ۽ منتظم وٽ به دستياب ناهن. اهي هيٺين سطح جون شيون آهن. انھن تائين رسائي حاصل ڪرڻ لاء، PostgreSQL SQL افعال جي صورت ۾ ھڪڙو انٽرفيس مهيا ڪري ٿو. اسان انهن ڪمن کي استعمال ڪندي چونڊيل چونڊون ڪري سگهون ٿا ۽ ڪجهه قسم جي ميٽرڪ (يا ميٽرڪ جو سيٽ) حاصل ڪري سگهون ٿا.
- بهرحال، اهو هميشه انهن فنڪشن کي استعمال ڪرڻ لاء آسان ناهي، تنهن ڪري افعال (VIEWs) لاء بنياد آهن. اهي مجازي جدول آهن جيڪي هڪ مخصوص سب سسٽم تي انگ اکر مهيا ڪن ٿا، يا ڊيٽابيس ۾ واقعن جي ڪجهه سيٽ تي.
- اهي ٺهيل نظريا (VIEWs) انگن اکرن سان ڪم ڪرڻ لاءِ مکيه يوزر انٽرفيس آهن. اهي بغير ڪنهن اضافي سيٽنگن جي ڊفالٽ طور تي دستياب آهن، توهان انهن کي فوري طور تي استعمال ڪري سگهو ٿا، ڏسي سگهو ٿا، اتان کان معلومات وٺي سگهو ٿا. ۽ پڻ شامل آهن. ادارا سرڪاري آھن. توهان انسٽال ڪري سگهو ٿا postgresql-contrib پيڪيج (مثال طور، postgresql94-contrib)، ترتيب ۾ ضروري ماڊل لوڊ ڪريو، ان لاءِ پيٽرول بيان ڪريو، PostgreSQL کي ٻيهر شروع ڪريو ۽ توھان ان کي استعمال ڪري سگھو ٿا. (نوٽ. ورهائڻ تي منحصر آهي، تعاون جي تازي ورزن ۾ پيڪيج مکيه پيڪيج جو حصو آهي).
- ۽ اتي غير رسمي تعاون آھن. اهي معياري PostgreSQL ورڇ سان فراهم نه ڪيا ويا آهن. انهن کي لازمي طور تي مرتب ڪيو وڃي يا لائبريري طور نصب ڪيو وڃي. اختيار تمام مختلف ٿي سگهن ٿا، ان تي منحصر آهي ته هن غير رسمي تعاون جو ڊولپر ڇا آيو آهي.
هي سلائڊ ڏيکاري ٿو اهي سڀئي نظارا (VIEWs) ۽ انهن مان ڪجهه افعال جيڪي PostgreSQL 9.4 ۾ موجود آهن. جيئن اسان ڏسي سگهون ٿا، انهن مان ڪيترائي آهن. ۽ اهو پريشان ٿيڻ بلڪل آسان آهي جيڪڏهن توهان ان کي پهريون ڀيرو تجربو ڪري رهيا آهيو.
بهرحال، جيڪڏهن اسان اڳئين تصوير وٺو Как тратится время на PostgreSQL ۽ هن فهرست سان مطابقت، اسان هي تصوير حاصل ڪندا آهيون. هر نظارو (VIEWs)، يا هر فنڪشن، اسان مناسب انگ اکر حاصل ڪرڻ لاءِ هڪ مقصد يا ٻئي لاءِ استعمال ڪري سگهون ٿا جڏهن اسان وٽ PostgreSQL هلندڙ آهي. ۽ اسان اڳ ۾ ئي subsystem جي آپريشن جي باري ۾ ڪجهه معلومات حاصل ڪري سگهو ٿا.
پهرين شيء اسان کي نظر ايندي 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 تمام سادو آهي. ۽ اسان هن ڊيٽا کي پاڻ لاء ڏسي سگهون ٿا.
۽ هتي آهن حد جا قدر. اسان ڪمن ۽ رول بيڪ جي تناسب کي ڏسو. ڪميٽس ٽرانزيڪشن جي ڪامياب تصديق آهي. رول بيڪ هڪ رول بيڪ آهي، يعني ٽرانزيڪشن ڪجهه ڪم ڪيو، ڊيٽابيس کي ڇڪايو، ڪجهه سمجهيو، ۽ پوء ناڪامي ٿي، ۽ ٽرانزيڪشن جا نتيجا رد ڪيا ويا. يعني rollbacks جو تعداد مسلسل وڌندڙ خراب آهي. ۽ توهان کي ڪنهن به طرح انهن کان پاسو ڪرڻ گهرجي، ۽ ڪوڊ کي تبديل ڪرڻ گهرجي ته جيئن اهو نه ٿئي.
تڪرار نقل سان لاڳاپيل آهن. ۽ ان کان به پاسو ڪيو وڃي. جيڪڏهن توهان وٽ ڪجهه سوال آهن جيڪي نقل تي عمل ڪيا ويا آهن ۽ تڪرار پيدا ٿين ٿا، پوء توهان کي انهن تڪرارن جو تجزيو ڪرڻ جي ضرورت آهي ۽ ڏسو ته ڇا ٿئي ٿو. تفصيلات لاگن ۾ ڳولهي سگهجن ٿا. ۽ تڪرارن کي حل ڪريو ته جيئن ايپليڪيشن جون درخواستون بغير ڪنهن غلطي جي ڪم ڪن.
Deadlocks پڻ هڪ خراب صورتحال آهي. جڏهن درخواستون وسيلن لاءِ مقابلو ڪن ٿيون، هڪ درخواست هڪ وسيلو تائين رسائي حاصل ڪئي ۽ تالا ڪڍيو، ٻي درخواست ٻئي وسيلن تائين رسائي ڪئي ۽ تالا پڻ ورتو، ۽ پوءِ ٻنهي درخواستن هڪ ٻئي جي وسيلن تائين رسائي ڪئي ۽ پاڙيسري کي تالا ڇڏڻ جي انتظار ۾ روڪي ڇڏيو. اهو پڻ هڪ مشڪل صورتحال آهي. انهن کي ايپليڪيشنن کي ٻيهر لکڻ ۽ وسيلن تائين رسائي کي ترتيب ڏيڻ جي سطح تي خطاب ڪرڻ جي ضرورت آهي. ۽ جيڪڏهن توهان ڏسندا ته توهان جا بند لاڳاپا لڳاتار وڌي رهيا آهن، توهان کي لاگ ان ۾ تفصيل ڏسڻ جي ضرورت آهي، انهن حالتن جو تجزيو ڪيو جيڪي پيدا ٿيا آهن ۽ ڏسو ته مسئلو ڇا آهي.
عارضي فائلون (temp_files) پڻ خراب آھن. جڏهن هڪ صارف جي درخواست ڪافي ياداشت نه هوندي آهي ته آپريشنل، عارضي ڊيٽا کي گڏ ڪرڻ لاء، اهو ڊسڪ تي هڪ فائل ٺاهي ٿو. ۽ سڀئي آپريشن جيڪي هن کي ياداشت ۾ هڪ عارضي بفر ۾ انجام ڏئي سگهي ٿو، هو اڳ ۾ ئي ڊسڪ تي انجام ڏيڻ شروع ڪري ٿو. اهو سست آهي. هي سوال جي عمل جو وقت وڌائي ٿو. ۽ ڪلائنٽ جيڪو پوسٽ گري ايس ايس ايل کي درخواست موڪلي ٿو ٿوري دير بعد جواب ملي ويندو. جيڪڏهن اهي سڀئي عمل ميموري ۾ ڪيا ويا آهن، پوسٽ گريس تمام تيز جواب ڏيندو ۽ ڪلائنٽ گهٽ انتظار ڪندو.
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 parameters جي بدلي min_wal_size и max_wal_size.
ايندڙ سبسسٽم پس منظر ليکڪ آهي - background writer. هي ڇا ڪري رهيو آهي؟ اهو مسلسل هڪ لامحدود لوپ ۾ هلندو آهي. اهو صفحن کي اسڪين ڪري ٿو حصيداري بفرن ۾ ۽ گندي صفحن کي فلش ڪري ٿو جيڪو اهو ڊسڪ ڏانهن ڳولي ٿو. هن طريقي سان، اهو چيڪ پوائنٽر کي چيڪ پوائنٽنگ دوران گهٽ ڪم ڪرڻ ۾ مدد ڪري ٿو.
هن کي ٻيو ڇا گهرجي؟ اهو مهيا ڪري ٿو صاف صفحن جي ضرورت لاءِ حصيداري بفرن ۾ جيڪڏهن اهي اوچتو گهربل هجن (وڏي مقدار ۾ ۽ فوري طور تي) ڊيٽا کي گڏ ڪرڻ لاءِ. فرض ڪريو هڪ صورتحال پيدا ٿي جڏهن درخواست کي صاف صفحن جي ضرورت آهي ۽ اهي اڳ ۾ ئي حصيداري بفرن ۾ آهن. پوسٽ گريس backend هو صرف انهن کي وٺي ٿو ۽ انهن کي استعمال ڪري ٿو، هن کي پاڻ کي صاف ڪرڻ جي ضرورت ناهي. پر جيڪڏهن اوچتو اهڙا صفحا نه آهن، پس منظر روڪي ٿو ۽ صفحن کي ڳولڻ شروع ڪري ٿو انهن کي ڊسڪ ڏانهن فلش ڪرڻ ۽ انهن کي پنهنجي ضرورتن لاءِ وٺي - جيڪو هن وقت تي عمل ڪرڻ واري درخواست جي وقت تي منفي اثر وجهي ٿو. جيڪڏهن توهان ڏسو ٿا ته توهان وٽ هڪ پيٽرولر آهي maxwritten_clean وڏو، ان جو مطلب اهو آهي ته پس منظر ليکڪ پنهنجو ڪم نه ڪري رهيو آهي ۽ توهان کي پيٽرولر وڌائڻ جي ضرورت آهي bgwriter_lru_maxpagesته جيئن هو هڪ چڪر ۾ وڌيڪ ڪم ڪري سگهي، وڌيڪ صفحا صاف ڪري.
۽ ٻيو تمام مفيد اشارو آهي buffers_backend_fsync. پس منظر fsync نٿا ڪن ڇو ته اهو سست آهي. اهي IO اسٽيڪ چيڪ پوائنٽر کي fsync پاس ڪن ٿا. چيڪ پوائنٽر جي پنهنجي قطار آهي، اهو وقتي طور تي fsync کي پروسيس ڪري ٿو ۽ ميموري ۾ صفحن کي ڊسڪ تي فائلن سان هم وقت سازي ڪري ٿو. جيڪڏهن چيڪ پوائنٽر قطار وڏي ۽ ڀريل آهي، پوء پس منظر کي مجبور ڪيو ويندو آهي پاڻ کي fsync ڪرڻ ۽ اهو پس منظر کي سست ڪري ٿو، يعني ڪلائنٽ ان کان پوءِ جواب وصول ڪندو. جيڪڏهن توهان ڏسو ٿا ته توهان وٽ اها قيمت صفر کان وڌيڪ آهي، پوء اهو اڳ ۾ ئي هڪ مسئلو آهي ۽ توهان کي پس منظر ليکڪ جي سيٽنگن تي ڌيان ڏيڻ جي ضرورت آهي ۽ ڊسڪ سب سسٽم جي ڪارڪردگي جو جائزو وٺڻ جي ضرورت آهي.
خبردار: _هيٺ ڏنل متن نقل سان لاڳاپيل شمارياتي نظارن کي بيان ڪري ٿو. Postgres 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().
عام طور تي، اتي metacommands آهن 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;۽ ان جي ڊيزائن جي ڪري، UPDATE ھڪڙو بھاري ويٽ آپريشن آھي. پر ان کي آسان بڻائي سگهجي ٿو. کائو hot updates. اهي PostgreSQL ورزن 8.3 ۾ ظاهر ٿيا. ۽ هي ڇا آهي؟ هي هڪ هلڪو وزن اپڊيٽ آهي جيڪو انڊيڪسس کي ٻيهر تعمير ڪرڻ جو سبب ناهي. اهو آهي، اسان رڪارڊ کي اپڊيٽ ڪيو، پر صرف صفحي ۾ رڪارڊ (جيڪو ٽيبل سان تعلق رکي ٿو) کي اپڊيٽ ڪيو ويو، ۽ انڊيڪس اڃا تائين صفحي ۾ ساڳئي رڪارڊ ڏانهن اشارو ڪيو. ڪم جي ڪا اهڙي دلچسپ منطق آهي، جڏهن ڪو خال اچي ٿو ته ان ۾ اهي زنجير آهن. hot rebuilds ۽ سڀڪنھن شيء کي انڊيڪس کي اپڊيٽ ڪرڻ کان سواء ڪم جاري آهي، ۽ سڀڪنھن شيء کي وسيلن جي گھٽ فضول سان ٿئي ٿو.
۽ جڏهن توهان وٽ آهي 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 ۾ جدولن ۾ ڏسي سگهون ٿا ته هن وقت اسان وٽ ڪيترا خلا آهن. بهرحال، اهو سمجهڻ تمام ڏکيو آهي ته قطار ۾ ڪيتريون ٽيبلون آهن.
نوٽ: _ Postgres 10 کان وٺي، ويڪيوم ويڪيوم کي ٽريڪ ڪرڻ واري صورتحال تمام گهڻي بهتر ٿي چڪي آهي - pg_stat_progress منظر ظاهر ٿيو آهيويڪيوم، جيڪو آٽو ويڪيوم مانيٽرنگ جي مسئلي کي تمام گهڻو آسان بڻائي ٿو.
اسان ھي آسان سوال استعمال ڪري سگھون ٿا. ۽ اسان ڏسي سگهون ٿا جڏهن خلا کي ٺاهيو وڃي. پر، خلا ڪيئن ۽ ڪڏهن شروع ٿيڻ گهرجي؟ اهي تارن جا پراڻا نسخا آهن جن بابت مون اڳ ۾ ڳالهايو. تازه ڪاري ٿي وئي آهي، قطار جو نئون نسخو داخل ڪيو ويو آهي. اسٽرنگ جو هڪ پراڻو نسخو ظاهر ٿيو آهي. ٽيبل pg_stat_user_tables اتي هڪ اهڙي parameter آهي n_dead_tup. اهو ڏيکاري ٿو "مئل" قطارن جو تعداد. ۽ جيترو جلد مئل قطارن جو تعداد هڪ خاص حد کان وڌيڪ ٿي چڪو آهي، هڪ autovacuum ميز تي ايندي.
۽ هي حد ڪيئن ڳڻيو وڃي ٿو؟ هي ٽيبل ۾ قطارن جي ڪل تعداد جو هڪ تمام مخصوص سيڪڙو آهي. ھڪڙو پيٽرولر آھي 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 هفتا)، پوء گهڻو ڪري اهي خراب انڊيڪس آهن، اسان کي انهن مان نجات حاصل ڪرڻ جي ضرورت آهي.
نوٽ: جڏهن اسٽريمنگ ريپليڪشن ڪلسٽرز جي صورت ۾ غير استعمال ٿيل انڊيڪس جي ڳولا ڪريو، توهان کي ڪلستر جي سڀني نوڊس کي جانچڻ جي ضرورت آهي، ڇاڪاڻ ته انگ اکر عالمي نه آهن، ۽ جيڪڏهن انڊيڪس ماسٽر تي استعمال نه ڪيو ويو آهي، پوء اهو استعمال ڪري سگهجي ٿو replicas تي (جيڪڏهن ڪو لوڊ آهي).
ٻه لنڪس:
اهي وڌيڪ ترقي يافته سوال جا مثال آهن ته ڪيئن غير استعمال ٿيل انڊيڪس کي ڏسو.
ٻيو لنڪ هڪ تمام دلچسپ سوال آهي. اتي هڪ تمام غير معمولي منطق آهي. مان ان کي جائزو وٺڻ جي صلاح ڏيان ٿو.
انڊيڪس ذريعي ٻيو ڇا ڪرڻ گهرجي؟
-
غير استعمال ٿيل انڊيڪس خراب آهن.
-
اهي جاء وٺن ٿا.
-
اپڊيٽ آپريشن کي سست ڪريو.
-
خال لاءِ اضافي ڪم.
جيڪڏهن اسان غير استعمال ٿيل انڊيڪس کي هٽائي ڇڏيو، ته پوء اسان صرف ڊيٽابيس کي بهتر ڪنداسين.
ايندڙ ڏيک آهي pg_stat_activity. هي افاديت جو هڪ analogue آهي 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 تي ڪيترو خرچ ڪيو، يعني، فائل سسٽم سان آپريشن ۽ پروسيسر جي استعمال کي ڏسڻ ۾ اچي ٿو. بهرحال، ماڊل نوجوان آهي (khe-khe) ۽ ان جي ڪم لاءِ ان کي PostgreSQL 9.4 ۽ pg_stat_statements جي ضرورت آهي، جنهن جو مون اڳ ذڪر ڪيو آهي.
-
انگ اکر استعمال ڪرڻ جي صلاحيت مفيد آهي. توهان کي ٽئين پارٽي سافٽ ويئر جي ضرورت ناهي. تون ڏسي سگھين ٿو، ڏسي سگھين ٿو، ڪجھ ڪري سگھين ٿو، انجام ڏئي سگھين ٿو.
-
انگ اکر استعمال ڪرڻ آسان آهي، اهو سادو SQL آهي. توهان هڪ درخواست گڏ ڪئي، ان کي مرتب ڪيو، ان کي موڪليو، ان کي ڏٺو.
-
انگ اکر سوالن جا جواب ڏيڻ ۾ مدد ڪن ٿا. جيڪڏهن توهان وٽ سوال آهن، توهان انگن اکرن ڏانهن رخ ڪريو - ڏسو، نتيجو ڪڍو، نتيجن جو تجزيو ڪريو.
-
۽ تجربو. ڪيتريون ئي درخواستون، گھڻي ڊيٽا. توھان ھميشه ڪجھ موجوده سوال کي بھتر ڪري سگھو ٿا. توهان درخواست جو پنهنجو نسخو ٺاهي سگهو ٿا جيڪو توهان لاءِ مناسب آهي اصل کان بهتر ۽ استعمال ڪريو.
حوالن
صحيح لنڪس جيڪي مضمون ۾ مليا هئا، جن جي بنياد تي، رپورٽ ۾ هئا.
ليکڪ وڌيڪ لکي ٿو
(eng)
شماريات ڪليڪٽر
سسٽم انتظامي ڪم
تعاون ماڊلز
SQL utilities ۽ sql ڪوڊ جا مثال
توهان جي ڌيان لاء توهان سڀني جي مهرباني!
جو ذريعو: www.habr.com