PostgreSQL کی کارکردگی کو بہتر بنانے کے لیے لینکس ٹیوننگ۔ الیا کوسموڈیمیانسکی

Ilya Kosmodemyansky کی 2015 کی رپورٹ کا ٹرانسکرپٹ "پوسٹگری ایس کیو ایل کی کارکردگی کو بہتر بنانے کے لیے لینکس ٹیوننگ"

ڈس کلیمر: میں نوٹ کرتا ہوں کہ یہ رپورٹ نومبر 2015 کی ہے - 4 سال سے زیادہ گزر چکے ہیں اور کافی وقت گزر چکا ہے۔ رپورٹ میں زیر بحث ورژن 9.4 اب تعاون یافتہ نہیں ہے۔ پچھلے 4 سالوں میں، PostgreSQL کی 5 نئی ریلیز جاری کی گئی ہیں، اور لینکس کرنل کے 15 ورژن جاری کیے گئے ہیں۔ اگر آپ ان اقتباسات کو دوبارہ لکھتے ہیں، تو آپ کو ایک مختلف رپورٹ ملے گی۔ لیکن یہاں ہم PostgreSQL کے لیے بنیادی لینکس ٹیوننگ پر غور کرتے ہیں، جو آج بھی متعلقہ ہے۔

میرا نام Ilya Kosmodemyansky ہے۔ میں PostgreSQL-Consulting میں کام کرتا ہوں۔ اور اب میں اس بارے میں تھوڑی بات کروں گا کہ عام طور پر ڈیٹا بیس اور PostgreSQL کے سلسلے میں لینکس کے ساتھ کیا کرنا ہے، کیونکہ اصول کافی ملتے جلتے ہیں۔

ہم کیا بات کریں گے؟ اگر آپ PostgreSQL کے ساتھ بات چیت کرتے ہیں، تو کسی حد تک آپ کو UNIX ایڈمن ہونا ضروری ہے۔ اس کا کیا مطلب ہے؟ اگر ہم اوریکل اور پوسٹگری ایس کیو ایل کا موازنہ کریں تو اوریکل میں آپ کو 80% DBA ڈیٹا بیس ایڈمن اور 20% لینکس ایڈمن ہونے کی ضرورت ہے۔

PostgreSQL کے ساتھ یہ قدرے پیچیدہ ہے۔ PostgreSQL کے ساتھ آپ کو لینکس کے کام کرنے کے طریقے کے بارے میں بہت بہتر سمجھنا ضروری ہے۔ اور ایک ہی وقت میں، لوکوموٹو کے بعد تھوڑا چلائیں، کیونکہ حال ہی میں ہر چیز کو اچھی طرح سے اپ ڈیٹ کیا گیا ہے. اور نئے دانا جاری کیے جاتے ہیں، اور نئی فعالیت ظاہر ہوتی ہے، کارکردگی بہتر ہوتی ہے، وغیرہ۔

ہم لینکس کے بارے میں کیوں بات کر رہے ہیں؟ بالکل اس لیے نہیں کہ ہم لینکس کانفرنس پیٹر میں موجود ہیں، بلکہ اس لیے کہ جدید حالات میں ڈیٹا بیس کو عام طور پر اور PostgreSQL کے استعمال کے لیے سب سے زیادہ جائز آپریٹنگ سسٹم لینکس ہے۔ کیونکہ فری بی ایس ڈی، بدقسمتی سے، کچھ بہت ہی عجیب سمت میں ترقی کر رہا ہے۔ اور کارکردگی اور بہت سی دوسری چیزوں کے ساتھ مسائل ہوں گے۔ Windows پر PostgreSQL کی کارکردگی عام طور پر ایک الگ سنگین مسئلہ ہے، اس حقیقت کی بنیاد پر کہ ونڈوز میں UNIX جیسی مشترکہ میموری نہیں ہے، جبکہ PostgreSQL اس سے جڑا ہوا ہے، کیونکہ یہ ایک ملٹی پروسیس سسٹم ہے۔

اور مجھے لگتا ہے کہ ہر کوئی سولاریس جیسے exotics میں کم دلچسپی رکھتا ہے، تو چلیں.

ایک جدید لینکس ڈسٹری بیوشن میں 1 سے زیادہ syctl آپشنز ہیں، اس پر منحصر ہے کہ آپ کرنل کیسے بناتے ہیں۔ ایک ہی وقت میں، اگر ہم مختلف گری دار میوے کو دیکھتے ہیں، تو ہم کئی طریقوں سے کسی چیز کو ایڈجسٹ کرسکتے ہیں. فائل سسٹم کے پیرامیٹرز ہیں کہ انہیں کیسے ماؤنٹ کیا جائے۔ اگر آپ کے ذہن میں سوالات ہیں کہ اسے کیسے شروع کیا جائے: BIOS میں کس چیز کو فعال کرنا ہے، ہارڈ ویئر کو کیسے ترتیب دینا ہے، وغیرہ۔

یہ ایک بہت بڑا حجم ہے جس پر کئی دنوں تک بحث کی جا سکتی ہے، اور ایک مختصر رپورٹ میں نہیں، لیکن اب میں اہم باتوں پر توجہ مرکوز کروں گا، ان ریکوں سے کیسے بچنا ہے جو آپ کو لینکس پر اپنے ڈیٹا بیس کو اچھی طرح سے استعمال کرنے سے روکنے کی ضمانت دیتے ہیں اگر آپ ان کو درست نہ کرو. اور ساتھ ہی ایک اہم نکتہ یہ ہے کہ بہت سے ڈیفالٹ پیرامیٹرز ان سیٹنگز میں شامل نہیں ہیں جو ڈیٹا بیس کے لیے درست ہیں۔ یعنی پہلے سے طے شدہ طور پر یہ خراب کام کرے گا یا بالکل نہیں۔

لینکس میں کون سے روایتی ٹیوننگ اہداف ہیں؟ میرا خیال ہے کہ چونکہ آپ سبھی لینکس انتظامیہ کے ساتھ کام کر رہے ہیں، اس لیے یہ بتانے کی کوئی خاص ضرورت نہیں ہے کہ اہداف کیا ہیں۔

آپ ٹیون کر سکتے ہیں:

• سی پی یو.
• یاداشت.
• ذخیرہ۔
• دیگر ہم اس کے بارے میں آخر میں ناشتے کے لیے بات کریں گے۔ یہاں تک کہ، مثال کے طور پر، توانائی کی بچت کی پالیسی جیسے پیرامیٹرز کارکردگی کو انتہائی غیر متوقع طور پر متاثر کر سکتے ہیں اور نہ کہ انتہائی خوشگوار طریقے سے۔

PostgreSQL اور عام طور پر ڈیٹا بیس کی خصوصیات کیا ہیں؟ مسئلہ یہ ہے کہ آپ کسی بھی انفرادی نٹ کو موافقت نہیں دے سکتے اور دیکھ سکتے ہیں کہ ہماری کارکردگی میں نمایاں بہتری آئی ہے۔

جی ہاں، ایسے گیجٹس ہیں، لیکن ڈیٹا بیس ایک پیچیدہ چیز ہے۔ یہ ان تمام وسائل کے ساتھ تعامل کرتا ہے جو سرور کے پاس ہیں اور پوری طرح سے بات چیت کرنے کو ترجیح دیتے ہیں۔ اگر آپ میزبان OS کو استعمال کرنے کے بارے میں اوریکل کی موجودہ سفارشات پر نظر ڈالیں تو یہ اس منگول خلاباز کے بارے میں مذاق کی طرح ہوگا - کتے کو کھانا کھلانا اور کسی چیز کو ہاتھ نہ لگانا۔ آئیے ڈیٹا بیس کو تمام وسائل دیتے ہیں، ڈیٹا بیس خود ہی سب کچھ ترتیب دے گا۔

