vm.min_free_kbytes کیا ہے اور اسے کیسے ٹیون کیا جائے؟

What Is Vm Min_free_kbytes



لینکس کرنل کے لیے vm.min_free_kbytes sysctl ٹیون ایبل کیا ہے اور اس کی قیمت کیا ہونی چاہیے؟ ہم اس پیرامیٹر کا مطالعہ کریں گے اور اس مضمون میں چلنے والے لینکس سسٹم کو کیسے متاثر کرتا ہے۔ ہم OS پیج کیشے اور mallocs پر اس کے اثرات کی جانچ کریں گے اور جب یہ پیرامیٹر سیٹ ہو جائے تو سسٹم فری کمانڈ کیا دکھاتا ہے۔ ہم اس ٹیون ایبل کے لیے مثالی اقدار کے بارے میں کچھ تعلیم یافتہ اندازے لگائیں گے اور ہم دکھائیں گے کہ ریبوٹس سے بچنے کے لیے مستقل طور پر vm.min_free_kbytes کیسے سیٹ کریں۔ تو چلو چلتے ہیں.

vm.min_free_kbytes کیسے کام کرتا ہے۔

نظام کے مناسب کام کو یقینی بنانے کے لیے نظام کو میموری الاٹمنٹ کی ضرورت پڑ سکتی ہے۔ اگر دانا تمام میموری کو مختص کرنے کی اجازت دیتا ہے تو یہ مشکل ہو سکتا ہے جب باقاعدہ آپریشن کے لیے میموری کی ضرورت ہو تاکہ OS کو آسانی سے چلتا رہے۔ یہی وجہ ہے کہ دانا ٹیون ایبل vm.min_free_kbytes مہیا کرتا ہے۔ ٹیون ایبل دانا کے میموری مینیجر کو کم از کم ایکس میموری مفت رکھنے پر مجبور کرے گا۔ یہاں سے سرکاری تعریف ہے۔ لینکس کرنل دستاویزات : یہ لینکس VM کو کم از کم کلو بائٹس مفت رکھنے پر مجبور کرنے کے لیے استعمال کیا جاتا ہے۔ VM اس نمبر کا استعمال سسٹم میں ہر لو میم زون کے لیے واٹر مارک [WMARK_MIN] ویلیو کی گنتی کے لیے کرتا ہے۔ ہر لو میم زون کو اس کے سائز پر تناسب کی بنیاد پر متعدد محفوظ مفت صفحات ملتے ہیں۔ PF_MEMALLOC مختص کرنے کے لیے میموری کی کم سے کم مقدار درکار ہے۔ اگر آپ اسے 1024KB سے کم پر سیٹ کرتے ہیں تو ، آپ کا سسٹم ٹھیک ٹھیک ٹوٹ جائے گا ، اور زیادہ بوجھ کے تحت تعطل کا شکار ہو جائے گا۔ اس کو بہت زیادہ سیٹ کرنے سے آپ کی مشین فوری طور پر OOM ہوجائے گی۔







vm.min_free_kbytes کام کی توثیق۔

یہ جانچنے کے لیے کہ min_free_kbytes کی ترتیب ڈیزائن کے مطابق کام کر رہی ہے ، میں نے صرف 3.75 GB رام کے ساتھ ایک لینکس ورچوئل مثال بنائی ہے۔ سسٹم کا تجزیہ کرنے کے لیے نیچے دی گئی مفت کمانڈ استعمال کریں:



#مفت



ایم بی میں پرنٹ شدہ اقدار کے لیے -m پرچم کا استعمال کرتے ہوئے اوپر میموری کی مفت افادیت کو دیکھ رہے ہیں۔ کل میموری 3.5 سے 3.75 GB میموری ہے۔ 121 MB میموری استعمال ہوتی ہے ، 3.3 GB میموری مفت ہوتی ہے ، 251 MB بفر کیش کے ذریعے استعمال ہوتی ہے۔ اور 3.3 جی بی میموری دستیاب ہے۔





اب ہم vm.min_free_kbytes کی قدر کو تبدیل کرنے جا رہے ہیں اور دیکھیں گے کہ سسٹم میموری پر کیا اثر پڑتا ہے۔ ہم ذیل میں کرنل پیرامیٹر ویلیو کو تبدیل کرنے کے لیے پروک ورچوئل فائل سسٹم کی نئی قیمت کی بازگشت کریں گے۔

# گونج 1500000>/proc/sys/vm/min_free_kbytes۔
# sysctl vm.min_free_kbytes۔



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

#مفت

