පාඨමාලා ආරම්භයට ආසන්න දිනක ලිපියේ පරිවර්තනය සකස් කරන ලදී .
කාලානුරූපව, එහෙන් මෙහෙන්, කර්නල් සුසර කිරීම සම්බන්ධයෙන් ග්ලස්ටර්ගේ නිර්දේශ සහ මේ සඳහා අවශ්‍යතාවයක් තිබේද යන්න පිළිබඳව ප්‍රශ්න මතු වේ.
එවැනි අවශ්යතාවක් කලාතුරකින් පැන නගී. බොහෝ වැඩ බර මත, කර්නලය ඉතා හොඳින් ක්රියා කරයි. අවාසියක් තිබුණත්. ඓතිහාසිකව, Linux කර්නලය කාර්ය සාධනය වැඩි දියුණු කිරීමේ ප්‍රධාන මාර්ගය ලෙස හැඹිලිගත කිරීම ඇතුළුව, අවස්ථාව ලබා දෙන්නේ නම්, මතකය විශාල ප්‍රමාණයක් පරිභෝජනය කිරීමට කැමැත්තෙන් සිටී.
බොහෝ අවස්ථාවලදී, මෙය හොඳින් ක්රියා කරයි, නමුත් අධික බරක් යටතේ එය ගැටළු ඇති විය හැක.
අධික බරක් යටතේ මන්දගාමී වීමට පටන් ගත් CAD, EDA සහ ඒ හා සමාන මතක තීව්‍ර පද්ධති පිළිබඳ අපට බොහෝ අත්දැකීම් තිබේ. ඒ වගේම සමහර වෙලාවට අපි Gluster එකේ ප්‍රශ්නවලට මුහුණ දුන්නා. දින ගණනාවක් තිස්සේ මතක භාවිතය සහ තැටි ප්‍රමාදය හොඳින් නිරීක්ෂණය කිරීමෙන් පසු, අපට ඒවායේ අධික බර, විශාල iowait, කර්නල් දෝෂ (kernel oops), freezes යනාදිය ලැබුණි.
මෙම ලිපිය විවිධ අවස්ථා වලදී සිදු කරන ලද බොහෝ සුසර කිරීමේ අත්හදා බැලීම්වල ප්‍රතිඵලයකි. මෙම පරාමිතීන්ට ස්තූතියි, සමස්ත ප්රතිචාර දැක්වීම පමණක් නොව, පොකුර ද සැලකිය යුතු ලෙස ස්ථාවර වී ඇත.
මතක සුසර කිරීම සම්බන්ධයෙන් ගත් කල, මුලින්ම බැලිය යුත්තේ අතථ්‍ය මතක උප පද්ධතියයි (VM, අතථ්‍ය මතකය), එය ඔබව ව්‍යාකූල කළ හැකි විකල්ප විශාල ප්‍රමාණයක් ඇත.
vm.swappiness
පරාමිතිය vm.swappiness RAM හා සසඳන විට කර්නලය swap (swap, pageging) භාවිතා කරන ආකාරය තීරණය කරයි. එය ප්‍රභව කේතයේ "සිතියම් කළ මතකය සොරකම් කිරීමේ ප්‍රවණතාව" ලෙසද අර්ථ දක්වා ඇත. ඉහළ swappiness යන්නෙන් අදහස් වන්නේ කර්නලය සිතියම්ගත පිටු මාරු කිරීමට වැඩි නැඹුරුවක් දක්වන බවයි. අඩු swappiness අගයක් යනු ප්‍රතිවිරුද්ධ දෙයයි: කර්නලය මතකයෙන් පිටු අඩු වේ. වෙනත් වචන වලින් කිවහොත්, ඉහළ අගය vm.swappiness, පද්ධතිය swap භාවිතා කරන තරමට.
විශාල දත්ත ප්‍රමාණයක් RAM තුළට පටවා බෑම නිසා විශාල වශයෙන් හුවමාරු කිරීම නුසුදුසුය. බොහෝ අය තර්ක කරන්නේ swapiness අගය විශාල විය යුතු බවයි, නමුත් මගේ අත්දැකීම අනුව, එය "0" ලෙස සැකසීම වඩා හොඳ කාර්ය සාධනයකට මඟ පාදයි.
ඔබට මෙහි වැඩිදුර කියවිය හැකිය -
එහෙත්, නැවතත්, මෙම සැකසුම් ප්රවේශමෙන් යෙදිය යුතු අතර විශේෂිත යෙදුමක් පරීක්ෂා කිරීමෙන් පසුව පමණි. අධික ලෙස පටවන ලද ප්‍රවාහ යෙදුම් සඳහා, මෙම පරාමිතිය "0" ලෙස සැකසිය යුතුය. "0" ලෙස වෙනස් කළ විට, පද්ධති ප්‍රතිචාරය වැඩි දියුණු වේ.
vm.vfs_cache_pressure
මෙම සැකසුම හැඹිලි නාමාවලිය සහ ඉනෝඩ වස්තු සඳහා කර්නලය විසින් පරිභෝජනය කරන මතකය පාලනය කරයි (දන්ත සහ ඉනෝඩය).
පෙරනිමි අගය 100ක් සමඟින්, කර්නලය විසින් dentry සහ inode හැඹිලි "සාධාරණ" පදනමක් මත pagecache සහ swapcache වෙත නිදහස් කිරීමට උත්සාහ කරනු ඇත. vfs_cache_pressure අඩු කිරීම කර්නලය dentri සහ inode caches තබා ගැනීමට හේතු වේ. අගය "0" වූ විට, මතකයේ පීඩනය හේතුවෙන් කර්නලය කිසි විටෙක දන්ත සහ ඉනෝඩ හැඹිලිය ෆ්ලෂ් නොකරන අතර මෙය පහසුවෙන් මතකයෙන් බැහැර දෝෂයකට තුඩු දිය හැකිය. vfs_cache_pressure 100 ට වඩා වැඩි කිරීම කර්නලය දත් හා ඉනෝඩ සේදීමට ප්‍රමුඛත්වය දීමට හේතු වේ.
GlusterFS භාවිතා කරන විට, විශාල දත්ත ප්‍රමාණයක් සහ කුඩා ගොනු රාශියක් ඇති බොහෝ පරිශීලකයින්ට, inode/dentry caching හේතුවෙන් සේවාදායකයේ සැලකිය යුතු 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-90 GB පිටු හැඹිලි තැටියට ෆ්ලෂ් කිරීම සාමාන්‍ය මතක බර පද්ධති සඳහා උපකාර කළ හැකි අතර, එහි ප්‍රතිඵලයක් ලෙස ඉදිරිපස යෙදුම් සඳහා විශාල ප්‍රමාදයක් ඇති කරයි, සමස්ත ප්රතිචාර දැක්වීම සහ අන්තර්ක්‍රියාකාරීත්වය අඩු කරයි.
"1" > /proc/sys/vm/pagecache
පිටු හැඹිලි යනු ගොනු සහ ක්‍රියාත්මක කළ හැකි වැඩසටහන් වල දත්ත ගබඩා කරන හැඹිලියකි, එනම් මේවා ගොනු හෝ බ්ලොක් උපාංගවල සත්‍ය අන්තර්ගතය සහිත පිටු වේ. මෙම හැඹිලිය තැටි කියවීම් ගණන අඩු කිරීමට භාවිතා කරයි. "1" අගයක් යනු හැඹිලිය සඳහා RAM වලින් 1% ක් භාවිතා කරන අතර RAM වලින් කියවීමට වඩා තැටියෙන් කියවීම් වැඩි වේ. මෙම සැකසුම වෙනස් කිරීම අවශ්‍ය නොවේ, නමුත් ඔබ පිටු හැඹිලිය පාලනය කිරීම ගැන ව්‍යාකූල නම්, ඔබට එය භාවිතා කළ හැක.
"අවසන් දිනය" > /sys/block/sdc/queue/scheduler
I/O උපලේඛකය යනු ලිනක්ස් කර්නල් සංරචකයක් වන අතර එය කියවීමට සහ ලිවීමට පෝලිම් හසුරුවයි. න්‍යායාත්මකව, ස්මාර්ට් RAID පාලකයක් සඳහා "noop" භාවිතා කිරීම වඩා හොඳය, මන්ද ලිනක්ස් තැටියේ භෞතික ජ්‍යාමිතිය ගැන කිසිවක් නොදන්නා නිසා තැටි ජ්‍යාමිතිය හොඳින් දන්නා පාලකයට ඉල්ලීම ඉක්මනින් සැකසීමට ඉඩ දීම වඩාත් කාර්යක්ෂම වේ. හැකි. නමුත් "අවසාන දිනය" කාර්ය සාධනය වැඩි දියුණු කරන බව පෙනේ. ඔබට Linux කර්නල් ප්‍රභව කේත ලේඛනයෙන් උපලේඛන ගැන වැඩිදුර කියවිය හැක: 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
පිටු-පොකුරු පරාමිතිය එක් වරකදී swap වෙත ලියා ඇති පිටු ගණන පාලනය කරයි. ඉහත උදාහරණයේ, 16 KB RAID තීරු ප්‍රමාණයට අනුව අගය "64" ලෙස සකසා ඇත. එය swappiness = 0 සමඟ තේරුමක් නැත, නමුත් ඔබ swappiness 10 හෝ 20 ලෙස සකසන්නේ නම්, RAID තීරු ප්‍රමාණය 64K වන විට මෙම අගය භාවිතා කිරීම ඔබට උපකාරී වනු ඇත.
blockdev --setra 4096 /dev/<devname> (-sdb, hdc හෝ dev_mapper)
බොහෝ RAID පාලක සඳහා පෙරනිමි බ්ලොක් උපාංග සැකසුම් බොහෝ විට භයානක කාර්ය සාධනයක් ඇති කරයි. ඉහත විකල්පය එකතු කිරීමෙන් 4096 * 512-byte අංශ සඳහා කියවීමට පෙරට සකසයි. අවම වශයෙන්, ප්‍රවාහ මෙහෙයුම් සඳහා, 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