اصولی طور پر، کسی حد تک صورت حال PostgreSQL کے ساتھ بالکل یکساں ہے۔ فرق یہ ہے کہ ڈیٹا بیس ابھی تک اپنے لیے تمام وسائل لینے کے قابل نہیں ہے، یعنی کہیں لینکس کی سطح پر آپ کو یہ سب خود ترتیب دینے کی ضرورت ہے۔

بنیادی خیال یہ نہیں ہے کہ کسی ایک ہدف کو منتخب کریں اور اسے ٹیوننگ شروع کریں، مثال کے طور پر، میموری، سی پی یو یا اس طرح کی کوئی چیز، بلکہ کام کے بوجھ کا تجزیہ کرنا اور ممکنہ حد تک تھرو پٹ کو بہتر بنانے کی کوشش کرنا ہے تاکہ وہ بوجھ جو اچھے پروگرامرز نے بنایا ہو۔ ہمارے صارفین سمیت ہمارے لیے۔

یہ کیا ہے اس کی وضاحت کے لیے یہاں ایک تصویر ہے۔ ایک لینکس OS بفر ہے اور مشترکہ میموری ہے اور PostgreSQL مشترکہ بفرز ہیں۔ پوسٹگری ایس کیو ایل، اوریکل کے برعکس، براہ راست صرف کرنل بفر کے ذریعے کام کرتا ہے، یعنی، ڈسک سے کسی صفحہ کو اپنی مشترکہ میموری میں داخل کرنے کے لیے، اسے کرنل بفر اور پیچھے سے گزرنا ضروری ہے، بالکل وہی صورت حال۔

ڈسکیں اس نظام کے تحت رہتی ہیں۔ میں نے اسے بطور ڈسک کھینچا۔ درحقیقت، ایک RAID کنٹرولر ہو سکتا ہے، وغیرہ۔

اور یہ ان پٹ آؤٹ پٹ کسی نہ کسی طرح اس معاملے کے ذریعے ہوتا ہے۔

PostgreSQL ایک کلاسک ڈیٹا بیس ہے۔ اندر ایک صفحہ ہے۔ اور تمام ان پٹ اور آؤٹ پٹ صفحات کا استعمال کرتے ہوئے ہوتا ہے۔ ہم صفحات کے ساتھ میموری میں بلاکس کو بڑھا رہے ہیں۔ اور اگر کچھ نہیں ہوا تو ہم انہیں صرف پڑھتے ہیں، پھر آہستہ آہستہ وہ اس کیش سے، مشترکہ بفرز سے غائب ہو جاتے ہیں اور واپس ڈسک پر آ جاتے ہیں۔

اگر ہم کسی جگہ کسی چیز کو تبدیل کرتے ہیں، تو پورے صفحہ پر گندا نشان لگا دیا جاتا ہے۔ میں نے انہیں یہاں نیلے رنگ میں نشان زد کیا۔ اور اس کا مطلب یہ ہے کہ یہ صفحہ بلاک اسٹوریج کے ساتھ مطابقت پذیر ہونا چاہیے۔ یعنی جب ہم نے اسے گندا کیا تو ہم نے وال میں انٹری دی۔ اور وقت کے کسی حیرت انگیز لمحے پر، چیک پوائنٹ نامی ایک واقعہ آیا۔ اور اس لاگ میں معلومات درج تھیں کہ وہ پہنچ چکا ہے۔ اور اس کا مطلب یہ ہے کہ ان مشترکہ بفرز میں اس وقت یہاں موجود تمام گندے صفحات کو کرنل بفر کے ذریعے fsync کا استعمال کرتے ہوئے اسٹوریج ڈسک کے ساتھ ہم آہنگ کیا گیا تھا۔

ایسا کیوں کیا جا رہا ہے؟ اگر ہم نے وولٹیج کھو دیا، تو ہمیں یہ صورتحال نہیں ملی کہ سارا ڈیٹا ضائع ہو گیا۔ مستقل میموری، جس کے بارے میں سب نے ہمیں بتایا، ڈیٹا بیس تھیوری میں اب تک ہے - یہ ایک روشن مستقبل ہے، جس کے لیے ہم یقیناً کوشش کرتے ہیں اور ہمیں یہ پسند ہے، لیکن فی الحال وہ مائنس 20 سال میں رہتے ہیں۔ اور، یقینا، اس سب کی نگرانی کرنے کی ضرورت ہے.

اور تھرو پٹ کو زیادہ سے زیادہ کرنے کا کام ان تمام مراحل کو ٹھیک کرنا ہے تاکہ یہ سب تیزی سے آگے پیچھے ہو جائے۔ مشترکہ میموری بنیادی طور پر ایک صفحہ کیش ہے۔ PostgreSQL میں ہم نے ایک منتخب سوال یا کچھ بھیجا، اس نے یہ ڈیٹا ڈسک سے بازیافت کیا۔ وہ مشترکہ بفروں میں ختم ہوئے۔ اس کے مطابق، یہ بہتر کام کرنے کے لئے، بہت زیادہ میموری ہونا ضروری ہے.

یہ سب کچھ اچھی طرح اور تیزی سے کام کرنے کے لیے، آپ کو تمام مراحل پر آپریٹنگ سسٹم کو درست طریقے سے ترتیب دینے کی ضرورت ہے۔ اور متوازن ہارڈ ویئر کا انتخاب کریں، کیونکہ اگر آپ کے پاس کسی جگہ عدم توازن ہے، تو آپ بہت زیادہ میموری بنا سکتے ہیں، لیکن یہ کافی رفتار سے سروس نہیں کی جائے گی۔

اور آئیے ان پوائنٹس میں سے ہر ایک کو دیکھتے ہیں۔

ان صفحات کو تیزی سے آگے پیچھے کرنے کے لیے، آپ کو درج ذیل کو حاصل کرنے کی ضرورت ہے:

• سب سے پہلے، آپ کو میموری کے ساتھ زیادہ مؤثر طریقے سے کام کرنے کی ضرورت ہے.
• دوم، جب میموری سے صفحات ڈسک پر جاتے ہیں تو یہ منتقلی زیادہ موثر ہونی چاہیے۔
• اور تیسرا، اچھی ڈسکیں ہونی چاہئیں۔

اگر آپ کے پاس سرور میں 512 جی بی ریم ہے اور یہ سب کچھ بغیر کسی کیش کے SATA ہارڈ ڈرائیو پر ختم ہوجاتا ہے، تو پورا ڈیٹا بیس سرور نہ صرف ایک کدو، بلکہ SATA انٹرفیس کے ساتھ ایک کدو بن جاتا ہے۔ آپ اس میں براہ راست بھاگ جائیں گے۔ اور آپ کو کچھ بھی نہیں بچائے گا۔

یادداشت کے ساتھ پہلے نقطہ کے بارے میں، تین چیزیں ایسی ہیں جو زندگی کو بہت مشکل بنا سکتی ہیں۔

ان میں سے پہلی NUMA ہے۔ NUMA ایک ایسی چیز ہے جو کارکردگی کو بہتر بنانے کے لیے بنائی گئی ہے۔ کام کے بوجھ کے لحاظ سے مختلف چیزوں کو بہتر بنایا جا سکتا ہے۔ اور اس کی نئی موجودہ شکل میں، یہ ڈیٹا بیس جیسی ایپلی کیشنز کے لیے بہت اچھا نہیں ہے جو صفحہ کیشے کے مشترکہ بفرز کو شدت سے استعمال کرتے ہیں۔

مختصراً۔ آپ کیسے بتا سکتے ہیں کہ NUMA میں کچھ غلط ہے؟ آپ کو کسی قسم کی ناخوشگوار دستک ہے، اچانک کچھ سی پی یو اوور لوڈ ہو گیا ہے۔ اسی وقت، آپ PostgreSQL میں سوالات کا تجزیہ کرتے ہیں اور دیکھتے ہیں کہ وہاں کچھ بھی ایسا نہیں ہے۔ یہ استفسارات اتنے زیادہ CPU نہیں ہونے چاہئیں۔ آپ اسے طویل عرصے تک پکڑ سکتے ہیں۔ PostgreSQL کے لیے NUMA کو کنفیگر کرنے کے بارے میں شروع سے ہی درست تجویز کا استعمال کرنا آسان ہے۔

