د مقالې ژباړه د کورس د پیل په ماښام چمتو شوې وه .
د وخت په تیریدو سره ، دلته او هلته د کرنل دودیز کولو په اړه د ګلسټر وړاندیزونو په اړه پوښتنې راپورته کیږي او ایا دا اړینه ده.
دا اړتیا په ندرت سره پیښیږي. کور د ډیری کاري بارونو لاندې خورا ښه فعالیت کوي. که څه هم یو نیمګړتیا شتون لري. په تاریخي توګه، د لینکس کرنل په اسانۍ سره ډیری حافظه مصرفوي که چیرې فرصت ورکړل شي، په شمول د کیچ کولو لپاره د فعالیت ښه کولو لومړنۍ وسیلې په توګه.
په ډیری قضیو کې دا عالي کار کوي ، مګر د دروند بار لاندې دا کولی شي ستونزې رامینځته کړي.
موږ د سیسټمونو سره کار کولو پراخه تجربه لرو چې ډیری حافظه مصرفوي ، لکه CAD ، EDA او داسې نور ، کوم چې د لوړ بار لاندې ورو ورو پیل شو. او ځینې وختونه موږ په ګلستر کې له ستونزو سره مخ شو. له یوې ورځې څخه د ډیرو لپاره کارول شوي حافظې او ډیسک انتظار وخت په احتیاط سره څارلو وروسته ، موږ د ډیسک اوورلوډ ، لوی iowait ، د کرنل غلطۍ (کرنل اوپس) ، منجمد او داسې نور ترلاسه کړل.
دا مقاله په مختلفو حالتونو کې ترسره شوي د ډیری پیرامیټرو ټونینګ تجربو پایله ده. د دې پیرامیټونو څخه مننه، نه یوازې په عمومي ډول غبرګون ښه شوی، بلکې د کلستر عملیات هم د پام وړ ثبات شوی.
کله چې د حافظې تنظیم کولو خبره راځي ، د لیدو لپاره لومړی ځای د مجازی حافظې سب سیسټم (VM) دی ، کوم چې لوی شمیر اختیارونه لري چې کولی شي تاسو مغشوش کړي.
vm.swappiness
پارسيم vm.swappiness دا معلوموي چې د RAM په پرتله څومره کرنل سویپ کاروي. دا د سرچینې کوډ کې د "نقشه شوي حافظې غلا کولو تمایل" په توګه هم تعریف شوی. د لوړ تبادلې ارزښت پدې معنی دی چې کرنل به د نقشه شوي پاڼو بدلولو لپاره ډیر حساس وي. د ټيټ swappiness ارزښت برعکس معنی لري: کرنل به د حافظې څخه لږ مخونه بدل کړي. په بل عبارت، ارزښت لوړ دی vm.swappiness، هرڅومره چې سیسټم به swap کاروي.
د تبادلې پراخه کارول ناغوښتل دي ، ځکه چې د ډیټا لوی بلاکونه په رام کې بار شوي او پورته کیږي. ډیری خلک استدلال کوي چې د بدلون ارزښت باید لوړ وي، مګر زما په تجربه کې، دا "0" ته ترتیب کول د غوره فعالیت پایلې لري.
تاسو کولی شئ دلته نور ولولئ -
مګر بیا، دا ترتیبات باید په احتیاط سره وکارول شي او یوازې د ځانګړي غوښتنلیک ازموینې وروسته. د لوړ بار شوي سټیمینګ غوښتنلیکونو لپاره ، دا پیرامیټر باید "0" ته تنظیم شي. کله چې "0" ته بدل شي، د سیسټم غبرګون ښه کیږي.
vm.vfs_cache_pressure
دا ترتیب هغه حافظه کنټرولوي چې د کرنل لخوا مصرف شوي د ډایرکټری څیزونو او انډونو (ډینټري او انډ) کیچ کولو لپاره مصرف کیږي.
د 100 د ډیفالټ ارزښت سره، کرنل به هڅه وکړي چې د dentry او inode کیچونه په مناسب ډول د پاڼې کیچ او سویپ کیچ ته آزاد کړي. د vfs_cache_pressure کمیدل د دې لامل کیږي چې دانی د غاښونو او انود کیچونو ساتنه وکړي. کله چې ارزښت "0" وي، دانی به هیڅکله د حافظې د فشار له امله د غاښونو او انوډ کیچ فلش نه کړي، او دا کولی شي په اسانۍ سره د حافظې څخه بهر غلطی لامل شي. د vfs_cache_pressure له 100 څخه پورته زیاتول د دې لامل کیږي چې کرنل د غاښونو او انوډ پاڼې ته لومړیتوب ورکړي.
کله چې د ګلسټر ایف ایس کاروئ ، ډیری کارونکي د ډیټا لوی مقدار او ډیری کوچني فایلونه په اسانۍ سره کولی شي په سرور کې د انوډ / ډینټري کیچ کولو له امله د پام وړ مقدار RAM وکاروي ، کوم چې د ضعیف فعالیت لامل کیدی شي ځکه چې کرنل باید په سیسټم کې د ډیټا جوړښتونه اداره کړي. د 40 GB حافظې سره. د دې پیرامیټر له 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-90GB پاڼې کیچ فلش کول عادي خبره ده ، په پایله کې د مخکښې پای غوښتنلیکونو لپاره لوی ځنډ رامینځته کیږي ، د عمومي غبرګون او متقابل عمل کمول.
"1" > /proc/sys/vm/pagecache
د پاڼې کیچ یوه زیرمه ده چې د فایلونو او اجرا وړ برنامو څخه ډیټا ذخیره کوي ، دا د فایلونو یا بلاک وسیلو اصلي مینځپانګې سره پا pagesې دي. دا زیرمه د ډیسک لوستلو شمیر کمولو لپاره کارول کیږي. د "1" ارزښت پدې معنی دی چې کیچ د رام 1٪ کاروي او د ډیسک څخه به د رام څخه ډیر لوستل کیږي. دا اړینه نده چې دا ترتیب بدل کړئ، مګر که تاسو د پاڼې کیچ کنټرول کولو په اړه بې رحمه یاست، تاسو کولی شئ دا وکاروئ.
"ختمه نیټه" > /sys/block/sdc/queue/scheduler
د I/O مهالویش کونکی د لینکس کرنل یوه برخه ده چې د لوستلو او لیکلو کتارونه اداره کوي. په تیوري کې ، دا غوره ده چې د سمارټ RAID کنټرولر لپاره "نوپ" وکاروئ ، ځکه چې لینکس د ډیسک فزیکي جیومیټري په اړه هیڅ نه پوهیږي ، نو دا خورا مؤثره ده چې کنټرولر ته اجازه ورکړئ چې د ډیسک جیومیټري ښه پوهیږي ، غوښتنه پروسس کړي. ژر تر ژره. مګر داسې ښکاري چې "مهمه نیټه" فعالیت ښه کوي. د مهالویش په اړه نور معلومات د لینکس کرنل سرچینې کوډ لپاره په اسنادو کې موندل کیدی شي: 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" ته ټاکل شوی ترڅو د RAID پټې اندازې 64 KB سره سمون ومومي. دا معنی نلري کله چې swappiness = 0، مګر که تاسو swappiness 10 یا 20 ته وټاکئ، نو د دې ارزښت کارول به تاسو سره مرسته وکړي کله چې د RAID پټې اندازه 64 KB وي.
blockdev --setra 4096 /dev/<devname> (-sdb، hdc یا dev_mapper)
د ډیری RAID کنټرولرونو لپاره د ډیفالټ بلاک وسیلې تنظیمات اکثرا د ناوړه فعالیت پایله وي. د پورته اختیار اضافه کول د 4096 * 512 بایټ سکټورونو لپاره د لوستلو دمخه تنظیموي. لږترلږه د سټرینګ عملیاتو لپاره ، سرعت د لوستلو مخکې له لارې د آن چپ ډیسک کیچ ډکولو سره د هغه مودې په جریان کې لوړیږي چې کرنل د I/O چمتو کولو لپاره کاروي. زیرمه کولی شي هغه معلومات وساتي چې د راتلونکي لوستلو پرمهال به غوښتنه وشي. خورا ډیر لوستل کولی شي د لوی فایلونو لپاره تصادفي I/O وژني که چیرې دا د احتمالي ګټور ډیسک وخت کاروي یا د کیچ څخه بهر ډیټا بار کړي.
لاندې د فایل سیسټم په کچه یو څو نور وړاندیزونه دي. مګر دوی لاهم ندي ازمول شوي. ډاډ ترلاسه کړئ چې ستاسو د فایل سیسټم د پټو اندازه او په صف کې د ډیسکونو شمیر پیژني. د مثال په توګه، دا د raid5 صف دی چې د 64K پټې اندازې سره د شپږو ډیسکونو (په حقیقت کې پنځه، ځکه چې یو ډیسک د برابرۍ لپاره کارول کیږي). دا سپارښتنې د نظري انګیرنې پر بنسټ دي او د 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