مضمون کا ترجمہ کورس کے آغاز کے موقع پر تیار کیا گیا تھا۔ .
وقتا فوقتا، یہاں اور وہاں، کرنل ٹیوننگ کے حوالے سے گلسٹر کی سفارشات کے بارے میں سوالات پیدا ہوتے ہیں اور کیا اس کی ضرورت ہے۔
ایسی ضرورت شاذ و نادر ہی پیش آتی ہے۔ زیادہ تر کام کے بوجھ پر، دانا بہت اچھی کارکردگی کا مظاہرہ کرتا ہے۔ اگرچہ ایک منفی پہلو ہے۔ تاریخی طور پر، لینکس کا کرنل اگر موقع دیا جائے تو بہت زیادہ میموری استعمال کرنے کے لیے تیار رہا ہے، بشمول کارکردگی کو بہتر بنانے کے لیے کیشنگ کے لیے۔
زیادہ تر معاملات میں، یہ ٹھیک کام کرتا ہے، لیکن بھاری بوجھ کے تحت یہ مسائل کا باعث بن سکتا ہے۔
ہمارے پاس میموری انٹینسیو سسٹمز جیسا کہ CAD، EDA اور اس طرح کا کافی تجربہ ہے، جو بھاری بوجھ کے باعث سست ہونا شروع ہو گئے ہیں۔ اور بعض اوقات ہم گلسٹر میں مسائل کا شکار ہو جاتے ہیں۔ کئی دنوں تک میموری کے استعمال اور ڈسک کی لیٹنسی کا بغور مشاہدہ کرنے کے بعد، ہمیں ان کا اوورلوڈ، بہت بڑا iowait، kernel errors (kernel oops)، منجمد وغیرہ ملا۔
یہ مضمون مختلف حالات میں کیے گئے بہت سے ٹیوننگ تجربات کا نتیجہ ہے۔ ان پیرامیٹرز کی بدولت نہ صرف مجموعی ردعمل میں بہتری آئی ہے بلکہ کلسٹر بھی نمایاں طور پر مستحکم ہوا ہے۔
جب میموری ٹیوننگ کی بات آتی ہے، تو سب سے پہلی چیز ورچوئل میموری سب سسٹم (VM، ورچوئل میموری) ہے، جس میں آپشنز کی ایک بڑی تعداد موجود ہے جو آپ کو الجھن میں ڈال سکتی ہے۔
vm.swappiness
پیرامیٹر vm.swappiness اس بات کا تعین کرتا ہے کہ RAM کے مقابلے میں دانا کتنا سویپ (swap، pageing) استعمال کرتا ہے۔ اس کی تعریف سورس کوڈ میں "میپڈ میموری چوری کرنے کا رجحان" کے طور پر بھی کی گئی ہے۔ زیادہ تبدیلی کا مطلب یہ ہے کہ دانا میپ شدہ صفحات کو تبدیل کرنے کی طرف زیادہ مائل ہوگا۔ کم swappiness قدر کا مطلب اس کے برعکس ہے: دانا میموری سے کم صفحہ کرے گا۔ دوسرے لفظوں میں، قدر جتنی زیادہ ہوگی۔ vm.swappiness، نظام جتنا زیادہ سویپ استعمال کرے گا۔
تبادلہ کا ایک بڑا استعمال ناپسندیدہ ہے، کیونکہ ڈیٹا کے بڑے بلاکس کو RAM میں لوڈ اور ان لوڈ کیا جاتا ہے۔ بہت سے لوگ دلیل دیتے ہیں کہ swapiness قدر بڑی ہونی چاہیے، لیکن میرے تجربے میں، اسے "0" پر سیٹ کرنا بہتر کارکردگی کا باعث بنتا ہے۔
آپ یہاں مزید پڑھ سکتے ہیں -
لیکن، ایک بار پھر، ان ترتیبات کو احتیاط کے ساتھ لاگو کیا جانا چاہئے اور صرف ایک مخصوص ایپلی کیشن کی جانچ کے بعد۔ انتہائی بھری ہوئی اسٹریمنگ ایپلیکیشنز کے لیے، یہ پیرامیٹر "0" پر سیٹ ہونا چاہیے۔ "0" میں تبدیل ہونے پر، سسٹم کی ردعمل بہتر ہو جاتی ہے۔
vm.vfs_cache_pressure
یہ سیٹنگ ڈائرکٹری اور انوڈ آبجیکٹ (ڈینٹری اور انوڈ) کیچنگ کے لیے کرنل کے ذریعے استعمال کی جانے والی میموری کو کنٹرول کرتی ہے۔
100 کی ڈیفالٹ ویلیو کے ساتھ، کرنل ڈینٹری اور انوڈ کیچز کو "منصفانہ" بنیادوں پر پیج کیچ اور سویپ کیچ کے لیے آزاد کرنے کی کوشش کرے گا۔ vfs_cache_pressure میں کمی کی وجہ سے دانا ڈینٹری اور انوڈ کیچز کو برقرار رکھتا ہے۔ جب قدر "0" ہے، تو دانا میموری کے دباؤ کی وجہ سے کبھی بھی ڈینٹری اور انوڈ کیشے کو فلش نہیں کرے گا، اور یہ آسانی سے میموری سے باہر ہونے والی خرابی کا باعث بن سکتا ہے۔ vfs_cache_pressure کو 100 سے اوپر بڑھانا دانا کو ڈینٹری اور انوڈ فلشنگ کو ترجیح دینے کا سبب بنتا ہے۔
GlusterFS کا استعمال کرتے وقت، بہت سے صارفین ڈیٹا کی بڑی مقدار اور بہت سی چھوٹی فائلیں آسانی سے سرور پر RAM کی ایک قابل ذکر مقدار کو inode/dentry caching کی وجہ سے استعمال کر سکتے ہیں، جو کارکردگی میں کمی کا باعث بن سکتا ہے کیونکہ کرنل کو سسٹم پر ڈیٹا ڈھانچے پر کارروائی کرنی پڑتی ہے۔ 40 جی بی میموری کے ساتھ۔ اس قدر کو 100 سے اوپر مقرر کرنے سے بہت سے صارفین کو بہتر کیشنگ اور دانا کی بہتر ردعمل حاصل کرنے میں مدد ملی ہے۔
vm.dirty_background_ratio اور vm.dirty_ratio
پہلا پیرامیٹر (vm.dirty_background_ratio) گندے صفحات کے ساتھ میموری کی فیصد کا تعین کرتا ہے، جس تک پہنچنے کے بعد پس منظر میں موجود گندے صفحات کو ڈسک پر فلش کرنا ضروری ہے۔ جب تک اس فیصد تک نہیں پہنچ جاتا، کوئی بھی صفحہ ڈسک پر فلش نہیں ہوتا ہے۔ اور جب ری سیٹ شروع ہوتا ہے، تو یہ چلنے والے عمل میں خلل ڈالے بغیر پس منظر میں چلتا ہے۔
دوسرا پیرامیٹر (vm.dirty_ratio) میموری کے اس فیصد کی وضاحت کرتا ہے جس پر جبری فلیش شروع ہونے سے پہلے گندے صفحات پر قبضہ کیا جا سکتا ہے۔ ایک بار جب اس حد تک پہنچ جاتا ہے، تمام عمل مطابقت پذیر (مسدود) ہو جاتے ہیں اور ان کو اس وقت تک جاری رکھنے کی اجازت نہیں ہوتی جب تک کہ ان کی درخواست کردہ I/O حقیقت میں مکمل نہ ہو جائے اور ڈیٹا ڈسک پر نہ ہو۔ بھاری I/O کے ساتھ، یہ ایک مسئلہ کا باعث بنتا ہے کیونکہ کوئی ڈیٹا کیچنگ نہیں ہے اور I/O کرنے والے تمام عمل I/O کے انتظار میں مسدود ہیں۔ یہ بڑی تعداد میں معلق عمل، زیادہ بوجھ، نظام کی عدم استحکام اور خراب کارکردگی کا باعث بنتا ہے۔
ان ترتیبات کو کم کرنے سے ڈیٹا زیادہ کثرت سے ڈسک پر فلش ہوتا ہے اور RAM میں محفوظ نہیں ہوتا ہے۔ اس سے میموری والے بھاری نظاموں میں مدد مل سکتی ہے جہاں 45-90 GB پیج کیچز کو ڈسک پر فلش کرنا معمول کی بات ہے، جس کے نتیجے میں فرنٹ اینڈ ایپلی کیشنز کے لیے بہت زیادہ تاخیر ہوتی ہے، مجموعی ردعمل اور تعامل کو کم کیا جاتا ہے۔
"1" > /proc/sys/vm/pagecache
صفحہ کیش ایک کیش ہے جو فائلوں اور قابل عمل پروگراموں کے ڈیٹا کو ذخیرہ کرتا ہے، یعنی یہ وہ صفحات ہیں جن میں فائلز یا بلاک ڈیوائسز کے اصل مواد ہیں۔ اس کیش کو ڈسک ریڈز کی تعداد کو کم کرنے کے لیے استعمال کیا جاتا ہے۔ "1" کی قدر کا مطلب ہے کہ RAM کا 1% کیشے کے لیے استعمال ہوتا ہے اور RAM کے مقابلے ڈسک سے زیادہ پڑھے جائیں گے۔ اس ترتیب کو تبدیل کرنا ضروری نہیں ہے، لیکن اگر آپ صفحہ کی کیش کو کنٹرول کرنے کے بارے میں بے چین ہیں، تو آپ اسے استعمال کر سکتے ہیں۔
"ڈیڈ لائن" > /sys/block/sdc/queue/scheduler
I/O شیڈولر ایک لینکس کرنل جزو ہے جو پڑھنے اور لکھنے کی قطار کو سنبھالتا ہے۔ اصولی طور پر، سمارٹ RAID کنٹرولر کے لیے "noop" کا استعمال کرنا بہتر ہے، کیونکہ لینکس ڈسک کی فزیکل جیومیٹری کے بارے میں کچھ نہیں جانتا، اس لیے یہ زیادہ کارآمد ہے کہ کنٹرولر، جو ڈسک جیومیٹری کو اچھی طرح جانتا ہے، درخواست پر جلد سے جلد کارروائی کرے۔ ممکن. لیکن ایسا لگتا ہے کہ "ڈیڈ لائن" کارکردگی کو بہتر بناتی ہے۔ آپ لینکس کرنل سورس کوڈ دستاویزات میں شیڈولرز کے بارے میں مزید پڑھ سکتے ہیں: linux/Documentation/block/*osched.txt. اور میں نے مخلوط آپریشنز (کئی تحریری کارروائیوں) کے دوران پڑھنے کے تھرو پٹ میں اضافہ دیکھا ہے۔
"256" > /sys/block/sdc/queue/nr_requests
شیڈولر کو بھیجے جانے سے پہلے بفر میں I/O درخواستوں کی تعداد۔ کچھ کنٹرولرز کی اندرونی قطار کا سائز (قطار_گہرائی) I/O شیڈولر کی nr_requests سے بڑا ہوتا ہے، اس لیے I/O شیڈولر کے پاس درخواستوں کو مناسب طریقے سے ترجیح دینے اور ضم کرنے کا بہت کم امکان ہوتا ہے۔ ڈیڈ لائن اور CFQ شیڈولرز کے لیے، یہ بہتر ہے جب nr_requests کنٹرولر کی اندرونی قطار سے 2 گنا زیادہ ہو۔ درخواستوں کو ضم کرنے اور دوبارہ ترتیب دینے سے شیڈیولر کو بھاری بوجھ میں زیادہ جوابدہ ہونے میں مدد ملتی ہے۔
echo "16" > /proc/sys/vm/page-cluster
صفحہ کلسٹر پیرامیٹر ان صفحات کی تعداد کو کنٹرول کرتا ہے جو ایک وقت میں سویپ پر لکھے جاتے ہیں۔ مندرجہ بالا مثال میں، قیمت 16 KB کی RAID پٹی کے سائز کے مطابق "64" پر سیٹ کی گئی ہے۔ swappiness = 0 کے ساتھ اس کا کوئی مطلب نہیں ہے، لیکن اگر آپ swappiness کو 10 یا 20 پر سیٹ کرتے ہیں تو اس قدر کو استعمال کرنے سے آپ کو مدد ملے گی جب RAID پٹی کا سائز 64K ہے۔
blockdev --setra 4096 /dev/<devname> (-sdb، hdc یا dev_mapper)
بہت سے RAID کنٹرولرز کے لیے ڈیفالٹ بلاک ڈیوائس سیٹنگز اکثر خوفناک کارکردگی کا باعث بنتی ہیں۔ مندرجہ بالا آپشن کو شامل کرنے سے 4096 * 512 بائٹ سیکٹرز کے لیے ریڈ-ایڈ سیٹ ہو جاتا ہے۔ کم از کم، سٹریمنگ آپریشنز کے لیے، I/O کی تیاری کے لیے کرنل کے استعمال کردہ دورانیے کے دوران آن-چِپ ڈسک کیشے کو ریڈ-ایڈ کے ساتھ بھر کر رفتار بڑھائی جاتی ہے۔ کیشے میں ڈیٹا ہو سکتا ہے جس کی اگلی پڑھنے پر درخواست کی جائے گی۔ بہت زیادہ prefetch بڑی فائلوں کے لیے بے ترتیب I/O کو ختم کر سکتا ہے اگر یہ ممکنہ طور پر مفید ڈسک کا وقت استعمال کرتا ہے یا ڈیٹا کو کیشے سے باہر لوڈ کرتا ہے۔
فائل سسٹم کی سطح پر ذیل میں کچھ اور سفارشات ہیں۔ لیکن ان کا ابھی تک ٹیسٹ نہیں ہوا ہے۔ یقینی بنائیں کہ آپ کا فائل سسٹم پٹی کے سائز اور صف میں موجود ڈسکوں کی تعداد کو جانتا ہے۔ مثال کے طور پر، یہ چھ ڈسکوں کی 5K پٹی raid64 صف ہے (دراصل پانچ، کیونکہ ایک ڈسک برابری کے لیے استعمال ہوتی ہے)۔ یہ سفارشات نظریاتی مفروضوں پر مبنی ہیں اور RAID ماہرین کے مختلف بلاگز/مضامین سے مرتب کی گئی ہیں۔
-> ext4 fs, 5 disks, 64K stripe, units in 4K blocks
mkfs -text4 -E stride=$((64/4))
-> xfs, 5 disks, 64K stripe, units in 512-byte sectors
mkfs -txfs -d sunit=$((64*2)) -d swidth=$((5*64*2))بڑی فائلوں کے لیے، اوپر درج پٹی کے سائز کو بڑھانے پر غور کریں۔
انتباہ! اوپر بیان کردہ ہر چیز کچھ قسم کی ایپلی کیشنز کے لیے انتہائی ساپیکش ہے۔ یہ مضمون متعلقہ ایپلی کیشنز کی پیشگی صارف کی جانچ کے بغیر کسی بہتری کی ضمانت نہیں دیتا۔ یہ صرف اس صورت میں استعمال کیا جانا چاہئے جب یہ نظام کی مجموعی ردعمل کو بہتر بنانے کے لئے ضروری ہے، یا اگر یہ موجودہ مسائل کو حل کرتا ہے.
اضافی مواد:
مزید پڑھ
ماخذ: www.habr.com