واقعی کیا ہو رہا ہے؟ NUMA کا مطلب ہے نان یونیفارم میموری تک رسائی۔ کیا مقصد ہے؟ آپ کے پاس سی پی یو ہے، اس کے ساتھ ہی اس کی لوکل میموری ہے۔ اور یہ میموری آپس میں دوسرے CPUs سے میموری کو کھینچ سکتی ہے۔

اگر آپ بھاگتے ہیں۔ numactl --hardwareپھر آپ کو اتنی بڑی چادر ملے گی۔ دوسری چیزوں کے علاوہ، ایک فاصلاتی میدان ہو گا. نمبرز ہوں گے - 10-20، کچھ اس طرح۔ یہ نمبر اس ریموٹ میموری کو لینے اور اسے مقامی طور پر استعمال کرنے کے لیے ہاپس کی تعداد سے زیادہ کچھ نہیں ہیں۔ اصول میں، ایک اچھا خیال. یہ کام کے بوجھ کی ایک حد کے تحت کارکردگی کو اچھی طرح سے تیز کرتا ہے۔

اب تصور کریں کہ آپ کے پاس ایک سی پی یو ہے جو پہلے اپنی مقامی میموری کو استعمال کرنے کی کوشش کر رہا ہے، پھر کسی چیز کے لیے آپس میں جڑ کر دوسری میموری کو کھینچنے کی کوشش کر رہا ہے۔ اور یہ CPU آپ کا پورا PostgreSQL صفحہ کیش حاصل کرتا ہے - بس، کچھ گیگا بائٹس۔ آپ کو ہمیشہ بدترین کیس ملتا ہے، کیونکہ CPU پر اس ماڈیول میں عام طور پر بہت کم میموری ہوتی ہے۔ اور تمام میموری جو سرو کی جاتی ہے ان آپس میں جڑ جاتی ہے۔ یہ سست اور اداس باہر کر دیتا ہے. اور آپ کا پروسیسر جو اس نوڈ کی خدمت کرتا ہے مسلسل اوورلوڈ ہوتا ہے۔ اور اس میموری تک رسائی کا وقت خراب، سست ہے۔ یہ وہ صورت حال ہے جو آپ نہیں چاہتے ہیں اگر آپ اسے ڈیٹا بیس کے لیے استعمال کر رہے ہیں۔

لہذا، ڈیٹا بیس کے لیے ایک زیادہ درست آپشن یہ ہے کہ لینکس آپریٹنگ سسٹم کو معلوم نہ ہو کہ وہاں کیا ہو رہا ہے۔ تاکہ یہ میموری تک رسائی حاصل کرے جیسا کہ یہ کرتا ہے۔

ایسا کیوں ہے؟ ایسا لگتا ہے کہ یہ اس کے برعکس ہونا چاہئے۔ یہ ایک سادہ وجہ سے ہوتا ہے: ہمیں صفحہ کیشے کے لیے بہت زیادہ میموری کی ضرورت ہوتی ہے - دسیوں، سینکڑوں گیگا بائٹس۔

اور اگر ہم یہ سب کچھ مختص کرتے ہیں اور اپنے ڈیٹا کو وہاں محفوظ کرتے ہیں، تو کیش کے استعمال سے حاصل ہونے والا فائدہ میموری تک اس طرح کی مشکل رسائی سے حاصل ہونے والے فائدہ سے کافی زیادہ ہوگا۔ اور اس طرح ہم اس حقیقت کے مقابلے میں بے مثال فائدہ اٹھائیں گے کہ ہم NUMA کا استعمال کرتے ہوئے زیادہ موثر طریقے سے میموری تک رسائی حاصل کریں گے۔

لہذا، اس وقت یہاں دو نقطہ نظر ہیں، جب تک کہ روشن مستقبل نہ آجائے، اور ڈیٹا بیس خود یہ معلوم کرنے کے قابل نہیں ہے کہ یہ کن سی پی یوز پر چل رہا ہے اور اسے کہاں سے کچھ نکالنے کی ضرورت ہے۔

لہذا، صحیح نقطہ نظر NUMA کو مکمل طور پر غیر فعال کرنا ہے۔مثال کے طور پر، ریبوٹ کرتے وقت۔ زیادہ تر صورتوں میں، جیت اتنی بڑی مقدار کی ہوتی ہے کہ اس کا سوال ہی پیدا نہیں ہوتا کہ کون سا بہتر ہے۔

ایک اور آپشن ہے۔ ہم اسے پہلے والے کے مقابلے زیادہ کثرت سے استعمال کرتے ہیں، کیونکہ جب کوئی کلائنٹ سپورٹ کے لیے ہمارے پاس آتا ہے، تو سرور کو دوبارہ شروع کرنا اس کے لیے بہت بڑی بات ہے۔ اس کا وہاں کاروبار ہے۔ اور وہ NUMA کی وجہ سے مسائل کا سامنا کرتے ہیں۔ لہذا، ہم اسے دوبارہ شروع کرنے کے مقابلے میں کم ناگوار طریقوں سے غیر فعال کرنے کی کوشش کرتے ہیں، لیکن یہ چیک کرنے میں محتاط رہیں کہ یہ غیر فعال ہے۔ کیونکہ، جیسا کہ تجربہ ظاہر کرتا ہے، یہ اچھی بات ہے کہ ہم پیرنٹ PostgreSQL عمل پر NUMA کو غیر فعال کر دیں، لیکن یہ بالکل ضروری نہیں ہے کہ یہ کام کرے۔ ہمیں چیک کرنے اور دیکھنے کی ضرورت ہے کہ وہ واقعی بند ہے۔

رابرٹ ہاس کی ایک اچھی پوسٹ ہے۔ یہ PostgreSQL کمٹٹرز میں سے ایک ہے۔ تمام نچلی سطح کے گبلٹس کے کلیدی ڈویلپرز میں سے ایک۔ اور اگر آپ اس پوسٹ کے لنکس کی پیروی کرتے ہیں، تو وہ کئی رنگین کہانیاں بیان کرتے ہیں کہ کس طرح NUMA نے لوگوں کی زندگی کو مشکل بنا دیا۔ دیکھیں، سسٹم ایڈمنسٹریٹر کی چیک لسٹ کا مطالعہ کریں کہ ہمارے ڈیٹا بیس کو اچھی طرح سے کام کرنے کے لیے سرور پر کن چیزوں کو ترتیب دینے کی ضرورت ہے۔ ان ترتیبات کو لکھنے اور چیک کرنے کی ضرورت ہے، کیونکہ بصورت دیگر یہ بہت اچھا نہیں ہوگا۔

براہ کرم نوٹ کریں کہ یہ ان تمام ترتیبات پر لاگو ہوتا ہے جن کے بارے میں میں بات کروں گا۔ لیکن عام طور پر ڈیٹا بیس کو غلطی برداشت کرنے کے لیے ماسٹر سلیو موڈ میں جمع کیا جاتا ہے۔ غلام پر یہ سیٹنگز کرنا نہ بھولیں کیونکہ ایک دن آپ کا ایکسیڈنٹ ہو گا اور آپ غلام کی طرف چلے جائیں گے اور وہ آقا بن جائے گا۔

ہنگامی صورتحال میں، جب سب کچھ بہت خراب ہے، آپ کا فون مسلسل بج رہا ہے اور آپ کا باس ایک بڑی چھڑی کے ساتھ دوڑتا ہوا آتا ہے، آپ کے پاس چیک کرنے کے بارے میں سوچنے کا وقت نہیں ہوگا۔ اور نتائج کافی تباہ کن ہو سکتے ہیں۔

