میرا مشورہ ہے کہ آپ 2016 کے آغاز سے آندرے سالنیکوف کی رپورٹ کا ٹرانسکرپٹ پڑھیں "ایپلی کیشنز میں مخصوص غلطیاں جو postgresql میں پھولنے کا باعث بنتی ہیں"
اس رپورٹ میں، میں ایپلی کیشنز میں ان بنیادی خامیوں کا تجزیہ کروں گا جو ایپلیکیشن کوڈ کو ڈیزائن کرنے اور لکھنے کے مرحلے پر پیدا ہوتی ہیں۔ اور میں صرف وہی غلطیاں لوں گا جو Postgresql میں پھولنے کا باعث بنتی ہیں۔ ایک اصول کے طور پر، یہ آپ کے سسٹم کی مجموعی کارکردگی کے اختتام کا آغاز ہے، حالانکہ ابتدائی طور پر اس کے لیے کوئی شرط نظر نہیں آتی تھی۔
سب کو خوش آمدید کہتے ہوئے خوشی ہوئی! یہ رپورٹ میرے ساتھی کی طرف سے پچھلی رپورٹ کی طرح تکنیکی نہیں ہے۔ اس رپورٹ کا مقصد بنیادی طور پر بیک اینڈ سسٹم ڈویلپرز کے لیے ہے کیونکہ ہمارے پاس کلائنٹس کی کافی بڑی تعداد ہے۔ اور وہ سب ایک جیسی غلطیاں کرتے ہیں۔ میں آپ کو ان کے بارے میں بتاؤں گا۔ میں وضاحت کروں گا کہ یہ غلطیاں کن مہلک اور بری چیزوں کا باعث بنتی ہیں۔
غلطیاں کیوں کی جاتی ہیں؟ وہ دو وجوہات کی بناء پر کیے جاتے ہیں: بے ترتیب طور پر، شاید یہ کام کرے گا اور کچھ میکانزم سے لاعلمی کی وجہ سے جو ڈیٹا بیس اور ایپلیکیشن کے درمیان سطح پر ہوتے ہیں، ساتھ ہی ساتھ ڈیٹا بیس میں بھی۔
میں آپ کو خوفناک تصویروں کے ساتھ تین مثالیں دوں گا کہ حالات کیسے خراب ہوئے۔ میں آپ کو وہاں ہونے والے میکانزم کے بارے میں مختصراً بتاؤں گا۔ اور ان سے کیسے نمٹا جائے، کب ہوا، اور غلطیوں کو روکنے کے لیے کون سے احتیاطی طریقے استعمال کیے جائیں۔ میں آپ کو معاون ٹولز کے بارے میں بتاؤں گا اور مفید لنکس فراہم کروں گا۔
میں نے ایک ٹیسٹ ڈیٹا بیس استعمال کیا جہاں میرے پاس دو میزیں تھیں۔ ایک پلیٹ کسٹمر اکاؤنٹس کے ساتھ، دوسری پلیٹ ان اکاؤنٹس پر لین دین کے ساتھ۔ اور کچھ تعدد کے ساتھ ہم ان اکاؤنٹس پر بیلنس اپ ڈیٹ کرتے ہیں۔
پلیٹ کا ابتدائی ڈیٹا: یہ کافی چھوٹا ہے، 2 MB۔ ڈیٹا بیس کے لیے اور خاص طور پر نشان کے لیے رسپانس ٹائم بھی بہت اچھا ہے۔ اور کافی اچھا بوجھ - پلیٹ کے مطابق فی سیکنڈ 2 آپریشنز۔
اور اس رپورٹ کے ذریعے میں آپ کو گراف دکھاؤں گا تاکہ آپ واضح طور پر سمجھ سکیں کہ کیا ہو رہا ہے۔ گراف کے ساتھ ہمیشہ 2 سلائیڈیں ہوں گی۔ پہلی سلائیڈ وہی ہے جو سرور پر عام طور پر ہوتا ہے۔
اور اس صورت حال میں، ہم دیکھتے ہیں کہ ہمارے پاس واقعی ایک چھوٹا سا نشان ہے. انڈیکس 2 MB پر چھوٹا ہے۔ یہ بائیں طرف پہلا گراف ہے۔
سرور پر اوسط جوابی وقت بھی مستحکم اور مختصر ہے۔ یہ اوپری دائیں گراف ہے۔
نیچے بائیں گراف سب سے طویل لین دین دکھاتا ہے۔ ہم دیکھتے ہیں کہ لین دین تیزی سے مکمل ہوتا ہے۔ اور آٹو ویکیوم ابھی تک یہاں کام نہیں کرتا ہے، کیونکہ یہ ایک ابتدائی ٹیسٹ تھا۔ یہ کام کرتا رہے گا اور ہمارے لیے مفید رہے گا۔
دوسری سلائیڈ ہمیشہ پلیٹ کی جانچ کے لیے وقف ہو گی۔ اس صورت حال میں، ہم کلائنٹ کے اکاؤنٹ کے بیلنس کو مسلسل اپ ڈیٹ کرتے رہتے ہیں۔ اور ہم دیکھتے ہیں کہ اپ ڈیٹ آپریشن کے لیے اوسط جوابی وقت کافی اچھا ہے، ایک ملی سیکنڈ سے بھی کم۔ ہم دیکھتے ہیں کہ پروسیسر کے وسائل (یہ اوپری دائیں گراف ہے) بھی یکساں طور پر اور کافی چھوٹے استعمال کیے جاتے ہیں۔
نیچے کا دائیں گراف دکھاتا ہے کہ اپ ڈیٹ کرنے سے پہلے ہم اپنی مطلوبہ لائن کی تلاش میں کتنی آپریٹنگ اور ڈسک میموری سے گزرتے ہیں۔ اور نشانی کے مطابق آپریشنز کی تعداد 2 فی سیکنڈ ہے جیسا کہ میں نے شروع میں کہا تھا۔
اور اب ہمارے ساتھ ایک المیہ ہے۔ کسی وجہ سے ایک طویل فراموش شدہ لین دین ہے۔ وجوہات عام طور پر تمام عام ہیں:
- سب سے عام میں سے ایک یہ ہے کہ ہم نے ایپلیکیشن کوڈ میں ایک بیرونی سروس تک رسائی حاصل کرنا شروع کر دی ہے۔ اور یہ خدمت ہمیں جواب نہیں دیتی۔ یعنی، ہم نے ایک ٹرانزیکشن کھولی، ڈیٹا بیس میں تبدیلی کی اور ایپلیکیشن سے میل پڑھنے یا اپنے انفراسٹرکچر کے اندر موجود کسی اور سروس پر گئے، اور کسی وجہ سے یہ ہمیں جواب نہیں دیتا ہے۔ اور ہمارا اجلاس ایک ایسی حالت میں پھنس گیا ہے جہاں یہ معلوم نہیں ہے کہ یہ کب حل ہوگا۔
- دوسری صورت حال وہ ہے جب ہمارے کوڈ میں کسی وجہ سے کوئی استثناء واقع ہوا ہے۔ اور استثناء میں ہم نے لین دین کے بند ہونے پر کارروائی نہیں کی۔ اور ہم نے کھلے لین دین کے ساتھ ہینگ سیشن کا اختتام کیا۔
- اور آخری معاملہ بھی کافی عام ہے۔ یہ کم معیار کا کوڈ ہے۔ کچھ فریم ورک ایک لین دین کھولتے ہیں۔ یہ لٹکا ہوا ہے، اور ہو سکتا ہے آپ کو ایپلی کیشن میں معلوم نہ ہو کہ آپ نے اسے لٹکا دیا ہے۔
ایسی باتیں کہاں لے جاتی ہیں؟
یہاں تک کہ ہماری میزیں اور اشاریہ جات ڈرامائی طور پر پھولنے لگتے ہیں۔ یہ بالکل ایک ہی بلوٹ اثر ہے. ڈیٹا بیس کے لیے، اس کا مطلب یہ ہوگا کہ ڈیٹا بیس کے رسپانس ٹائم میں بہت تیزی سے اضافہ ہوگا اور ڈیٹا بیس سرور پر بوجھ بڑھے گا۔ اور اس کے نتیجے میں ہماری درخواست کو نقصان پہنچے گا۔ کیونکہ اگر آپ نے ڈیٹا بیس کی درخواست پر اپنے کوڈ میں 10 ملی سیکنڈ، اپنی منطق پر 10 ملی سیکنڈ خرچ کیے، تو آپ کے فنکشن کو مکمل ہونے میں 20 ملی سیکنڈ لگے۔ اور اب تمہاری حالت بہت افسوسناک ہو گی۔
اور دیکھتے ہیں کیا ہوتا ہے۔ نیچے بائیں گراف سے پتہ چلتا ہے کہ ہمارے پاس ایک طویل لین دین ہے۔ اور اگر ہم اوپری بائیں گراف کو دیکھیں تو ہم دیکھتے ہیں کہ ہمارے ٹیبل کا سائز اچانک دو میگا بائٹس سے بڑھ کر 300 میگا بائٹس ہو گیا ہے۔ ایک ہی وقت میں، ٹیبل میں ڈیٹا کی مقدار میں کوئی تبدیلی نہیں آئی ہے، یعنی وہاں کافی حد تک کوڑا کرکٹ موجود ہے۔
اوسط سرور رسپانس ٹائم کے حوالے سے عمومی صورتحال بھی شدت کے کئی آرڈرز سے بدل گئی ہے۔ یعنی سرور پر تمام درخواستیں مکمل طور پر گرنے لگیں۔ اور اسی وقت، اندرونی پوسٹگریس عمل کو آٹو ویکیوم کی شکل میں شروع کیا گیا، جو کچھ کرنے کی کوشش کر رہے ہیں اور وسائل استعمال کر رہے ہیں۔
ہمارے نشان کے ساتھ کیا ہو رہا ہے؟ ایسا ہی. نشانی کے مطابق ہمارا اوسط ردعمل کا وقت کئی درجے بڑھ گیا ہے۔ خاص طور پر استعمال شدہ وسائل کے لحاظ سے، ہم دیکھتے ہیں کہ پروسیسر پر بوجھ بہت بڑھ گیا ہے۔ یہ اوپری دائیں گراف ہے۔ اور اس میں اضافہ ہوا ہے کیونکہ پروسیسر کو ضرورت کی تلاش میں بیکار لائنوں کے ایک گروپ سے چھانٹنا پڑتا ہے۔ یہ نیچے کا دائیں گراف ہے۔ اور اس کے نتیجے میں، فی سیکنڈ ہماری کالز کی تعداد میں بہت زیادہ کمی آنے لگی، کیونکہ ڈیٹا بیس کے پاس اتنی ہی درخواستوں پر کارروائی کرنے کا وقت نہیں تھا۔
ہمیں زندگی کی طرف واپس جانے کی ضرورت ہے۔ ہم آن لائن جاتے ہیں اور معلوم کرتے ہیں کہ طویل لین دین مسائل کا باعث بنتے ہیں۔ ہم اس لین دین کو ڈھونڈتے اور مار ڈالتے ہیں۔ اور ہمارے لیے سب کچھ نارمل ہوتا جا رہا ہے۔ سب کچھ کام کرتا ہے جیسا کہ اسے کرنا چاہئے۔
ہم پرسکون ہو گئے، لیکن تھوڑی دیر کے بعد ہم نے محسوس کرنا شروع کر دیا کہ ایپلی کیشن ایمرجنسی سے پہلے کی طرح کام نہیں کرتی۔ درخواستوں پر اب بھی آہستہ اور نمایاں طور پر آہستہ کارروائی کی جاتی ہے۔ خاص طور پر میری مثال میں ڈیڑھ سے دو گنا سست۔ سرور پر لوڈ بھی حادثے سے پہلے کے مقابلے زیادہ ہے۔
اور سوال: "اس وقت بیس پر کیا ہو رہا ہے؟" اور مندرجہ ذیل صورت حال بیس کے ساتھ ہوتی ہے۔ لین دین کے چارٹ پر آپ دیکھ سکتے ہیں کہ یہ رک گیا ہے اور واقعی کوئی طویل مدتی لین دین نہیں ہے۔ لیکن حادثے کے دوران نشان کا سائز مہلک طور پر بڑھ گیا۔ اور تب سے ان میں کوئی کمی نہیں آئی۔ بیس پر اوسط وقت مستحکم ہو گیا ہے۔ اور ایسا لگتا ہے کہ جوابات ہمارے لئے قابل قبول رفتار سے مناسب طریقے سے آرہے ہیں۔ آٹو ویکیوم زیادہ فعال ہو گیا اور اس نے نشان کے ساتھ کچھ کرنا شروع کر دیا، کیونکہ اسے مزید ڈیٹا کو چھاننے کی ضرورت ہے۔
خاص طور پر، اکاؤنٹس کے ساتھ ٹیسٹ پلیٹ کے مطابق، جہاں ہم بیلنس تبدیل کرتے ہیں: ایسا لگتا ہے کہ درخواست کے جواب کا وقت معمول پر آ گیا ہے۔ لیکن حقیقت میں یہ ڈیڑھ گنا زیادہ ہے۔
اور پروسیسر پر بوجھ سے، ہم دیکھتے ہیں کہ پروسیسر پر لوڈ کریش سے پہلے مطلوبہ قدر پر واپس نہیں آیا ہے۔ اور اس کی وجوہات بالکل نیچے دائیں گراف میں موجود ہیں۔ دیکھا جا سکتا ہے کہ وہاں میموری کی ایک خاص مقدار تلاش کی جا رہی ہے۔ یعنی مطلوبہ لائن تلاش کرنے کے لیے، ہم ڈیٹا بیس سرور کے وسائل کو ضائع کرتے ہیں جبکہ بیکار ڈیٹا کو چھانٹتے ہیں۔ فی سیکنڈ لین دین کی تعداد مستحکم ہو گئی ہے۔
مجموعی طور پر اچھا ہے، لیکن صورت حال پہلے سے کہیں زیادہ خراب ہے۔ اس ڈیٹا بیس کے ساتھ کام کرنے والی ہماری درخواست کے نتیجے میں ڈیٹا بیس کے انحطاط کو صاف کریں۔
اور یہ سمجھنے کے لیے کہ وہاں کیا ہو رہا ہے، اگر آپ پچھلی رپورٹ میں نہیں تھے، تو اب ایک چھوٹا سا نظریہ دیکھتے ہیں۔ اندرونی عمل کے بارے میں نظریہ۔ کار ویکیوم کیوں اور کیا کرتا ہے؟
سمجھنے کے لیے لفظی طور پر مختصراً۔ کسی وقت ہمارے پاس ایک میز ہے۔ ہمارے پاس ٹیبل میں قطاریں ہیں۔ یہ لائنیں فعال، زندہ، اور اب ہمیں کیا ضرورت ہو سکتی ہیں۔ وہ تصویر میں سبز رنگ میں نشان زد ہیں۔ اور ایسی ڈیڈ لائنیں ہیں جن پر پہلے ہی کام کیا جا چکا ہے، اپ ڈیٹ کر دیا گیا ہے، اور ان پر نئی اندراجات سامنے آئی ہیں۔ اور ان پر نشان لگا دیا گیا ہے کہ وہ ڈیٹا بیس میں مزید دلچسپی نہیں رکھتے۔ لیکن وہ پوسٹگریس کی خصوصیت کی وجہ سے ٹیبل میں ہیں۔
آپ کو کار ویکیوم کی ضرورت کیوں ہے؟ کسی وقت، آٹو ویکیوم آتا ہے، ڈیٹا بیس تک رسائی حاصل کرتا ہے اور اس سے پوچھتا ہے: "براہ کرم مجھے سب سے پرانے لین دین کی آئی ڈی دیں جو فی الحال ڈیٹا بیس میں کھلا ہے۔" ڈیٹا بیس اس آئی ڈی کو لوٹاتا ہے۔ اور آٹو ویکیوم، اس پر بھروسہ کرتے ہوئے، ٹیبل میں لائنوں کے ذریعے ترتیب دیتا ہے۔ اور اگر وہ دیکھتا ہے کہ کچھ لائنیں بہت پرانے لین دین کے ذریعے تبدیل کی گئی ہیں، تو اسے ان لائنوں کے طور پر نشان زد کرنے کا حق ہے جنہیں ہم مستقبل میں نئے ڈیٹا لکھ کر دوبارہ استعمال کر سکتے ہیں۔ یہ پس منظر کا عمل ہے۔
اس وقت، ہم ڈیٹا بیس کے ساتھ کام کرنا جاری رکھتے ہیں اور ٹیبل میں کچھ تبدیلیاں کرتے رہتے ہیں۔ اور ان خطوط پر، جنہیں ہم دوبارہ استعمال کر سکتے ہیں، ہم نیا ڈیٹا لکھتے ہیں۔ اور اس طرح ہمیں ایک سائیکل ملتا ہے، یعنی ہر وقت کچھ مردہ پرانی لکیریں وہاں نظر آتی ہیں، ان کے بجائے ہم نئی لائنیں لکھتے ہیں جن کی ہمیں ضرورت ہے۔ اور PostgreSQL کے کام کرنے کے لیے یہ ایک عام حالت ہے۔
حادثے کے دوران کیا ہوا؟ وہاں یہ عمل کیسے ہوا؟
ہمارے پاس کچھ حالت میں نشان تھا، کچھ زندہ، کچھ مردہ لائنیں. کار ویکیوم آ گیا ہے۔ اس نے ڈیٹا بیس سے پوچھا کہ ہمارا سب سے پرانا لین دین کیا ہے اور اس کی آئی ڈی کیا ہے۔ مجھے یہ آئی ڈی موصول ہوئی تھی، جو کئی گھنٹے پہلے کی ہو سکتی ہے، شاید دس منٹ پہلے۔ یہ اس بات پر منحصر ہے کہ آپ کے ڈیٹا بیس پر کتنا بوجھ ہے۔ اور وہ لائنوں کی تلاش میں چلا گیا جسے وہ دوبارہ استعمال کے طور پر نشان زد کر سکے۔ اور مجھے ہمارے ٹیبل میں ایسی لائنیں نہیں ملیں۔
لیکن اس وقت ہم میز کے ساتھ کام جاری رکھے ہوئے ہیں۔ ہم اس میں کچھ کرتے ہیں، اسے اپ ڈیٹ کرتے ہیں، ڈیٹا کو تبدیل کرتے ہیں۔ اس وقت ڈیٹا بیس کو کیا کرنا چاہیے؟ اس کے پاس موجودہ ٹیبل کے آخر میں نئی لائنیں شامل کرنے کے سوا کوئی چارہ نہیں ہے۔ اور اس طرح ہماری میز کا سائز پھولنا شروع ہو جاتا ہے۔
حقیقت میں، ہمیں کام کرنے کے لیے گرین لائنز کی ضرورت ہے۔ لیکن اس طرح کے مسئلے کے دوران، یہ پتہ چلتا ہے کہ پوری میز پر سبز لائنوں کا فیصد بہت کم ہے.
اور جب ہم کوئی استفسار کرتے ہیں، ڈیٹا بیس کو تمام لائنوں سے گزرنا پڑتا ہے: سرخ اور سبز دونوں، مطلوبہ لائن تلاش کرنے کے لیے۔ اور بیکار ڈیٹا کے ساتھ میز کو پھولنے کے اثر کو "بلوٹ" کہا جاتا ہے، جو ہماری ڈسک کی جگہ کو بھی کھا جاتا ہے۔ یاد رکھیں، یہ 2 MB تھا، یہ 300 MB ہو گیا؟ اب میگا بائٹس کو گیگا بائٹس میں تبدیل کریں اور آپ اپنے تمام ڈسک وسائل کو تیزی سے کھو دیں گے۔
ہمارے لیے کیا نتائج ہو سکتے ہیں؟
- میری مثال میں، ٹیبل اور انڈیکس میں 150 گنا اضافہ ہوا۔ ہمارے کچھ کلائنٹس کو زیادہ مہلک کیسز ہوئے ہیں جب انہوں نے ڈسک کی جگہ ختم کرنا شروع کردی۔
- میزوں کا سائز خود کبھی کم نہیں ہوگا۔ کچھ معاملات میں آٹو ویکیوم میز کی دم کو کاٹ سکتا ہے اگر صرف ڈیڈ لائنیں ہوں۔ لیکن چونکہ مسلسل گردش ہوتی رہتی ہے، اس لیے ایک سبز لائن آخر میں جم سکتی ہے اور اسے اپ ڈیٹ نہیں کیا جا سکتا، جب کہ باقی سب پلیٹ کے شروع میں کہیں لکھ دی جائیں گی۔ لیکن یہ ایک ایسا غیر متوقع واقعہ ہے کہ آپ کی میز خود ہی سائز میں سکڑ جائے گی، لہذا آپ کو اس کی امید نہیں رکھنی چاہیے۔
- ڈیٹا بیس کو بیکار لائنوں کے پورے گروپ کو ترتیب دینے کی ضرورت ہے۔ اور ہم ڈسک کے وسائل ضائع کرتے ہیں، ہم پروسیسر کے وسائل اور بجلی ضائع کرتے ہیں۔
- اور یہ براہ راست ہماری درخواست پر اثرانداز ہوتا ہے، کیونکہ اگر شروع میں ہم نے درخواست پر 10 ملی سیکنڈ، اپنے کوڈ پر 10 ملی سیکنڈ خرچ کیے، تو حادثے کے دوران ہم درخواست پر ایک سیکنڈ اور کوڈ پر 10 ملی سیکنڈ خرچ کرنے لگے، یعنی ایک آرڈر درخواست کی کارکردگی میں شدت کم ہوگئی۔ اور جب حادثہ حل ہو گیا تو ہم نے ایک درخواست پر 20 ملی سیکنڈ، کوڈ پر 10 ملی سیکنڈ خرچ کرنا شروع کر دیا۔ اس کا مطلب یہ ہے کہ ہماری پیداواری صلاحیت میں اب بھی ڈیڑھ گنا کمی آئی ہے۔ اور یہ سب ایک لین دین کی وجہ سے ہے جو منجمد ہو گیا، شاید ہماری غلطی سے۔
- اور سوال: "ہم سب کچھ واپس کیسے حاصل کر سکتے ہیں؟" تاکہ ہمارے ساتھ سب کچھ ٹھیک ہو اور درخواستیں حادثے سے پہلے کی طرح جلدی آئیں۔
اس مقصد کے لیے کام کا ایک خاص چکر لگایا جاتا ہے۔
سب سے پہلے ہمیں ان مسائل کی میزیں تلاش کرنے کی ضرورت ہے جو پھولے ہوئے ہیں۔ ہم سمجھتے ہیں کہ کچھ ٹیبلز میں ریکارڈنگ زیادہ فعال ہے، دوسروں میں کم فعال۔ اور اس کے لیے ہم ایکسٹینشن کا استعمال کرتے ہیں۔ . اس ایکسٹینشن کو انسٹال کرکے، آپ ایسے سوالات لکھ سکتے ہیں جو آپ کو کافی پھولی ہوئی میزیں تلاش کرنے میں مدد کریں گے۔
ایک بار جب آپ کو یہ میزیں مل جائیں تو آپ کو ان کو کمپریس کرنے کی ضرورت ہے۔ اس کے لیے پہلے سے ٹولز موجود ہیں۔ ہماری کمپنی میں ہم تین ٹولز استعمال کرتے ہیں۔ پہلا بلٹ ان ویکیوم فل ہے۔ وہ ظالم، سخت اور بے رحم ہے، لیکن بعض اوقات وہ بہت مفید ہوتا ہے۔ и - یہ میزیں کمپریس کرنے کے لیے تھرڈ پارٹی یوٹیلیٹیز ہیں۔ اور وہ ڈیٹا بیس کو زیادہ احتیاط سے پیش کرتے ہیں۔
ان کا استعمال اس بات پر ہوتا ہے کہ آپ کے لیے کیا زیادہ آسان ہے۔ لیکن میں آپ کو اس کے بارے میں آخر میں بتاؤں گا۔ اہم بات یہ ہے کہ تین ٹولز ہیں۔ منتخب کرنے کے لیے بہت کچھ ہے۔
جب ہم سب کچھ ٹھیک کر لیتے ہیں اور اس بات کو یقینی بناتے ہیں کہ سب کچھ ٹھیک ہے، ہمیں یہ جاننا چاہیے کہ مستقبل میں اس صورتحال کو کیسے روکا جائے:
- اسے کافی آسانی سے روکا جا سکتا ہے۔ آپ کو ماسٹر سرور پر سیشن کے دورانیے کی نگرانی کرنے کی ضرورت ہے۔ لین دین کی حالت میں بیکار میں خاص طور پر خطرناک سیشن. یہ وہ لوگ ہیں جنہوں نے ابھی ایک لین دین کھولا، کچھ کیا اور چھوڑ دیا، یا صرف لٹکا ہوا، کوڈ میں گم ہو گیا۔
- اور آپ کے لیے، بطور ڈیولپر، جب یہ حالات پیدا ہوں تو اپنے کوڈ کی جانچ کرنا ضروری ہے۔ یہ کرنا مشکل نہیں ہے۔ یہ ایک مفید چیک ہوگا۔ آپ طویل لین دین سے وابستہ "بچکانہ" مسائل کی ایک بڑی تعداد سے بچیں گے۔
ان گرافس میں، میں آپ کو دکھانا چاہتا تھا کہ اس معاملے میں VACUUM FULL کے ساتھ سائن سے گزرنے کے بعد ڈیٹا بیس کا نشان اور برتاؤ کیسے بدل گیا۔ یہ میرے لئے پیداوار نہیں ہے۔
ٹیبل کا سائز فوری طور پر چند میگا بائٹس کی اپنی عام آپریٹنگ حالت میں واپس آ گیا۔ اس نے سرور کے لیے اوسط جوابی وقت کو بہت زیادہ متاثر نہیں کیا۔
لیکن خاص طور پر ہمارے ٹیسٹ سائن کے لیے، جہاں ہم نے اکاؤنٹ بیلنس کو اپ ڈیٹ کیا، ہم دیکھتے ہیں کہ سائن میں ڈیٹا کو اپ ڈیٹ کرنے کی درخواست کے لیے اوسط جوابی وقت کو ایمرجنسی سے پہلے کی سطح تک کم کر دیا گیا تھا۔ اس درخواست کو مکمل کرنے کے لیے پروسیسر کے ذریعے استعمال کیے گئے وسائل بھی کریش سے پہلے کی سطح پر آ گئے۔ اور نیچے کا دائیں گراف دکھاتا ہے کہ اب ہمیں بالکل وہی لائن مل گئی ہے جس کی ہمیں فوراً ضرورت ہے، بغیر ڈیڈ لائنوں کے ان ڈھیروں سے گزرے جو میز کو سکیڑنے سے پہلے موجود تھیں۔ اور اوسط درخواست کا وقت تقریباً اسی سطح پر رہا۔ لیکن یہاں میرے ہارڈ ویئر میں ایک خرابی ہے۔
یہیں پر پہلی کہانی ختم ہوتی ہے۔ یہ سب سے عام ہے۔ اور یہ سب کے ساتھ ہوتا ہے، قطع نظر اس کے کہ کلائنٹ کے تجربے اور پروگرامرز کتنے اہل ہیں۔ جلد یا بدیر ایسا ہوتا ہے۔
دوسری کہانی، جس میں ہم لوڈ تقسیم کرتے ہیں اور سرور کے وسائل کو بہتر بناتے ہیں۔
- ہم پہلے ہی بڑے ہو چکے ہیں اور سنجیدہ لوگ بن چکے ہیں۔ اور ہم سمجھتے ہیں کہ ہمارے پاس ایک نقل ہے اور بوجھ کو متوازن کرنا ہمارے لیے اچھا ہوگا: ماسٹر کو لکھیں، اور نقل سے پڑھیں۔ اور عام طور پر یہ صورتحال اس وقت پیدا ہوتی ہے جب ہم کچھ رپورٹس یا ای ٹی ایل تیار کرنا چاہتے ہیں۔ اور کاروبار اس سے بہت خوش ہے۔ وہ واقعی پیچیدہ تجزیات کے ساتھ مختلف قسم کی رپورٹس چاہتا ہے۔
- رپورٹس میں کئی گھنٹے لگتے ہیں، کیونکہ پیچیدہ تجزیات کو ملی سیکنڈ میں شمار نہیں کیا جا سکتا۔ ہم بہادر لڑکوں کی طرح کوڈ لکھتے ہیں۔ داخل کرنے کی درخواست میں ہم ماسٹر پر ریکارڈنگ کرتے ہیں، اور نقل پر رپورٹس کو انجام دیتے ہیں۔
- بوجھ تقسیم کرنا۔
- سب کچھ بالکل ٹھیک کام کرتا ہے۔ ہم بہت اچھے ہیں۔
اور یہ صورت حال کیسی نظر آتی ہے؟ خاص طور پر ان گرافس پر، میں نے لین دین کی مدت کے لیے نقل سے لین دین کی مدت بھی شامل کی ہے۔ دیگر تمام گراف صرف ماسٹر سرور کا حوالہ دیتے ہیں۔
اس وقت تک، میرا رپورٹ بورڈ بڑھ چکا تھا۔ ان میں سے زیادہ ہیں۔ ہم دیکھتے ہیں کہ سرور کا اوسط جوابی وقت مستحکم ہے۔ ہم دیکھتے ہیں کہ نقل پر ہمارے پاس طویل عرصے سے چلنے والا لین دین ہے جو 2 گھنٹے تک چلتا ہے۔ ہم آٹو ویکیوم کا خاموش آپریشن دیکھتے ہیں، جو ڈیڈ لائنوں پر کارروائی کرتا ہے۔ اور ہمارے ساتھ سب کچھ ٹھیک ہے۔
خاص طور پر، ٹیسٹ شدہ پلیٹ کے مطابق، ہم وہاں اکاؤنٹ بیلنس کو اپ ڈیٹ کرتے رہتے ہیں۔ اور ہمارے پاس درخواستوں، مستحکم وسائل کی کھپت کے لیے ایک مستحکم جوابی وقت بھی ہے۔ ہمارے ساتھ سب کچھ ٹھیک ہے۔
اس لمحے تک سب کچھ ٹھیک ہے جب تک کہ نقل کے ساتھ تنازعہ کی وجہ سے یہ رپورٹس واپس آنا شروع نہ ہوں۔ اور وہ باقاعدہ وقفوں سے جوابی فائرنگ کرتے ہیں۔
ہم آن لائن جاتے ہیں اور پڑھنا شروع کرتے ہیں کہ ایسا کیوں ہو رہا ہے۔ اور ہم ایک حل تلاش کرتے ہیں۔
پہلا حل نقل کی تاخیر کو بڑھانا ہے۔ ہم جانتے ہیں کہ ہماری رپورٹ 3 گھنٹے تک چلتی ہے۔ ہم نے نقل کی تاخیر کو 3 گھنٹے پر مقرر کیا۔ ہم سب کچھ شروع کر رہے ہیں، لیکن ہمیں اب بھی بعض اوقات منسوخ ہونے کی اطلاعات کے ساتھ مسائل کا سامنا کرنا پڑتا ہے۔
ہم چاہتے ہیں کہ سب کچھ کامل ہو۔ ہم مزید چڑھتے ہیں۔ اور ہمیں انٹرنیٹ پر ایک ٹھنڈی ترتیب ملی - hot_standby_feedback۔ آئیے اسے آن کریں۔ Hot_standby_feedback ہمیں ماسٹر پر آٹو ویکیوم کو روکنے کی اجازت دیتا ہے۔ اس طرح، ہم نقل کے تنازعات سے مکمل طور پر چھٹکارا پاتے ہیں۔ اور رپورٹس کے ساتھ ہمارے لیے سب کچھ اچھا کام کرتا ہے۔
اور اس وقت ماسٹر سرور کے ساتھ کیا ہو رہا ہے؟ اور ہم ماسٹر سرور کے ساتھ مکمل پریشانی میں ہیں۔ اب ہم گراف دیکھ رہے ہیں جب میں نے ان دونوں سیٹنگز کو فعال کیا ہے۔ اور ہم دیکھتے ہیں کہ ہماری نقل پر سیشن کسی نہ کسی طرح ماسٹر سرور پر صورتحال کو متاثر کرنے لگا۔ اس پر اثر ہوتا ہے کیونکہ اس نے آٹو ویکیوم کو روک دیا تھا، جو ڈیڈ لائنوں کو صاف کرتا ہے۔ ہماری میز کا سائز ایک بار پھر آسمان کو چھونے لگا ہے۔ پورے ڈیٹا بیس میں استفسار پر عمل درآمد کا اوسط وقت بھی آسمان کو چھونے لگا۔ آٹو ویکیوم تھوڑا سا سخت ہو گیا۔
خاص طور پر، ہماری پلیٹ سے، ہم دیکھتے ہیں کہ اس پر ڈیٹا اپ ڈیٹ بھی آسمانوں پر چھلانگ لگا دیتا ہے۔ اسی طرح CPU کی کھپت میں بھی بہت اضافہ ہوا ہے۔ ہم ایک بار پھر بڑی تعداد میں مردہ، بیکار لائنوں سے گزر رہے ہیں۔ اور اس نشان کے جوابی وقت اور لین دین کی تعداد میں کمی آئی ہے۔
یہ کیسا نظر آئے گا اگر ہم نہیں جانتے کہ میں پہلے کس کے بارے میں بات کر رہا تھا؟
- ہم مسائل کی تلاش شروع کر دیتے ہیں۔ اگر ہمیں پہلے حصے میں مسائل کا سامنا کرنا پڑا، تو ہم جانتے ہیں کہ یہ ایک طویل لین دین کی وجہ سے ہو سکتا ہے اور ماسٹر کے پاس جانا ہے۔ ہمیں ماسٹر پر مسئلہ ہے۔ اسے ساسیج کرتا ہے۔ یہ گرم ہوتا ہے، اس کا لوڈ اوسط تقریباً سو ہے۔
- وہاں کی درخواستیں سست ہیں، لیکن ہمیں وہاں طویل عرصے سے چلنے والا کوئی لین دین نظر نہیں آتا ہے۔ اور ہم نہیں سمجھتے کہ معاملہ کیا ہے۔ ہمیں سمجھ نہیں آرہا کہ کہاں دیکھیں۔
- ہم سرور کا سامان چیک کرتے ہیں۔ شاید ہمارا چھاپہ گر گیا۔ شاید ہماری میموری اسٹک جل گئی ہے۔ ہاں کچھ بھی ہو سکتا ہے۔ لیکن نہیں، سرور نئے ہیں، سب کچھ ٹھیک کام کرتا ہے۔
- ہر کوئی چل رہا ہے: منتظمین، ڈویلپرز اور ڈائریکٹر۔ کچھ بھی مدد نہیں کرتا۔
- اور کسی وقت اچانک سب کچھ خود کو درست کرنا شروع کر دیتا ہے۔
اس وقت، ہماری نقل پر درخواست پر کارروائی کی گئی اور اسے چھوڑ دیا گیا۔ ہمیں رپورٹ مل گئی۔ کاروبار اب بھی خوش حال ہے۔ جیسا کہ آپ دیکھ سکتے ہیں، ہمارا نشان دوبارہ بڑھ گیا ہے اور سکڑنے والا نہیں ہے۔ سیشن کے ساتھ گراف پر، میں نے نقل سے اس طویل لین دین کا ایک ٹکڑا چھوڑا ہے تاکہ آپ اندازہ لگا سکیں کہ صورتحال کے مستحکم ہونے میں کتنا وقت لگتا ہے۔
سیشن ختم ہو چکا ہے۔ اور کچھ وقت کے بعد ہی سرور کم و بیش ترتیب میں آجاتا ہے۔ اور ماسٹر سرور پر درخواستوں کا اوسط جوابی وقت معمول پر آجاتا ہے۔ کیونکہ، آخر کار، آٹو ویکیوم کو ان ڈیڈ لائنوں کو صاف کرنے اور نشان زد کرنے کا موقع ملتا ہے۔ اور اپنا کام کرنے لگا۔ اور وہ کتنی جلدی کرتا ہے، اتنی جلدی ہم ترتیب میں آجائیں گے۔
ٹیسٹ شدہ ٹیبلٹ کے مطابق، جہاں ہم اکاؤنٹ بیلنس کو اپ ڈیٹ کرتے ہیں، ہمیں بالکل وہی تصویر نظر آتی ہے۔ اوسط اکاؤنٹ اپ ڈیٹ کا وقت بھی آہستہ آہستہ معمول پر آ رہا ہے۔ پروسیسر کے ذریعہ استعمال ہونے والے وسائل بھی کم ہوجاتے ہیں۔ اور فی سیکنڈ لین دین کی تعداد معمول پر آجاتی ہے۔ لیکن ہم ایک بار پھر معمول پر آ گئے ہیں، جیسا کہ ہم حادثے سے پہلے تھے۔
کسی بھی صورت میں، ہمیں کارکردگی میں کمی آتی ہے، جیسا کہ پہلی صورت میں، ڈیڑھ سے دو گنا، اور کبھی کبھی اس سے بھی زیادہ۔
ایسا لگتا ہے کہ ہم نے سب کچھ ٹھیک کر لیا ہے۔ بوجھ تقسیم کریں۔ سامان بیکار نہیں ہے۔ ہم نے اپنے ذہن کے مطابق درخواستیں تقسیم کیں لیکن پھر بھی سب کچھ خراب نکلا۔
- hot_standby_feedback کو فعال نہیں کرتے ہیں؟ ہاں، خاص طور پر مضبوط وجوہات کے بغیر اسے آن کرنے کی سفارش نہیں کی جاتی ہے۔ کیونکہ یہ موڑ براہ راست ماسٹر سرور کو متاثر کرتا ہے اور وہاں آٹو ویکیوم کے آپریشن کو معطل کر دیتا ہے۔ اسے کچھ نقل پر فعال کرکے اور اس کے بارے میں بھول کر، آپ ماسٹر کو مار سکتے ہیں اور ایپلیکیشن کے ساتھ بڑی پریشانیوں کا سامنا کر سکتے ہیں۔
- max_standby_streaming_delay میں اضافہ کریں؟ ہاں، رپورٹس کے لیے یہ سچ ہے۔ اگر آپ کے پاس تین گھنٹے کی رپورٹ ہے اور آپ نہیں چاہتے کہ نقل کے تنازعات کی وجہ سے یہ کریش ہو، تو بس تاخیر میں اضافہ کریں۔ ایک طویل مدتی رپورٹ کو کبھی بھی ڈیٹا کی ضرورت نہیں ہوتی ہے جو ابھی ڈیٹا بیس میں آیا ہے۔ اگر آپ کے پاس یہ تین گھنٹے کے لیے ہے، تو آپ اسے کچھ پرانے ڈیٹا کی مدت کے لیے چلا رہے ہیں۔ اور آپ کے لیے، چاہے تین گھنٹے کی تاخیر ہو یا چھ گھنٹے کی تاخیر سے کوئی فرق نہیں پڑے گا، لیکن آپ کو مسلسل رپورٹس موصول ہوں گی اور ان کے گرنے سے کوئی پریشانی نہیں ہوگی۔
- قدرتی طور پر، آپ کو نقلوں پر طویل سیشنز کو کنٹرول کرنے کی ضرورت ہے، خاص طور پر اگر آپ ریپلیکا پر hot_standby_feedback کو فعال کرنے کا فیصلہ کرتے ہیں۔ کیونکہ کچھ بھی ہو سکتا ہے۔ ہم نے یہ نقل ڈویلپر کو دی ہے تاکہ وہ درخواستوں کی جانچ کر سکے۔ اس نے ایک دیوانہ وار درخواست لکھی۔ اس نے اسے لانچ کیا اور چائے پینے چلا گیا، اور ہمیں قائم ماسٹر مل گیا۔ یا شاید ہم نے وہاں غلط درخواست ڈال دی ہے۔ حالات مختلف ہیں۔ نقل پر سیشنز کی نگرانی ماسٹر کی طرح احتیاط سے کی جانی چاہیے۔
- اور اگر آپ کے پاس نقل کے بارے میں تیز اور طویل سوالات ہیں، تو اس صورت میں یہ بہتر ہے کہ بوجھ تقسیم کرنے کے لیے ان کو تقسیم کریں۔ یہ streaming_delay کا لنک ہے۔ تیز رفتار والوں کے لیے، نقل میں تھوڑی تاخیر کے ساتھ ایک نقل رکھیں۔ طویل عرصے سے چلنے والی رپورٹنگ کی درخواستوں کے لیے، ایک نقل رکھیں جو 6 گھنٹے یا ایک دن پیچھے رہ سکتی ہے۔ یہ بالکل نارمل صورتحال ہے۔
ہم نتائج کو اسی طرح ختم کرتے ہیں:
- ہمیں پھولی ہوئی میزیں ملتی ہیں۔
- اور ہم اسے سب سے آسان ٹول کے ساتھ کمپریس کرتے ہیں جو ہمارے لیے مناسب ہے۔
دوسری کہانی یہیں ختم ہوتی ہے۔ آئیے تیسری کہانی کی طرف چلتے ہیں۔
ہمارے لیے بھی کافی عام ہے جس میں ہم ہجرت کرتے ہیں۔
- کوئی بھی سافٹ ویئر پروڈکٹ بڑھ رہا ہے۔ اس کے تقاضے بدل رہے ہیں۔ کسی بھی صورت میں، ہم ترقی کرنا چاہتے ہیں. اور ایسا ہوتا ہے کہ ہمیں جدول میں موجود ڈیٹا کو اپ ڈیٹ کرنے کی ضرورت ہوتی ہے، یعنی اس نئی فعالیت کے لیے جو ہم اپنی ترقی کے حصے کے طور پر متعارف کروا رہے ہیں، اپنی منتقلی کے لحاظ سے ایک اپ ڈیٹ کو چلانے کے لیے۔
- پرانا ڈیٹا فارمیٹ تسلی بخش نہیں ہے۔ آئیے کہتے ہیں کہ اب ہم دوسرے ٹیبل کی طرف آتے ہیں، جہاں میں ان اکاؤنٹس پر لین دین کرتا ہوں۔ اور ہم کہتے ہیں کہ وہ روبل میں تھے، اور ہم نے درستگی کو بڑھانے اور اسے کوپیکس میں کرنے کا فیصلہ کیا۔ اور اس کے لیے ہمیں ایک اپ ڈیٹ کرنے کی ضرورت ہے: لین دین کی رقم کے ساتھ فیلڈ کو ایک سو سے ضرب دیں۔
- آج کی دنیا میں، ہم خودکار ڈیٹا بیس ورژن کنٹرول ٹولز استعمال کرتے ہیں۔ چلو ہم کہتے ہیں کہ . ہم وہاں اپنی ہجرت کا اندراج کرتے ہیں۔ ہم اسے اپنے ٹیسٹ بیس پر آزماتے ہیں۔ سب کچھ ٹھیک ہے. اپ ڈیٹ سے گزر رہا ہے۔ یہ تھوڑی دیر کے لیے کام کو روکتا ہے، لیکن ہمیں تازہ ترین ڈیٹا ملتا ہے۔ اور ہم اس پر نئی فعالیت شروع کر سکتے ہیں۔ ہر چیز کی جانچ اور جانچ کی گئی۔ ہر چیز کی تصدیق ہوگئی۔
- ہم نے منصوبہ بند کام کیا اور ہجرت کی۔
یہاں آپ کے سامنے پیش کردہ اپ ڈیٹ کے ساتھ منتقلی ہے۔ چونکہ یہ میرے اکاؤنٹ کی ٹرانزیکشنز ہیں، اس لیے پلیٹ 15 جی بی تھی۔ اور چونکہ ہم ہر لائن کو اپ ڈیٹ کرتے ہیں، ہم نے اپ ڈیٹ کے ساتھ ٹیبل کا سائز دوگنا کر دیا، کیونکہ ہم نے ہر لائن کو دوبارہ لکھا۔
منتقلی کے دوران، ہم اس پلیٹ کے ساتھ کچھ نہیں کر سکتے تھے، کیونکہ اس کی تمام درخواستوں کو قطار میں رکھا گیا تھا اور اس اپ ڈیٹ کے مکمل ہونے تک انتظار کیا گیا تھا۔ لیکن یہاں میں آپ کی توجہ ان نمبروں کی طرف مبذول کرانا چاہتا ہوں جو عمودی محور پر ہیں۔ یعنی، ہمارے پاس تقریباً 5 ملی سیکنڈ کی منتقلی سے پہلے درخواست کا اوسط وقت ہے اور پروسیسر لوڈ، ڈسک میموری کو پڑھنے کے لیے بلاک آپریشنز کی تعداد 7,5 سے کم ہے۔
ہم نے ہجرت کی اور دوبارہ مسائل کا سامنا کرنا پڑا۔
ہجرت کامیاب رہی، لیکن:
- پرانی فعالیت کو مکمل ہونے میں اب زیادہ وقت لگتا ہے۔
- میز پھر سے سائز میں بڑھ گئی۔
- سرور پر لوڈ پھر سے پہلے سے زیادہ ہو گیا۔
- اور، یقینا، ہم اب بھی اس فعالیت کے ساتھ ٹنکرنگ کر رہے ہیں جس نے اچھی طرح سے کام کیا، ہم نے اسے تھوڑا بہتر کیا ہے۔
اور یہ ایک بار پھر پھولنا ہے، جو ہماری زندگیوں کو دوبارہ برباد کر دیتا ہے۔
یہاں میں یہ ظاہر کرتا ہوں کہ ٹیبل، پچھلے دو صورتوں کی طرح، اپنے پچھلے سائز پر واپس نہیں جا رہا ہے۔ ایسا لگتا ہے کہ سرور کا اوسط بوجھ کافی ہے۔
اور اگر ہم کھاتوں کے ساتھ میز کی طرف رجوع کرتے ہیں، تو ہم دیکھیں گے کہ اس جدول کے لیے درخواست کا اوسط وقت دوگنا ہو گیا ہے۔ پروسیسر پر بوجھ اور میموری میں ترتیب دی گئی لائنوں کی تعداد 7,5 سے اوپر گئی، لیکن کم تھی۔ اور یہ پروسیسرز کے معاملے میں 2 بار، بلاک آپریشنز کے معاملے میں 1,5 گنا بڑھ گیا، یعنی ہمیں سرور کی کارکردگی میں کمی آئی۔ اور نتیجے کے طور پر - ہماری درخواست کی کارکردگی کا انحطاط۔ اسی وقت، کالوں کی تعداد تقریباً اسی سطح پر رہی۔
اور یہاں اہم بات یہ سمجھنا ہے کہ اس طرح کی نقل مکانی کو صحیح طریقے سے کیسے کیا جائے۔ اور انہیں کرنے کی ضرورت ہے۔ ہم یہ نقل مکانی کافی مستقل مزاجی سے کرتے ہیں۔
- اتنی بڑی نقل مکانی خود بخود نہیں ہوتی۔ انہیں ہمیشہ قابو میں رہنا چاہیے۔
- ایک باشعور شخص کی نگرانی ضروری ہے۔ اگر آپ کی ٹیم میں DBA ہے، تو DBA کو کرنے دیں۔ اس کا کام ہے۔ اگر نہیں، تو سب سے زیادہ تجربہ کار شخص کو کرنے دیں، جو ڈیٹا بیس کے ساتھ کام کرنا جانتا ہے۔
- ایک نیا ڈیٹا بیس اسکیما، یہاں تک کہ اگر ہم ایک کالم کو اپ ڈیٹ کرتے ہیں، ہم ہمیشہ مراحل میں تیار کرتے ہیں، یعنی ایپلیکیشن کے نئے ورژن کے رول آؤٹ ہونے سے پہلے:
- نئے فیلڈز شامل کیے گئے ہیں جس میں ہم اپ ڈیٹ شدہ ڈیٹا کو ریکارڈ کریں گے۔
- ہم پرانے فیلڈ سے ڈیٹا کو چھوٹے حصوں میں نئے فیلڈ میں منتقل کرتے ہیں۔ ہم ایسا کیوں کر رہے ہیں؟ سب سے پہلے، ہم ہمیشہ اس عمل کے عمل کو کنٹرول کرتے ہیں. ہم جانتے ہیں کہ ہم نے پہلے ہی بہت سارے بیچوں کو منتقل کر دیا ہے اور ہمارے پاس بہت سارے بچے ہیں۔
- اور دوسرا مثبت اثر یہ ہے کہ اس طرح کے ہر بیچ کے درمیان ہم لین دین کو بند کرتے ہیں، ایک نیا کھولتے ہیں، اور یہ آٹو ویکیوم کو پلیٹ کے مطابق کام کرنے کی اجازت دیتا ہے، دوبارہ استعمال کے لیے ڈیڈ لائنوں کو نشان زد کرتا ہے۔
- ان لائنوں کے لیے جو ایپلی کیشن کے چلنے کے دوران ظاہر ہوں گی (ہمارے پاس اب بھی پرانی ایپلیکیشن چل رہی ہے)، ہم ایک ٹرگر شامل کرتے ہیں جو نئی فیلڈز میں نئی قدریں لکھتا ہے۔ ہمارے معاملے میں، یہ پرانی قدر کا ایک سو سے ضرب ہے۔
- اگر ہم مکمل طور پر ضدی ہیں اور ایک ہی فیلڈ چاہتے ہیں، تو تمام منتقلی مکمل ہونے پر اور ایپلیکیشن کا نیا ورژن لانے سے پہلے، ہم صرف فیلڈز کا نام تبدیل کر دیتے ہیں۔ پرانے کو کچھ ایجاد شدہ نام دیا جاتا ہے، اور نئے شعبوں کا نام بدل کر پرانے رکھ دیا جاتا ہے۔
- اور اس کے بعد ہی ہم ایپلیکیشن کا نیا ورژن لانچ کرتے ہیں۔
اور اس کے ساتھ ساتھ نہ ہمیں پھولے گا اور نہ ہی کارکردگی کے لحاظ سے نقصان ہوگا۔
یہیں پر تیسری کہانی ختم ہوتی ہے۔
اور اب ان ٹولز کے بارے میں کچھ اور تفصیل جن کا ذکر میں نے پہلی کہانی میں کیا تھا۔
بلوٹ تلاش کرنے سے پہلے، آپ کو ایکسٹینشن انسٹال کرنا چاہیے۔ .
تاکہ آپ کو سوالات کے ساتھ آنے کی ضرورت نہ پڑے، ہم پہلے ہی اپنے کام میں یہ سوالات لکھ چکے ہیں۔ آپ انہیں استعمال کر سکتے ہیں۔ یہاں دو گزارشات ہیں۔
- پہلی کو کام کرنے میں کافی وقت لگتا ہے، لیکن یہ آپ کو میز سے بلوٹ کی صحیح قدریں دکھائے گا۔
- دوسرا تیزی سے کام کرتا ہے اور بہت مؤثر ہے جب آپ کو جلدی سے اندازہ لگانے کی ضرورت ہوتی ہے کہ آیا ٹیبل کے مطابق پھولا ہوا ہے یا نہیں۔ اور آپ کو یہ بھی سمجھنا چاہئے کہ پوسٹگریس ٹیبل میں بلوٹ ہمیشہ موجود ہوتا ہے۔ یہ اس کے MVCC ماڈل کی ایک خصوصیت ہے۔
- اور زیادہ تر معاملات میں میزوں کے لیے 20% بلوٹ معمول کی بات ہے۔ یعنی آپ کو فکر نہیں کرنی چاہیے اور اس ٹیبل کو کمپریس کرنا چاہیے۔
ہم نے معلوم کیا کہ ان میزوں کی شناخت کیسے کی جائے جو بیکار ڈیٹا کے ساتھ سوجی ہوئی ہیں۔
اب اپھارہ ٹھیک کرنے کے طریقہ کے بارے میں:
- اگر ہمارے پاس ایک چھوٹی ٹیبلٹ اور اچھی ڈسکیں ہیں، یعنی ایک گیگا بائٹ تک کی گولی پر، تو ویکیوم فل استعمال کرنا کافی ممکن ہے۔ وہ آپ سے میز پر چند سیکنڈ کے لیے ایک خصوصی تالا لے گا اور ٹھیک ہے، لیکن وہ سب کچھ جلدی اور سختی سے کرے گا۔ VACUUM FULL کیا کرتا ہے؟ یہ میز پر ایک خصوصی تالا لگاتا ہے اور پرانی میزوں سے نئی ٹیبل میں لائیو قطاروں کو دوبارہ لکھتا ہے۔ اور آخر میں وہ ان کی جگہ لے لیتا ہے۔ یہ پرانی فائلوں کو حذف کرتا ہے اور پرانی فائلوں کو نئی فائلوں سے بدل دیتا ہے۔ لیکن اس کے کام کی مدت کے لئے، یہ میز پر ایک خصوصی تالا لیتا ہے. اس کا مطلب ہے کہ آپ اس ٹیبل کے ساتھ کچھ نہیں کر سکتے: نہ اس پر لکھیں، نہ اس میں پڑھیں، نہ اس میں ترمیم کریں۔ اور VACUUM FULL کو ڈیٹا لکھنے کے لیے اضافی ڈسک کی جگہ درکار ہوتی ہے۔
- اگلا ٹول . اپنے اصول میں، یہ ویکیوم فل سے بہت ملتا جلتا ہے، کیونکہ یہ پرانی فائلوں سے ڈیٹا کو نئی فائلوں میں بھی لکھتا ہے اور انہیں ٹیبل میں بدل دیتا ہے۔ لیکن ایک ہی وقت میں، یہ اپنے کام کے آغاز میں ہی میز پر ایک خصوصی تالا نہیں لیتا ہے، بلکہ اسے صرف اس وقت لیتا ہے جب اس کے پاس فائلوں کو تبدیل کرنے کے لیے پہلے سے تیار ڈیٹا موجود ہوتا ہے۔ اس کی ڈسک کے وسائل کی ضروریات ویکیوم فل کی طرح ہیں۔ آپ کو اضافی ڈسک کی جگہ کی ضرورت ہے، اور یہ بعض اوقات اہم ہوتا ہے اگر آپ کے پاس ٹیرا بائٹ ٹیبل ہیں۔ اور یہ کافی پروسیسر سے بھوکا ہے کیونکہ یہ I/O کے ساتھ فعال طور پر کام کرتا ہے۔
- تیسری افادیت ہے . یہ وسائل کے ساتھ زیادہ محتاط ہے کیونکہ یہ قدرے مختلف اصولوں کے مطابق کام کرتا ہے۔ pgcompacttable کا بنیادی خیال یہ ہے کہ یہ تمام لائیو قطاروں کو ٹیبل میں اپ ڈیٹس کا استعمال کرتے ہوئے ٹیبل کے شروع میں لے جاتا ہے۔ اور پھر یہ اس میز پر ایک خلا چلاتا ہے، کیونکہ ہم جانتے ہیں کہ ہمارے شروع میں زندہ قطاریں اور آخر میں مردہ قطاریں ہیں۔ اور ویکیوم خود ہی اس دم کو کاٹ دیتا ہے، یعنی اسے ڈسک میں زیادہ جگہ کی ضرورت نہیں ہوتی۔ اور اس کے ساتھ ساتھ وسائل کے لحاظ سے بھی اسے نچوڑا جا سکتا ہے۔
اوزار کے ساتھ سب کچھ۔
اگر آپ کو بلوٹ کا موضوع مزید اندر تلاش کرنے کے لحاظ سے دلچسپ لگتا ہے، تو یہاں کچھ مفید لنکس ہیں:
- - یہ میرے ساتھی کی ایک رپورٹ ہے۔ یہ عمومی بات ہے کہ پوسٹگریس کی جگہ اس کے کام اور زندگی کے دوران کہاں جاتی ہے۔ اور بلوٹ کے بارے میں ڈیٹا بیس کے منتظمین کے لیے ایک بہت بڑا اور تفصیلی تکنیکی ٹکڑا موجود ہے۔
- - یہ ہمارے ذخیرے کا ایک لنک ہے، جہاں ہم ڈیٹا بیس کی حالت کو جانچنے کے لیے مفید اسکرپٹس کا ایک گروپ ذخیرہ کرتے ہیں۔ وہاں آپ کو بلوٹ تلاش کرنے کے لیے اسکرپٹ مل سکتے ہیں۔
- и ٹولز کے لنکس جو آپ کو علامات کو سکڑنے میں مدد کریں گے۔
- - یہ میرے ساتھی کی ایک پوسٹ ہے۔ وہاں وہ کافی سنجیدگی سے اور تکنیکی طور پر منتظمین کے قریب کی سطح پر بلوٹ کا تفصیل سے تجزیہ کرتا ہے۔
میں نے ڈویلپرز کے لیے ایک خوفناک کہانی دکھانے کی زیادہ کوشش کی، کیونکہ وہ ہمارے ڈیٹا بیس کے براہ راست کلائنٹ ہیں اور انہیں یہ سمجھنا چاہیے کہ کیا اور کن اعمال کا باعث بنتا ہے۔ مجھے امید ہے کہ میں کامیاب ہو گیا۔ آپکی توجہ کا شکریہ!
آپ کے سوالات
رپورٹ کے لیے شکریہ! آپ نے اس بارے میں بات کی کہ آپ کس طرح مسائل کی نشاندہی کر سکتے ہیں۔ انہیں کیسے خبردار کیا جا سکتا ہے؟ یعنی، میرے پاس ایک ایسی صورتحال تھی جہاں درخواستیں صرف اس وجہ سے نہیں لٹک جاتی تھیں کہ انہوں نے کچھ بیرونی خدمات تک رسائی حاصل کی تھی۔ یہ صرف کچھ جنگلی جوڑ تھے۔ کچھ چھوٹی چھوٹی بے ضرر درخواستیں تھیں جو دن بھر لٹکتی رہیں اور پھر کچھ بکواس کرنے لگیں۔ یعنی جو آپ بیان کرتے ہیں اس سے بالکل مماثل ہے۔ اس کو کیسے ٹریک کریں؟ بیٹھو اور مسلسل دیکھتے رہو کہ کون سی درخواست پھنس گئی ہے؟ یہ کیسے روکا جا سکتا ہے؟
اس صورت میں، یہ آپ کی کمپنی کے منتظمین کے لیے ایک کام ہے، ضروری نہیں کہ DBA کے لیے ہو۔
میں ایک منتظم ہوں۔
PostgreSQL میں pg_stat_activity نامی ایک نظریہ ہے جو گھمبیر سوالات کو ظاہر کرتا ہے۔ اور آپ دیکھ سکتے ہیں کہ یہ وہاں کتنی دیر تک لٹکا رہتا ہے۔
کیا مجھے ہر 5 منٹ بعد اندر آکر دیکھنا ہوگا؟
کرون سیٹ کریں اور چیک کریں۔ اگر آپ کے پاس طویل مدتی درخواست ہے، تو ایک خط لکھیں اور بس۔ یعنی، آپ کو اپنی آنکھوں سے دیکھنے کی ضرورت نہیں ہے، یہ خودکار ہو سکتا ہے۔ آپ کو ایک خط ملے گا، آپ اس پر ردعمل ظاہر کریں گے۔ یا آپ خود بخود گولی مار سکتے ہیں۔
کیا ایسا ہونے کی کوئی واضح وجوہات ہیں؟
میں نے کچھ کو درج کیا ہے۔ دیگر پیچیدہ مثالیں۔ اور کافی دیر تک بات چیت ہو سکتی ہے۔
رپورٹ کے لیے شکریہ! میں pg_repack یوٹیلیٹی کے بارے میں واضح کرنا چاہتا تھا۔ اگر وہ ایک خصوصی لاک نہیں کرتی ہے، تو پھر...
وہ ایک خصوصی لاک کرتی ہے۔
... تب میں ممکنہ طور پر ڈیٹا کھو سکتا ہوں۔ کیا اس دوران میری درخواست کو کچھ بھی ریکارڈ نہیں کرنا چاہیے؟
نہیں، یہ ٹیبل کے ساتھ آسانی سے کام کرتا ہے، یعنی pg_repack پہلے موجود تمام لائیو لائنوں کو منتقل کرتا ہے۔ قدرتی طور پر، میز میں کسی قسم کا داخلہ وہاں ہوتا ہے. وہ صرف اس پونی ٹیل کو باہر پھینک رہا ہے۔
یعنی، وہ آخر میں ایسا کرتا ہے؟
آخر میں، وہ ان فائلوں کو تبدیل کرنے کے لیے ایک خصوصی لاک لیتا ہے۔
کیا یہ VACUUM FULL سے تیز ہوگا؟
ویکیوم فل، جیسے ہی یہ شروع ہوا، فوری طور پر ایک خصوصی لاک لے لیا۔ اور جب تک وہ سب کچھ نہیں کرتا، وہ اسے جانے نہیں دے گا۔ اور pg_repack صرف فائل کی تبدیلی کے وقت ایک خصوصی لاک لیتا ہے۔ اس وقت آپ وہاں نہیں لکھیں گے، لیکن ڈیٹا ضائع نہیں ہوگا، سب کچھ ٹھیک ہو جائے گا۔
ہیلو! آپ نے کار ویکیوم کے آپریشن کے بارے میں بات کی۔ سرخ، پیلے اور سبز ریکارڈنگ سیلز کے ساتھ ایک گراف تھا۔ یعنی پیلے رنگ والے - اس نے انہیں حذف شدہ کے طور پر نشان زد کیا۔ اور اس کے نتیجے میں ان میں کچھ نیا لکھا جا سکتا ہے؟
جی ہاں. پوسٹگریس لائنوں کو حذف نہیں کرتا ہے۔ اس کے پاس ایسی خاصیت ہے۔ اگر ہم نے ایک لائن کو اپ ڈیٹ کیا، تو ہم نے پرانی کو حذف شدہ کے بطور نشان زد کیا۔ اس لائن کو تبدیل کرنے والے لین دین کی شناخت وہاں ظاہر ہوتی ہے، اور ہم ایک نئی لائن لکھتے ہیں۔ اور ہمارے پاس ایسے سیشن ہیں جو ممکنہ طور پر انہیں پڑھ سکتے ہیں۔ کسی وقت وہ کافی بوڑھے ہو جاتے ہیں۔ اور آٹو ویکیوم کس طرح کام کرتا ہے اس کا خلاصہ یہ ہے کہ یہ ان لائنوں سے گزرتا ہے اور انہیں غیر ضروری کے طور پر نشان زد کرتا ہے۔ اور آپ وہاں ڈیٹا کو اوور رائٹ کر سکتے ہیں۔
میں سمجھتا ہوں۔ لیکن یہ وہ نہیں ہے جس کے بارے میں سوال ہے۔ میں نے ختم نہیں کیا۔ آئیے فرض کریں کہ ہمارے پاس ایک میز ہے۔ اس میں متغیر سائز کے فیلڈز ہیں۔ اور اگر میں کچھ نیا ڈالنے کی کوشش کرتا ہوں تو یہ پرانے سیل میں فٹ نہیں ہو سکتا۔
نہیں، کسی بھی صورت میں پوری لائن وہاں اپ ڈیٹ ہو جاتی ہے۔ پوسٹگریس کے پاس ڈیٹا اسٹوریج کے دو ماڈل ہیں۔ یہ ڈیٹا کی قسم سے منتخب کرتا ہے۔ وہاں ڈیٹا ہے جو براہ راست ٹیبل میں محفوظ کیا جاتا ہے، اور وہاں ڈیٹا بھی موجود ہے۔ یہ بڑی مقدار میں ڈیٹا ہیں: ٹیکسٹ، json۔ وہ الگ الگ پلیٹوں میں محفوظ ہیں۔ اور ان گولیوں کے مطابق، بلوٹ کے ساتھ ایک ہی کہانی ہوتی ہے، یعنی سب کچھ ایک جیسا ہے۔ وہ صرف الگ سے درج ہیں۔
رپورٹ کے لیے شکریہ! کیا مدت کو محدود کرنے کے لیے بیان کے ٹائم آؤٹ سوالات کا استعمال کرنا قابل قبول ہے؟
بہت قابل قبول۔ ہم اسے ہر جگہ استعمال کرتے ہیں۔ اور چونکہ ہمارے پاس اپنی خدمات نہیں ہیں، اس لیے ہم ریموٹ سپورٹ فراہم کرتے ہیں، ہمارے پاس کافی قسم کے کلائنٹس ہیں۔ اور ہر کوئی اس سے پوری طرح مطمئن ہے۔ یعنی، ہمارے پاس کرون جابز ہیں جو چیک کرتی ہیں۔ سیشن کی مدت کلائنٹ کے ساتھ صرف متفق ہے، جس سے پہلے ہم متفق نہیں ہیں. یہ ایک منٹ ہو سکتا ہے، یہ 10 منٹ ہو سکتا ہے۔ یہ بیس پر بوجھ اور اس کے مقصد پر منحصر ہے۔ لیکن ہم سب pg_stat_activity استعمال کرتے ہیں۔
رپورٹ کے لیے شکریہ! میں آپ کی رپورٹ کو اپنی درخواستوں پر لاگو کرنے کی کوشش کر رہا ہوں۔ اور ایسا لگتا ہے کہ ہم ہر جگہ ایک لین دین شروع کرتے ہیں، اور اسے ہر جگہ واضح طور پر مکمل کرتے ہیں۔ اگر کچھ استثناء ہے، تو پھر بھی رول بیک ہوتا ہے۔ اور پھر میں سوچنے لگا۔ سب کے بعد، ٹرانزیکشن واضح طور پر شروع نہیں ہو سکتا. یہ شاید لڑکی کو اشارہ ہے۔ اگر میں صرف ایک ریکارڈ کو اپ ڈیٹ کرتا ہوں تو کیا لین دین PostgreSQL میں شروع ہوگا اور کنکشن منقطع ہونے پر ہی مکمل ہوگا؟
اگر آپ ابھی ایپلیکیشن لیول کے بارے میں بات کر رہے ہیں، تو یہ اس ڈرائیور پر منحصر ہے جسے آپ استعمال کر رہے ہیں، اس ORM پر جو استعمال ہو رہا ہے۔ وہاں بہت ساری ترتیبات ہیں۔ اگر آپ نے آٹو کمٹ کو فعال کیا ہے، تو وہاں ایک لین دین شروع ہوتا ہے اور فوری طور پر بند ہوجاتا ہے۔
یعنی، یہ اپ ڈیٹ کے فوراً بعد بند ہو جاتا ہے؟
یہ ترتیبات پر منحصر ہے۔ میں نے ایک ترتیب کا نام دیا۔ یہ آٹو کمٹ آن ہے۔ یہ کافی عام ہے۔ اگر یہ فعال ہے، تو لین دین کھلا اور بند ہو گیا ہے۔ جب تک کہ آپ نے واضح طور پر "لین دین شروع کریں" اور "لین دین کا اختتام" نہیں کہا، لیکن سیشن میں صرف ایک درخواست شروع کی۔
ہیلو! رپورٹ کے لیے شکریہ! آئیے تصور کریں کہ ہمارے پاس ایک ڈیٹا بیس ہے جو سوجن اور سوجن ہے اور پھر سرور پر جگہ ختم ہوجاتی ہے۔ کیا اس صورتحال کو ٹھیک کرنے کے لیے کوئی ٹولز موجود ہیں؟
سرور پر جگہ کو مناسب طریقے سے مانیٹر کرنے کی ضرورت ہے۔
مثال کے طور پر، ڈی بی اے چائے پینے گیا، کسی ریزورٹ میں تھا، وغیرہ۔
جب کوئی فائل سسٹم بنتا ہے تو کم از کم کسی قسم کی بیک اپ اسپیس بن جاتی ہے جہاں ڈیٹا نہیں لکھا جاتا۔
کیا ہوگا اگر یہ مکمل طور پر صفر سے نیچے ہے؟
وہاں اسے محفوظ جگہ کہا جاتا ہے، یعنی اسے آزاد کیا جا سکتا ہے اور اس پر منحصر ہے کہ یہ کتنی بڑی جگہ بنائی گئی ہے، آپ کو خالی جگہ ملتی ہے۔ پہلے سے طے شدہ میں نہیں جانتا کہ کتنے ہیں۔ اور دوسری صورت میں، ڈسک فراہم کریں تاکہ آپ کے پاس تعمیر نو کا عمل کرنے کی گنجائش ہو۔ آپ کچھ ٹیبل کو حذف کر سکتے ہیں جس کی آپ کو ضرورت نہ ہونے کی ضمانت دی گئی ہے۔
کیا کوئی اور اوزار ہیں؟
یہ ہمیشہ ہاتھ سے تیار ہوتا ہے۔ اور مقامی طور پر یہ واضح ہو جاتا ہے کہ وہاں کیا کرنا بہتر ہے، کیونکہ کچھ ڈیٹا اہم ہے اور کچھ غیر اہم ہے۔ اور ہر ڈیٹا بیس اور اس کے ساتھ کام کرنے والی ایپلیکیشن کے لیے، یہ کاروبار پر منحصر ہے۔ یہ ہمیشہ مقامی طور پر فیصلہ کیا جاتا ہے.
رپورٹ کے لیے شکریہ! میرے دو سوال ہیں۔ سب سے پہلے، آپ نے سلائیڈیں دکھائیں جو یہ ظاہر کرتی ہیں کہ جب لین دین پھنس جاتا ہے، تو میز کی جگہ کا سائز اور انڈیکس سائز دونوں بڑھ جاتے ہیں۔ اور رپورٹ پر مزید افادیت کا ایک گروپ تھا جو ٹیبلٹ کو پیک کرتا ہے۔ انڈیکس کے بارے میں کیا خیال ہے؟
وہ انہیں بھی پیک کرتے ہیں۔
لیکن خلا انڈیکس کو متاثر نہیں کرتا؟
کچھ انڈیکس کے ساتھ کام کرتے ہیں۔ مثال کے طور پر، pg_rapack، pgcompacttable۔ ویکیوم اشاریہ جات کو دوبارہ بناتا ہے اور ان کو متاثر کرتا ہے۔ VACUUM FULL کے ساتھ خیال ہر چیز کو اوور رائٹ کرنا ہے، یعنی یہ سب کے ساتھ کام کرتا ہے۔
اور دوسرا سوال۔ مجھے سمجھ نہیں آتی کہ نقل پر رپورٹس نقل پر ہی اتنا انحصار کیوں کرتی ہیں۔ مجھے ایسا لگتا تھا کہ رپورٹیں پڑھی جاتی ہیں، اور نقل لکھی جاتی ہے۔
نقل کے تنازعہ کا کیا سبب ہے؟ ہمارے پاس ایک ماسٹر ہے جس پر عمل ہوتا ہے۔ ہمارے پاس کار ویکیوم چل رہا ہے۔ آٹو ویکیوم اصل میں کیا کرتا ہے؟ وہ کچھ پرانی لائنیں کاٹ رہا ہے۔ اگر اس وقت ہمارے پاس نقل پر ایک درخواست ہے جو ان پرانی لائنوں کو پڑھتی ہے، اور ماسٹر پر ایسی صورت حال پیدا ہوتی ہے کہ آٹو ویکیوم نے ان لائنوں کو اوور رائٹنگ کے لیے ممکنہ طور پر نشان زد کیا، تو ہم نے انہیں اوور رائٹ کر دیا۔ اور ہمیں ایک ڈیٹا پیکٹ موصول ہوا، جب ہمیں ان لائنوں کو دوبارہ لکھنے کی ضرورت ہوتی ہے جن کی درخواست کو نقل پر ضرورت ہوتی ہے، تو نقل کا عمل آپ کے ترتیب کردہ ٹائم آؤٹ کا انتظار کرے گا۔ اور پھر PostgreSQL فیصلہ کرے گا کہ اس کے لیے کیا زیادہ اہم ہے۔ اور نقل اس کے لیے درخواست سے زیادہ اہم ہے، اور وہ نقل پر یہ تبدیلیاں کرنے کے لیے درخواست کو گولی مار دے گا۔
اینڈری، میرا ایک سوال ہے۔ یہ شاندار گراف جو آپ نے پریزنٹیشن کے دوران دکھائے، کیا یہ آپ کی کسی افادیت کے کام کا نتیجہ ہیں؟ گراف کیسے بنائے گئے؟
یہ ایک خدمت ہے۔ .
کیا یہ تجارتی مصنوعات ہے؟
جی ہاں. یہ ایک تجارتی مصنوعات ہے۔
ماخذ: www.habr.com