الیکسی لیسوفسکی کی 2015 کی رپورٹ کا ٹرانسکرپٹ "پوسٹگری ایس کیو ایل کے اندرونی اعدادوشمار میں گہرا غوطہ لگانا"
رپورٹ کے مصنف کی طرف سے دستبرداری: میں نوٹ کرتا ہوں کہ یہ رپورٹ نومبر 2015 کی ہے - 4 سال سے زیادہ گزر چکے ہیں اور کافی وقت گزر چکا ہے۔ رپورٹ میں زیر بحث ورژن 9.4 اب تعاون یافتہ نہیں ہے۔ گزشتہ 4 سالوں کے دوران 5 نئی ریلیز جاری کی گئی ہیں جن میں اعداد و شمار کے حوالے سے بہت سی جدتیں، بہتری اور تبدیلیاں کی گئی ہیں اور کچھ مواد پرانا اور متعلقہ نہیں ہے۔ جیسا کہ میں نے جائزہ لیا، میں نے ان جگہوں کو نشان زد کرنے کی کوشش کی تاکہ قاری کو گمراہ نہ کیا جائے۔ میں نے ان اقتباسات کو دوبارہ نہیں لکھا، ان میں سے بہت سارے ہیں اور نتیجہ بالکل مختلف رپورٹ ہوگا۔
PostgreSQL DBMS ایک بہت بڑا میکانزم ہے، اور یہ میکانزم بہت سے سب سسٹمز پر مشتمل ہے، جس کا مربوط آپریشن براہ راست DBMS کی کارکردگی کو متاثر کرتا ہے۔ آپریشن کے دوران، اجزاء کے آپریشن کے بارے میں اعداد و شمار اور معلومات جمع کی جاتی ہیں، جو آپ کو PostgreSQL کی تاثیر کا جائزہ لینے اور کارکردگی کو بہتر بنانے کے لیے اقدامات کرنے کی اجازت دیتی ہیں۔ تاہم، اس میں بہت ساری معلومات موجود ہیں اور اسے کافی آسان شکل میں پیش کیا گیا ہے۔ اس معلومات پر کارروائی کرنا اور اس کی ترجمانی کرنا بعض اوقات ایک مکمل طور پر غیر معمولی کام ہوتا ہے، اور ٹولز اور یوٹیلیٹیز کا "چڑیا گھر" ایک جدید ڈی بی اے کو بھی آسانی سے الجھا سکتا ہے۔
صبح بخیر میرا نام الیکسی ہے۔ جیسا کہ الیا نے کہا، میں PostgreSQL کے اعدادوشمار کے بارے میں بات کروں گا۔
PostgreSQL سرگرمی کے اعدادوشمار۔ PostgreSQL کے دو اعدادوشمار ہیں۔ سرگرمی کے اعدادوشمار جن پر تبادلہ خیال کیا جائے گا۔ اور ڈیٹا کی تقسیم کے بارے میں شیڈولر کے اعدادوشمار۔ میں خاص طور پر PostgreSQL سرگرمی کے اعدادوشمار کے بارے میں بات کروں گا، جو ہمیں کارکردگی کا اندازہ لگانے اور اسے بہتر بنانے کی اجازت دیتے ہیں۔
میں آپ کو بتاؤں گا کہ آپ کو درپیش مختلف مسائل کو حل کرنے کے لیے اعدادوشمار کو مؤثر طریقے سے کیسے استعمال کیا جائے۔
رپورٹ میں کیا نہیں ہوگا؟ رپورٹ میں میں شیڈولر کے اعدادوشمار پر ہاتھ نہیں ڈالوں گا، کیونکہ... ڈیٹا بیس میں ڈیٹا کو کیسے ذخیرہ کیا جاتا ہے اور استفسار کے منصوبہ ساز کو اس ڈیٹا کی کوالٹیٹیو اور مقداری خصوصیات کا اندازہ کیسے آتا ہے اس پر ایک علیحدہ رپورٹ کے لیے یہ ایک الگ موضوع ہے۔
اور کوئی ٹول ریویو نہیں ہوگا، میں ایک پروڈکٹ کا دوسرے سے موازنہ نہیں کروں گا۔ کوئی اشتہار نہیں ہوگا۔ آئیے اسے ایک طرف رکھتے ہیں۔
میں آپ کو دکھانا چاہتا ہوں کہ شماریات کا استعمال مفید ہے۔ یہ ضروری ہے. یہ استعمال کرنا محفوظ ہے۔ ہمیں صرف باقاعدہ SQL اور SQL کے بنیادی علم کی ضرورت ہے۔
اور آئیے اس بارے میں بات کرتے ہیں کہ مسائل کو حل کرنے کے لیے کن اعدادوشمار کا انتخاب کرنا ہے۔
اگر ہم PostgreSQL کو دیکھیں اور عمل کو دیکھنے کے لیے آپریٹنگ سسٹم پر کمانڈ چلائیں تو ہمیں ایک "بلیک باکس" نظر آئے گا۔ ہم کچھ ایسے عمل دیکھیں گے جو کچھ کر رہے ہیں، اور نام سے ہم تقریباً اندازہ لگا سکتے ہیں کہ وہ وہاں کیا کر رہے ہیں، کیا کر رہے ہیں۔ لیکن، جوہر میں، یہ ایک بلیک باکس ہے؛ ہم اندر نہیں دیکھ سکتے۔
ہم CPU لوڈ کو دیکھ سکتے ہیں۔ top، ہم کچھ سسٹم یوٹیلیٹیز کے ذریعہ میموری کے استعمال کو دیکھ سکتے ہیں، لیکن ہم PostgreSQL کے اندر نہیں دیکھ پائیں گے۔ اس کے لیے ہمیں دوسرے ٹولز کی ضرورت ہے۔
اور آگے چل کر بتاؤں گا کہ وقت کہاں گزارا ہے۔ اگر ہم PostgreSQL کو اس طرح کے خاکے کی شکل میں تصور کریں، تو ہم جواب دے سکتے ہیں کہ وقت کہاں گزارا ہے۔ یہ دو چیزیں ہیں: یہ ایپلی کیشنز سے کلائنٹ کی درخواستوں اور پس منظر کے کاموں پر کارروائی کر رہا ہے جو PostgreSQL خود کو چلانے کے لیے انجام دیتا ہے۔
اگر ہم اوپر بائیں کونے کو دیکھنا شروع کرتے ہیں، تو ہم دیکھ سکتے ہیں کہ کلائنٹ کی درخواستوں پر کیسے عمل ہوتا ہے۔ درخواست درخواست سے آتی ہے اور مزید کام کے لیے کلائنٹ سیشن کھولا جاتا ہے۔ درخواست شیڈولر کو بھیجی جاتی ہے۔ شیڈیولر ایک سوال کا منصوبہ بناتا ہے۔ پھانسی کے لیے مزید بھیجتا ہے۔ جدولوں اور اشاریہ جات سے وابستہ کسی قسم کا بلاک ڈیٹا ان پٹ/آؤٹ پٹ ہے۔ ضروری ڈیٹا کو ڈسک سے میموری میں ایک خاص علاقے "مشترکہ بفرز" میں پڑھا جاتا ہے۔ درخواست کے نتائج، اگر وہ اپ ڈیٹس، ڈیلیٹس ہیں، WAL میں ٹرانزیکشن لاگ میں ریکارڈ کیے جاتے ہیں۔ کچھ شماریاتی معلومات لاگ یا شماریات جمع کرنے والے میں ختم ہوتی ہیں۔ اور درخواست کا نتیجہ کلائنٹ کو واپس بھیج دیا جاتا ہے۔ جس کے بعد کلائنٹ ایک نئی درخواست کے ساتھ ہر چیز کو دوبارہ دہرا سکتا ہے۔
پس منظر کے کاموں اور پس منظر کے عمل کے بارے میں کیا خیال ہے؟ ہمارے پاس کئی ایسے عمل ہیں جو ڈیٹا بیس کو عام آپریٹنگ موڈ میں چلاتے رہتے ہیں۔ رپورٹ میں ان عملوں پر بھی توجہ دی جائے گی: آٹو ویکیوم، چیک پوائنٹر، نقل سے متعلق عمل، پس منظر لکھنے والا۔ میں رپورٹ کرتے وقت ان میں سے ہر ایک کو چھووں گا۔
اعداد و شمار کے ساتھ کیا مسائل ہیں؟
- بہت ساری معلومات ہیں۔ PostgreSQL 9.4 اعداد و شمار کے ڈیٹا کو دیکھنے کے لیے 109 میٹرکس فراہم کرتا ہے۔ تاہم، اگر ڈیٹا بیس بہت سے ٹیبلز، اسکیموں، ڈیٹا بیسز کو اسٹور کرتا ہے، تو ان تمام میٹرکس کو ٹیبلز، ڈیٹا بیس کی متعلقہ تعداد سے ضرب دینا ہوگا۔ یعنی اس سے بھی زیادہ معلومات ہیں۔ اور اس میں ڈوبنا بہت آسان ہے۔
- اگلا مسئلہ یہ ہے کہ شماریات کی نمائندگی کاؤنٹرز کے ذریعے کی جاتی ہے۔ اگر ہم ان اعدادوشمار پر نظر ڈالیں تو ہم مسلسل بڑھتے ہوئے کاؤنٹر دیکھیں گے۔ اور اگر اعدادوشمار کو دوبارہ ترتیب دینے کے بعد کافی وقت گزر چکا ہے، تو ہم قدریں اربوں میں دیکھیں گے۔ اور وہ ہمیں کچھ نہیں بتاتے۔
- کوئی کہانی نہیں۔ اگر آپ کو کسی قسم کی ناکامی ہوئی ہے، کوئی چیز 15-30 منٹ پہلے گر گئی تھی، تو آپ اعداد و شمار استعمال کرنے کے قابل نہیں ہوں گے اور یہ نہیں دیکھ سکیں گے کہ 15-30 منٹ پہلے کیا ہوا تھا۔ یہ مسئلہ ہے۔
- PostgreSQL میں بنائے گئے ٹول کی کمی ایک مسئلہ ہے۔ کرنل ڈویلپرز کوئی افادیت فراہم نہیں کرتے ہیں۔ ان کے پاس ایسا کچھ نہیں ہے۔ وہ صرف ڈیٹا بیس میں اعدادوشمار فراہم کرتے ہیں۔ اسے استعمال کرو، اس سے درخواست کرو، جو چاہو کرو۔
- چونکہ PostgreSQL میں کوئی ٹول نہیں بنایا گیا ہے، اس لیے یہ ایک اور مسئلہ پیدا کرتا ہے۔ تھرڈ پارٹی ٹولز کے بہت سارے۔ ہر کمپنی جس کے کم و بیش براہ راست ہاتھ ہیں وہ اپنا پروگرام لکھنے کی کوشش کر رہی ہے۔ اور نتیجے کے طور پر، کمیونٹی کے پاس بہت سارے ٹولز ہیں جو اعداد و شمار کے ساتھ کام کرنے کے لیے استعمال کیے جا سکتے ہیں۔ اور کچھ ٹولز میں کچھ صلاحیتیں ہوتی ہیں، دوسرے ٹولز میں دوسری صلاحیتیں نہیں ہوتیں، یا کچھ نئی صلاحیتیں ہوتی ہیں۔ اور ایسی صورت حال پیدا ہوتی ہے کہ آپ کو دو، تین یا چار ٹولز استعمال کرنے کی ضرورت ہوتی ہے جو ایک دوسرے کو اوورلیپ کرتے ہیں اور مختلف افعال رکھتے ہیں۔ یہ بہت ناگوار بات ہے۔
اس سے کیا ہوتا ہے؟ براہ راست اعدادوشمار لینے کے قابل ہونا ضروری ہے، تاکہ پروگراموں پر انحصار نہ کریں، یا کسی طرح خود ان پروگراموں کو بہتر بنائیں: اپنا فائدہ حاصل کرنے کے لیے کچھ فنکشنز شامل کریں۔
اور آپ کو SQL کا بنیادی علم درکار ہے۔ اعداد و شمار سے کچھ ڈیٹا حاصل کرنے کے لیے، آپ کو ایس کیو ایل کے سوالات بنانے کی ضرورت ہے، یعنی آپ کو یہ جاننا ہوگا کہ سلیکٹ اور جوائن کیسے مرتب کیے جاتے ہیں۔
اعداد و شمار ہمیں کئی چیزیں بتاتے ہیں۔ انہیں زمروں میں تقسیم کیا جا سکتا ہے۔
- پہلی قسم ڈیٹا بیس میں ہونے والے واقعات ہیں۔ یہ تب ہوتا ہے جب ڈیٹا بیس میں کچھ واقعہ ہوتا ہے: ایک درخواست، میز تک رسائی، آٹو ویکیوم، کمٹ، پھر یہ سب واقعات ہیں۔ ان واقعات سے متعلقہ کاؤنٹرز میں اضافہ کیا گیا ہے۔ اور ہم ان واقعات کو ٹریک کرسکتے ہیں۔
- دوسری قسم اشیاء کی خصوصیات ہیں جیسے میزیں اور ڈیٹا بیس۔ ان کے پاس خواص ہیں۔ یہ میزوں کا سائز ہے۔ ہم میزوں کی نمو اور اشاریہ جات کی نمو کو ٹریک کر سکتے ہیں۔ ہم حرکیات میں تبدیلیاں دیکھ سکتے ہیں۔
- اور تیسری قسم تقریب پر گزارا ہوا وقت ہے۔ ایک درخواست ایک واقعہ ہے۔ اس کی مدت کا اپنا مخصوص پیمانہ ہے۔ یہاں سے شروع ہوا، یہیں ختم ہوا۔ ہم اسے ٹریک کر سکتے ہیں۔ یا تو ڈسک سے بلاک کو پڑھنے یا لکھنے میں جتنا وقت لگتا ہے۔ ایسی چیزوں کا سراغ بھی لگایا جاتا ہے۔
اعداد و شمار کے ذرائع درج ذیل ہیں:
- مشترکہ میموری (مشترکہ بفرز) میں جامد ڈیٹا کو ذخیرہ کرنے کے لیے ایک سیگمنٹ ہوتا ہے، ایسے کاؤنٹرز بھی ہوتے ہیں جن میں مسلسل اضافہ ہوتا ہے جب کچھ واقعات رونما ہوتے ہیں، یا ڈیٹا بیس کے آپریشن میں کچھ لمحات پیدا ہوتے ہیں۔
- یہ تمام کاؤنٹرز صارف کے لیے قابل رسائی نہیں ہیں اور منتظم کے لیے بھی قابل رسائی نہیں ہیں۔ یہ کم درجے کی چیزیں ہیں۔ ان تک رسائی کے لیے، PostgreSQL SQL فنکشنز کی شکل میں ایک انٹرفیس فراہم کرتا ہے۔ ہم ان فنکشنز کا استعمال کرتے ہوئے سلیکٹ تھرو بنا سکتے ہیں اور کسی قسم کی میٹرک (یا میٹرکس کا سیٹ) حاصل کر سکتے ہیں۔
- تاہم، ان فنکشنز کا استعمال ہمیشہ آسان نہیں ہوتا، لہذا فنکشنز ویوز (VIEWs) کی بنیاد ہیں۔ یہ ورچوئل ٹیبلز ہیں جو ایک مخصوص سب سسٹم پر یا ڈیٹا بیس میں واقعات کے مخصوص سیٹ پر اعداد و شمار فراہم کرتی ہیں۔
- یہ ایمبیڈڈ ویوز (VIEWs) اعداد و شمار کے ساتھ کام کرنے کے لیے بنیادی یوزر انٹرفیس ہیں۔ وہ بغیر کسی اضافی ترتیبات کے بطور ڈیفالٹ دستیاب ہیں، آپ انہیں فوری طور پر استعمال کر سکتے ہیں، انہیں دیکھ سکتے ہیں اور ان سے معلومات لے سکتے ہیں۔ اور پھر شراکتیں ہیں۔ شراکتیں سرکاری ہیں۔ آپ postgresql-contrib پیکیج انسٹال کر سکتے ہیں (مثال کے طور پر، postgresql94-contrib)، کنفیگریشن میں مطلوبہ ماڈیول لوڈ کر سکتے ہیں، اس کے لیے پیرامیٹرز بتا سکتے ہیں، PostgreSQL کو دوبارہ شروع کر سکتے ہیں اور آپ اسے استعمال کر سکتے ہیں۔ (نوٹ. تقسیم پر منحصر ہے، حالیہ ورژنز میں کنٹریب پیکج مرکزی پیکج کا حصہ ہے۔).
- اور غیر سرکاری شراکتیں ہیں۔ وہ معیاری PostgreSQL تقسیم میں شامل نہیں ہیں۔ انہیں یا تو مرتب کیا جانا چاہیے یا لائبریری کے طور پر انسٹال کیا جانا چاہیے۔ اختیارات بہت مختلف ہو سکتے ہیں، اس بات پر منحصر ہے کہ اس غیر سرکاری شراکت کا ڈویلپر کیا لے کر آیا ہے۔
یہ سلائیڈ ان تمام VIEWs اور کچھ فنکشنز کو پیش کرتی ہے جو PostgreSQL 9.4 میں دستیاب ہیں۔ جیسا کہ ہم دیکھتے ہیں، ان میں سے بہت سے ہیں. اور اگر آپ پہلی بار اس کا سامنا کرتے ہیں تو الجھن میں پڑنا بہت آسان ہے۔
تاہم، اگر ہم پچھلی تصویر لیں Как тратится время на PostgreSQL اور اس فہرست کے ساتھ ہم آہنگ، ہمیں یہ تصویر ملتی ہے۔ جب PostgreSQL چل رہا ہو تو ہم متعلقہ اعداد و شمار حاصل کرنے کے لیے ہر ایک منظر (VIEWs) یا ہر فنکشن کو کسی نہ کسی مقصد کے لیے استعمال کر سکتے ہیں۔ اور ہم سب سسٹم کے آپریشن کے بارے میں پہلے ہی کچھ معلومات حاصل کر سکتے ہیں۔
پہلی چیز جس پر ہم غور کریں گے۔ pg_stat_database. جیسا کہ ہم دیکھ سکتے ہیں، یہ ایک کارکردگی ہے۔ اس میں بہت سی معلومات ہیں۔ انتہائی متنوع معلومات۔ اور یہ ہمارے ڈیٹا بیس میں کیا ہو رہا ہے اس کے بارے میں بہت مفید معلومات فراہم کرتا ہے۔
ہم وہاں سے کون سی مفید چیزیں لے سکتے ہیں؟ آئیے سب سے آسان چیزوں کے ساتھ شروع کریں۔
select
sum(blks_hit)*100/sum(blks_hit+blks_read) as hit_ratio
from pg_stat_database;پہلی چیز جسے ہم دیکھ سکتے ہیں وہ ہے کیشے ہٹ فیصد۔ کیش ہٹ ریٹ ایک مفید میٹرک ہے۔ یہ آپ کو اندازہ لگانے کی اجازت دیتا ہے کہ مشترکہ بفرز کیشے سے کتنا ڈیٹا لیا جاتا ہے اور ڈسک سے کتنا پڑھا جاتا ہے۔
یہ واضح ہے کہ ہمارے پاس جتنے زیادہ کیش ہٹ ہوں گے، اتنا ہی بہتر ہے۔. ہم اس میٹرک کی پیمائش فیصد کے طور پر کرتے ہیں۔ اور، مثال کے طور پر، اگر ہماری ان کیش ہٹس کا فیصد 90% سے زیادہ ہے، تو یہ اچھی بات ہے۔ اگر یہ 90% سے نیچے گر جاتا ہے، تو اس کا مطلب ہے کہ ہمارے پاس اتنی میموری نہیں ہے کہ ہم ڈیٹا کے گرم سر کو میموری میں رکھیں۔ اور اس ڈیٹا کو استعمال کرنے کے لیے، PostgreSQL کو ڈسک تک رسائی حاصل کرنے پر مجبور کیا جاتا ہے اور یہ اس سے سست ہے اگر ڈیٹا کو میموری سے پڑھا گیا ہو۔ اور آپ کو میموری کو بڑھانے کے بارے میں سوچنے کی ضرورت ہے: یا تو مشترکہ بفرز میں اضافہ کریں، یا ہارڈویئر میموری (RAM) میں اضافہ کریں۔
select
datname,
(xact_commit*100)/(xact_commit+xact_rollback) as c_ratio,
deadlocks, conflicts,
temp_file, pg_size_pretty(temp_bytes) as temp_size
from pg_stat_database;آپ اس کارکردگی سے اور کیا لے سکتے ہیں؟ آپ ڈیٹا بیس میں ہونے والی بے ضابطگیوں کو دیکھ سکتے ہیں۔ یہاں کیا دکھایا گیا ہے؟ کمٹ، رول بیکس، عارضی فائلوں کی تخلیق، ان کا سائز، تعطل اور تنازعات ہیں۔
ہم اس درخواست کو استعمال کر سکتے ہیں۔ یہ SQL بہت آسان ہے۔ اور ہم یہاں اس ڈیٹا کو دیکھ سکتے ہیں۔
اور یہاں حد کی قدریں ہیں۔ ہم کمٹ اور رول بیکس کے تناسب کو دیکھتے ہیں۔ کمٹ ایک لین دین کی کامیاب تصدیق ہے۔ رول بیکس ایک رول بیک ہیں، یعنی ایک ٹرانزیکشن نے کچھ کام کیا، ڈیٹا بیس کو تنگ کیا، کچھ کا حساب لگایا، اور پھر ناکامی واقع ہوئی اور لین دین کے نتائج کو ضائع کر دیا گیا۔ یہ ہے کہ رول بیکس کی تعداد میں مسلسل اضافہ برا ہے۔ اور آپ کو کسی نہ کسی طرح ان سے بچنا چاہئے، اور کوڈ میں ترمیم کرنا چاہئے تاکہ ایسا نہ ہو۔
تنازعات نقل سے متعلق ہیں۔ اور ان سے بھی بچنا چاہیے۔ اگر آپ کے پاس کچھ سوالات ہیں جو نقل پر عمل میں آتے ہیں اور تنازعات پیدا ہوتے ہیں، تو آپ کو ان تنازعات کو حل کرنے اور یہ دیکھنے کی ضرورت ہے کہ کیا ہو رہا ہے۔ تفصیلات نوشتہ جات میں مل سکتی ہیں۔ اور تنازعات کے حالات کو ختم کریں تاکہ درخواست کی درخواستیں بغیر کسی غلطی کے کام کریں۔
تعطل کا بھی برا حال ہے۔ جب درخواستیں وسائل کے لیے لڑ رہی ہوں تو، ایک درخواست نے ایک وسیلہ تک رسائی حاصل کی اور تالا لے لیا، دوسری درخواست نے دوسرے وسائل تک رسائی حاصل کی اور تالا بھی لے لیا، اور پھر دونوں درخواستوں نے ایک دوسرے کے وسائل تک رسائی حاصل کی اور پڑوسی کے تالے کے جاری ہونے کا انتظار کرتے ہوئے بلاک کر دیا۔ یہ بھی ایک پریشانی کی صورت حال ہے۔ انہیں ایپلی کیشنز کو دوبارہ لکھنے اور وسائل تک رسائی کو سیریلائز کرنے کی سطح پر حل کرنے کی ضرورت ہے۔ اور اگر آپ دیکھتے ہیں کہ آپ کے تعطل میں مسلسل اضافہ ہو رہا ہے، تو آپ کو لاگز میں موجود تفصیلات کو دیکھنے کی ضرورت ہے، پیدا ہونے والے حالات کا تجزیہ کریں اور دیکھیں کہ مسئلہ کیا ہے۔
عارضی فائلیں (temp_files) بھی خراب ہیں۔ جب صارف کی درخواست میں آپریشنل، عارضی ڈیٹا کو ایڈجسٹ کرنے کے لیے کافی میموری نہیں ہوتی ہے، تو یہ ڈسک پر ایک فائل بناتی ہے۔ اور وہ تمام آپریشن جو یہ میموری میں عارضی بفر میں انجام دے سکتا ہے ڈسک پر انجام دینا شروع ہو جاتا ہے۔ یہ سست ہے۔ اس سے استفسار پر عمل درآمد کا وقت بڑھ جاتا ہے۔ اور کلائنٹ جس نے PostgreSQL کو درخواست بھیجی ہے اسے تھوڑی دیر بعد جواب موصول ہوگا۔ اگر یہ تمام کارروائیاں میموری میں کی جاتی ہیں، تو Postgres بہت تیزی سے جواب دے گا اور کلائنٹ کم انتظار کرے گا۔
Pg_stat_bgwriter - یہ نقطہ نظر دو PostgreSQL پس منظر کے سب سسٹمز کے عمل کو بیان کرتا ہے: یہ checkpointer и background writer.
سب سے پہلے، کنٹرول پوائنٹس کو دیکھتے ہیں، نام نہاد. checkpoints. کنٹرول پوائنٹس کیا ہیں؟ چیک پوائنٹ ٹرانزیکشن لاگ میں ایک پوزیشن ہے جو اس بات کی نشاندہی کرتی ہے کہ لاگ میں ریکارڈ کی گئی تمام ڈیٹا تبدیلیوں کو ڈسک پر موجود ڈیٹا کے ساتھ کامیابی سے ہم آہنگ کیا گیا ہے۔ یہ عمل، کام کے بوجھ اور ترتیبات پر منحصر ہے، طویل ہوسکتا ہے اور زیادہ تر ڈسک پر ڈیٹا فائلوں کے ساتھ مشترکہ بفرز میں گندے صفحات کو ہم آہنگ کرنے پر مشتمل ہوتا ہے۔ یہ کس لیے ہے؟ اگر PostgreSQL مسلسل ڈسک تک رسائی حاصل کر رہا تھا اور وہاں سے ڈیٹا حاصل کر رہا تھا، اور ہر ایک رسائی پر ڈیٹا لکھ رہا تھا، تو یہ سست ہو گا۔ لہذا، PostgreSQL میں ایک میموری سیگمنٹ ہے جس کا سائز کنفیگریشن کی سیٹنگز پر منحصر ہے۔ پوسٹگریس اس میموری میں لائیو ڈیٹا کو بعد میں پروسیسنگ یا استفسار کے لیے اسٹور کرتا ہے۔ ڈیٹا کو تبدیل کرنے کی درخواستوں کی صورت میں، اسے تبدیل کر دیا جاتا ہے۔ اور ہمیں ڈیٹا کے دو ورژن ملتے ہیں۔ ایک ہماری یادداشت میں ہے، دوسرا ڈسک پر ہے۔ اور وقتاً فوقتاً آپ کو اس ڈیٹا کو سنکرونائز کرنے کی ضرورت ہوتی ہے۔ ہمیں میموری میں جو کچھ تبدیل ہوتا ہے اسے ڈسک سے ہم آہنگ کرنے کی ضرورت ہے۔ اس کے لیے آپ کو چوکیوں کی ضرورت ہے۔
چیک پوائنٹ مشترکہ بفرز سے گزرتا ہے، ان گندے صفحات کو نشان زد کرتا ہے جو چیک پوائنٹ کے لیے درکار ہیں۔ پھر یہ مشترکہ بفرز کے ذریعے دوسرا پاس شروع کرتا ہے۔ اور جن صفحات کو چیک پوائنٹ کے لیے نشان زد کیا گیا ہے، یہ پہلے سے ہی ان کو ہم آہنگ کرتا ہے۔ اس طرح ڈیٹا کو ڈسک کے ساتھ ہم آہنگ کیا جاتا ہے۔
چوکیاں دو قسم کی ہوتی ہیں۔ ایک چوکی ٹائم آؤٹ کے ساتھ چلائی جاتی ہے۔ یہ چوکی مفید اور اچھی ہے - checkpoint_timed. اور مانگ پر چوکیاں ہیں - checkpoint required. یہ چیک پوائنٹ اس وقت ہوتا ہے جب ہمارے پاس ڈیٹا کا بہت بڑا ریکارڈ ہوتا ہے۔ ہم نے لین دین کے بہت سارے لاگز ریکارڈ کیے ہیں۔ اور PostgreSQL کا خیال ہے کہ اسے جلد از جلد ان سب کو ہم آہنگ کرنے، ایک چوکی بنانے اور آگے بڑھنے کی ضرورت ہے۔
اور اگر آپ اعدادوشمار کو دیکھیں pg_stat_bgwriter اور دیکھا کہ آپ کے پاس کیا ہے۔ checkpoint_req checkpoint_timed سے بہت بڑا ہے، پھر یہ برا ہے۔ برا کیوں؟ اس کا مطلب یہ ہے کہ PostgreSQL مسلسل دباؤ میں رہتا ہے جب اسے ڈسک پر ڈیٹا لکھنے کی ضرورت ہوتی ہے۔ ٹائم آؤٹ چیک پوائنٹ کم دباؤ والا ہوتا ہے اور اسے اندرونی شیڈول کے مطابق انجام دیا جاتا ہے اور یہ وقت کے ساتھ ساتھ پھیلا ہوا ہے۔ PostgreSQL میں کام کو روکنے اور ڈسک کے سب سسٹم پر دباؤ نہ ڈالنے کی صلاحیت ہے۔ یہ PostgreSQL کے لیے مفید ہے۔ اور سوالات جو چیک پوائنٹ کے دوران انجام دیئے جاتے ہیں اس حقیقت سے تناؤ کا سامنا نہیں کریں گے کہ ڈسک سب سسٹم مصروف ہے۔
اور چوکی کو ایڈجسٹ کرنے کے لیے تین پیرامیٹرز ہیں:
-
сheckpoint_segments. -
сheckpoint_timeout. -
сheckpoint_competion_target.
وہ آپ کو کنٹرول پوائنٹس کے آپریشن کو منظم کرنے کی اجازت دیتے ہیں۔ لیکن میں ان پر نہیں رہوں گا۔ ان کا اثر ایک الگ موضوع ہے۔
انتباہ: رپورٹ میں زیر بحث ورژن 9.4 اب متعلقہ نہیں ہے۔ PostgreSQL کے جدید ورژن میں پیرامیٹر checkpoint_segments پیرامیٹرز کی طرف سے تبدیل min_wal_size и max_wal_size.
اگلا ذیلی نظام پس منظر کا مصنف ہے۔ background writer. وہ کیا کر رہا ہے؟ یہ ایک لامتناہی لوپ میں مسلسل چلتا ہے. مشترکہ بفرز میں صفحات کو اسکین کرتا ہے اور گندے صفحات کو ڈمپ کرتا ہے جو اسے ڈسک پر ملتا ہے۔ اس طرح، یہ چیک پوائنٹ پر عمل درآمد کے دوران کم کام کرنے میں چوکیدار کی مدد کرتا ہے۔
اس کے لیے اور کیا ضرورت ہے؟ یہ مشترکہ بفرز میں خالی صفحات کی ضرورت فراہم کرتا ہے اگر ڈیٹا کو ایڈجسٹ کرنے کے لیے انہیں اچانک (بڑی مقدار میں اور فوری طور پر) درکار ہو۔ فرض کریں کہ ایک ایسی صورت حال پیدا ہوئی جب خالی صفحات کو درخواست مکمل کرنے کی ضرورت تھی اور وہ پہلے سے ہی مشترکہ بفرز میں موجود تھے۔ پوسٹ گریسیو backend وہ صرف انہیں اٹھا کر استعمال کرتا ہے، اسے خود کچھ صاف کرنے کی ضرورت نہیں ہے۔ لیکن اگر اچانک ایسے صفحات نہ ہوں تو بیک اینڈ کام کو روک دیتا ہے اور صفحات کو ڈسک پر ڈمپ کرنے اور اپنی ضروریات کے لیے لے جانے کے لیے تلاش کرنا شروع کر دیتا ہے - جو کہ فی الحال عمل درآمد کی درخواست کے وقت کو منفی طور پر متاثر کرتا ہے۔ اگر آپ دیکھتے ہیں کہ آپ کے پاس پیرامیٹر ہے۔ maxwritten_clean بڑے، اس کا مطلب ہے کہ پس منظر لکھنے والا اپنا کام نہیں کر رہا ہے اور آپ کو پیرامیٹرز بڑھانے کی ضرورت ہے۔ bgwriter_lru_maxpagesتاکہ وہ ایک چکر میں مزید کام کر سکے، مزید صفحات صاف کر سکے۔
اور ایک اور بہت مفید اشارے ہے۔ buffers_backend_fsync. بیک اینڈ fsync نہیں ہوتے ہیں کیونکہ یہ سست ہے۔ وہ IO اسٹیک چیک پوائنٹر کو fsync پاس کرتے ہیں۔ چیک پوائنٹر کی اپنی قطار ہوتی ہے، یہ وقتاً فوقتاً fsync پر کارروائی کرتا ہے اور میموری میں صفحات کو ڈسک پر موجود فائلوں کے ساتھ ہم آہنگ کرتا ہے۔ اگر چوکی پر قطار بڑی اور بھری ہوئی ہے، تو بیک اینڈ کو خود fsync کرنے پر مجبور کیا جاتا ہے اور اس سے بیک اینڈ کا کام سست ہوجاتا ہے۔، یعنی کلائنٹ کو اس سے زیادہ دیر میں جواب موصول ہوگا۔ اگر آپ دیکھتے ہیں کہ آپ کی قیمت صفر سے زیادہ ہے، تو یہ پہلے سے ہی ایک مسئلہ ہے اور آپ کو بیک گراؤنڈ رائٹر کی سیٹنگز پر توجہ دینے کی ضرورت ہے اور ڈسک سب سسٹم کی کارکردگی کا بھی جائزہ لینا ہوگا۔
انتباہ: _مندرجہ ذیل متن نقل سے وابستہ شماریاتی خیالات کو بیان کرتا ہے۔ پوسٹگریس 10 میں زیادہ تر ویو اور فنکشن کے ناموں کا نام تبدیل کر دیا گیا تھا۔ نام تبدیل کرنے کا جوہر بدلنا تھا۔ xlog پر wal и location پر lsn فنکشن / ویو کے ناموں وغیرہ میں خاص مثال، فنکشن pg_xlog_location_diff() کا نام تبدیل کر دیا گیا۔ pg_wal_lsn_diff()._
ہمارے یہاں بھی بہت سی چیزیں ہیں۔ لیکن ہمیں صرف مقام سے متعلق اشیاء کی ضرورت ہے۔
اگر ہم دیکھتے ہیں کہ تمام اقدار برابر ہیں، تو یہ ایک مثالی آپشن ہے اور نقل ماسٹر سے پیچھے نہیں رہتی۔
یہاں یہ ہیکساڈیسیمل پوزیشن ٹرانزیکشن لاگ میں پوزیشن ہے۔ اگر ڈیٹا بیس میں کوئی سرگرمی ہو تو یہ مسلسل بڑھتا ہے: داخل کرنا، حذف کرنا، وغیرہ۔
сколько записано xlog в байтах
$ select
pg_xlog_location_diff(pg_current_xlog_location(),'0/00000000');
лаг репликации в байтах
$ select
client_addr,
pg_xlog_location_diff(pg_current_xlog_location(), replay_location)
from pg_stat_replication;
лаг репликации в секундах
$ select
extract(epoch from now() - pg_last_xact_replay_timestamp());اگر یہ چیزیں مختلف ہیں، تو ایک قسم کا وقفہ ہے. وقفہ نقل اور ماسٹر کے درمیان وقفہ ہے، یعنی ڈیٹا سرورز کے درمیان مختلف ہوتا ہے۔
وقفے کی تین وجوہات ہیں:
- یہ ڈسک سب سسٹم ریکارڈنگ فائل سنکرونائزیشن کا مقابلہ نہیں کر سکتا۔
- یہ ممکنہ نیٹ ورک کی خرابیاں ہیں، یا نیٹ ورک اوورلوڈ، جب ڈیٹا کے پاس نقل تک پہنچنے کا وقت نہیں ہوتا ہے اور وہ اسے دوبارہ نہیں بنا سکتا۔
- اور پروسیسر۔ پروسیسر ایک بہت ہی نایاب معاملہ ہے۔ اور یہ میں نے دو تین بار دیکھا لیکن ایسا بھی ہو سکتا ہے۔
اور یہاں تین سوالات ہیں جو ہمیں اعدادوشمار استعمال کرنے کی اجازت دیتے ہیں۔ ہم اندازہ لگا سکتے ہیں کہ ہم نے ٹرانزیکشن لاگ میں کتنا ریکارڈ کیا ہے۔ اس طرح کی ایک تقریب ہے 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 سے زیادہ ہے، تو یہ پہلے سے ہی ایک اشارہ ہے کہ شاید آپ کو کہیں ایک انڈیکس بنانے کی ضرورت ہے تاکہ استفسارات انڈیکس پر مبنی ہوں، یا اس طرح کے ترتیب وار اسکینوں کا استعمال کرنے والے سوالات کو بہتر بنانا ممکن ہے۔ کہ ایسا نہیں ہوتا۔
ایک سادہ مثال - آئیے کہتے ہیں کہ ایک بڑی آفسیٹ اور 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;اور اس کے نئے ڈیزائن کی وجہ سے، اپ ڈیٹ ایک ہیوی ویٹ آپریشن ہے۔ لیکن انہیں آسان بنایا جا سکتا ہے۔ کھاؤ hot updates. وہ PostgreSQL ورژن 8.3 میں نمودار ہوئے۔ اور یہ کیا ہے؟ یہ ایک ہلکا پھلکا اپ ڈیٹ ہے جس کی وجہ سے اشاریہ جات دوبارہ نہیں بنتے۔ یعنی، ہم نے ریکارڈ کو اپ ڈیٹ کیا، لیکن صرف صفحہ میں موجود ریکارڈ (جو ٹیبل سے تعلق رکھتا ہے) کو اپ ڈیٹ کیا گیا، اور اشاریہ جات اب بھی صفحہ میں اسی ریکارڈ کی طرف اشارہ کرتے ہیں۔ ایک دلچسپ آپریٹنگ منطق ہے: جب خلا آتا ہے، تو یہ زنجیریں بناتا ہے hot دوبارہ تعمیر کرتا ہے اور ہر چیز اشاریہ جات کو اپ ڈیٹ کیے بغیر کام کرتی رہتی ہے، اور سب کچھ وسائل کے کم ضیاع کے ساتھ ہوتا ہے۔
اور آپ کب کرتے ہیں۔ n_tup_hot_upd بڑا، پھر یہ بہت اچھا ہے۔ اس کا مطلب یہ ہے کہ ہلکے وزن کی تازہ کارییں غالب ہیں اور یہ ہمارے لیے وسائل کے لحاظ سے سستا ہے اور سب کچھ ٹھیک ہے۔
ALTER TABLE table_name SET (fillfactor = 70);حجم کو کیسے بڑھایا جائے۔ hot updateov ہم استعمال کر سکتے ہیں۔ 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 ایک ذیلی نظام ہے جس کے لیے PostgreSQL میں بہت کم اعدادوشمار ہیں۔ ہم صرف pg_stat_activity میں ٹیبلز میں دیکھ سکتے ہیں کہ اس وقت ہمارے پاس کتنے ویکیوم ہیں۔ تاہم، ابھی یہ سمجھنا بہت مشکل ہے کہ قطار میں کتنی میزیں ہیں۔
نوٹ: _پوسٹگریس 10 کے ساتھ شروع کرتے ہوئے، واٹوواک ٹریکنگ کے ساتھ صورتحال بہت بہتر ہوئی ہے - pg_stat_progress منظر سامنے آیا ہےویکیوم، جو کار ویکیوم کی نگرانی کے معاملے کو نمایاں طور پر آسان بناتا ہے۔
ہم اس آسان سوال کو استعمال کر سکتے ہیں۔ اور ہم دیکھ سکتے ہیں کہ کب خلا بنانا پڑے گا۔ لیکن خلا کیسے اور کب شروع ہونا چاہئے؟ یہ ان لائنوں کے میراثی ورژن ہیں جن کے بارے میں میں پہلے بات کر رہا تھا۔ اپ ڈیٹ ہوا، لائن کا ایک نیا ورژن داخل کیا گیا تھا۔ سٹرنگ کا ایک پرانا ورژن ظاہر ہوا ہے۔ میز میں pg_stat_user_tables اس طرح کا ایک پیرامیٹر ہے n_dead_tup. یہ "مردہ" لائنوں کی تعداد دکھاتا ہے۔ اور جیسے ہی مردہ قطاروں کی تعداد ایک خاص حد سے زیادہ ہو جائے گی، ایک آٹو ویکیوم میز پر آجائے گا۔
اور اس حد کا حساب کیسے لگایا جاتا ہے؟ یہ ٹیبل میں قطاروں کی کل تعداد کا ایک خاص فیصد ہے۔ ایک پیرامیٹر ہے۔ autovacuum_vacuum_scale_factor. یہ فیصد کا تعین کرتا ہے۔ آئیے کہتے ہیں 10% + 50 لائنوں کی ایک اضافی بنیادی حد ہے۔ اور کیا ہوتا ہے؟ جب ہمارے پاس ٹیبل کی تمام قطاروں کی "10% + 50" سے زیادہ مردہ قطاریں ہوتی ہیں، تو ہم ٹیبل کو آٹو ویکیوم پر رکھتے ہیں۔
select c.relname,
current_setting('autovacuum_vacuum_threshold') as av_base_thresh,
current_setting('autovacuum_vacuum_scale_factor') as av_scale_factor,
(current_setting('autovacuum_vacuum_threshold')::int +
(current_setting('autovacuum_vacuum_scale_factor')::float * c.reltuples))
as av_thresh,
s.n_dead_tup
from pg_stat_user_tables s join pg_class c ON s.relname = c.relname
where s.n_dead_tup > (current_setting('autovacuum_vacuum_threshold')::int
+ (current_setting('autovacuum_vacuum_scale_factor')::float * c.reltuples));تاہم، ایک نقطہ ہے. پیرامیٹرز کے لیے بنیادی حد av_base_thresh и av_scale_factor انفرادی طور پر تفویض کیا جا سکتا ہے. اور، اس کے مطابق، حد عالمی نہیں ہوگی، بلکہ میز کے لیے انفرادی ہوگی۔ لہذا، حساب کرنے کے لئے، آپ کو چالوں اور چالوں کو استعمال کرنے کی ضرورت ہے. اور اگر آپ دلچسپی رکھتے ہیں، تو آپ Avito سے ہمارے ساتھیوں کے تجربے کو دیکھ سکتے ہیں (سلائیڈ پر لنک غلط ہے اور متن میں اپ ڈیٹ کیا گیا ہے)۔
کے لیے انہوں نے لکھا ، جو ان چیزوں کو مدنظر رکھتا ہے۔ وہاں ایک دو چادروں والا فٹ کلاتھ ہے۔ لیکن یہ درست طریقے سے حساب لگاتا ہے اور کافی مؤثر طریقے سے ہمیں یہ اندازہ کرنے کی اجازت دیتا ہے کہ ہمیں میزوں کے لیے کہاں بہت زیادہ خلا کی ضرورت ہے جہاں بہت کم ہے۔
ہم اس کے بارے میں کیا کر سکتے ہیں؟ اگر ہمارے پاس ایک بڑی قطار ہے اور آٹو ویکیوم اس کا مقابلہ نہیں کر سکتا، تو ہم ویکیوم ورکرز کی تعداد بڑھا سکتے ہیں، یا ویکیوم کو مزید جارحانہ بنا سکتے ہیں۔، تاکہ یہ پہلے متحرک ہوجائے، میز کو چھوٹے ٹکڑوں میں پروسیس کرتا ہے۔ اور اس طرح قطار کم ہو جائے گی۔ - یہاں اہم چیز ڈسکوں پر بوجھ کی نگرانی کرنا ہے، کیونکہ... ویکیوم کوئی مفت چیز نہیں ہے، حالانکہ SSD/NVMe ڈیوائسز کی آمد کے ساتھ مسئلہ کم نمایاں ہو گیا ہے۔
Pg_stat_all_indexes اشاریہ جات کے اعداد و شمار ہیں۔ وہ بڑی نہیں ہے۔ اور ہم اسے اشاریہ جات کے استعمال سے متعلق معلومات حاصل کرنے کے لیے استعمال کر سکتے ہیں۔ اور مثال کے طور پر، ہم یہ تعین کر سکتے ہیں کہ ہمارے پاس کون سے اشاریہ جات اضافی ہیں۔
جیسا کہ میں پہلے ہی کہہ چکا ہوں، اپ ڈیٹ صرف ٹیبلز کی اپ ڈیٹ نہیں ہے، یہ انڈیکسز کی اپ ڈیٹ بھی ہے۔ اس کے مطابق، اگر ہمارے پاس ٹیبل پر بہت سے اشاریہ جات ہیں، تو ٹیبل میں قطاروں کو اپ ڈیٹ کرتے وقت، انڈیکس شدہ فیلڈز کے اشاریہ جات کو بھی اپ ڈیٹ کرنے کی ضرورت ہے، اور اگر ہمارے پاس غیر استعمال شدہ اشاریہ جات ہیں جن کے لیے کوئی انڈیکس اسکین نہیں ہے، تو وہ بیلسٹ کی طرح لٹک جاتے ہیں۔ اور ہمیں ان سے چھٹکارا حاصل کرنے کی ضرورت ہے۔ اس کے لیے ہمیں ایک میدان چاہیے۔ idx_scan. ہم صرف انڈیکس اسکینوں کی تعداد کو دیکھتے ہیں۔ اگر اشاریہ جات میں اعداد و شمار کے ذخیرہ کی نسبتاً طویل مدت (کم از کم 2-3 ہفتوں) میں صفر اسکین ہوتے ہیں، تو زیادہ تر امکان ہے کہ یہ خراب اشاریہ جات ہیں، ہمیں ان سے چھٹکارا حاصل کرنے کی ضرورت ہے۔
نوٹ: سٹریمنگ ریپلیکیشن کلسٹرز کے معاملے میں غیر استعمال شدہ اشاریہ جات کی تلاش کرتے وقت، آپ کو تمام کلسٹر نوڈس کو چیک کرنے کی ضرورت ہے، کیونکہ اعداد و شمار عالمی نہیں ہیں، اور اگر انڈیکس ماسٹر پر استعمال نہیں کیا جاتا ہے، تو اسے نقلوں پر استعمال کیا جا سکتا ہے (اگر وہاں بوجھ ہے)۔
دو لنکس:
یہ غیر استعمال شدہ اشاریہ جات کو تلاش کرنے کے طریقے کے بارے میں مزید جدید استفسار کی مثالیں ہیں۔
دوسرا لنک ایک دلچسپ درخواست ہے۔ وہاں ایک بہت ہی غیر معمولی منطق ہے۔ میں اسے حوالہ کے لیے تجویز کرتا ہوں۔
انڈیکس کا استعمال کرتے ہوئے خلاصہ کرنے کے قابل اور کیا ہے؟
-
غیر استعمال شدہ اشاریہ جات خراب ہیں۔
-
وہ جگہ لیتے ہیں۔
-
اپ ڈیٹ کی کارروائیوں کو سست کریں۔
-
ویکیوم کے لیے اضافی کام۔
اگر ہم غیر استعمال شدہ اشاریہ جات کو ہٹاتے ہیں، تو ہم صرف ڈیٹا بیس کو بہتر بنائیں گے۔
اگلی پیش کش ہے۔ pg_stat_activity. یہ افادیت کا ایک ینالاگ ہے۔ ps، صرف PostgreSQL میں۔ اگر ps'آپ آپریٹنگ سسٹم میں عمل کو دیکھتے ہیں، پھر pg_stat_activity یہ آپ کو PostgreSQL کے اندر کی سرگرمی دکھائے گا۔
ہم وہاں سے کون سی مفید چیزیں لے سکتے ہیں؟
select
count(*)*100/(select current_setting('max_connections')::int)
from pg_stat_activity;ہم عام سرگرمی دیکھ سکتے ہیں، ڈیٹا بیس میں کیا ہو رہا ہے۔ ہم ایک نئی تعیناتی کر سکتے ہیں۔ یہاں سب کچھ پھٹ چکا ہے، نئے کنکشن قبول نہیں کیے جاتے، درخواست میں غلطیاں آرہی ہیں۔
select
client_addr, usename, datname, count(*)
from pg_stat_activity group by 1,2,3 order by 4 desc;ہم اس طرح ایک استفسار چلا سکتے ہیں اور کنکشن کی زیادہ سے زیادہ حد کے نسبت کنکشن کا کل فیصد دیکھ سکتے ہیں اور دیکھ سکتے ہیں کہ کس کے پاس سب سے زیادہ کنکشن ہیں۔ اور اس دی گئی صورت میں ہم اس صارف کو دیکھتے ہیں۔ cron_role 508 کنکشن کھولے گئے۔ اور وہاں اس کے ساتھ کچھ ہوا۔ ہمیں اس سے نمٹنے اور اسے دیکھنے کی ضرورت ہے۔ اور یہ بالکل ممکن ہے کہ یہ کسی قسم کے غیر متضاد رابطوں کی تعداد ہو۔
اگر ہمارے پاس OLTP کام کا بوجھ ہے تو سوالات تیز، بہت تیز ہونے چاہئیں اور طویل سوالات نہیں ہونے چاہئیں۔ تاہم، اگر طویل سوالات پیدا ہوتے ہیں، تو مختصر مدت میں اس کے بارے میں فکر کرنے کی کوئی بات نہیں ہے، لیکن طویل عرصے میں، طویل سوالات ڈیٹابیس کو نقصان پہنچاتے ہیں؛ جب ٹیبل کے ٹکڑے ٹکڑے ہوتے ہیں تو وہ میزوں کے بلوٹ اثر کو بڑھاتے ہیں۔ آپ کو بلوٹ اور طویل سوالات دونوں سے چھٹکارا حاصل کرنے کی ضرورت ہے۔
select
client_addr, usename, datname,
clock_timestamp() - xact_start as xact_age,
clock_timestamp() - query_start as query_age,
query
from pg_stat_activity order by xact_start, query_start;براہ کرم نوٹ کریں: اس درخواست کے ساتھ ہم طویل سوالات اور لین دین کی شناخت کر سکتے ہیں۔ ہم فنکشن کا استعمال کرتے ہیں۔ clock_timestamp() آپریٹنگ وقت کا تعین کرنے کے لئے. طویل سوالات جو ہمیں ملے، ہم انہیں یاد کر سکتے ہیں، انہیں پورا کر سکتے ہیں۔ explain، منصوبوں کو دیکھیں اور کسی نہ کسی طرح اصلاح کریں۔ ہم موجودہ طویل درخواستوں کو گولی مار دیتے ہیں اور اپنی زندگی کے ساتھ آگے بڑھتے ہیں۔
select * from pg_stat_activity where state in
('idle in transaction', 'idle in transaction (aborted)';خراب لین دین لین دین میں بیکار اور لین دین میں بیکار (اسقاط شدہ) حالتوں میں لین دین ہیں۔
اس کا کیا مطلب ہے؟ لین دین کی متعدد ریاستیں ہیں۔ اور ان میں سے ایک ریاست کسی بھی وقت فرض کی جا سکتی ہے۔ ریاستوں کی وضاحت کے لیے ایک میدان ہے۔ state اس پیشکش میں. اور ہم اسے ریاست کا تعین کرنے کے لیے استعمال کرتے ہیں۔
select * from pg_stat_activity where state in
('idle in transaction', 'idle in transaction (aborted)';اور، جیسا کہ میں نے اوپر کہا، یہ دونوں ریاستیں۔ لین دین میں بیکار اور لین دین میں بے کار (منقطع) خراب ہیں۔ یہ کیا ہے؟ یہ اس وقت ہوتا ہے جب ایپلیکیشن نے کوئی لین دین کھولا، کچھ کارروائیاں کیں اور اپنے کاروبار کو شروع کیا۔ لین دین کھلا رہتا ہے۔ یہ لٹک جاتا ہے، اس میں کچھ نہیں ہوتا، یہ کنکشن لے لیتا ہے، بدلی ہوئی قطاروں پر تالے لگاتا ہے اور ممکنہ طور پر دیگر میزوں کے بلوٹ کو بڑھاتا ہے، پوسٹرجس ٹرانزیکشن انجن کے فن تعمیر کی وجہ سے۔ اور اس طرح کے لین دین کو بھی بند کر دینا چاہیے، کیونکہ وہ عام طور پر نقصان دہ ہوتے ہیں، کسی بھی صورت میں۔
اگر آپ دیکھتے ہیں کہ آپ کے ڈیٹا بیس میں ان میں سے 5-10-20 سے زیادہ ہیں، تو آپ کو فکر کرنے کی ضرورت ہے اور ان کے ساتھ کچھ کرنا شروع کر دیں۔
یہاں ہم حساب وقت کے لیے بھی استعمال کرتے ہیں۔ clock_timestamp(). ہم لین دین کو شوٹ کرتے ہیں اور درخواست کو بہتر بناتے ہیں۔
جیسا کہ میں نے اوپر کہا، بلاک کرنا اس وقت ہوتا ہے جب دو یا زیادہ لین دین ایک یا وسائل کے ایک گروپ کے لیے لڑتے ہیں۔ اس کے لیے ہمارے پاس ایک میدان ہے۔ waiting بولین ویلیو کے ساتھ true یا false.
سچ ہے - اس کا مطلب ہے کہ عمل زیر التواء ہے، کچھ کرنے کی ضرورت ہے۔ جب کوئی عمل انتظار کر رہا ہوتا ہے، تو اس کا مطلب ہے کہ اس عمل کو شروع کرنے والا کلائنٹ بھی انتظار کر رہا ہے۔ کلائنٹ براؤزر میں بیٹھتا ہے اور انتظار بھی کرتا ہے۔
انتباہ: پوسٹگریس ورژن 9.6 فیلڈ سے شروع ہو رہا ہے۔ waiting ہٹا دیا گیا اور اس کی بجائے دو مزید معلوماتی فیلڈز شامل کر دی گئیں۔ wait_event_type и wait_event._
کیا؟ اگر آپ طویل عرصے تک سچ دیکھتے ہیں، تو اس کا مطلب ہے کہ آپ کو ایسی درخواستوں سے چھٹکارا حاصل کرنے کی ضرورت ہے۔ ہم صرف اس طرح کے لین دین کو گولی مار دیتے ہیں۔ ہم ڈویلپرز کو لکھتے ہیں کہ انہیں کسی نہ کسی طرح بہتر بنانے کی ضرورت ہے تاکہ وسائل کی کوئی دوڑ نہ ہو۔ اور پھر ڈویلپرز ایپلی کیشن کو بہتر بناتے ہیں تاکہ ایسا نہ ہو۔
اور انتہائی، لیکن ممکنہ طور پر غیر مہلک معاملہ ہے۔ تعطل کی موجودگی. دو لین دین نے دو وسائل کو اپ ڈیٹ کیا، پھر ان تک دوبارہ رسائی حاصل کی، اس بار مخالف وسائل تک۔ اس صورت میں، PostgreSQL خود ٹرانزیکشن کو ختم کر دیتا ہے تاکہ کوئی دوسرا کام جاری رکھ سکے۔ یہ ایک مردہ صورت حال ہے اور وہ خود اس کا اندازہ نہیں لگا سکتی۔ لہذا، PostgreSQL انتہائی اقدامات کرنے پر مجبور ہے۔
اور یہاں دو سوالات ہیں جو آپ کو بلاکنگ کو ٹریک کرنے کی اجازت دیتے ہیں۔ ہم نقطہ نظر کا استعمال کرتے ہیں pg_locks، جو آپ کو بھاری تالے کو ٹریک کرنے کی اجازت دیتا ہے۔
اور پہلا لنک خود درخواست کا متن ہے۔ یہ کافی لمبا ہے۔
اور دوسرا لنک تالے پر ایک مضمون ہے۔ یہ پڑھنا مفید ہے، یہ بہت دلچسپ ہے۔
تو ہم کیا دیکھتے ہیں؟ ہم دو درخواستیں دیکھتے ہیں۔ کے ساتھ لین دین ALTER TABLE ایک بلاک کرنے والا لین دین ہے۔ یہ شروع ہوا، لیکن مکمل نہیں ہوا، اور اس لین دین کو ریکارڈ کرنے والی درخواست کہیں اور کام کر رہی ہے۔ اور دوسری درخواست اپ ڈیٹ ہے۔ وہ اپنا کام جاری رکھنے سے پہلے الٹر ٹیبل کے ختم ہونے کا انتظار کرتا ہے۔
اس طرح ہم یہ معلوم کر سکتے ہیں کہ کس نے کس کو بند کیا، کس کو پکڑا ہوا ہے، اور ہم اس سے مزید نمٹ سکتے ہیں۔
اگلا ماڈیول ہے۔ pg_stat_statements. جیسا کہ میں نے کہا، یہ ایک ماڈیول ہے۔ اسے استعمال کرنے کے لیے، آپ کو اس کی لائبریری کو کنفیگریشن میں لوڈ کرنا ہوگا، PostgreSQL کو دوبارہ شروع کرنا ہوگا، ماڈیول (ایک کمانڈ کے ساتھ) انسٹال کرنا ہوگا اور پھر ہمارے پاس ایک نیا منظر ہوگا۔
Cреднее время запроса в милисекундах
$ select (sum(total_time) / sum(calls))::numeric(6,3)
from pg_stat_statements;
Самые активно пишущие (в shared_buffers) запросы
$ select query, shared_blks_dirtied
from pg_stat_statements
where shared_blks_dirtied > 0 order by 2 desc;ہم وہاں سے کیا لے سکتے ہیں؟ اگر ہم سادہ چیزوں کے بارے میں بات کرتے ہیں، تو ہم استفسار پر عمل درآمد کا اوسط وقت لے سکتے ہیں۔ وقت بڑھ رہا ہے، جس کا مطلب ہے کہ PostgreSQL آہستہ آہستہ جواب دے رہا ہے اور ہمیں کچھ کرنے کی ضرورت ہے۔
ہم ڈیٹا بیس میں سب سے زیادہ فعال تحریری لین دین کو دیکھ سکتے ہیں جو مشترکہ بفرز میں ڈیٹا کو تبدیل کرتے ہیں۔ دیکھیں کہ وہاں کون ڈیٹا کو اپ ڈیٹ یا ڈیلیٹ کرتا ہے۔
اور ہم ان درخواستوں کے لیے مختلف اعدادوشمار کو آسانی سے دیکھ سکتے ہیں۔
ہم ہیں pg_stat_statements ہم اسے رپورٹس بنانے کے لیے استعمال کرتے ہیں۔ ہم دن میں ایک بار اعدادوشمار کو دوبارہ ترتیب دیتے ہیں۔ آئیے اسے جمع کرتے ہیں۔ اگلی بار اعداد و شمار کو دوبارہ ترتیب دینے سے پہلے، آئیے ایک رپورٹ بناتے ہیں۔ رپورٹ کا لنک یہ ہے۔ آپ اسے دیکھ سکتے ہیں۔
ہم کیا کر رہے ہیں؟ ہم تمام درخواستوں کے لیے عمومی اعدادوشمار کا حساب لگاتے ہیں۔ پھر، ہر درخواست کے لیے، ہم ان مجموعی اعدادوشمار میں اس کے انفرادی تعاون کو شمار کرتے ہیں۔
اور ہم کیا دیکھ سکتے ہیں؟ ہم دیگر تمام درخواستوں کے پس منظر کے خلاف کسی خاص قسم کی تمام درخواستوں کے عمل درآمد کے کل وقت کو دیکھ سکتے ہیں۔ ہم مجموعی تصویر کے نسبت CPU اور I/O وسائل کے استعمال کو دیکھ سکتے ہیں۔ اور پہلے ہی ان سوالات کو بہتر بنائیں۔ ہم اس رپورٹ کی بنیاد پر سرفہرست سوالات تیار کر رہے ہیں اور پہلے ہی سوچنے کے لیے خوراک حاصل کر رہے ہیں کہ کیا بہتر بنایا جائے۔
ہم نے پردے کے پیچھے کیا چھوڑا ہے؟ ابھی کچھ گذارشات باقی ہیں جن پر میں نے غور نہیں کیا کیونکہ وقت محدود ہے۔
ہے pgstattuple معیاری کنٹریبس پیکج کا ایک اضافی ماڈیول بھی ہے۔ یہ آپ کو اندازہ کرنے کی اجازت دیتا ہے۔ bloat میزیں، نام نہاد ٹیبل کے ٹکڑے کرنا. اور اگر بہت زیادہ فریگمنٹیشن ہے تو آپ کو اسے ہٹانے اور مختلف ٹولز استعمال کرنے کی ضرورت ہے۔ اور فنکشن pgstattuple ایک طویل وقت کے لئے کام کرتا ہے. اور جتنی زیادہ میزیں ہوں گی، اتنی ہی دیر کام کرے گی۔
اگلی شراکت ہے۔ pg_buffercache. یہ آپ کو مشترکہ بفرز کا معائنہ کرنے کی اجازت دیتا ہے: کتنی شدت سے اور کن ٹیبل بفر پیجز کے لیے استعمال کیے جاتے ہیں۔ اور یہ آسانی سے آپ کو مشترکہ بفرز کو دیکھنے اور وہاں کیا ہو رہا ہے اس کا اندازہ کرنے کی اجازت دیتا ہے۔
اگلا ماڈیول ہے۔ pgfincore. یہ سسٹم کال کے ذریعے نچلی سطح کے ٹیبل آپریشنز کی اجازت دیتا ہے۔ mincore()، یعنی یہ آپ کو ایک میز کو مشترکہ بفرز میں لوڈ کرنے، یا اسے اتارنے کی اجازت دیتا ہے۔ اور یہ دوسری چیزوں کے ساتھ ساتھ آپریٹنگ سسٹم کے صفحہ کیشے کا معائنہ کرنے کی اجازت دیتا ہے، یعنی، مشترکہ بفرز میں، صفحہ کیشے میں میز کتنی جگہ پر قبضہ کرتا ہے، اور ہمیں صرف میز کے کام کے بوجھ کا اندازہ کرنے کی اجازت دیتا ہے۔
اگلا ماڈیول - pg_stat_kcache. یہ سسٹم کال کا بھی استعمال کرتا ہے۔ getrusage(). اور یہ درخواست پر عمل درآمد سے پہلے اور بعد میں اسے انجام دیتا ہے۔ اور نتیجے کے اعداد و شمار میں، یہ ہمیں اندازہ لگانے کی اجازت دیتا ہے کہ ہماری درخواست نے ڈسک I/O پر کتنا خرچ کیا، یعنی فائل سسٹم کے ساتھ آپریشنز اور پروسیسر کے استعمال کو دیکھتے ہیں۔ تاہم، ماڈیول جوان ہے (کھانسی کی کھانسی) اور اس کے آپریشن کے لیے اسے PostgreSQL 9.4 اور pg_stat_statements کی ضرورت ہے، جس کا میں نے پہلے ذکر کیا ہے۔
-
اعدادوشمار کو استعمال کرنے کا طریقہ جاننا مفید ہے۔ آپ کو تھرڈ پارٹی پروگرامز کی ضرورت نہیں ہے۔ آپ اندر آ سکتے ہیں، دیکھ سکتے ہیں، کچھ کر سکتے ہیں، کچھ کر سکتے ہیں۔
-
اعداد و شمار کا استعمال مشکل نہیں ہے، یہ صرف باقاعدہ SQL ہے۔ آپ نے درخواست جمع کی، اسے مرتب کیا، بھیج دیا، اسے دیکھا۔
-
اعداد و شمار سوالات کے جوابات میں مدد کرتے ہیں۔ اگر آپ کے سوالات ہیں، تو آپ اعدادوشمار کی طرف رجوع کریں - دیکھیں، نتائج اخذ کریں، نتائج کا تجزیہ کریں۔
-
اور تجربہ۔ بہت ساری درخواستیں ہیں، بہت سارے ڈیٹا ہیں۔ آپ ہمیشہ ایک موجودہ استفسار کو بہتر بنا سکتے ہیں۔ آپ اس درخواست کا اپنا ورژن بنا سکتے ہیں جو آپ کے لیے اصل سے زیادہ مناسب ہو اور اسے استعمال کریں۔
حوالہ جات
مناسب روابط جو مضمون میں پائے گئے، مواد پر مبنی، رپورٹ میں تھے۔
مصنف مزید لکھیں۔
(انگریزی)
شماریات جمع کرنے والا
سسٹم ایڈمنسٹریشن کے افعال
ماڈیولز کا تعاون کریں۔
ایس کیو ایل یوٹیلز اور ایس کیو ایل کوڈ کی مثالیں۔
آپ کی توجہ کے لیے آپ سب کا شکریہ!
ماخذ: www.habr.com