اگلا نکتہ بڑے صفحات کا ہے۔ بڑے صفحات کو الگ سے جانچنا مشکل ہے، اور ایسا کرنے کا کوئی فائدہ نہیں، حالانکہ ایسے معیارات موجود ہیں جو یہ کر سکتے ہیں۔ وہ گوگل کے لیے آسان ہیں۔

کیا مقصد ہے؟ آپ کے پاس بہت زیادہ RAM والا سرور نہیں ہے، مثال کے طور پر، 30 GB سے زیادہ۔ آپ بڑے صفحات استعمال نہیں کرتے ہیں۔ اس کا مطلب یہ ہے کہ میموری کے استعمال کے معاملے میں آپ کے پاس یقینی طور پر اوور ہیڈ ہے۔ اور یہ اوور ہیڈ سب سے زیادہ خوشگوار سے دور ہے۔

ایسا کیوں ہے؟ تو کیا ہو رہا ہے؟ آپریٹنگ سسٹم میموری کو چھوٹے ٹکڑوں میں مختص کرتا ہے۔ یہ بہت آسان ہے، یہ تاریخی طور پر کیسے ہوا. اور اگر ہم تفصیل میں جائیں تو، OS کو ورچوئل ایڈریسز کو فزیکل ایڈریسز میں ترجمہ کرنا چاہیے۔ اور یہ عمل سب سے آسان نہیں ہے، لہذا OS اس آپریشن کے نتیجے کو Translation Lookaside Buffer (TLB) میں کیش کرتا ہے۔

اور چونکہ TLB ایک کیش ہے، اس صورت حال میں کیش میں موجود تمام مسائل پیدا ہوتے ہیں۔ سب سے پہلے، اگر آپ کے پاس بہت زیادہ RAM ہے اور یہ تمام چھوٹے ٹکڑوں میں مختص ہے، تو یہ بفر بہت بڑا ہو جاتا ہے۔ اور اگر ذخیرہ بڑا ہے، تو اس کے ذریعے تلاش کرنا سست ہے۔ اوور ہیڈ صحت مند ہے اور یہ خود ہی جگہ لیتا ہے، یعنی RAM کو کسی غلط چیز سے استعمال کیا جا رہا ہے۔ اس بار۔

دو - ایسی صورت حال میں جتنا زیادہ کیش بڑھتا ہے، اتنا ہی زیادہ امکان ہوتا ہے کہ آپ کے پاس کیش چھوٹ جائے گی۔ اور اس کیش کی افادیت تیزی سے کم ہوتی جاتی ہے جیسے جیسے اس کا سائز بڑھتا ہے۔ لہذا، آپریٹنگ سسٹم ایک سادہ نقطہ نظر کے ساتھ آئے. یہ ایک طویل عرصے سے لینکس میں استعمال ہو رہا ہے۔ یہ فری بی ایس ڈی میں بہت عرصہ پہلے شائع ہوا تھا۔ لیکن ہم لینکس کے بارے میں بات کر رہے ہیں۔ یہ بہت بڑے صفحات ہیں۔

اور یہاں یہ واضح رہے کہ بڑے صفحات، ایک خیال کے طور پر، ابتدائی طور پر کمیونٹیز کی طرف سے دھکیل دیا گیا تھا جس میں اوریکل اور آئی بی ایم شامل تھے، یعنی ڈیٹا بیس بنانے والوں کا پختہ خیال تھا کہ یہ ڈیٹا بیس کے لیے بھی کارآمد ہوگا۔

اور یہ PostgreSQL سے دوستی کیسے کی جا سکتی ہے؟ سب سے پہلے، لینکس کرنل میں بڑے صفحات کو فعال کرنا ضروری ہے۔

دوم، انہیں sysctl پیرامیٹر کے ذریعے واضح طور پر بیان کیا جانا چاہیے - وہاں کتنے ہیں۔ یہاں کے نمبر کسی پرانے سرور سے ہیں۔ آپ حساب لگا سکتے ہیں کہ آپ کے پاس کتنے مشترکہ بفرز ہیں تاکہ بڑے صفحات وہاں فٹ ہو سکیں۔

اور اگر آپ کا پورا سرور PostgreSQL کے لیے وقف ہے، تو ایک اچھا نقطہ آغاز یا تو 25% RAM کو مشترکہ بفرز کے لیے مختص کرنا ہے، یا 75% اگر آپ کو یقین ہے کہ آپ کا ڈیٹا بیس یقینی طور پر اس 75% میں فٹ ہو جائے گا۔ نقطہ آغاز ایک۔ اور غور کریں، اگر آپ کے پاس 256 جی بی ریم ہے، تو، اس کے مطابق، آپ کے پاس 64 جی بی بڑے بفرز ہوں گے۔ کچھ مارجن کے ساتھ لگ بھگ حساب لگائیں - اس اعداد و شمار کو کیا مقرر کیا جانا چاہئے۔

ورژن 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 شروع ہوتا ہے، جب یہ مشترکہ میموری کو مختص کرتا ہے، تو یہ اس میموری کو بڑے صفحات سے حاصل کرنے کی کوشش کرتا ہے۔ اور اگر یہ کام نہیں کرتا ہے، تو یہ عام انتخاب پر واپس چلا جاتا ہے۔ اور اگر آپ کے پاس FreeBSD یا Solaris ہے، تو آپ کوشش کر سکتے ہیں، یہ ہمیشہ محفوظ ہے۔

اگر آن ہے، تو یہ صرف شروع نہیں ہوتا ہے اگر یہ بڑے صفحات میں سے انتخاب نہ کر سکے۔ یہاں یہ پہلے ہی ہے کہ کون اور کیا اچھا ہے۔ لیکن اگر آپ نے کوشش کی ہے، تو چیک کریں کہ آپ کے پاس واقعی وہی ہے جس کی آپ کو ضرورت ہے، کیونکہ غلطی کی بہت گنجائش ہے۔ فی الحال یہ فعالیت صرف لینکس پر کام کرتی ہے۔

آگے جانے سے پہلے ایک اور چھوٹا نوٹ۔ شفاف بڑے صفحات ابھی PostgreSQL کے بارے میں نہیں ہیں۔ وہ انہیں عام طور پر استعمال نہیں کر سکتا۔ اور اس طرح کے کام کے بوجھ کے لیے شفاف بڑے صفحات کے ساتھ، جب مشترکہ میموری کے ایک بڑے ٹکڑے کی ضرورت ہوتی ہے، تو فوائد صرف بہت بڑے حجم کے ساتھ آتے ہیں۔ اگر آپ کے پاس ٹیرا بائٹس میموری ہے تو یہ عمل میں آسکتا ہے۔ اگر ہم روزمرہ کی مزید ایپلی کیشنز کے بارے میں بات کر رہے ہیں، جب آپ کی مشین پر 32, 64, 128, 256 GB میموری ہے، تو معمول کے بڑے صفحات ٹھیک ہیں، اور ہم صرف شفاف کو غیر فعال کر دیتے ہیں۔

اور یادداشت کے بارے میں آخری چیز کا براہ راست تعلق فروٹ سے نہیں ہے، یہ واقعی آپ کی زندگی کو تباہ کر سکتا ہے۔ تمام تھرو پٹ اس حقیقت سے بہت متاثر ہوں گے کہ سرور مسلسل تبدیل ہو رہا ہے۔

اور یہ بہت سے طریقوں سے بہت ناگوار ہوگا۔ اور بنیادی مسئلہ یہ ہے کہ جدید دانا پرانے لینکس کرنل سے قدرے مختلف برتاؤ کرتے ہیں۔ اور یہ چیز اس پر قدم رکھنا کافی ناگوار ہے، کیونکہ جب ہم تبادلہ کے ساتھ کسی قسم کے کام کے بارے میں بات کرتے ہیں، تو یہ OOM-قاتل کی بے وقت آمد پر ختم ہو جاتی ہے۔ اور OOM- قاتل، جو بروقت نہیں پہنچا اور PostgreSQL چھوڑ دیا، ناخوشگوار ہے۔ اس کے بارے میں سب کو معلوم ہو گا یعنی آخری صارف تک۔

