2015 جي رپورٽ جو نقل Ilya Kosmodemyansky پاران "PostgreSQL ڪارڪردگي کي بهتر ڪرڻ لاءِ لينڪس ٽيوننگ"
رد ڪرڻ: مان نوٽ ڪريان ٿو ته اها رپورٽ نومبر 2015 جي آهي - 4 سال کان وڌيڪ گذري ويا آهن ۽ گهڻو وقت گذري چڪو آهي. رپورٽ ۾ بحث ڪيل نسخو 9.4 هاڻي سپورٽ ناهي. گذريل 4 سالن ۾، PostgreSQL جا 5 نوان رليز جاري ڪيا ويا آھن، ۽ لينڪس ڪنيل جا 15 ورجن جاري ڪيا ويا آھن. جيڪڏهن توهان انهن پاسن کي ٻيهر لکندا، توهان هڪ مختلف رپورٽ سان ختم ٿي ويندا. پر هتي اسان PostgreSQL لاءِ بنيادي لينڪس ٽيوننگ تي غور ڪريون ٿا، جيڪو اڄ به لاڳاپيل آهي.
منهنجو نالو Ilya Kosmodemyansky آهي. مان PostgreSQL-Consulting تي ڪم ڪريان ٿو. ۽ هاڻي مان ٿورڙي ڳالهه ڪندس ته لينڪس سان ڇا ڪجي عام طور تي ڊيٽابيس جي حوالي سان ۽ خاص طور تي PostgreSQL، ڇاڪاڻ ته اصول بلڪل ساڳيا آهن.
اسان ڇا ڳالهائينداسين؟ جيڪڏهن توهان PostgreSQL سان رابطو ڪريو ٿا، ته پوءِ ڪنهن حد تائين توهان کي UNIX منتظم ٿيڻو پوندو. هن جو ڇا مطلب آهي؟ جيڪڏهن اسان Oracle ۽ PostgreSQL جو مقابلو ڪريون ٿا، ته پوءِ Oracle ۾ توهان کي 80٪ DBA ڊيٽابيس ايڊمن ۽ 20٪ لينڪس ايڊمن هجڻ جي ضرورت آهي.
PostgreSQL سان اهو ٿورڙو وڌيڪ پيچيده آهي. PostgreSQL سان توهان کي وڌيڪ بهتر سمجهڻ جي ضرورت آهي ته لينڪس ڪيئن ڪم ڪري ٿو. ۽ ساڳئي وقت، ٿوري دير کان پوء هلو لوڪوموٽو، ڇو ته تازو هر شيء کي چڱي طرح اپڊيٽ ڪيو ويو آهي. ۽ نوان ڪنيل جاري ڪيا ويا آهن، ۽ نئين ڪارڪردگي ظاهر ٿئي ٿي، ڪارڪردگي بهتر، وغيره.
اسان لينڪس بابت ڇو ڳالهائي رهيا آهيون؟ بلڪل نه ڇو ته اسان لينڪس ڪانفرنس ۾ آهيون پيٽر، پر ڇاڪاڻ ته جديد حالتن ۾ عام طور تي ڊيٽابيسس استعمال ڪرڻ لاءِ سڀ کان وڌيڪ جواز وارو آپريٽنگ سسٽم ۽ خاص طور تي PostgreSQL لينڪس آهي. ڇو ته فري بي ايس ڊي، بدقسمتي سان، ترقي ڪري رهيو آهي ڪجهه عجيب هدايتن ۾. ۽ ڪارڪردگي ۽ ٻين ڪيترن ئي شين سان گڏ مسئلا هوندا. ونڊوز تي PostgreSQL جي ڪارڪردگي عام طور تي هڪ الڳ سنگين مسئلو آهي، ان حقيقت تي ٻڌل آهي ته ونڊوز وٽ يونڪس جي ساڳي شيئر ڪيل ياداشت ناهي، جڏهن ته PostgreSQL سڀ ان سان جڙيل آهي، ڇاڪاڻ ته اهو هڪ ملٽي پروسيس سسٽم آهي.
۽ مان سمجهان ٿو ته هرڪو سولاريس وانگر exotics ۾ گهٽ دلچسپي رکي ٿو، تنهنڪري اچو.
هڪ جديد لينڪس ڊسٽريبيوشن ۾ 1 کان وڌيڪ syctl آپشنز آهن، ان تي منحصر آهي ته توهان ڪيني ڪيئن ٺاهيندا آهيو. ساڳئي وقت، جيڪڏهن اسان مختلف نٽ تي نظر رکون ٿا، اسان ڪيترن ئي طريقن سان ڪجهه ترتيب ڏئي سگهون ٿا. اتي فائل سسٽم پيٽرولر آهن انهن کي ڪيئن نصب ڪرڻ تي. جيڪڏهن توهان وٽ سوال آهي ته ان کي ڪيئن شروع ڪجي: BIOS ۾ ڇا کي فعال ڪرڻ، هارڊويئر کي ڪيئن ترتيب ڏيڻ، وغيره.
اهو هڪ تمام وڏو حجم آهي جنهن تي ڪيترن ئي ڏينهن ۾ بحث ڪري سگهجي ٿو، ۽ هڪ مختصر رپورٽ ۾ نه، پر هاڻي مان اهم شين تي ڌيان ڏيندس، انهن ريڪز کان ڪيئن بچجي جيڪي توهان کي لينڪس تي توهان جي ڊيٽابيس کي چڱي طرح استعمال ڪرڻ کان روڪڻ جي ضمانت ڏين ٿيون. ان کي درست نه ڪريو. ۽ ساڳئي وقت، هڪ اهم نقطو اهو آهي ته ڪيترائي ڊفالٽ پيٽرولر سيٽنگن ۾ شامل نه آهن جيڪي ڊيٽابيس لاء صحيح آهن. اھو آھي، ڊفالٽ طور اھو ڪم ڪندو خراب يا بلڪل نه.
لينڪس ۾ ڪهڙا روايتي ٽيوننگ هدف آهن؟ مان سمجهان ٿو ته جيئن توهان سڀ لينڪس انتظاميه سان معاملو ڪري رهيا آهيو، اتي ڪا خاص ضرورت ناهي وضاحت ڪرڻ جي ڪهڙي مقصد آهن.
توھان ڪري سگھو ٿا:
- سي پي يو.
- هوندي آهي.
- اسٽوريج.
- ٻيو. اسان ان بابت آخر ۾ هڪ ناشتو لاء ڳالهائينداسين. جيتوڻيڪ، مثال طور، پيٽرولر جهڙوڪ توانائي جي بچت جي پاليسين ڪارڪردگي تي اثر انداز ڪري سگهن ٿيون هڪ تمام غير متوقع ۽ تمام خوشگوار انداز ۾.
PostgreSQL ۽ عام طور تي ڊيٽابيس جون خاصيتون ڇا آهن؟ مسئلو اهو آهي ته توهان ڪنهن به انفرادي نٽ کي ٽائيڪ نٿا ڪري سگهو ۽ ڏسو ته اسان جي ڪارڪردگي بهتر ٿي چڪي آهي.
ها، اهڙا گيجٽ آهن، پر ڊيٽابيس هڪ پيچيده شيء آهي. اهو سڀني وسيلن سان رابطو ڪري ٿو جيڪو سرور وٽ آهي ۽ مڪمل طور تي لهه وچڙ ڪرڻ کي ترجيح ڏئي ٿو. جيڪڏهن توهان Oracle جي موجوده سفارشن تي نظر وجهو ته ميزبان او ايس کي ڪيئن استعمال ڪجي، اهو ان منگوليائي ڪوسموناٽ بابت مذاق وانگر هوندو - ڪتي کي کارايو ۽ ڪنهن به شيءِ کي هٿ نه ڏيو. اچو ته ڊيٽابيس کي سڀ وسيلا ڏيون، ڊيٽابيس پاڻ ئي سڀ ڪجهه ترتيب ڏيندو.
اصول ۾، ڪجهه حد تائين صورتحال بلڪل ساڳي آهي PostgreSQL سان. فرق اهو آهي ته ڊيٽابيس اڃا تائين پنهنجي لاءِ سڀ وسيلا کڻڻ جي قابل ناهي، يعني ڪٿي لينڪس سطح تي توهان کي اهو سڀ ڪجهه پاڻ کي ترتيب ڏيڻ جي ضرورت آهي.
بنيادي خيال اهو نه آهي ته ڪنهن هڪ ٽارگيٽ کي چونڊيو ۽ ان کي ٽيون ڪرڻ شروع ڪيو وڃي، مثال طور، ميموري، سي پي يو يا اهڙي ڪا شيءِ، پر ڪم لوڊ جو تجزيو ڪرڻ ۽ ان ذريعي جي وڌ کان وڌ رفتار کي بهتر ڪرڻ جي ڪوشش ڪرڻ آهي ته جيئن اهو لوڊ جيڪو سٺو پروگرامر ٺاهي. اسان لاءِ، اسان جي استعمال ڪندڙن سميت.
هتي هڪ تصوير آهي وضاحت ڪرڻ لاءِ ته اهو ڇا آهي. هتي هڪ لينڪس او ايس بفر آهي ۽ اتي شيئر ڪيل ميموري آهي ۽ اتي PostgreSQL شيئر بفر آهن. PostgreSQL، Oracle جي برعڪس، سڌو سنئون صرف ڪنيل بفر ذريعي ڪم ڪري ٿو، يعني، ڊسڪ مان هڪ صفحي لاءِ ان جي گڏيل ياداشت ۾ وڃڻ لاءِ، ان کي ڪنيل بفر ذريعي وڃڻو پوندو ۽ پوئتي، بلڪل ساڳي صورتحال.
ڊسڪ هن سسٽم هيٺ رهن ٿا. مون هن کي ڊسڪ وانگر ٺاهيو. حقيقت ۾، ٿي سگهي ٿو هڪ RAID ڪنٽرولر، وغيره.
۽ اهو ان پٽ-آئوٽ هڪ طريقو يا ٻيو هن معاملي ذريعي ٿئي ٿو.
PostgreSQL هڪ شاندار ڊيٽابيس آهي. اندر هڪ صفحو آهي. ۽ سڀ انپٽ ۽ آئوٽ پُٽ ٿئي ٿو صفحا استعمال ڪندي. اسان بلاڪ کي ميموري ۾ صفحن سان گڏ ڪري رهيا آهيون. ۽ جيڪڏھن ڪجھ به نه ٿيو، اسان صرف انھن کي پڙھندا آھيون، پوء تدريجي طور تي اھي ھن ڪيش مان غائب ٿي ويندا آھن، گڏيل بفرن مان ۽ واپس ڊسڪ تي ختم ٿي ويندا آھن.
جيڪڏهن اسان ڪنهن جاءِ تي ڪا شيءِ مٽائينداسين ته پوءِ سڄو صفحو گندي طور نشان لڳل هوندو. مون انهن کي هتي نيري ۾ نشان لڳايو. ۽ هن جو مطلب اهو آهي ته هي صفحو بلاڪ اسٽوريج سان هم وقت سازي ٿيڻ گهرجي. اهو آهي، جڏهن اسان ان کي گندو ڪيو، اسان وال ۾ داخلا داخل ڪئي. ۽ وقت جي ڪجهه عجيب لمحن تي، هڪ رجحان جنهن کي چيڪ پوائنٽ سڏيو ويندو آهي آيو. ۽ معلومات هن لاگ ۾ رڪارڊ ڪئي وئي هئي ته هو پهچي چڪو هو. ۽ هن جو مطلب اهو آهي ته اهي سڀئي گندا صفحا جيڪي هن وقت هتي هئا انهن شيئر ٿيل بفرن ۾ اسٽوريج ڊسڪ سان هم وقت سازي ڪئي وئي fsync استعمال ڪندي ڪرنل بفر ذريعي.
اهو ڇو ڪيو پيو وڃي؟ جيڪڏهن اسان وولٹیج وڃائي ڇڏيو، پوء اسان کي صورتحال نه ملي ته سڀ ڊيٽا گم ٿي ويو. مسلسل ياداشت، جنهن بابت هرڪو اسان کي ٻڌايو آهي، ڊيٽابيس جي نظريي ۾ ايترو پري آهي - اهو هڪ روشن مستقبل آهي، جنهن لاء اسان، يقينا، ڪوشش ڪندا آهيون ۽ اسان ان کي پسند ڪندا آهيون، پر هن وقت تائين اهي 20 سالن کان گهٽ ۾ رهن ٿا. ۽، يقينا، اهو سڀ ڪجهه نگراني ڪرڻ جي ضرورت آهي.
۽ وڌ کان وڌ ٿرو پُٽ جو ڪم انهن سڀني مرحلن تي ٺيڪ ٺاڪ ڪرڻ آهي ته جيئن اهو سڀ ڪجهه تيزيءَ سان اڳتي وڌي وڃي. شيئر ڪيل ياداشت بنيادي طور تي هڪ صفحو ڪيش آهي. PostgreSQL ۾ اسان هڪ چونڊيو سوال يا ٻيو ڪجهه موڪليو، اهو هن ڊيٽا کي ڊسڪ مان حاصل ڪيو. اهي گڏيل بفرن ۾ ختم ٿي ويا. ان جي مطابق، هن کي بهتر ڪم ڪرڻ لاء، اتي تمام گهڻو ياداشت هجڻ گهرجي.
اهو سڀ ڪجهه سٺو ۽ جلدي ڪم ڪرڻ لاء، توهان کي درست طريقي سان آپريٽنگ سسٽم کي سڀني مرحلن تي ترتيب ڏيڻ جي ضرورت آهي. ۽ متوازن هارڊويئر چونڊيو، ڇو ته جيڪڏهن توهان وٽ ڪنهن جاءِ تي عدم توازن آهي، ته پوءِ توهان تمام گهڻي ياداشت ٺاهي سگهو ٿا، پر اها ڪافي رفتار سان خدمت نه ڪئي ويندي.
۽ اچو ته انهن مان هر هڪ نقطي ذريعي وڃو.
انهن صفحن کي تيزيءَ سان اڳتي ۽ پوئتي سفر ڪرڻ لاءِ، توهان کي هيٺيان حاصل ڪرڻ گهرجن:
- پهرين، توهان کي ميموري سان وڌيڪ موثر ڪم ڪرڻ جي ضرورت آهي.
- ٻيو، هي منتقلي جڏهن ميموري کان صفحا ڊسڪ ڏانهن وڃو وڌيڪ موثر هجڻ گهرجي.
- ۽ ٽيون، اتي سٺي ڊسڪ هجڻ گهرجي.
جيڪڏهن توهان وٽ سرور ۾ 512 GB ريم آهي ۽ اهو سڀ ڪجهه بغير ڪنهن ڪيش جي SATA هارڊ ڊرائيو تي ختم ٿي وڃي ٿو، ته پوءِ سڄو ڊيٽابيس سرور نه رڳو ڪدو، پر SATA انٽرفيس سان گڏ ڪدو بڻجي ويندو. توهان ان ۾ سڌو سنئون هلندا. ۽ ڪجھ به نه بچائيندو.
ياداشت سان گڏ پهرين نقطي جي حوالي سان، ٽي شيون آهن جيڪي زندگي کي تمام ڏکيو بڻائي سگهن ٿيون.
انهن مان پهريون نمبر NUMA آهي. NUMA هڪ شيء آهي جيڪا ڪارڪردگي بهتر ڪرڻ لاء ٺهيل آهي. ڪم لوڊ تي منحصر ڪري، مختلف شيون بهتر ٿي سگهن ٿيون. ۽ ان جي نئين موجوده شڪل ۾، اهو تمام سٺو ناهي ايپليڪيشنن لاءِ جيئن ته ڊيٽابيس جيڪي شدت سان استعمال ڪن ٿا صفحو ڪيش شيئر ٿيل بفرز.
مختصر لفظن ۾. توهان ڪيئن ٻڌائي سگهو ٿا ته NUMA سان ڪجهه غلط آهي؟ توهان وٽ ڪجهه قسم جي ناپسنديده دستڪ آهي، اوچتو ڪجهه سي پي يو اوور لوڊ ٿي ويو آهي. ساڳئي وقت، توهان PostgreSQL ۾ سوالن جو تجزيو ڪيو ۽ ڏسو ته اتي ڪجھ به ساڳيو ناهي. انهن سوالن کي ايترو سي پي يو نه هجڻ گهرجي. توهان هن کي ڊگهي وقت تائين پڪڙي سگهو ٿا. NUMA کي ڪيئن ترتيب ڏيڻ تي شروع کان ئي صحيح تجويز استعمال ڪرڻ آسان آهي PostgreSQL لاءِ.
ڇا واقعي ٿي رهيو آهي؟ NUMA جو مطلب آهي غير يونيفارم ميموري رسائي. ڳالهه ڪهڙي آهي؟ توهان وٽ هڪ سي پي يو آهي، ان جي اڳيان ان جي مقامي ياداشت آهي. ۽ هي ميموري ڳنڍي سگھي ٿي ٻين سي پي يوز کان ميموري کي ڇڪي سگھي ٿي.
جيڪڏهن توهان هلندا آهيو numactl --hardware، پوءِ توھان کي اھڙي وڏي چادر ملندي. ٻين شين جي وچ ۾، هڪ فاصلو فيلڊ هوندو. اتي نمبر هوندا - 10-20، ڪجهه اهڙي طرح. اهي انگ هن ريموٽ ياداشت کي کڻڻ ۽ مقامي طور تي استعمال ڪرڻ لاءِ هاپس جي تعداد کان وڌيڪ ڪجهه نه آهن. اصول ۾، هڪ سٺو خيال. اهو ڪم ڪار لوڊ جي هڪ حد جي تحت ڪارڪردگي کي تيز ڪري ٿو.
ھاڻي تصور ڪريو ته توھان وٽ ھڪڙو سي پي يو آھي پھريائين پنھنجي مقامي ياداشت کي استعمال ڪرڻ جي ڪوشش ڪري رھيو آھي، پوءِ ڪوشش ڪري رھيو آھي ٻي ميموري کي ڪڍڻ جي ذريعي ڪنھن شيءِ لاءِ ڪنيڪٽ ذريعي. ۽ هي سي پي يو توهان جي پوري PostgreSQL پيج ڪيش حاصل ڪري ٿو - اهو ئي آهي، ڪجهه گيگا بائيٽ. توهان هميشه بدترين صورت ۾ حاصل ڪندا آهيو، ڇاڪاڻ ته سي پي يو تي عام طور تي ان ماڊل ۾ ٿوري ياداشت هوندي آهي. ۽ سڀ يادگيري جيڪا خدمت ڪئي وئي آهي انهن جي وچ ۾ ڳنڍيل آهي. اهو سست ۽ اداس نڪرندو آهي. ۽ توهان جو پروسيسر جيڪو خدمت ڪري ٿو اهو نوڊ مسلسل اوورلوڊ ٿيل آهي. ۽ هن ياداشت جي رسائي وقت خراب، سست آهي. اها صورتحال آهي جيڪا توهان نٿا چاهيو جيڪڏهن توهان هن کي ڊيٽابيس لاءِ استعمال ڪري رهيا آهيو.
تنهن ڪري، ڊيٽابيس لاء هڪ وڌيڪ صحيح اختيار آهي لينڪس آپريٽنگ سسٽم لاء اهو نه ڄاڻڻ لاء ته اتي ڇا ٿي رهيو آهي. انهي ڪري ته اهو ميموري تائين رسائي ڪري ٿو جيئن اهو ڪندو آهي.
ائين ڇو آهي؟ اهو لڳي ٿو ته ان جي چوڌاري ٻي واٽ هجڻ گهرجي. اهو هڪ سادي سبب جي ڪري ٿئي ٿو: اسان کي صفحي جي ڪيش لاءِ تمام گهڻي ياداشت جي ضرورت آهي - ڏهه، سوين گيگا بائيٽ.
۽ جيڪڏهن اسان اهو سڀ ڪجهه مختص ڪيو ۽ اتي اسان جي ڊيٽا کي ڪيش ڪيو، ته پوء ڪيش استعمال ڪرڻ مان حاصلات ميموري تائين اهڙي مشڪل رسائي جي حاصلات کان گهڻو وڌيڪ هوندو. ۽ اهڙيءَ طرح اسان ان حقيقت جي مقابلي ۾ لاتعداد فائدو وٺنداسين ته اسان NUMA استعمال ڪندي ميموري کي وڌيڪ موثر طريقي سان رسائي ڪنداسين.
تنهن ڪري، هن وقت هتي ٻه طريقا آهن، جيستائين روشن مستقبل اچي چڪو آهي، ۽ ڊيٽابيس پاڻ اهو معلوم ڪرڻ جي قابل ناهي ته اهو ڪهڙي سي پي يوز تي هلي رهيو آهي ۽ ڪٿي ان کي ڪجهه ڪڍڻ جي ضرورت آهي.
تنهن ڪري، صحيح طريقي سان NUMA کي مڪمل طور تي غير فعال ڪرڻ آهي، مثال طور، جڏهن ريبوٽ. اڪثر صورتن ۾، فتحون اهڙيون وڏيون ترتيبون هونديون آهن، جو سوال ئي پيدا نٿو ٿئي ته ڪهڙو بهتر آهي.
اتي هڪ ٻيو اختيار آهي. اسان ان کي پهرين کان وڌيڪ استعمال ڪندا آهيون، ڇاڪاڻ ته جڏهن ڪو گراهڪ اسان وٽ مدد لاءِ اچي ٿو، سرور کي ريبوٽ ڪرڻ هن لاءِ وڏي ڳالهه آهي. هن جو اتي ڪاروبار آهي. ۽ اهي NUMA جي ڪري مشڪلاتن جو تجربو ڪن ٿا. تنهن ڪري، اسان ان کي غير فعال ڪرڻ جي ڪوشش ڪندا آهيون ريبوٽ جي ڀيٽ ۾ گهٽ جارحتي طريقن سان، پر محتاط رهو ته چيڪ ڪريو ته اهو معذور آهي. ڇاڪاڻ ته، جيئن تجربو ڏيکاري ٿو، اهو سٺو آهي ته اسان NUMA کي غير فعال ڪريون والدين PostgreSQL عمل تي، پر اهو بلڪل ضروري ناهي ته اهو ڪم ڪندو. اسان کي جانچڻ ۽ ڏسڻ جي ضرورت آهي ته هوء واقعي بند ٿي وئي.
رابرٽ هاس پاران هڪ سٺي پوسٽ آهي. هي هڪ آهي PostgreSQL ڪمنٽس. سڀني گهٽ-سطح گبلٽس جي اهم ڊولپرز مان هڪ آهي. ۽ جيڪڏهن توهان هن پوسٽ جي لنڪ جي پيروي ڪندا آهيو، اهي ڪيتريون ئي رنگين ڳالهيون بيان ڪندا آهن ته ڪيئن NUMA ماڻهن جي زندگي کي ڏکيو بڻائي ڇڏيو. ڏسو، سسٽم ايڊمنسٽريٽر چيڪ لسٽ جو مطالعو ڪريو جيڪو سرور تي ترتيب ڏيڻ جي ضرورت آهي انهي لاءِ ته اسان جي ڊيٽابيس کي بهتر ڪم ڪرڻ لاءِ. انهن سيٽنگن کي لکڻ ۽ جانچڻ جي ضرورت آهي، ڇاڪاڻ ته ٻي صورت ۾ اهو تمام سٺو نه ٿيندو.
مهرباني ڪري نوٽ ڪريو ته اهو سڀني سيٽنگن تي لاڳو ٿئي ٿو جنهن بابت آئون ڳالهائيندس. پر عام طور تي ڊيٽابيس گڏ ڪيا ويندا آهن ماسٽر-غلام موڊ ۾ غلطي رواداري لاءِ. غلام تي اهي سيٽنگون ڪرڻ نه وساريو ڇو ته هڪ ڏينهن توهان سان حادثو ٿيندو ۽ توهان غلام ڏانهن تبديل ٿي ويندا ۽ اهو مالڪ بڻجي ويندو.
ايمرجنسي واري صورتحال ۾، جڏهن هر شيءِ تمام خراب آهي، توهان جو فون مسلسل وڄي رهيو آهي ۽ توهان جو باس هڪ وڏي لٺ سان ڊوڙندو اچي ٿو، توهان وٽ چيڪ ڪرڻ بابت سوچڻ جو وقت نه هوندو. ۽ نتيجا تمام خراب ٿي سگهن ٿا.
ايندڙ نقطو وڏو صفحا آهي. وڏن صفحن کي الڳ الڳ جانچڻ ڏکيو آهي، ۽ ائين ڪرڻ ۾ ڪو به مقصد ناهي، جيتوڻيڪ اهڙا معيار آهن جيڪي اهو ڪري سگهن ٿيون. اهي گوگل کي آسان آهن.
ڳالهه ڪهڙي آهي؟ توھان وٽ تمام گھڻو قيمتي سرور نه آھي تمام گھڻي رام سان، مثال طور، 30 GB کان وڌيڪ. توهان وڏا صفحا استعمال نٿا ڪريو. هن جو مطلب اهو آهي ته توهان کي ضرور ميموري استعمال جي لحاظ کان مٿي آهي. ۽ هي مٿي تمام گهڻي خوشگوار کان پري آهي.
ائين ڇو آهي؟ پوءِ ڇا پيو ٿئي؟ آپريٽنگ سسٽم ميموري کي ننڍن ٽڪرن ۾ مختص ڪري ٿو. اهو تمام آسان آهي، اهو ڪيئن تاريخي طور تي ٿيو. ۽ جيڪڏهن اسان تفصيل ۾ وڃون ٿا، او ايس کي لازمي طور تي ورچوئل ايڊريس کي جسماني طور ترجمو ڪرڻ گهرجي. ۽ اهو عمل تمام سادو نه آهي، تنهن ڪري او ايس هن آپريشن جي نتيجي کي ترجمي ۾ ڏسندي ڏسندي بفر (TLB) ۾ محفوظ ڪري ٿو.
۽ جيئن ته TLB هڪ ڪيش آهي، هن صورتحال ۾ ڪيش ۾ موجود سڀئي مسئلا پيدا ٿين ٿا. پهرين، جيڪڏهن توهان وٽ تمام گهڻو رام آهي ۽ اهو سڀ ڪجهه ننڍن حصن ۾ مختص ڪيو ويو آهي، پوء هي بفر تمام وڏو ٿي ويندو. ۽ جيڪڏهن ڪيش وڏو آهي، ته پوءِ ان جي ڳولا سستي آهي. اوور هيڊ صحت مند آهي ۽ اهو پاڻ ئي جاءِ وٺي ٿو، يعني ريم ڪنهن غلط شيءِ سان استعمال ٿي رهي آهي. هن ڀيري.
ٻه - اهڙي صورتحال ۾ جيترو وڌيڪ ڪيش وڌندو، اوترو ئي وڌيڪ امڪان اهو آهي ته توهان وٽ ڪيش مس هوندو. ۽ هن ڪيش جي ڪارڪردگي تيزي سان گهٽجي ويندي آهي جيئن ان جي سائيز وڌائي ٿي. تنهن ڪري، آپريٽنگ سسٽم هڪ سادي طريقي سان آيو. اهو هڪ ڊگهي وقت تائين لينڪس ۾ استعمال ڪيو ويو آهي. اهو ظاهر ٿيو FreeBSD ۾ ايترو گهڻو اڳ نه. پر اسان لينڪس بابت ڳالهائي رهيا آهيون. اهي وڏا صفحا آهن.
۽ هتي اهو ياد رکڻ گهرجي ته وڏا صفحا، هڪ خيال جي طور تي، شروعاتي طور تي برادرين طرفان ڌڪايو ويو هو، جنهن ۾ Oracle ۽ IBM شامل هئا، يعني ڊيٽابيس ٺاهيندڙن جو خيال هو ته اهو ڊيٽابيس لاء پڻ ڪارائتو هوندو.
۽ اهو ڪيئن ٿي سگهي ٿو دوستي PostgreSQL سان؟ پهرين، لينڪس ڪرنل ۾ وڏا صفحا فعال ٿيڻ گهرجن.
ٻيو، انهن کي واضح طور تي sysctl پيٽرولر طرفان بيان ڪيو وڃي - ڪيترا آهن. هتي نمبر ڪجهه پراڻي سرور مان آهن. توهان اندازو لڳائي سگهو ٿا ته توهان وٽ ڪيترا شيئر ٿيل بفر آهن ته جيئن وڏا صفحا اتي فٽ ٿي سگهن.
۽ جيڪڏهن توهان جو سمورو سرور PostgreSQL لاءِ وقف آهي، ته پوءِ هڪ سٺو شروعاتي نقطو اهو آهي ته يا ته 25% ريم کي شيئر ٿيل بفرز لاءِ مختص ڪيو وڃي، يا 75% جيڪڏهن توهان کي پڪ آهي ته توهان جو ڊيٽابيس هن 75 سيڪڙو ۾ ضرور پورو ٿيندو. شروعاتي نقطي هڪ. ۽ غور ڪريو، جيڪڏھن توھان وٽ آھي 256 GB جي ريم، پوء، توھان جي مطابق، توھان وٽ 64 GB وڏا بفر آھن. ڪجھ مارجن سان لڳ ڀڳ ڳڻپ ڪريو - اھو انگ ڇا مقرر ڪيو وڃي.
نسخو 9.2 کان اڳ (جيڪڏهن مان غلط نه آهيان، نسخو 8.2 کان)، اهو ممڪن هو PostgreSQL کي ٽئين پارٽي لائبريري استعمال ڪندي وڏن صفحن سان ڳنڍڻ. ۽ اهو هميشه ٿيڻ گهرجي. پهرين، توهان کي دانا جي ضرورت آهي ته وڏي صفحن کي صحيح طور تي مختص ڪرڻ جي قابل ٿي. ۽، ٻيو، انهي ڪري ته ايپليڪيشن جيڪا انهن سان ڪم ڪري ٿي انهن کي استعمال ڪري سگهي ٿي. اهو صرف انهي طريقي سان استعمال نه ڪيو ويندو. جيئن ته PostgreSQL سسٽم 5 انداز ۾ ميموري مختص ڪئي آهي، اهو libhugetlbfs استعمال ڪري سگهجي ٿو - هي لائبريري جو پورو نالو آهي.
9.3 ۾، PostgreSQL ڪارڪردگي بهتر ٿي وئي جڏهن ميموري سان ڪم ڪندي ۽ سسٽم 5 ميموري مختص ڪرڻ جو طريقو ختم ڪيو ويو. هرڪو ڏاڍو خوش هو، ڇاڪاڻ ته ٻي صورت ۾ توهان هڪ مشين تي ٻه PostgreSQL مثال هلائڻ جي ڪوشش ڪندا، ۽ هو چوي ٿو ته مون وٽ ڪافي شيئر ياداشت نه آهي. ۽ هو چوي ٿو ته sysctl کي درست ڪرڻ جي ضرورت آهي. ۽ اتي هڪ اهڙي sysctl آهي ته توهان اڃا تائين ريبوٽ ڪرڻ جي ضرورت آهي، وغيره. عام طور تي، هرڪو خوش هو. پر mmap ياداشت مختص ڪرڻ وڏي صفحن جي استعمال کي ٽوڙي ڇڏيو. اسان جا گهڻا گراهڪ استعمال ڪندا آهن وڏي حصيداري بفرز. ۽ اسان سختي سان صلاح ڏني ته 9.3 تي سوئچ نه ڪيو وڃي، ڇاڪاڻ ته مٿي مٿي چڱا فيصد ۾ ڳڻڻ شروع ڪيو.
پر ڪميونٽي هن مسئلي تي ڌيان ڏنو ۽ 9.4 ۾ هن واقعي کي تمام سٺو ڪم ڪيو. ۽ 9.4 ۾ postgresql.conf ۾ هڪ پيٽرول ظاهر ٿيو جنهن ۾ توهان ڪوشش ڪري سگهو ٿا، آن يا آف.
ڪوشش ڪريو محفوظ اختيار. جڏهن PostgreSQL شروع ٿئي ٿو، جڏهن اهو گڏيل ياداشت مختص ڪري ٿو، اهو هن يادگيري کي وڏي صفحن مان پڪڙڻ جي ڪوشش ڪري ٿو. ۽ جيڪڏهن اهو ڪم نٿو ڪري، ته اهو واپس عام چونڊ ڏانهن موٽندو. ۽ جيڪڏهن توهان وٽ مفت بي ايس ڊي يا سولاريس آهي، ته توهان ڪوشش ڪري سگهو ٿا، اهو هميشه محفوظ آهي.
جيڪڏهن تي، پوء اهو صرف شروع نٿو ٿئي جيڪڏهن اهو وڏي صفحن مان نه چونڊيو وڃي. هتي اهو اڳ ۾ ئي آهي ته ڪير ۽ ڪهڙو سٺو آهي. پر جيڪڏهن توهان ڪوشش ڪئي آهي، ته پوءِ چيڪ ڪريو ته توهان وٽ حقيقت آهي جيڪا توهان کي نمايان ڪرڻ جي ضرورت آهي، ڇاڪاڻ ته اتي غلطي جي تمام گهڻي گنجائش آهي. في الحال هي فنڪشنلٽي صرف لينڪس تي ڪم ڪري ٿي.
اسان کي اڳتي وڌڻ کان اڳ هڪ وڌيڪ ننڍڙو نوٽ. شفاف وڏا صفحا اڃا تائين PostgreSQL بابت نه آهن. هو انهن کي عام طور تي استعمال نٿا ڪري سگهن. ۽ اهڙي ڪم لوڊ لاءِ شفاف وڏن صفحن سان، جڏهن گڏيل يادگيري جو هڪ وڏو ٽڪرو گهربل هجي، فائدا صرف تمام وڏي مقدار سان ايندا آهن. جيڪڏهن توهان وٽ يادگيري جي ٽيرا بائيٽ آهي ته پوء اهو راند ۾ اچي سگهي ٿو. جيڪڏهن اسان روزمره جي وڌيڪ ايپليڪيشنن جي باري ۾ ڳالهائي رهيا آهيون، جڏهن توهان وٽ توهان جي مشين تي 32, 64, 128, 256 GB جي ميموري آهي، ته پوءِ معمولي وڏا صفحا ٺيڪ آهن، ۽ اسان صرف شفاف کي غير فعال ڪريون ٿا.
۽ ياداشت بابت آخري شيء سڌو سنئون ميوو سان لاڳاپيل ناهي، اهو واقعي توهان جي زندگي کي برباد ڪري سگهي ٿو. سڀ throughput تمام گهڻو متاثر ٿيندو حقيقت اها آهي ته سرور مسلسل تبديل ٿي رهيو آهي.
۽ اهو ڪيترن ئي طريقن سان تمام ناپسنديده ٿيندو. ۽ بنيادي مسئلو اهو آهي ته جديد ڪرنل پراڻن لينڪس ڪنلز کان ٿورو مختلف طريقي سان عمل ڪن ٿا. ۽ اها شيءِ تي قدم کڻڻ لاءِ ڪافي ناخوشگوار آهي، ڇاڪاڻ ته جڏهن اسان ڪنهن قسم جي ڪم جي باري ۾ ڳالهايون ٿا ادل سان، اهو ختم ٿي ويندو آهي اوم-قاتل جي اڻ وقتي آمد سان. ۽ OOM-قاتل، جيڪو بروقت انداز ۾ نه آيو ۽ PostgreSQL ڇڏيو، ناپسنديده آهي. هرڪو هن جي باري ۾ ڄاڻندو، يعني آخري استعمال ڪندڙ تائين.
ڇا ٿي رهيو آهي؟ توھان وٽ ھڪڙو وڏو مقدار آھي رام اتي، سڀ ڪجھ ڪم ڪري ٿو. پر ڪن سببن ڪري سرور ادل بدلجي ٿو وڃي ۽ ان جي ڪري سست ٿئي ٿو. اهو لڳي ٿو ته اتي تمام گهڻو يادگار آهي، پر اهو ٿئي ٿو.
اڳي، اسان vm.swappiness کي صفر ڪرڻ جي صلاح ڏني، يعني ادل کي غير فعال ڪرڻ. اڳي، اهو لڳي ٿو ته 32 GB جي رام ۽ لاڳاپيل گڏيل بفر هڪ وڏي رقم هئي. ادل جو بنيادي مقصد اهو آهي ته اسان کي ڪرسٽ اڇلائڻ جي جڳهه هجي جيڪڏهن اسان گر ٿي وڃون. ۽ اهو هاڻي خاص طور تي پورو نه ڪيو ويو. ۽ پوءِ تون هن ڪرسيءَ سان ڇا ڪندين؟ اهو هڪ ڪم آهي جتي اهو واضح ناهي ته ڇو ادل بدلائڻ جي ضرورت آهي، خاص طور تي اهڙي سائيز جي.
پر وڌيڪ جديد ۾، يعني، ڪنييل جي ٽئين نسخن ۾، رويي کي تبديل ڪيو ويو آهي. ۽ جيڪڏهن توهان سويپ کي صفر تي سيٽ ڪيو، يعني ان کي بند ڪريو، پوء جلدي يا دير سان، جيتوڻيڪ اتي ڪجهه رام باقي آهي، هڪ OOM قاتل توهان وٽ اچي ويندو تمام گهڻي صارفين کي مارڻ لاء. ڇاڪاڻ ته هو غور ڪندو ته اهڙي ڪم جي لوڊ سان اسان وٽ اڃا ٿورو ٿورو بچيو آهي ۽ اسان ٻاهر نڪري وينداسين، يعني سسٽم جي عمل کي ختم ڪرڻ لاءِ نه، پر گهٽ اهم شيءِ کي ختم ڪرڻ لاءِ. هي گهٽ اهم هوندو، گڏيل ياداشت جو شديد صارف، يعني پوسٽ ماسٽر. ۽ ان کان پوء اهو سٺو ٿيندو جيڪڏهن بنياد کي بحال ڪرڻ جي ضرورت ناهي.
تنهن ڪري، هاڻي ڊفالٽ، جيتري قدر مون کي ياد آهي، اڪثر تقسيم 6 جي ڀرسان آهن، يعني توهان کي ڪهڙي نقطي تي استعمال ڪرڻ شروع ڪرڻ گهرجي swap استعمال ڪرڻ جي لحاظ سان ڪيتري ميموري باقي رهي ٿي. اسان ھاڻي vm.swappiness = 1 کي ترتيب ڏيڻ جي صلاح ڏيون ٿا، ڇاڪاڻتہ اھو عملي طور تي ان کي بند ڪري ٿو، پر اھو ساڳيو اثر نٿو ڏئي جيئن ھڪڙي OOM-قاتل سان جيڪو غير متوقع طور تي اچي ويو ۽ سڄي شيء کي ماري ڇڏيو.
اڳتي ڇا آهي؟ جڏهن اسان ڊيٽابيس جي ڪارڪردگي جي باري ۾ ڳالهايون ٿا ۽ تدريجي طور تي ڊسڪ ڏانهن وڌو ٿا، هرڪو پنهنجي سر تي قبضو ڪرڻ شروع ڪري ٿو. ڇاڪاڻ ته حقيقت اها آهي ته ڊسڪ سست آهي ۽ ياداشت تيز آهي، هرڪو ننڍپڻ کان واقف آهي. ۽ هرڪو ڄاڻي ٿو ته ڊيٽابيس ۾ ڊسڪ ڪارڪردگي جا مسئلا هوندا.
مکيه PostgreSQL ڪارڪردگي جو مسئلو چيڪ پوائنٽس اسپائڪس سان لاڳاپيل ناهي ڇو ته ڊسڪ سست آهي. اهو سڀ کان وڌيڪ ممڪن آهي انهي حقيقت جي ڪري ته ميموري ۽ ڊسڪ بينڊوڊٿ متوازن نه آهن. بهرحال، اهي مختلف هنڌن تي متوازن نه هوندا. PostgreSQL ترتيب نه آهي، OS ترتيب نه آهي، هارڊويئر ترتيب نه آهي ۽ هارڊويئر غلط آهي. ۽ اهو مسئلو صرف ان صورت ۾ نه ٿو ٿئي جڏهن سڀ ڪجهه ٿئي جيئن اهو ٿيڻ گهرجي، يعني يا ته ڪو لوڊ ناهي، يا سيٽنگون ۽ هارڊويئر چڱي طرح چونڊيل آهن.
اهو ڇا آهي ۽ اهو ڇا نظر اچي ٿو؟ عام طور تي جيڪي ماڻهو PostgreSQL سان ڪم ڪن ٿا انهن کي هن معاملي ۾ هڪ کان وڌيڪ ڀيرا داخل ڪيو آهي. مان وضاحت ڪندس. جيئن مون چيو، PostgreSQL وقتي طور تي چيڪ پوائنٽس ٺاهي ٿو گندي صفحن کي ڊمپ ڪرڻ لاءِ شيئر ڪيل ياداشت ۾ ڊسڪ ۾. جيڪڏهن اسان وٽ وڏي مقدار ۾ شيئر ڪيل ميموري آهي، ته پوءِ چيڪ پوائنٽ شروع ٿئي ٿو ڊسڪ تي گهرو اثر، ڇاڪاڻ ته اهو انهن صفحن کي fsync سان ڊمپ ڪري ٿو. اهو kernel بفر ۾ اچي ٿو ۽ fsync استعمال ڪندي ڊسڪ ڏانهن لکيو ويو آهي. ۽ جيڪڏهن هن ڪاروبار جو مقدار وڏو آهي، ته پوء اسان هڪ ناپسنديده اثر ڏسي سگهون ٿا، يعني ڊسڪ جي تمام وڏي استعمال.
هتي مون وٽ ٻه تصويرون آهن. مان هاڻي وضاحت ڪندس ته اهو ڇا آهي. اهي ٻه وقت سان لاڳاپيل گراف آهن. پهريون گراف ڊسڪ استعمال آهي. هتي اهو وقت ۾ تقريبا 90٪ تائين پهچي ٿو. جيڪڏهن توهان وٽ ڊيٽابيس جي ناڪامي آهي جسماني ڊسڪ سان، هڪ RAID ڪنٽرولر استعمال سان 90٪ تي، پوء اها خراب خبر آهي. هن جو مطلب آهي ته ٿورو وڌيڪ ۽ اهو 100 تائين پهچي ويندو ۽ I/O بند ٿي ويندو.
جيڪڏهن توهان وٽ هڪ ڊسڪ صف آهي، ته اها ٿوري مختلف ڪهاڻي آهي. اهو منحصر آهي ته اهو ڪيئن ترتيب ڏنو ويو آهي، ڪهڙي قسم جي صف آهي، وغيره.
۽ متوازي طور تي، اندروني پوسٽ گريس ڏسڻ مان هڪ گراف هتي ترتيب ڏنل آهي، جيڪو ٻڌائي ٿو ته چيڪ پوائنٽ ڪيئن ٿئي ٿي. ۽ هتي سائو رنگ ڏيکاري ٿو ڪيترا بفر، اهي گندا صفحا، ان وقت هن چيڪ پوائنٽ تي هم وقت سازي لاءِ پهتا. ۽ هي آهي بنيادي شيء جيڪا توهان کي ڄاڻڻ جي ضرورت آهي هتي. اسان ڏسون ٿا ته اسان وٽ هتي ڪيترائي صفحا آهن ۽ ڪجهه نقطي تي اسان بورڊ کي مارايو، اهو آهي، اسان لکيو ۽ لکيو، هتي ڊسڪ سسٽم واضح طور تي تمام مصروف آهي. ۽ اسان جي چيڪ پوائنٽ ڊسڪ تي تمام مضبوط اثر آهي. مثالي طور، صورتحال هن طرح وڌيڪ ڏسڻ گهرجي، يعني اسان وٽ هتي گهٽ رڪارڊنگ هئي. ۽ اسان ان کي سيٽنگن سان درست ڪري سگھون ٿا ته جيئن اهو جاري رهندو. يعني ريسائيڪلنگ ننڍي هوندي آهي، پر هتي ڪجهه نه ڪجهه لکي رهيا آهيون.
هن مسئلي کي ختم ڪرڻ لاء ڇا ڪرڻ جي ضرورت آهي؟ جيڪڏهن توهان ڊيٽابيس جي تحت IO کي روڪيو آهي، ان جو مطلب اهو آهي ته سڀئي صارف جيڪي انهن جي درخواستن کي پورو ڪرڻ لاء آيا انتظار ڪندا.
جيڪڏهن توهان لينڪس جي نقطي نظر کان ڏسندا آهيو، جيڪڏهن توهان سٺو هارڊويئر ورتو، ان کي صحيح طور تي ترتيب ڏنو، ترتيب ڏنو PostgreSQL عام طور تي ته جيئن اهي اهي چيڪ پوسٽون گهٽ اڪثر ڪري، انهن کي هڪ ٻئي جي وچ ۾ وقت جي حوالي سان پکڙيل آهن، پوء توهان ڊفالٽ ڊيبين پيٽرولر ۾ قدم کڻو. اڪثر لينڪس جي تقسيم لاء، هي تصوير آهي: vm.dirty_ratio=20، vm.dirty_background_ratio=10.
هن جو ڇا مطلب آهي؟ ڪرنل 2.6 مان ھڪڙو ڀڄڻ وارو شيطان ظاهر ٿيو. Pdglush، ان تي منحصر آهي ته ڪير استعمال ڪري رهيو آهي، جيڪو پس منظر ۾ گندي صفحن کي ڪرنل بفر مان خارج ڪرڻ ۽ رد ڪرڻ ۾ مصروف آهي جڏهن گندي صفحن کي رد ڪرڻ ضروري آهي، ڪابه پرواهه ناهي، جڏهن پس منظر کي رد ڪرڻ مدد نه ڪندو آهي.
پس منظر ڪڏهن ايندو؟ جڏهن سرور تي موجود ڪل RAM جو 10٪ گندي صفحن تي قبضو ڪيو ويندو آهي ڪنيل بفر ۾، هڪ خاص لکڻ بند فنڪشن کي پس منظر ۾ سڏيو ويندو آهي. اهو پس منظر ڇو آهي؟ هڪ پيٽرولر جي طور تي، اهو حساب ۾ وٺندو آهي ڪيترا صفحا بند ڪرڻ لاء. ۽، اچو ته چوندا آهن، هو بند ڪري ٿو N صفحا. ۽ ٿوري دير لاءِ اها شيءِ سمهي پوي ٿي. ۽ پوءِ هوءَ وري اچي ٿي ۽ ڪجهه وڌيڪ صفحا نقل ڪري ٿي.
هي هڪ انتهائي سادي ڪهاڻي آهي. هتي مسئلو هڪ ترڻ جي تلاءَ جهڙو آهي، جڏهن اهو هڪ پائپ ۾ وهي ٿو ته ٻئي ۾ وهي ٿو. اسان جي چيڪ پوائنٽ پهچي وئي ۽ جيڪڏهن ان کي رد ڪرڻ لاءِ ڪجهه گندا صفحا موڪليا ويا ته پوءِ آهستي آهستي پوري شيءِ صاف ٿي ويندي ڪرنل بفر pgflush مان.
جيڪڏهن اهي گندا صفحا گڏ ٿيندا رهيا ته اهي 20 سيڪڙو تائين گڏ ٿين ٿا، جنهن کان پوءِ او ايس جي ترجيح هوندي آهي ته سڄي شيءِ کي ڊسڪ تي لکجي، ڇو ته پاور ناڪام ٿي ويندي ۽ اسان لاءِ سڀ ڪجهه خراب ٿي ويندو. اسان هن ڊيٽا کي وڃائي ڇڏينداسين، مثال طور.
چال ڇا آهي؟ چال اها آهي ته جديد دنيا ۾ اهي پيرا ميٽرز آهن 20 ۽ 10٪ ڪل ريم جو مشين تي، اهي توهان وٽ موجود ڪنهن به ڊسڪ سسٽم جي ذريعي وڃڻ جي لحاظ کان بلڪل خوفناڪ آهن.
تصور ڪريو ته توهان وٽ 128 GB جي رام آهي. 12,8 GB توهان جي ڊسڪ سسٽم ۾ اچي ٿو. ۽ ڪابه پرواهه ناهي ته توهان وٽ ڪهڙي ڪيش آهي، ڪابه پرواهه ناهي ته توهان وٽ ڪهڙي صف آهي، اهي گهڻو وقت نه رهندا.
تنهن ڪري، اسان سفارش ڪريون ٿا ته توهان انهن نمبرن کي فوري طور تي ترتيب ڏيو توهان جي RAID ڪنٽرولر جي صلاحيتن جي بنياد تي. مون فوري طور تي هڪ سفارش ڪئي هتي هڪ ڪنٽرولر لاءِ جنهن وٽ 512 MB ڪيش آهي.
سڀڪنھن شيء کي تمام سادو سمجهيو ويندو آهي. توهان بائيٽ ۾ vm.dirty_background وجهي سگهو ٿا. ۽ اهي سيٽنگون اڳئين ٻن کي منسوخ ڪن ٿيون. يا ته تناسب ڊفالٽ طور تي آهي، يا اهي بائيٽ سان چالو آهن، پوءِ اهي بائيٽ سان ڪم ڪندا. پر جيئن ته مان هڪ DBA صلاحڪار آهيان ۽ مختلف ڪلائنٽ سان ڪم ڪريان ٿو، مان ڪوشش ڪريان ٿو اسٽرا ڪڍڻ ۽ تنهن ڪري، جيڪڏهن بائيٽ ۾، پوء بائيٽ ۾. ڪنهن به اها گارنٽي نه ڏني ته هڪ سٺو منتظم سرور ۾ وڌيڪ ميموري شامل نه ڪندو، ان کي ريبوٽ ڪندو، ۽ انگ اکر ساڳيو رهندو. بس انهن نمبرن کي ڳڻيو ته جيئن هر شي اتي هڪ گارنٽي سان گڏ هجي.
ڇا ٿيندو جيڪڏهن توهان مناسب نه آهيو؟ مون لکيو آهي ته ڪنهن به فلشنگ کي مؤثر طريقي سان روڪيو ويندو آهي، پر حقيقت ۾ اها تقرير جو هڪ انگ آهي. آپريٽنگ سسٽم ۾ هڪ وڏو مسئلو آهي - ان ۾ تمام گھڻا گندا صفحا آهن، تنهنڪري توهان جي ڪلائنٽ جي ٺاهيل IO کي مؤثر طريقي سان روڪيو ويو آهي، يعني ايپليڪيشن آئي آهي ڊيٽابيس ڏانهن هڪ sql سوال موڪلڻ لاء، اهو انتظار ڪري رهيو آهي. ان لاءِ ڪو به انپٽ/آئوٽ پُٽ سڀ کان گھٽ ترجيح آهي، ڇاڪاڻ ته ڊيٽابيس هڪ چيڪ پوائنٽ تي قبضو ڪيل آهي. ۽ جڏهن هوء ختم ٿيندي ته اهو مڪمل طور تي واضح ناهي. ۽ جڏهن توهان حاصل ڪيو آهي غير پس منظر فلشنگ، ان جو مطلب اهو آهي ته توهان جي سڀني IO ان تي قبضو ڪيو ويو آهي. ۽ جيستائين اهو ختم نه ٿيندو، توهان ڪجھ به نه ڪندا.
هتي ٻه وڌيڪ اهم نقطا آهن جيڪي هن رپورٽ جي دائري کان ٻاهر آهن. اهي سيٽنگون postgresql.conf ۾ سيٽنگون سان ملن ٿيون، يعني چيڪ پوائنٽ سيٽنگون. ۽ توهان جي ڊسڪ سسٽم کي مناسب طور تي ترتيب ڏيڻ گهرجي. جيڪڏهن توهان وٽ RAID تي ڪيش آهي، ته ان ۾ بيٽري هجڻ گهرجي. ماڻهو بيٽري کان سواءِ سٺي ڪيش سان RAID خريد ڪندا آهن. جيڪڏهن توهان وٽ RAID ۾ SSDs آهن، پوء انهن کي سرور هجڻ گهرجي، اتي ڪيپيسٽر هجڻ گهرجن. هتي هڪ تفصيلي چيڪ لسٽ آهي. هي لنڪ منهنجي رپورٽ تي مشتمل آهي PostgreSQL ۾ ڪارڪردگي ڊسڪ کي ڪيئن ترتيب ڏيو. اتي اهي سڀئي چيڪ لسٽون آهن.
ٻيو ڇا ڪري سگهي ٿو زندگي ڏاڍي ڏکي؟ اهي ٻه پيرا ميٽر آهن. اهي نسبتا نئين آهن. ڊفالٽ طور، اهي مختلف ايپليڪيشنن ۾ شامل ڪري سگھجن ٿيون. ۽ اهي زندگي کي ڏکيو بڻائي سگهن ٿا جيڪڏهن اهي غلط طور تي بند ڪيا ويا آهن.
اتي ٻه نسبتا نئين شيون آهن. اهي اڳ ۾ ئي ٽئين ڪور ۾ ظاهر ٿي چڪا آهن. هي آهي sched_migration_cost nanoseconds ۽ sched_autogroup_enabled ۾، جيڪو ڊفالٽ طور هڪ آهي.
۽ اهي توهان جي زندگي ڪيئن برباد ڪندا؟ sched_migration_cost ڇا آهي؟ لينڪس تي، شيڊولر هڪ پروسيس کي هڪ سي پي يو کان ٻئي ڏانهن منتقل ڪري سگهي ٿو. ۽ PostgreSQL لاءِ، جيڪو سوالن تي عمل ڪري ٿو، ٻئي سي پي يو ڏانهن لڏپلاڻ مڪمل طور تي واضح ناهي. آپريٽنگ سسٽم جي نقطي نظر کان، جڏهن توهان اوپن آفيس ۽ ٽرمينل جي وچ ۾ ونڊوز کي مٽايو، اهو سٺو ٿي سگهي ٿو، پر ڊيٽابيس لاءِ هي تمام خراب آهي. تنهن ڪري، هڪ معقول پاليسي آهي ته migration_cost کي ڪجهه وڏي قيمت تي مقرر ڪيو وڃي، گهٽ ۾ گهٽ ڪيترائي هزار نانوس سيڪنڊ.
شيڊيولر لاءِ اهو ڇا مطلب ٿيندو؟ غور ڪيو ويندو ته ان دوران عمل اڃا به گرم آهي. اھو آھي، جيڪڏھن توھان وٽ ھڪڙو ڊگھي ھلندڙ ٽرانزيڪشن آھي جيڪو ھڪڙي عرصي کان ڪجھ ڪري رھيو آھي، شيڊولر اھو سمجھندو. هو سمجهندو ته جيستائين اهو وقت گذرندو، تيستائين هن عمل کي ڪٿي به لڏڻ جي ضرورت ناهي. جيڪڏهن ساڳئي وقت اهو عمل ڪجهه ڪري ٿو، ته اهو ڪٿي به لڏپلاڻ نه ڪيو ويندو، اهو خاموشيء سان سي پي يو تي ڪم ڪندو جيڪو ان کي مختص ڪيو ويو هو. ۽ نتيجو شاندار آهي.
ٻيو نقطو خودڪار گروپ آهي. خاص ڪم لوڊ لاءِ هڪ سٺو خيال آهي جيڪي جديد ڊيٽابيس سان لاڳاپيل نه آهن - اهو آهي گروپ پروسيسز کي ورچوئل ٽرمينل ذريعي جنهن مان اهي لانچ ڪيا ويا آهن. اهو ڪجهه ڪمن لاءِ آسان آهي. عملي طور تي، PostgreSQL هڪ گھڻ-پروسيس سسٽم آهي هڪ پريفورڪ سان جيڪو هڪ واحد ٽرمينل کان هلندو آهي. توهان وٽ هڪ تالا ليکڪ آهي، چيڪ پوائنٽ، ۽ توهان جي ڪلائنٽ جي سڀني درخواستن کي هڪ شيڊولر ۾ گروپ ڪيو ويندو، في سي پي يو. ۽ اُھي اُتي ھڪٻئي سان سندس آزاد ٿيڻ جو انتظار ڪندا، انھيءَ لاءِ ته ھڪ ٻئي سان مداخلت ڪري ۽ کيس وڌيڪ عرصي تائين قبضو ڪري سگھن. هي هڪ ڪهاڻي آهي جيڪا اهڙي لوڊ جي صورت ۾ مڪمل طور تي غير ضروري آهي، تنهنڪري ان کي بند ڪرڻ جي ضرورت آهي.
منهنجي ساٿي Alexey Lesovsky هڪ سادي pgbench سان ٽيسٽون ڪيون، جتي هن لڏپلاڻ جي قيمت ۾ واڌ ڪئي ۽ آٽو گروپ بند ڪري ڇڏيو. خراب هارڊويئر تي فرق لڳ ڀڳ 10 سيڪڙو هو. پوسٽ گريس ميلنگ لسٽ تي هڪ بحث آهي جتي ماڻهو سوال جي رفتار ۾ ساڳي تبديلين جا نتيجا ڏين ٿا متاثر ٿيل 50٪. اهڙيون ڪهاڻيون تمام گهڻيون آهن.
۽ آخرڪار، پاور بچت پاليسي بابت. سٺي ڳالهه اها آهي ته لينڪس هاڻي هڪ ليپ ٽاپ تي استعمال ڪري سگهجي ٿو. ۽ اهو سمجھيو ويندو ته بيٽري کي چڱي طرح استعمال ڪيو ويندو. پر اوچتو اهو معلوم ٿيو ته اهو سرور تي پڻ ٿي سگهي ٿو.
ان کان علاوه، جيڪڏهن توهان ڪجهه ميزبان کان سرور ڪرائي تي، پوء "سٺو" ميزبانن کي پرواه ناهي ته توهان وٽ بهتر ڪارڪردگي آهي. انهن جو ڪم اهو آهي ته انهن جي لوهه کي ممڪن طور تي ممڪن طور تي استعمال ڪيو وڃي. تنهن ڪري، ڊفالٽ طور اهي آپريٽنگ سسٽم تي ليپ ٽاپ پاور بچت موڊ کي فعال ڪري سگهن ٿا.
جيڪڏھن توھان ھي سامان استعمال ڪندا آھيو سرور تي ڊيٽابيس سان گڏ بھاري لوڊ، پوء توھان جي پسند آھي acpi_cpufreq + permormance. جيتوڻيڪ آن ڊيمانڊ سان به مسئلا هوندا.
Intel_pstate ھڪڙو ٿورو مختلف ڊرائيور آھي. ۽ ھاڻي ھن کي ترجيح ڏني وئي آھي، جيئن اھو بعد ۾ آھي ۽ بھتر ڪم ڪري ٿو.
۽، مطابق، گورنر صرف ڪارڪردگي آهي. Ondemand، powersave ۽ ٻيو سڀ ڪجھ توهان جي باري ۾ نه آهي.
وضاحتي تجزيو جا نتيجا PostgreSQL جي شدت جي ڪيترن ئي آرڊرن کان مختلف ٿي سگھن ٿا جيڪڏھن توھان پاور سيو کي چالو ڪيو، ڇاڪاڻ ته عملي طور تي توھان جي ڊيٽابيس جي ھيٺان CPU مڪمل طور تي غير متوقع طريقي سان ھلندو.
اهي شيون ڊفالٽ طور شامل ٿي سگھن ٿيون. غور سان ڏسو ته ڏسو ته ڇا انهن ان کي ڊفالٽ طور تي آن ڪيو. اهو هڪ واقعي وڏو مسئلو ٿي سگهي ٿو.
۽ آخر ۾، مان چوڻ چاهيان ٿو ته اسان جي PosgreSQL-Consulting DBA ٽيم جي ماڻهن جي مهرباني، يعني ميڪس بوگڪ ۽ Alexey Lesovsky، جيڪي هر روز هن معاملي ۾ اڳتي وڌي رهيا آهن. ۽ اسان ڪوشش ڪريون ٿا ته اسان پنهنجي گراهڪن لاءِ بهترين ڪري سگهون ته جيئن اهو سڀ ڪجهه انهن لاءِ ڪم ڪري. اهو هوائي جهازن جي حفاظت جي هدايتن وانگر آهي. هتي سڀ ڪجهه رت ۾ لکيل آهي. انهن مان هر هڪ کي ڪنهن نه ڪنهن مسئلي جي عمل ۾ ملي ٿو. مان انهن کي توهان سان حصيداري ڪرڻ ۾ خوش آهيان.
سوال:
تنهنجي مهرباني! جيڪڏهن، مثال طور، هڪ ڪمپني پئسا بچائڻ چاهي ٿي ۽ ڊيٽابيس ۽ ايپليڪيشن منطق کي هڪ سرور تي رکڻ چاهي ٿي، يا جيڪڏهن ڪمپني مائڪرو سروس آرڪيٽيڪچرز جي فيشني رجحان جي پيروي ڪري ٿي، جنهن ۾ PostgreSQL هڪ ڪنٽينر ۾ هلندو آهي. چال ڇا آهي؟ Sysctl عالمي سطح تي پوري ڪرنل کي متاثر ڪندو. مون نه ٻڌو آهي sysctls ڪنهن به طرح ورچوئل ٿي رهيو آهي ته جيئن اهي ڪنٽينر تي الڳ الڳ ڪم ڪن. هتي صرف هڪ سي گروپ آهي ۽ اتي صرف ڪنٽرول جو حصو آهي. توهان هن سان ڪيئن رهي سگهو ٿا؟ يا جيڪڏهن توهان ڪارڪردگي چاهيو ٿا، پوء هڪ الڳ هارڊويئر سرور تي PostgreSQL هلايو ۽ ان کي ٽيون ڪريو؟
اسان توهان جي سوال جو جواب ٽن طريقن سان ڏنو. جيڪڏهن اسان هارڊويئر سرور جي باري ۾ نه ڳالهائي رهيا آهيون جنهن کي ترتيب ڏئي سگهجي ٿو، وغيره، پوء آرام ڪريو، انهن سيٽنگن کان سواء سڀ ڪجهه ٺيڪ ڪم ڪندو. جيڪڏهن توهان وٽ اهڙو لوڊ آهي ته توهان کي اهي سيٽنگون ٺاهڻ گهرجن، ته پوءِ توهان انهن سيٽنگن کان اڳ لوهه جي سرور تي ايندا.
ڇا مسئلو آهي؟ جيڪڏهن اهو هڪ مجازي مشين آهي، ته پوء گهڻو ڪري توهان وٽ ڪيترائي مسئلا هوندا، مثال طور، حقيقت اها آهي ته اڪثر مجازي مشينن تي ڊسڪ جي ويڪرائي ڪافي متضاد آهي. ايستائين جو ڊسڪ جي ذريعي وڃڻ سٺو آهي، پوء هڪ ناڪام I/O ٽرانزيڪشن جيڪو تمام گهڻو اثر انداز نٿو ڪري اوسط throughput تي جيڪو چيڪ پوائنٽ جي وقت يا WAL تي لکڻ جي وقت تي ٿيو، پوء ڊيٽابيس کي ان کان تمام گهڻو نقصان ٿيندو. ۽ توھان ان کي نوٽيس ڪنداسين ان کان اڳ توھان انھن مسئلن ۾ ھلندا.
جيڪڏهن توهان وٽ آهي NGINX ساڳئي سرور تي، توهان وٽ پڻ ساڳيو مسئلو هوندو. هو گڏيل ياداشت لاءِ وڙهندو. ۽ توهان هتي بيان ڪيل مسئلن کي حاصل نه ڪندا.
پر ٻئي طرف، انهن مان ڪجهه پيٽرولر اڃا تائين توهان سان لاڳاپيل هوندا. مثال طور، dirty_ratio sysctl سان سيٽ ڪريو ته جيئن اهو ايترو چريو نه آهي - ڪنهن به صورت ۾، هي مدد ڪندو. هڪ طريقو يا ٻيو، توهان وٽ ڊسڪ سان رابطو هوندو. ۽ اهو غلط نموني جي مطابق ٿيندو. اهو عام طور تي هڪ ڊفالٽ آهي انهن پيراگرافن لاءِ جيڪي مون ڏيکاريا آهن. ۽ ڪنهن به صورت ۾ ان کي تبديل ڪرڻ بهتر آهي.
پر NUMA سان مسئلا ٿي سگهن ٿا. VmWare، مثال طور، ڪم ڪري ٿو NUMA سان بلڪل سامهون سيٽنگون سان. ۽ هتي توهان کي چونڊڻ گهرجي - هڪ لوهه سرور يا هڪ غير لوهه.
مون وٽ ھڪڙو سوال آھي Amazon AWS سان لاڳاپيل. اهي تصويرون اڳ ۾ ترتيب ڏنل آهن. انهن مان هڪ کي سڏيو ويندو آهي Amazon RDS. ڇا انهن جي آپريٽنگ سسٽم لاءِ ڪي ڪسٽم سيٽنگون آهن؟
اتي سيٽنگون آھن، پر اھي مختلف سيٽنگون آھن. هتي اسان آپريٽنگ سسٽم کي ترتيب ڏيون ٿا ته ڊيٽابيس هن شيء کي ڪيئن استعمال ڪندو. ۽ اهڙا پيرا ميٽر آهن جيڪي طئي ڪن ٿا ته اسان کي هاڻي ڪٿي وڃڻ گهرجي، جهڙوڪ شڪل ڏيڻ. اهو آهي، اسان کي تمام گهڻا وسيلن جي ضرورت آهي، اسان هاڻي انهن کي کائينداسين. ان کان پوء، Amazon RDS انهن وسيلن کي سخت ڪري ٿو، ۽ ڪارڪردگي اتي گهٽجي ٿي. اتي انفرادي ڪهاڻيون آهن ته ڪيئن ماڻهو هن معاملي سان گندا ڪرڻ شروع ڪري رهيا آهن. ڪڏهن ڪڏهن ڪافي ڪاميابي سان. پر هن جو او ايس سيٽنگن سان ڪو به واسطو ناهي. اهو بادل کي هيڪ ڪرڻ وانگر آهي. اها هڪ مختلف ڪهاڻي آهي.
ڇو شفاف وڏن صفحن جو وڏو TLB جي مقابلي ۾ ڪو اثر نه آهي؟
نه ڏيو. اهو ڪيترن ئي طريقن سان وضاحت ڪري سگهجي ٿو. پر حقيقت ۾ اهي صرف اهو نه ڏيندا آهن. PostgreSQL جي تاريخ ڇا آهي؟ شروعات تي، اهو مختص ڪري ٿو هڪ وڏو ٽڪرو گڏيل ياداشت جو. ڇا اهي شفاف آهن يا نه مڪمل طور تي غير لاڳاپيل آهي. حقيقت اها آهي ته اهي شروع ۾ بيٺا آهن سڀ ڪجهه بيان ڪري ٿو. ۽ جيڪڏهن تمام گهڻي ياداشت آهي ۽ توهان کي حصيداري_ميموري حصي کي ٻيهر ٺاهڻ جي ضرورت آهي، پوء شفاف وڏا صفحا لاڳاپيل هوندا. PostgreSQL ۾، اهو صرف شروع ۾ هڪ وڏي حصي ۾ مختص ڪيو ويو آهي ۽ اهو ئي آهي، ۽ پوء اتي ڪجهه خاص ناهي. توهان ڪري سگهو ٿا، يقينا، ان کي استعمال ڪريو، پر هڪ موقعو آهي ته حصيداري_ميموري جي ڪرپشن حاصل ڪرڻ جو جڏهن اهو ڪجهه ٻيهر مختص ڪري ٿو. PostgreSQL ان بابت نٿو ڄاڻي.
جو ذريعو: www.habr.com