PostgreSQL کے لیے لینکس میں آؤٹ آف میموری کلر ترتیب دینا

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

آؤٹ آف میموری قاتل

جب کوئی سرور یا عمل میموری سے باہر ہو جاتا ہے، تو لینکس 2 حل پیش کرتا ہے: پورے سسٹم کو کریش کر دیں یا اس عمل (ایپلی کیشن) کو ختم کر دیں جو میموری کو کھا رہا ہے۔ یقیناً بہتر ہے کہ اس عمل کو ختم کر دیا جائے اور OS کو کریش ہونے سے بچایا جائے۔ مختصر طور پر، آؤٹ آف میموری کلر ایک ایسا عمل ہے جو کرنل کو کریش ہونے سے بچانے کے لیے کسی ایپلیکیشن کو ختم کر دیتا ہے۔ یہ OS کو چلانے کے لیے ایپلیکیشن کی قربانی دیتا ہے۔ آئیے پہلے اس بات پر بات کرتے ہیں کہ OOM کیسے کام کرتا ہے اور اسے کیسے کنٹرول کیا جاتا ہے، اور پھر دیکھیں کہ OOM Killer کس طرح فیصلہ کرتا ہے کہ کس ایپلیکیشن کو ختم کرنا ہے۔

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

Out of Memory: Killed process 12345 (postgres).

اگر سسٹم میں میموری کم ہے اور اسے آزاد نہیں کیا جا سکتا تو فنکشن کہا جاتا ہے۔ out_of_memory. اس مرحلے پر، اس کے پاس صرف ایک کام باقی ہے - ایک یا زیادہ عمل کو مکمل کریں۔ کیا OOM- قاتل کو فوری طور پر اس عمل کو ختم کرنا چاہیے یا یہ انتظار کر سکتا ہے؟ ظاہر ہے، جب out_of_memory کال کی جاتی ہے، تو یہ I/O آپریشن یا ڈسک پر پیجنگ کا انتظار کرنے کی وجہ سے ہوتا ہے۔ لہذا، OOM قاتل کو پہلے چیک کرنا چاہیے اور، ان کی بنیاد پر، فیصلہ کرنا چاہیے کہ اس عمل کو ختم کرنے کی ضرورت ہے۔ اگر نیچے دیے گئے تمام چیک مثبت ہیں، OOM اس عمل کو ختم کر دے گا۔

عمل کا انتخاب

جب میموری ختم ہوجائے تو فنکشن کہا جاتا ہے۔ out_of_memory(). اس کا ایک فنکشن ہے۔ select_bad_process()، جو فنکشن سے ایک تشخیص حاصل کرتا ہے۔ badness(). "بدترین" عمل کو نشانہ بنایا جائے گا۔ فنکشن badness() کچھ اصولوں کے مطابق عمل کا انتخاب کرتا ہے۔

1. دانا کو اپنے لیے کچھ کم از کم میموری کی ضرورت ہوتی ہے۔
2. آپ کو بہت زیادہ میموری خالی کرنے کی ضرورت ہے۔
3. ایسے عمل کو ختم کرنے کی ضرورت نہیں ہے جو بہت کم میموری استعمال کررہے ہیں۔
4. کم از کم عمل مکمل کرنے کی ضرورت ہے۔
5. پیچیدہ الگورتھم جو ان عملوں کی تکمیل کے امکانات کو بڑھاتے ہیں جنہیں صارف خود مکمل کرنا چاہتا ہے۔

ان تمام چیکس کو مکمل کرنے کے بعد، OOM اسکور کی جانچ کرتا ہے (oom_score)۔ OOM تفویض کرتا ہے۔ oom_score ہر عمل، اور پھر اس قدر کو میموری کی مقدار سے ضرب دیتا ہے۔ بڑی قدروں والے عمل کے OOM قاتل کا شکار ہونے کا زیادہ امکان ہوتا ہے۔ روٹ یوزر سے وابستہ پروسیسز کا اسکور کم ہوتا ہے اور اسے ختم کرنے پر مجبور ہونے کا امکان کم ہوتا ہے۔

postgres=# SELECT pg_backend_pid();
pg_backend_pid 
----------------
    3813
(1 row)

پوسٹگریس پروسیس ID 3813 ہے، لہذا دوسرے شیل میں اس کرنل پیرامیٹر کا استعمال کرتے ہوئے اسکور حاصل کرنا ممکن ہے oom_score:

vagrant@vagrant:~$ sudo cat /proc/3813/oom_score
2

اگر آپ نہیں چاہتے ہیں کہ OOM-Killer اس عمل کو بالکل ختم کردے، تو ایک اور کرنل آپشن موجود ہے: oom_score_adj. اپنی قدر کے عمل کو مکمل کرنے کے امکانات کو کم کرنے کے لیے ایک بڑی منفی قدر شامل کریں۔

sudo echo -100 > /proc/3813/oom_score_adj

قدر مقرر کرنے کے لیے oom_score_adjسروس بلاک میں OOMScoreAdjust سیٹ کریں:

[Service]
OOMScoreAdjust=-1000

یا استعمال کریں۔ oomprotect ایک ٹیم میں rcctl.

rcctl set <i>servicename</i> oomprotect -1000

کسی عمل کو زبردستی ختم کرنا

جب ایک یا زیادہ عمل پہلے سے ہی منتخب ہو جاتے ہیں، OOM-Killer فنکشن کو کال کرتا ہے۔ oom_kill_task(). یہ فنکشن عمل کو ختم کرنے کا سگنل بھیجتا ہے۔ یادداشت کی کمی کی صورت میں oom_kill() عمل میں SIGKILL سگنل بھیجنے کے لیے اس فنکشن کو کال کرتا ہے۔ کرنل لاگ پر ایک پیغام لکھا جاتا ہے۔