کیا ہو رہا ہے؟ آپ کے پاس وہاں بڑی مقدار میں RAM ہے، سب کچھ ٹھیک کام کرتا ہے۔ لیکن کسی وجہ سے سرور سویپ میں ہینگ ہو جاتا ہے اور اس کی وجہ سے سست ہو جاتا ہے۔ ایسا لگتا ہے کہ یادداشت بہت زیادہ ہے، لیکن ایسا ہوتا ہے۔

پہلے، ہم نے vm.swappiness کو صفر پر سیٹ کرنے کا مشورہ دیا تھا، یعنی سویپ کو غیر فعال کرنا۔ پہلے، ایسا لگتا تھا کہ 32 جی بی ریم اور اسی طرح کے مشترکہ بفرز ایک بہت بڑی رقم تھی۔ تبادلہ کا بنیادی مقصد یہ ہے کہ اگر ہم گر جائیں تو کرسٹ کو پھینکنے کے لئے جگہ ہو۔ اور یہ اب خاص طور پر پورا نہیں ہوا تھا۔ اور پھر آپ اس پرت کا کیا کرنے جا رہے ہیں؟ یہ ایک ایسا کام ہے جہاں یہ بہت واضح نہیں ہے کہ تبادلہ کی ضرورت کیوں ہے، خاص طور پر اس طرح کے سائز کا۔

لیکن زیادہ جدید، یعنی کرنل کے تیسرے ورژن میں، رویہ بدل گیا ہے۔ اور اگر آپ سویپ کو صفر پر سیٹ کرتے ہیں، یعنی اسے آف کر دیتے ہیں، تو جلد یا بدیر، یہاں تک کہ اگر کچھ RAM باقی ہے، ایک OOM قاتل آپ کے پاس سب سے زیادہ صارفین کو مارنے کے لیے آئے گا۔ کیونکہ وہ اس بات پر غور کرے گا کہ اس طرح کے کام کے بوجھ کے ساتھ ہمارے پاس ابھی تھوڑا سا باقی ہے اور ہم باہر کود جائیں گے، یعنی سسٹم کے عمل کو کیل کرنے کے لیے نہیں، بلکہ کسی کم اہم چیز کو ختم کرنے کے لیے۔ یہ کم اہم مشترکہ میموری کا گہرا صارف ہوگا، یعنی پوسٹ ماسٹر۔ اور اس کے بعد بیس کو بحال نہ کرنا پڑے تو اچھا ہو گا۔

لہذا، اب پہلے سے طے شدہ، جہاں تک مجھے یاد ہے، زیادہ تر تقسیمیں 6 کے آس پاس ہیں، یعنی کتنی میموری باقی ہے اس پر منحصر ہے کہ آپ کو کس مقام پر سویپ کا استعمال شروع کرنا چاہیے۔ اب ہم vm.swappiness = 1 سیٹ کرنے کی تجویز کرتے ہیں، کیونکہ یہ عملی طور پر اسے بند کر دیتا ہے، لیکن OOM-قاتل کے ساتھ وہی اثرات نہیں دیتا جو غیر متوقع طور پر پہنچ کر پوری چیز کو ہلاک کر دیتا ہے۔

اس کے بعد کیا ہے؟ جب ہم ڈیٹا بیس کی کارکردگی کے بارے میں بات کرتے ہیں اور آہستہ آہستہ ڈسک کی طرف بڑھتے ہیں تو ہر کوئی اپنا سر پکڑنے لگتا ہے۔ کیونکہ ڈسک سست اور یادداشت تیز ہونے کی حقیقت بچپن سے ہی سب کو معلوم ہے۔ اور ہر کوئی جانتا ہے کہ ڈیٹا بیس میں ڈسک کی کارکردگی کے مسائل ہوں گے۔

اہم پوسٹگری ایس کیو ایل کارکردگی کا مسئلہ چیک پوائنٹس اسپائکس سے وابستہ نہیں ہوتا کیونکہ ڈسک سست ہے۔ یہ سب سے زیادہ امکان اس حقیقت کی وجہ سے ہے کہ میموری اور ڈسک بینڈوتھ متوازن نہیں ہیں۔ تاہم، وہ مختلف جگہوں پر متوازن نہیں ہوسکتے ہیں۔ PostgreSQL کنفیگر نہیں ہے، OS کنفیگر نہیں ہے، ہارڈ ویئر کنفیگر نہیں ہے اور ہارڈ ویئر غلط ہے۔ اور یہ مسئلہ صرف اس صورت میں نہیں ہوتا جب سب کچھ جیسا ہونا چاہیے ہوتا ہے، یعنی یا تو کوئی بوجھ نہیں ہے، یا سیٹنگز اور ہارڈ ویئر کو اچھی طرح سے منتخب کیا گیا ہے۔

یہ کیا ہے اور یہ کیسا لگتا ہے؟ عام طور پر جو لوگ PostgreSQL کے ساتھ کام کرتے ہیں وہ ایک سے زیادہ بار اس معاملے میں داخل ہو چکے ہیں۔ میں سمجھا دوں گا۔ جیسا کہ میں نے کہا، پوسٹگری ایس کیو ایل وقتاً فوقتاً ڈسک پر مشترکہ میموری میں گندے صفحات کو ڈمپ کرنے کے لیے چوکیاں بناتا ہے۔ اگر ہمارے پاس مشترکہ میموری کی بڑی مقدار ہے، تو چیک پوائنٹ کا ڈسک پر گہرا اثر ہونا شروع ہو جاتا ہے، کیونکہ یہ ان صفحات کو fsync کے ساتھ پھینک دیتا ہے۔ یہ کرنل بفر میں آتا ہے اور fsync کا استعمال کرتے ہوئے ڈسک پر لکھا جاتا ہے۔ اور اگر اس کاروبار کا حجم بڑا ہے، تو ہم ایک ناخوشگوار اثر دیکھ سکتے ہیں، یعنی ڈسکوں کا ایک بہت بڑا استعمال۔

یہاں میرے پاس دو تصویریں ہیں۔ اب میں وضاحت کروں گا کہ یہ کیا ہے۔ یہ دو وقت سے منسلک گراف ہیں۔ پہلا گراف ڈسک کا استعمال ہے۔ یہاں یہ اس وقت تقریباً 90% تک پہنچ جاتا ہے۔ اگر آپ کے پاس فزیکل ڈسک کے ساتھ ڈیٹا بیس کی ناکامی ہے، جس میں RAID کنٹرولر کا استعمال 90٪ ہے، تو یہ بری خبر ہے۔ اس کا مطلب ہے کہ تھوڑا اور اور یہ 100 تک پہنچ جائے گا اور I/O رک جائے گا۔

اگر آپ کے پاس ڈسک کی صف ہے، تو یہ قدرے مختلف کہانی ہے۔ یہ اس بات پر منحصر ہے کہ اسے کس طرح ترتیب دیا گیا ہے، یہ کس قسم کی صف ہے، وغیرہ۔

اور متوازی طور پر، اندرونی پوسٹگریس ویو سے ایک گراف یہاں ترتیب دیا گیا ہے، جو بتاتا ہے کہ چیک پوائنٹ کیسے ہوتا ہے۔ اور یہاں کا سبز رنگ ظاہر کرتا ہے کہ کتنے بفر، یہ گندے صفحات، اس وقت ہم آہنگی کے لیے اس چوکی پر پہنچے۔ اور یہ وہ اہم چیز ہے جو آپ کو یہاں جاننے کی ضرورت ہے۔ ہم دیکھتے ہیں کہ ہمارے یہاں بہت سارے صفحات ہیں اور کسی وقت ہم بورڈ کو مارتے ہیں، یعنی ہم نے لکھا اور لکھا، یہاں ڈسک سسٹم واضح طور پر بہت مصروف ہے۔ اور ہماری چوکی کا ڈسک پر بہت گہرا اثر ہے۔ مثالی طور پر، صورتحال اس طرح کی نظر آنی چاہیے، یعنی ہمارے یہاں ریکارڈنگ کم تھی۔ اور ہم اسے سیٹنگز کے ساتھ ٹھیک کر سکتے ہیں تاکہ یہ اسی طرح چلتا رہے۔ یعنی ری سائیکلنگ چھوٹی ہے لیکن کہیں نہ کہیں ہم یہاں کچھ لکھ رہے ہیں۔