مفت میموری اور بفر کیش کمانڈ کے ذریعہ تبدیل نہیں ہوتے ہیں ، لیکن میموری کی مقدار بطور ظاہر ہوتی ہے۔ دستیاب 3327 سے کم کر کے 1222 MB کر دیا گیا ہے۔ جو کہ پیرامیٹر میں 1.5 جی بی کی مفت میموری میں تبدیلی کا تخمینہ ہے۔

اب آئیے 2 جی بی ڈیٹا فائل بنائیں اور پھر دیکھیں کہ اس فائل کو بفر کیشے میں پڑھنے سے اقدار پر کیا اثر پڑتا ہے۔ ذیل میں بش اسکرپٹ کی 2 لائنوں میں 2GB ڈیٹا فائل بنانے کا طریقہ یہ ہے۔ اسکرپٹ ڈی ڈی کمانڈ کا استعمال کرتے ہوئے 35 ایم بی کی بے ترتیب فائل تیار کرے گی اور پھر اسے 70 بار نئی میں کاپی کرے گی۔ ڈیٹا فائل پیداوار:

# dd if =/dev/random of =/root/d1.txt count = 1000000
# for i in `seq 1 70`؛ echo $ i؛ cat /root/d1.txt >> /root /data_file ہو گیا

آئیے فائل کو پڑھیں اور مندرجات کو نظرانداز کرتے ہوئے فائل کو /dev /null پر ری ڈائریکٹ کریں:

#کیٹڈیٹا فائل> /دیو/خالی

ٹھیک ہے ، اس سسٹم کے ساتھ ہمارے سسٹم کی یادداشت کو کیا ہوا ہے ، آئیے اب اسے چیک کریں:

#مفت

مندرجہ بالا نتائج کا تجزیہ۔ ہمارے پاس ابھی بھی 1.8 جی بی مفت میموری ہے لہذا دانا نے ہماری مائن_ فری_ک بائٹس سیٹنگ کی وجہ سے میموری کا ایک بڑا حصہ محفوظ کیا ہے۔ بفر کیشے نے 1691 MB استعمال کیا ہے جو کہ ہماری ڈیٹا فائل کے کل سائز سے کم ہے جو کہ 2.3 GB ہے۔ بظاہر پورا۔ ڈیٹا فائل بفر کیشے کے لیے استعمال کرنے کے لیے دستیاب میموری کی کمی کی وجہ سے کیشے میں محفوظ نہیں کیا جا سکا۔ ہم اس بات کی توثیق کر سکتے ہیں کہ پوری فائل کیشے میں محفوظ نہیں ہے بلکہ فائل کو پڑھنے کی بار بار کوششوں کا وقت ہے۔ اگر اسے کیش کیا گیا تو ، فائل کو پڑھنے میں ایک سیکنڈ کا ایک حصہ لگے گا۔ آؤ اس کو آزماتے ہیں.

# ٹائم کیٹ ڈیٹا_ فائل> /dev /null۔
# ٹائم کیٹ ڈیٹا_ فائل> /dev /null۔

فائل کو پڑھنے میں تقریبا 20 20 سیکنڈ لگے جس کا مطلب یہ ہے کہ یہ یقینی طور پر تمام کیش نہیں ہے۔

ایک حتمی توثیق کے طور پر آئیے vm.min_free_kbytes کو کم کرتے ہیں تاکہ صفحے کے کیشے کو کام کرنے کی زیادہ گنجائش ہو اور ہم توقع کرسکتے ہیں کہ کیشے کو کام کرتے ہوئے دیکھا جائے اور فائل کو بہت تیزی سے پڑھا جائے۔

# گونج 67584>/proc/sys/vm/min_free_kbytes۔
# ٹائم کیٹ ڈیٹا_ فائل> /dev /null۔
# ٹائم کیٹ ڈیٹا_ فائل> /dev /null۔

فائل کو کیش کرنے کے لیے دستیاب اضافی میموری کے ساتھ پڑھنے کا وقت 20 سیکنڈ سے کم ہو کر .364 سیکنڈ رہ گیا۔

میں ایک اور تجربہ کرنے کے لیے بے چین ہوں۔ اس اعلی vm.min_free_kbytes ترتیب کے پیش نظر C پروگرام سے میموری مختص کرنے کے لیے malloc کالز کے ساتھ کیا ہوتا ہے۔ کیا یہ میلوک کو ناکام کرے گا؟ کیا نظام مر جائے گا؟ پہلے اپنے تجربات کو دوبارہ شروع کرنے کے لیے vm.min_free_kbytes سیٹنگ کو واقعی اعلی قیمت پر ری سیٹ کریں:

#باہر پھینک دیا 1500000۔ > /فیصد/sys/vm/min_free_kbytes۔

آئیے اپنی آزاد یادداشت کو دوبارہ دیکھیں:

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

