مضمون جو ترجمو ڪورس جي شروعات جي موقعي تي تيار ڪيو ويو .
وقتي طور تي، هتي ۽ اتي، سوال پيدا ٿين ٿا Gluster جي سفارشن جي باري ۾ ڪرنل ٽيوننگ بابت ۽ ڇا ان جي ضرورت آهي.
اهڙي ضرورت تمام گهٽ ٿيندي آهي. اڪثر ڪم لوڊ تي، ڪنييل تمام سٺو ڪم ڪري ٿو. جيتوڻيڪ اتي هڪ downside آهي. تاريخي طور تي، لينڪس ڪنييل تمام گهڻي ميموري کي استعمال ڪرڻ لاء تيار ٿي چڪو آهي جيڪڏهن موقعو ڏنو وڃي، بشمول ڪارڪردگي کي بهتر ڪرڻ لاء بنيادي طريقي سان ڪيچنگ لاء.
اڪثر ڪيسن ۾، اهو ڪم ٺيڪ آهي، پر ڳري لوڊ هيٺ اهو مسئلا پيدا ڪري سگهي ٿو.
اسان وٽ تمام گهڻو تجربو آهي ميموري جي شدت واري نظام جهڙوڪ CAD، EDA ۽ جهڙوڪ، جيڪو ڳري لوڊ هيٺ سست ٿيڻ شروع ڪيو. ۽ ڪڏهن ڪڏهن اسان گلسٽر ۾ مسئلن ۾ ڀڄي ويا. ڪيترن ئي ڏينهن تائين ميموري جي استعمال ۽ ڊسڪ جي دير سان غور سان مشاهدو ڪرڻ کان پوءِ، اسان انهن جي اوورلوڊ، وڏي آئوٽ، ڪرنل ايررز (ڪرنل اوپس)، فريز وغيره حاصل ڪيون.
هي آرٽيڪل مختلف حالتن ۾ ڪيل ڪيترن ئي ٽنگنگ تجربن جو نتيجو آهي. انهن معيارن جي مهرباني، نه رڳو مجموعي ردعمل بهتر ٿي چڪو آهي، پر ڪلستر پڻ خاص طور تي مستحڪم ٿي چڪو آهي.
جڏهن اها ميموري ٽيوننگ تي اچي ٿي، ڏسڻ لاءِ پهرين شيءِ آهي ورچوئل ميموري سبسسٽم (VM، ورچوئل ميموري)، جنهن ۾ وڏي تعداد ۾ آپشنز آهن جيڪي توهان کي پريشان ڪري سگهن ٿيون.
vm.swappiness
نيم vm.swappiness اهو طئي ڪري ٿو ته ڪتن ڪيترو استعمال ڪري ٿو سوپ (سوپ، پيجنگ) رام جي مقابلي ۾. اهو پڻ بيان ڪيو ويو آهي ماخذ ڪوڊ ۾ "ميپ ٿيل ياداشت چوري ڪرڻ جو رجحان". هڪ اعلي ادل جو مطلب آهي ته ڪرنل نقشي جي صفحن کي تبديل ڪرڻ لاء وڌيڪ مائل هوندو. گھٽ swappiness قدر جو مطلب آھي سامهون: ڪنيال ياداشت کان گھٽ صفحو ٿيندو. ٻين لفظن ۾، اعلي قدر vm.swappiness، وڌيڪ سسٽم ادل استعمال ڪندو.
ادل بدلائڻ جو وڏو استعمال ناپسنديده آهي، ڇاڪاڻ ته ڊيٽا جا وڏا بلاڪ رام ۾ لوڊ ۽ لوڊ ڪيا ويندا آهن. ڪيترائي ماڻهو بحث ڪن ٿا ته ادل جي قيمت وڏي هجڻ گهرجي، پر منهنجي تجربي ۾، ان کي ترتيب ڏيڻ "0" بهتر ڪارڪردگي جي ڪري ٿي.
توهان وڌيڪ پڙهي سگهو ٿا هتي -
پر، ٻيهر، اهي سيٽنگون احتياط سان لاڳو ٿيڻ گهرجن ۽ صرف هڪ خاص ايپليڪيشن کي جانچڻ کان پوء. انتهائي لوڊ ٿيل اسٽريمنگ ايپليڪيشنن لاءِ، هي پيٽرول مقرر ڪيو وڃي "0" تي. جڏهن تبديل ڪيو ويو "0"، سسٽم جي ردعمل بهتر ٿي.
vm.vfs_cache_pressure
هي سيٽنگ ڪيشنگ ڊاريڪٽري ۽ انوڊ آبجڪس (ڊنٽري ۽ انوڊ) لاءِ ڪنيل جي استعمال ڪيل ميموري کي ڪنٽرول ڪري ٿي.
100 جي ڊفالٽ قدر سان، ڪرنل ڊينٽري ۽ انوڊ ڪيچز کي ”منصفانه“ بنيادن تي پيج ڪيچ ۽ ادل بدلائڻ جي ڪوشش ڪندو. vfs_cache_pressure جي گھٽتائي ڪرينل کي ڊينٽري ۽ انوڊ ڪيش رکڻ جو سبب بڻائيندو آهي. جڏهن قدر "0" آهي، ڪرنل ڪڏهن به ڊينٽري ۽ انوڊ ڪيش کي ميموري پريشر جي ڪري فلش نه ڪندو، ۽ اهو آساني سان ميموري کان ٻاهر جي غلطي جي ڪري سگھي ٿو. vfs_cache_pressure 100 کان مٿي وڌائڻ ڪرينل کي ڊينٽري ۽ انوڊ فلشنگ کي ترجيح ڏئي ٿو.
GlusterFS استعمال ڪرڻ وقت، ڪيترائي استعمال ڪندڙ ڊيٽا جي وڏي مقدار سان ۽ ڪيتريون ئي ننڍيون فائلون آساني سان سرور تي وڏي مقدار ۾ RAM استعمال ڪري سگھن ٿيون انوڊ/ڊينٽري ڪيشنگ جي ڪري، جيڪا ڪارڪردگي جي خراب ٿيڻ جي ڪري ٿي سگھي ٿي جيئن ڪنيل کي سسٽم تي ڊيٽا جي جوڙجڪ کي پروسيس ڪرڻو پوندو. 40 GB ميموري سان. ھن قدر کي 100 کان مٿي سيٽ ڪرڻ ڪيترن ئي استعمال ڪندڙن جي مدد ڪئي آھي منصفانه ڪيشنگ حاصل ڪرڻ ۽ ڪنييل جوابن کي بھتر ڪيو.
vm.dirty_background_ratio ۽ vm.dirty_ratio
پهريون پيٽرولر (vm.dirty_background_ratio) گندي صفحن سان ميموري جي فيصد کي طئي ڪري ٿو، جنهن تي پهچڻ کان پوءِ اهو ضروري آهي ته پس منظر ۾ موجود گندي صفحن کي ڊسڪ ۾ فلش ڪرڻ شروع ڪيو وڃي. جيستائين هي فيصد پهچي نه وڃي، ڊسڪ تي ڪوبه صفحا فلش نه ٿيندا. ۽ جڏهن ريٽ شروع ٿئي ٿو، اهو پس منظر ۾ هلندو آهي بغير هلندڙ عملن ۾ مداخلت ڪرڻ جي.
ٻيو پيٽرولر (vm.dirty_ratio) ميموري جي فيصد کي بيان ڪري ٿو جيڪو زبردستي فليش شروع ٿيڻ کان اڳ گندي صفحن تي قبضو ڪري سگهجي ٿو. هڪ دفعو هن حد تائين پهچي وڃي ٿي، سڀئي عمل هم وقت ساز (بلاڪ) ٿي ويندا آهن ۽ جاري رکڻ جي اجازت نه هوندي جيستائين I/O انهن جي درخواست ڪئي اصل ۾ مڪمل ٿي وڃي ۽ ڊيٽا ڊسڪ تي هجي. Heavy I/O سان، هي هڪ مسئلو پيدا ڪري ٿو ڇو ته ڊيٽا ڪيشنگ نه آهي ۽ I/O ڪرڻ وارا سڀئي عمل I/O جي انتظار ۾ بند ٿيل آهن. اهو وڏي تعداد ۾ ٽنگيل عمل، اعلي لوڊ، سسٽم جي عدم استحڪام ۽ خراب ڪارڪردگي جي ڪري ٿي.
انهن سيٽنگن کي گھٽائڻ جي ڪري ڊيٽا کي وڌيڪ بار بار ڊسڪ تي فلش ڪيو وڃي ٿو ۽ ريم ۾ محفوظ نه ڪيو وڃي. هي ميموري-هائي سسٽم جي مدد ڪري سگهي ٿو جتي 45-90 GB پيج ڪيچز کي ڊسڪ تي فلش ڪرڻ عام آهي، نتيجي ۾ فرنٽ-اينڊ ايپليڪيشنن لاءِ وڏي ويڪرائي، مجموعي ردعمل ۽ تعامل کي گهٽائڻ.
"1" > /proc/sys/vm/pagecache
هڪ صفحو ڪيش هڪ ڪيش آهي جيڪو فائلن جي ڊيٽا کي محفوظ ڪري ٿو ۽ قابل عمل پروگرام، اهو آهي، اهي صفحا آهن فائلن جي حقيقي مواد يا بلاڪ ڊوائيسز سان. هي ڪيش ڊسڪ پڙهڻ جي تعداد کي گهٽائڻ لاء استعمال ڪيو ويندو آهي. "1" جي قيمت جو مطلب آهي ته 1٪ RAM ڪيش لاء استعمال ڪيو ويندو آهي ۽ اتي وڌيڪ ريڊ کان ڊسڪ مان ريم کان وڌيڪ هوندي. هن سيٽنگ کي تبديل ڪرڻ ضروري ناهي، پر جيڪڏهن توهان صفحو ڪيش کي ڪنٽرول ڪرڻ جي باري ۾ پريشان آهيو، ته توهان ان کي استعمال ڪري سگهو ٿا.
"ڊيڊ لائن" > /sys/block/sdc/queue/scheduler
I/O شيڊولر هڪ لينڪس ڪنييل جزو آهي جيڪو پڙهڻ ۽ لکڻ جي قطار کي سنڀاليندو آهي. نظريي ۾، سمارٽ RAID ڪنٽرولر لاءِ ”نوپ“ استعمال ڪرڻ بهتر آهي، ڇاڪاڻ ته لينڪس ڊسڪ جي فزيڪل جاميٽري بابت ڪجهه به نه ٿو ڄاڻي، تنهن ڪري اهو وڌيڪ ڪارائتو آهي ته ڪنٽرولر کي، جيڪو ڊسڪ جي جاميٽري کي چڱيءَ طرح ڄاڻي ٿو، درخواست تي جلدي عمل ڪري. ممڪن. پر اهو ڏسڻ ۾ اچي ٿو "ڊيٽ لائن" ڪارڪردگي بهتر ڪري ٿي. توهان شيڊيولرز بابت وڌيڪ پڙهي سگهو ٿا لينڪس ڪنيل سورس ڪوڊ دستاويزن ۾: linux/Documentation/block/*osched.txt. ۽ پڻ مون ڏٺو آهي ته ملايو آپريشن دوران پڙهڻ جي ذريعي ۾ اضافو (ڪيترائي لکن).
"256" > /sys/block/sdc/queue/nr_requests
بفر ۾ I/O درخواستن جو تعداد ان کان اڳ جو اھي شيڊولر ڏانھن منتقل ڪيا وڃن. ڪجهه ڪنٽرولرز جي اندروني قطار جي سائيز (queue_depth) I/O شيڊولر جي nr_requests کان وڏي آهي، تنهنڪري I/O شيڊولر کي مناسب ترجيح ڏيڻ ۽ ضم ڪرڻ جي درخواستن جو ٿورو موقعو آهي. ڊيڊ لائن ۽ CFQ شيڊيولرز لاءِ، اھو بھتر آھي جڏھن nr_requests ڪنٽرولر جي اندروني قطار کان 2 ڀيرا آھي. درخواستن کي ضم ڪرڻ ۽ ٻيهر ترتيب ڏيڻ ۾ مدد ڪري ٿي شيڊولر کي ڳري لوڊ هيٺ وڌيڪ جوابدار ٿيڻ.
گونج "16" > /proc/sys/vm/page-cluster
صفحو-ڪلسٽر پيٽرولر انهن صفحن جي تعداد کي سنڀاليندو آهي جيڪي هڪ وقت ۾ ادل تي لکيل آهن. مٿين مثال ۾، قيمت 16 KB جي RAID پٽي سائيز جي مطابق "64" تي مقرر ڪئي وئي آهي. اهو swappiness = 0 سان ڪو به مطلب نٿو رکي، پر جيڪڏهن توهان 10 يا 20 تي swappiness مقرر ڪيو ته پوء هي قيمت استعمال ڪندي توهان جي مدد ڪندي جڏهن RAID پٽي سائيز 64K آهي.
blockdev --setra 4096 /dev/<نالو> (-sdb، hdc يا dev_mapper)
ڪيترن ئي RAID ڪنٽرولرز لاءِ ڊفالٽ بلاڪ ڊيوائس سيٽنگون اڪثر ڪري خوفناڪ ڪارڪردگي جو نتيجو آهن. مٿي ڏنل آپشن کي شامل ڪرڻ سان 4096 * 512-بائيٽ سيڪٽرز لاءِ پڙھڻ-اڳتي سيٽ اپ ڪري ٿو. تمام گھٽ ۾ گھٽ، اسٽريمنگ آپريشنز لاءِ، رفتار وڌي ويندي آھي آن-چِپ ڊسڪ ڪيش کي ڀرڻ سان گڏ پڙھڻ واري عرصي دوران I/O تيار ڪرڻ لاءِ ڪنيل استعمال ڪيو. ڪيش ڊيٽا تي مشتمل ٿي سگھي ٿو جيڪا ايندڙ پڙهڻ تي درخواست ڪئي ويندي. تمام گھڻو اڳڀرائي وڏي فائلن لاءِ بي ترتيب 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