اس مسئلے پر قابو پانے کے لیے کیا کرنے کی ضرورت ہے؟ اگر آپ نے ڈیٹا بیس کے تحت IO کو روک دیا ہے، تو اس کا مطلب ہے کہ تمام صارفین جو اپنی درخواستیں پوری کرنے کے لیے آئے ہیں وہ انتظار کریں گے۔

اگر آپ لینکس کے نقطہ نظر سے دیکھیں تو، اگر آپ نے اچھا ہارڈ ویئر لیا ہے، اسے درست طریقے سے ترتیب دیا ہے، PostgreSQL کو عام طور پر ترتیب دیا ہے تاکہ یہ ان چوکیوں کو کم کثرت سے بنائے، انہیں وقت کے ساتھ ساتھ ایک دوسرے کے درمیان پھیلائے، تو آپ پہلے سے طے شدہ Debian پیرامیٹرز میں قدم رکھتے ہیں۔ لینکس کی زیادہ تر تقسیموں کے لیے، یہ تصویر ہے: vm.dirty_ratio=20، vm.dirty_background_ratio=10۔

اس کا کیا مطلب ہے؟ کرنل 2.6 سے ایک فلشنگ شیطان نمودار ہوا۔ Pdglush، اس بات پر منحصر ہے کہ کون کون سا استعمال کر رہا ہے، جو کرنل بفر سے گندے صفحات کو پس منظر میں ضائع کرنے میں مصروف ہے اور جب گندے صفحات کو ضائع کرنے کی ضرورت ہو تو اس سے کوئی فرق نہیں پڑتا ہے، جب بیک گراؤنڈ کو ضائع کرنے سے کوئی فائدہ نہیں ہوتا ہے۔

پس منظر کب آتا ہے؟ جب سرور پر دستیاب کل RAM کا 10% کرنل بفر میں گندے صفحات پر قبضہ کر لیا جاتا ہے، تو پس منظر میں ایک خصوصی رائٹ آف فنکشن بلایا جاتا ہے۔ پس منظر کیوں ہے؟ پیرامیٹر کے طور پر، یہ اس بات کو مدنظر رکھتا ہے کہ کتنے صفحات لکھنے ہیں۔ اور، ہم کہتے ہیں، وہ N صفحات لکھتا ہے۔ اور تھوڑی دیر کے لیے یہ چیز سو جاتی ہے۔ اور پھر وہ دوبارہ آتی ہے اور کچھ اور صفحات کاپی کرتی ہے۔

یہ ایک انتہائی سادہ کہانی ہے۔ یہاں مسئلہ سوئمنگ پول کی طرح ہے، جب یہ ایک پائپ میں ڈالتا ہے تو دوسرے میں بہہ جاتا ہے۔ ہماری چوکی پہنچ گئی اور اگر اس نے کچھ گندے صفحات کو ضائع کرنے کے لیے بھیج دیا، تو آہستہ آہستہ پوری چیز صاف طور پر کرنل بفر pgflush سے حل ہو جائے گی۔

اگر یہ گندے صفحات جمع ہوتے رہیں تو یہ 20% تک جمع ہو جاتے ہیں، جس کے بعد OS کی ترجیح یہ ہے کہ پوری چیز کو ڈسک پر لکھ دیا جائے، کیونکہ پاور فیل ہو جائے گی اور ہمارے لیے سب کچھ خراب ہو جائے گا۔ مثال کے طور پر ہم یہ ڈیٹا کھو دیں گے۔

چال کیا ہے؟ چال یہ ہے کہ جدید دنیا میں یہ پیرامیٹرز مشین پر موجود کل RAM کا 20 اور 10% ہیں، یہ آپ کے پاس موجود کسی بھی ڈسک سسٹم کے تھرو پٹ کے لحاظ سے بالکل ہی خوفناک ہیں۔

تصور کریں کہ آپ کے پاس 128 جی بی ریم ہے۔ آپ کے ڈسک سسٹم میں 12,8 جی بی آتا ہے۔ اور اس سے کوئی فرق نہیں پڑتا ہے کہ آپ کے پاس وہاں کیا کیش ہے، اس سے کوئی فرق نہیں پڑتا ہے کہ آپ کے پاس کوئی بھی صف ہے، وہ زیادہ دیر تک نہیں چلیں گے۔

لہذا، ہم تجویز کرتے ہیں کہ آپ اپنے RAID کنٹرولر کی صلاحیتوں کی بنیاد پر ان نمبروں کو فوری طور پر ایڈجسٹ کریں۔ میں نے فوری طور پر یہاں ایک ایسے کنٹرولر کے لیے سفارش کی جس کے پاس 512 MB کیشے ہے۔

سب کچھ بہت آسان سمجھا جاتا ہے. آپ بائٹس میں vm.dirty_background ڈال سکتے ہیں۔ اور یہ ترتیبات پچھلے دو کو منسوخ کر دیتی ہیں۔ یا تو تناسب پہلے سے طے شدہ ہے، یا بائٹس والے فعال ہیں، پھر بائٹس والے کام کریں گے۔ لیکن چونکہ میں ڈی بی اے کنسلٹنٹ ہوں اور مختلف کلائنٹس کے ساتھ کام کرتا ہوں، اس لیے میں اسٹرا کھینچنے کی کوشش کرتا ہوں اور اس لیے، اگر بائٹس میں، تو بائٹس میں۔ کسی نے اس بات کی کوئی گارنٹی نہیں دی کہ ایک اچھا ایڈمن سرور میں زیادہ میموری نہیں ڈالے گا، اسے ریبوٹ نہیں کرے گا، اور اعداد و شمار وہی رہیں گے۔ بس ان نمبروں کا حساب لگائیں تاکہ وہاں سب کچھ گارنٹی کے ساتھ فٹ ہو جائے۔

اگر آپ فٹ نہیں ہوتے تو کیا ہوتا ہے؟ میں نے لکھا ہے کہ کسی بھی فلشنگ کو مؤثر طریقے سے روک دیا جاتا ہے، لیکن حقیقت میں یہ تقریر کا ایک پیکر ہے۔ آپریٹنگ سسٹم میں ایک بڑا مسئلہ ہے - اس میں بہت سارے گندے صفحات ہیں، اس لیے آپ کے کلائنٹ جو IO تیار کرتے ہیں اسے مؤثر طریقے سے روک دیا جاتا ہے، یعنی ایپلیکیشن ڈیٹا بیس میں sql استفسار بھیجنے کے لیے آئی ہے، اس کا انتظار کیا جا رہا ہے۔ اس میں کوئی بھی ان پٹ/آؤٹ پٹ سب سے کم ترجیح ہے، کیونکہ ڈیٹا بیس پر ایک چوکی کا قبضہ ہوتا ہے۔ اور وہ کب ختم کرے گی یہ بالکل واضح نہیں ہے۔ اور جب آپ نان بیک گراؤنڈ فلشنگ حاصل کر لیتے ہیں، تو اس کا مطلب ہے کہ آپ کے تمام IO اس پر قابض ہیں۔ اور جب تک یہ ختم نہیں ہوتا، آپ کچھ نہیں کریں گے۔