# تناؤ-این جی-وی ایم 1-وی ایم بائٹس 1 جی-ٹائم آؤٹ 60۔
کشیدگی: معلومات:[17537۔]ہاگس بھیجنا:vm
کشیدگی: معلومات:[17537۔]کیشے مختص: پہلے سے طے شدہ کیشے کا سائز: 46080K۔
کشیدگی: معلومات:[17537۔]کامیاب دوڑ مکملمیں60.09 سیکنڈ(منٹ ،0.09۔خشک)
# تناؤ-این جی-وی ایم 2-وی ایم بائٹس 1 جی-ٹائم آؤٹ 60۔
# تناؤ-این جی-وی ایم 3-وی ایم بائٹس 1 جی-ٹائم آؤٹ 60۔

آئیے مزید کارکنوں کے ساتھ دوبارہ کوشش کریں ، ہم 1 ، 2 ، 3 ، 4 کارکنوں کو آزما سکتے ہیں اور کسی وقت اسے ناکام ہونا چاہیے۔ میرے ٹیسٹ میں یہ 1 اور 2 کارکنوں کے ساتھ پاس ہوا لیکن 3 کارکنوں کے ساتھ ناکام رہا۔

آئیے vm.min_free_kbytes کو کم نمبر پر ری سیٹ کریں اور دیکھیں کہ کیا اس سے 3 میموری سٹریسرز کو 1GB کے ساتھ 3.75GB سسٹم پر چلانے میں مدد ملتی ہے۔

# گونج 67584>/proc/sys/vm/min_free_kbytes۔
# تناؤ-این جی-وی ایم 3-وی ایم بائٹس 1 جی-ٹائم آؤٹ 60۔

اس بار یہ بغیر کسی غلطی کے کامیابی سے چلا ، میں نے اسے بغیر کسی پریشانی کے دو بار آزمایا۔ لہذا میں یہ نتیجہ اخذ کر سکتا ہوں کہ مالاک کے لیے زیادہ میموری دستیاب ہونے میں رویے کا فرق ہے ، جب vm.min_free_kbytes ویلیو کم قیمت پر سیٹ کی جاتی ہے۔

vm.min_free_kbytes کے لیے ڈیفالٹ سیٹنگ۔

میرے سسٹم پر سیٹنگ کے لیے ڈیفالٹ ویلیو 67584 ہے جو سسٹم پر تقریبا 1.8 1.8٪ رام یا 64 MB ہے۔ بہت زیادہ تباہ شدہ سسٹم پر حفاظتی وجوہات کی بناء پر میں اس کو تھوڑا سا 128MB تک بڑھا سکتا ہوں تاکہ زیادہ محفوظ فری میموری کی اجازت دی جا سکے ، تاہم اوسط استعمال کے لیے ڈیفالٹ ویلیو کافی سمجھدار لگتا ہے۔ سرکاری دستاویزات قیمت کو بہت زیادہ بنانے کے بارے میں خبردار کرتی ہیں۔ اسے سسٹم ریم کے 5 یا 10 to پر سیٹ کرنا شاید سیٹنگ کا مطلوبہ استعمال نہیں ہے ، اور بہت زیادہ ہے۔

ریبوٹس سے بچنے کے لیے vm.min_free_kbytes سیٹ کرنا۔

اس بات کو یقینی بنانے کے لیے کہ سیٹنگ ریبوٹس سے بچ سکتی ہے اور ڈیفالٹ ویلیوز میں بحال نہیں ہوتی ہے جب ریبوٹ کرتے وقت /etc/sysctl.conf فائل میں مطلوبہ نئی ویلیو ڈال کر sysctl سیٹنگ کو برقرار رکھنا یقینی بنائیں۔

نتیجہ

ہم نے دیکھا ہے کہ vm.min_free_kbytes linux kernel tunable میں ترمیم کی جا سکتی ہے اور سسٹم پر میموری کو محفوظ رکھا جا سکتا ہے تاکہ یہ یقینی بنایا جا سکے کہ نظام زیادہ مستحکم ہے خاص طور پر بھاری استعمال اور بھاری میموری الاٹمنٹ کے دوران۔ پہلے سے طے شدہ ترتیبات تھوڑی بہت کم ہوسکتی ہیں ، خاص طور پر ہائی میموری سسٹم پر اور اسے احتیاط سے بڑھایا جانا چاہیے۔ ہم نے دیکھا ہے کہ اس ٹیونبل کے ذریعے محفوظ کردہ میموری OS کیشے کو تمام میموری استعمال کرنے سے روکتی ہے اور کچھ میلوک آپریشنز کو بھی تمام میموری استعمال کرنے سے روکتی ہے۔