Out of Memory: Killed process [pid] [name].

OOM-Killer کو کیسے کنٹرول کریں۔

لینکس پر، آپ OOM-Killer کو فعال یا غیر فعال کر سکتے ہیں (حالانکہ مؤخر الذکر کی سفارش نہیں کی جاتی ہے)۔ فعال یا غیر فعال کرنے کے لیے پیرامیٹر کا استعمال کریں۔ vm.oom-kill. OOM-Killer کو رن ٹائم پر فعال کرنے کے لیے، کمانڈ چلائیں۔ sysctl.

sudo -s sysctl -w vm.oom-kill = 1

OOM-Killer کو غیر فعال کرنے کے لیے، اسی کمانڈ میں قدر 0 کی وضاحت کریں:

sudo -s sysctl -w vm.oom-kill = 0

اس کمانڈ کا نتیجہ ہمیشہ کے لیے محفوظ نہیں کیا جائے گا، لیکن صرف پہلے ریبوٹ تک۔ اگر آپ کو مزید استقامت کی ضرورت ہے تو اس لائن کو فائل میں شامل کریں۔ /etc/sysctl.conf:

echo vm.oom-kill = 1 >>/etc/sysctl.conf

فعال اور غیر فعال کرنے کا دوسرا طریقہ متغیر لکھنا ہے۔ panic_on_oom. قدر کو ہمیشہ چیک کیا جا سکتا ہے۔ /proc.

$ cat /proc/sys/vm/panic_on_oom
0

اگر آپ ویلیو کو 0 پر سیٹ کرتے ہیں، تو جب میموری ختم ہوجائے گی، تو کوئی کرنل گھبراہٹ نہیں ہوگی۔

$ echo 0 > /proc/sys/vm/panic_on_oom

اگر آپ ویلیو کو 1 پر سیٹ کرتے ہیں، تو جب میموری ختم ہوجائے گی، تو کرنل کی گھبراہٹ ہوگی۔

echo 1 > /proc/sys/vm/panic_on_oom

OOM-Killer کو نہ صرف آن اور آف کیا جا سکتا ہے۔ ہم پہلے ہی کہہ چکے ہیں کہ لینکس اصل میں مختص کیے بغیر دستیاب سے زیادہ میموری کو پروسیس کے لیے محفوظ کر سکتا ہے، اور یہ رویہ لینکس کرنل پیرامیٹر کے ذریعے کنٹرول کیا جاتا ہے۔ متغیر اس کے لیے ذمہ دار ہے۔ vm.overcommit_memory.

آپ اس کے لیے درج ذیل اقدار کی وضاحت کر سکتے ہیں:

0: دانا خود فیصلہ کرتا ہے کہ آیا بہت زیادہ میموری کو محفوظ کرنا ہے۔ یہ لینکس کے زیادہ تر ورژنز پر ڈیفالٹ ہے۔
1: دانا ہمیشہ اضافی میموری کو محفوظ رکھے گا۔ یہ خطرناک ہے، کیونکہ میموری ختم ہوسکتی ہے، کیونکہ، زیادہ تر امکان ہے، ایک دن عمل کو اس کی ضرورت ہوگی۔
2: دانا پیرامیٹر میں بیان کردہ سے زیادہ میموری محفوظ نہیں کرے گا۔ overcommit_ratio.

اس پیرامیٹر کے ساتھ، آپ میموری کا وہ فیصد بتاتے ہیں جسے زیادہ محفوظ کرنے کی اجازت ہے۔ اگر اس کے لیے کوئی گنجائش نہیں ہے، کوئی میموری مختص نہیں کی جائے گی، اور ریزرویشن سے انکار کردیا جائے گا۔ یہ PostgreSQL کے لیے تجویز کردہ سب سے محفوظ آپشن ہے۔ OOM-Killer ایک اور عنصر سے متاثر ہوتا ہے - تبادلہ کرنے کی صلاحیت، جسے متغیر کے ذریعے کنٹرول کیا جاتا ہے۔ cat /proc/sys/vm/swappiness. یہ قدریں کرنل کو بتاتی ہیں کہ پیجنگ کو کیسے ہینڈل کیا جائے۔ قدر جتنی زیادہ ہوگی، اتنا ہی کم امکان ہے کہ OOM اس عمل کو ختم کردے گا، لیکن I/O آپریشنز کی وجہ سے اس کا ڈیٹا بیس پر منفی اثر پڑتا ہے۔ اور اس کے برعکس - قدر جتنی کم ہوگی، OOM-Killer مداخلت کا امکان اتنا ہی زیادہ ہوگا، لیکن ڈیٹا بیس کی کارکردگی بھی زیادہ ہے۔ ڈیفالٹ ویلیو 60 ہے، لیکن اگر پورا ڈیٹا بیس میموری میں فٹ ہو جائے تو بہتر ہے کہ ویلیو کو 1 پر سیٹ کریں۔

کے نتائج

OOM-Killer میں "قاتل" کو آپ کو خوفزدہ نہ ہونے دیں۔ اس صورت میں، قاتل آپ کے نظام کا نجات دہندہ ہوگا۔ یہ بدترین عمل کو "مارتا" ہے اور سسٹم کو کریش ہونے سے بچاتا ہے۔ PostgreSQL کو ختم کرنے کے لیے OOM-Killer استعمال کرنے سے بچنے کے لیے، پر سیٹ کریں۔ vm.overcommit_memory قدر 2۔ یہ اس بات کی ضمانت نہیں دیتا کہ OOM-Killer کو مداخلت نہیں کرنی پڑے گی، لیکن یہ PostgreSQL کے عمل کو ختم کرنے پر مجبور کرنے کے امکانات کو کم کر دے گا۔

ماخذ: www.habr.com