یہاں دو اور اہم نکات ہیں جو اس رپورٹ کے دائرہ کار سے باہر ہیں۔ یہ ترتیبات postgresql.conf میں موجود ترتیبات سے مماثل ہونی چاہئیں، یعنی چیک پوائنٹس کی ترتیبات۔ اور آپ کا ڈسک سسٹم مناسب طریقے سے ترتیب دیا جانا چاہیے۔ اگر آپ کے پاس RAID پر کیش ہے، تو اس میں بیٹری ہونی چاہیے۔ لوگ بغیر بیٹری کے اچھے کیش کے ساتھ RAID خریدتے ہیں۔ اگر آپ کے پاس RAID میں SSDs ہیں، تو وہ سرور والے ہونے چاہئیں، وہاں capacitors ہونا چاہیے۔ یہاں ایک تفصیلی چیک لسٹ ہے۔ اس لنک میں پوسٹگری ایس کیو ایل میں پرفارمنس ڈسک کو کنفیگر کرنے کے بارے میں میری رپورٹ شامل ہے۔ وہاں یہ تمام چیک لسٹ موجود ہیں۔

زندگی کو اور کیا مشکل بنا سکتا ہے؟ یہ دو پیرامیٹرز ہیں۔ وہ نسبتاً نئے ہیں۔ پہلے سے طے شدہ طور پر، انہیں مختلف ایپلی کیشنز میں شامل کیا جا سکتا ہے۔ اور اگر وہ غلط طریقے سے آن کر دیے جائیں تو وہ زندگی کو اتنا ہی مشکل بنا سکتے ہیں۔

دو نسبتاً نئی چیزیں ہیں۔ وہ پہلے ہی تیسرے کور میں نمودار ہو چکے ہیں۔ یہ sched_migration_cost ہے nanoseconds میں اور sched_autogroup_enabled، جو پہلے سے طے شدہ ہے۔

اور وہ آپ کی زندگی کیسے برباد کرتے ہیں؟ شیڈول_مائیگریشن_کاسٹ کیا ہے؟ لینکس پر، شیڈیولر ایک پروسیس کو ایک سی پی یو سے دوسرے میں منتقل کر سکتا ہے۔ اور PostgreSQL کے لیے، جو سوالات کو انجام دیتا ہے، دوسرے CPU میں منتقل ہونا مکمل طور پر غیر واضح ہے۔ آپریٹنگ سسٹم کے نقطہ نظر سے، جب آپ اوپن آفس اور ٹرمینل کے درمیان ونڈوز سوئچ کرتے ہیں، تو یہ اچھا ہو سکتا ہے، لیکن ڈیٹا بیس کے لیے یہ بہت برا ہے۔ لہذا، ایک معقول پالیسی یہ ہے کہ migration_cost کو کچھ بڑی قدر، کم از کم کئی ہزار نانو سیکنڈز پر سیٹ کیا جائے۔

شیڈولر کے لیے اس کا کیا مطلب ہوگا؟ یہ غور کیا جائے گا کہ اس وقت کے دوران عمل اب بھی گرم ہے. یعنی، اگر آپ کے پاس ایک طویل عرصے سے چلنے والا لین دین ہے جو طویل عرصے سے کچھ کر رہا ہے، تو شیڈولر اس کو سمجھے گا۔ وہ سمجھے گا کہ جب تک یہ ٹائم آؤٹ نہیں گزر جاتا، اس عمل کو کہیں بھی منتقل کرنے کی ضرورت نہیں ہے۔ اگر ایک ہی وقت میں عمل کچھ کرتا ہے، تو اسے کہیں بھی منتقل نہیں کیا جائے گا، یہ خاموشی سے اس CPU پر کام کرے گا جو اسے مختص کیا گیا تھا۔ اور نتیجہ بہترین ہے۔

دوسرا نکتہ آٹو گروپ ہے۔ مخصوص کام کے بوجھ کے لیے ایک اچھا خیال ہے جو جدید ڈیٹا بیس سے متعلق نہیں ہیں - یہ اس ورچوئل ٹرمینل کے ذریعے گروپ پروسیس کے لیے ہے جہاں سے وہ لانچ کیے گئے ہیں۔ یہ کچھ کاموں کے لیے آسان ہے۔ عملی طور پر، PostgreSQL ایک ملٹی پروسیس سسٹم ہے جس میں ایک پریفورک ہے جو ایک ہی ٹرمینل سے چلتا ہے۔ آپ کے پاس ایک لاک رائٹر، چیک پوائنٹ ہے، اور آپ کی تمام کلائنٹ کی درخواستوں کو فی CPU، ایک شیڈولر میں گروپ کیا جائے گا۔ اور وہ وہاں متحد ہو کر اس کے آزاد ہونے کا انتظار کریں گے، تاکہ ایک دوسرے کے ساتھ مداخلت کریں اور اسے زیادہ دیر تک مصروف رکھیں۔ یہ ایک ایسی کہانی ہے جو اس طرح کے بوجھ کے معاملے میں مکمل طور پر غیر ضروری ہے اس لیے اسے بند کرنے کی ضرورت ہے۔

میرے ساتھی Alexey Lesovsky نے ایک سادہ pgbench کے ساتھ ٹیسٹ کیے، جہاں اس نے migration_cost کو ایک ترتیب سے بڑھایا اور آٹو گروپ کو بند کر دیا۔ خراب ہارڈ ویئر پر فرق تقریباً 10 فیصد تھا. پوسٹگریس میلنگ لسٹ پر ایک بحث ہے جہاں لوگ استفسار کی رفتار میں اسی طرح کی تبدیلیوں کے نتائج دیتے ہیں۔ متاثر 50%. ایسی کہانیاں بہت ہیں۔

اور آخر میں، بجلی کی بچت کی پالیسی کے بارے میں۔ اچھی بات یہ ہے کہ لینکس اب لیپ ٹاپ پر استعمال کیا جا سکتا ہے۔ اور یہ قیاس کیا جاتا ہے کہ بیٹری اچھی طرح استعمال کرے گی۔ لیکن اچانک پتہ چلا کہ یہ سرور پر بھی ہو سکتا ہے۔

مزید یہ کہ، اگر آپ کسی میزبان سے سرور کرایہ پر لیتے ہیں، تو "اچھے" میزبانوں کو اس بات کی پرواہ نہیں ہے کہ آپ کی کارکردگی بہتر ہے۔ ان کا کام اس بات کو یقینی بنانا ہے کہ ان کے لوہے کو زیادہ سے زیادہ مؤثر طریقے سے استعمال کیا جائے۔ لہذا، پہلے سے طے شدہ طور پر وہ آپریٹنگ سسٹم پر لیپ ٹاپ پاور سیونگ موڈ کو فعال کر سکتے ہیں۔

اگر آپ اس چیز کو سرور پر ڈیٹا بیس کے ساتھ بھاری بوجھ میں استعمال کرتے ہیں، تو آپ کا انتخاب acpi_cpufreq + permormance ہے۔ آن ڈیمانڈ کے ساتھ بھی مسائل ہوں گے۔

Intel_pstate تھوڑا مختلف ڈرائیور ہے۔ اور اب اس کو ترجیح دی جاتی ہے، جیسا کہ یہ بعد میں ہے اور بہتر کام کرتا ہے۔

اور، اس کے مطابق، گورنر صرف کارکردگی ہے. آنڈیمانڈ، پاور سیو اور باقی سب کچھ آپ کے بارے میں نہیں ہے۔

اگر آپ پاور سیو کو فعال کرتے ہیں تو وضاحتی تجزیہ PostgreSQL کے نتائج مختلف ہو سکتے ہیں، کیونکہ عملی طور پر آپ کے ڈیٹا بیس کے تحت CPU مکمل طور پر غیر متوقع طریقے سے چل رہا ہو گا۔

یہ آئٹمز بطور ڈیفالٹ شامل ہو سکتے ہیں۔ غور سے دیکھیں کہ آیا انہوں نے اسے بطور ڈیفالٹ آن کیا ہے۔ یہ واقعی ایک بڑا مسئلہ ہوسکتا ہے۔

اور آخر میں، میں ہماری PosgreSQL-Consulting DBA ٹیم کے لڑکوں کا شکریہ کہنا چاہتا ہوں، یعنی میکس بوگوک اور الیکسی لیسوفسکی، جو اس معاملے میں ہر روز آگے بڑھ رہے ہیں۔ اور ہم اپنے کلائنٹس کے لیے ہر ممکن کوشش کرنے کی کوشش کرتے ہیں تاکہ یہ سب ان کے لیے کام آئے۔ یہ ہوا بازی کی حفاظت کی ہدایات کی طرح ہے۔ یہاں سب کچھ خون سے لکھا ہوا ہے۔ ان میں سے ہر ایک گری دار میوے کسی نہ کسی مسئلے کے عمل میں پایا جاتا ہے۔ میں آپ کے ساتھ ان کا اشتراک کرنے کے لئے خوش ہوں.

سوالات:

شکریہ! اگر، مثال کے طور پر، کوئی کمپنی پیسہ بچانا چاہتی ہے اور ڈیٹا بیس اور ایپلیکیشن منطق کو ایک سرور پر رکھنا چاہتی ہے، یا اگر کمپنی مائیکرو سروس آرکیٹیکچرز کے فیشن کے رجحان کی پیروی کرتی ہے، جس میں PostgreSQL کنٹینر میں چلتا ہے۔ چال کیا ہے؟ Sysctl عالمی سطح پر پورے دانا کو متاثر کرے گا۔ میں نے sysctls کو کسی طرح سے ورچوئلائز ہونے کے بارے میں نہیں سنا ہے تاکہ وہ کنٹینر پر الگ سے کام کریں۔ وہاں صرف ایک سی گروپ ہے اور وہاں کنٹرول کا صرف ایک حصہ ہے۔ آپ اس کے ساتھ کیسے رہ سکتے ہیں؟ یا اگر آپ کارکردگی چاہتے ہیں، تو پوسٹگری ایس کیو ایل کو علیحدہ ہارڈ ویئر سرور پر چلائیں اور اسے ٹیون کریں؟

ہم نے آپ کے سوال کا جواب تقریباً تین طریقوں سے دیا۔ اگر ہم کسی ہارڈ ویئر سرور کے بارے میں بات نہیں کر رہے ہیں جسے ٹیون کیا جا سکتا ہے، وغیرہ، تو آرام کریں، ان سیٹنگز کے بغیر سب کچھ ٹھیک ہو جائے گا۔ اگر آپ کے پاس اتنا بوجھ ہے کہ آپ کو یہ ترتیبات بنانے کی ضرورت ہے، تو آپ ان ترتیبات سے پہلے آئرن سرور پر آجائیں گے۔

مسئلہ کیا ہے؟ اگر یہ ایک ورچوئل مشین ہے، تو غالباً آپ کو بہت سی پریشانیوں کا سامنا کرنا پڑے گا، مثال کے طور پر، اس حقیقت کے ساتھ کہ زیادہ تر ورچوئل مشینوں پر ڈسک کی لیٹنسی کافی متضاد ہے۔ یہاں تک کہ اگر ڈسک کا تھرو پٹ اچھا ہے، تب بھی ایک ناکام I/O ٹرانزیکشن جو چیک پوائنٹ کے وقت یا WAL کو لکھنے کے وقت ہوا اوسط تھرو پٹ کو زیادہ متاثر نہیں کرتا ہے، تب ڈیٹا بیس کو اس سے بہت نقصان پہنچے گا۔ اور آپ کو ان مسائل سے دوچار ہونے سے پہلے یہ محسوس ہوگا۔

اگر آپ کے پاس ایک ہی سرور پر NGINX ہے تو آپ کو بھی یہی مسئلہ درپیش ہوگا۔ وہ مشترکہ یادداشت کے لیے لڑے گا۔ اور آپ یہاں بیان کردہ مسائل تک نہیں پہنچ پائیں گے۔

لیکن دوسری طرف، ان میں سے کچھ پیرامیٹرز اب بھی آپ کے لیے متعلقہ ہوں گے۔ مثال کے طور پر، sysctl کے ساتھ dirty_ratio سیٹ کریں تاکہ یہ اتنا پاگل نہ ہو - کسی بھی صورت میں، اس سے مدد ملے گی۔ کسی نہ کسی طرح، آپ کا ڈسک کے ساتھ تعامل ہوگا۔ اور یہ غلط پیٹرن کے مطابق ہوگا۔ یہ عام طور پر ان پیرامیٹرز کے لیے ڈیفالٹ ہوتا ہے جو میں نے دکھائے۔ اور کسی بھی صورت میں ان کو تبدیل کرنا بہتر ہے۔

لیکن NUMA کے ساتھ مسائل ہو سکتے ہیں۔ VmWare، مثال کے طور پر، بالکل مخالف ترتیبات کے ساتھ NUMA کے ساتھ اچھی طرح کام کرتا ہے۔ اور یہاں آپ کو انتخاب کرنا ہوگا - لوہے کا سرور یا غیر آئرن سرور۔

میرے پاس Amazon AWS سے متعلق ایک سوال ہے۔ ان کی تصاویر پہلے سے ترتیب دی گئی ہیں۔ ان میں سے ایک Amazon RDS کہلاتا ہے۔ کیا ان کے آپریٹنگ سسٹم کے لیے کوئی کسٹم سیٹنگز ہیں؟

وہاں ترتیبات ہیں، لیکن وہ مختلف ترتیبات ہیں. یہاں ہم آپریٹنگ سسٹم کو اس لحاظ سے ترتیب دیتے ہیں کہ ڈیٹا بیس اس چیز کو کس طرح استعمال کرے گا۔ اور ایسے پیرامیٹرز ہیں جو اس بات کا تعین کرتے ہیں کہ ہمیں اب کہاں جانا چاہیے، جیسے کہ شکل دینا۔ یعنی ہمیں اتنے وسائل کی ضرورت ہے، اب ہم انہیں کھا جائیں گے۔ اس کے بعد، ایمیزون آر ڈی ایس ان وسائل کو سخت کرتا ہے، اور کارکردگی وہاں گر جاتی ہے۔ اس کی انفرادی کہانیاں ہیں کہ لوگ اس معاملے میں کس طرح گڑبڑ کرنا شروع کر رہے ہیں۔ کبھی کبھی کافی کامیابی سے بھی۔ لیکن اس کا OS کی ترتیبات سے کوئی تعلق نہیں ہے۔ یہ بادل کو ہیک کرنے جیسا ہے۔ وہ الگ کہانی ہے۔

ہیو ٹی ایل بی کے مقابلے شفاف بڑے صفحات کا کوئی اثر کیوں نہیں ہوتا؟

مت دینا. اس کی وضاحت کئی طریقوں سے کی جا سکتی ہے۔ لیکن حقیقت میں وہ اسے نہیں دیتے۔ PostgreSQL کی تاریخ کیا ہے؟ آغاز پر، یہ مشترکہ میموری کا ایک بڑا ٹکڑا مختص کرتا ہے۔ آیا وہ شفاف ہیں یا نہیں یہ مکمل طور پر غیر متعلق ہے۔ حقیقت یہ ہے کہ وہ شروع میں کھڑے ہیں ہر چیز کی وضاحت کرتا ہے۔ اور اگر بہت زیادہ میموری ہے اور آپ کو شیئرڈ_میموری سیگمنٹ کو دوبارہ بنانے کی ضرورت ہے، تو شفاف بڑے صفحات متعلقہ ہوں گے۔ PostgreSQL میں، اسے شروع میں ہی ایک بہت بڑا حصہ مختص کیا جاتا ہے اور بس، اور پھر وہاں کچھ خاص نہیں ہوتا ہے۔ آپ یقیناً اسے استعمال کر سکتے ہیں، لیکن شیئرڈ_میموری کے خراب ہونے کا امکان ہے جب یہ کسی چیز کو دوبارہ مختص کرتا ہے۔ PostgreSQL اس کے بارے میں نہیں جانتا ہے۔

ماخذ: www.habr.com