GlusterFS-നായി Linux കേർണൽ സജ്ജീകരിക്കുന്നു

കോഴ്‌സ് തുടങ്ങുന്നതിന്റെ തലേന്ന് തയ്യാറാക്കിയതാണ് ലേഖനത്തിന്റെ പരിഭാഷ അഡ്മിനിസ്ട്രേറ്റർ ലിനക്സ്. പ്രൊഫഷണൽ ».

ആനുകാലികമായി, അവിടെയും ഇവിടെയും, കേർണൽ ട്യൂണിംഗിനെ സംബന്ധിച്ച ഗ്ലസ്റ്ററിന്റെ ശുപാർശകളെക്കുറിച്ചും ഇതിന്റെ ആവശ്യമുണ്ടോ എന്നതിനെക്കുറിച്ചും ചോദ്യങ്ങൾ ഉയർന്നുവരുന്നു.

അത്തരമൊരു ആവശ്യം വളരെ അപൂർവമായി മാത്രമേ ഉണ്ടാകൂ. മിക്ക ജോലിഭാരങ്ങളിലും, കേർണൽ വളരെ നന്നായി പ്രവർത്തിക്കുന്നു. ഒരു പോരായ്മ ഉണ്ടെങ്കിലും. ചരിത്രപരമായി, ലിനക്സ് കേർണൽ, പെർഫോമൻസ് മെച്ചപ്പെടുത്തുന്നതിനുള്ള പ്രധാന മാർഗമായി കാഷിംഗ് ഉൾപ്പെടെ, അവസരം ലഭിച്ചാൽ ധാരാളം മെമ്മറി ഉപയോഗിക്കുവാൻ തയ്യാറാണ്.

മിക്ക കേസുകളിലും, ഇത് നന്നായി പ്രവർത്തിക്കുന്നു, പക്ഷേ കനത്ത ലോഡിൽ ഇത് പ്രശ്നങ്ങൾക്ക് ഇടയാക്കും.

CAD, EDA തുടങ്ങിയ മെമ്മറി ഇന്റൻസീവ് സിസ്റ്റങ്ങളിൽ ഞങ്ങൾക്ക് ധാരാളം അനുഭവങ്ങളുണ്ട്, അത് കനത്ത ലോഡിൽ വേഗത കുറയ്ക്കാൻ തുടങ്ങി. ചിലപ്പോൾ ഞങ്ങൾ ഗ്ലസ്റ്ററിൽ പ്രശ്‌നങ്ങളിൽ അകപ്പെട്ടു. മെമ്മറി ഉപയോഗവും ഡിസ്ക് ലേറ്റൻസിയും വളരെ ദിവസങ്ങളോളം സൂക്ഷ്മമായി നിരീക്ഷിച്ചതിന് ശേഷം, ഞങ്ങൾക്ക് അവരുടെ ഓവർലോഡ്, വലിയ iowait, കേർണൽ പിശകുകൾ (കെർണൽ oops), ഫ്രീസുകൾ മുതലായവ ലഭിച്ചു.

വിവിധ സാഹചര്യങ്ങളിൽ നടത്തിയ നിരവധി ട്യൂണിംഗ് പരീക്ഷണങ്ങളുടെ ഫലമാണ് ഈ ലേഖനം. ഈ പാരാമീറ്ററുകൾക്ക് നന്ദി, മൊത്തത്തിലുള്ള പ്രതികരണശേഷി മെച്ചപ്പെട്ടുവെന്ന് മാത്രമല്ല, ക്ലസ്റ്ററും ഗണ്യമായി സ്ഥിരത കൈവരിക്കുകയും ചെയ്തു.

മെമ്മറി ട്യൂണിംഗിനെക്കുറിച്ച് പറയുമ്പോൾ, നിങ്ങളെ ആശയക്കുഴപ്പത്തിലാക്കാൻ കഴിയുന്ന ധാരാളം ഓപ്ഷനുകൾ ഉള്ള വെർച്വൽ മെമ്മറി സബ്സിസ്റ്റം (VM, വെർച്വൽ മെമ്മറി) ആണ് ആദ്യം നോക്കേണ്ടത്.

vm.swappiness

പാരാമീറ്റർ vm.swappiness റാമുമായി താരതമ്യപ്പെടുത്തുമ്പോൾ കേർണൽ എത്രത്തോളം സ്വാപ്പ് (സ്വാപ്പ്, പേജിംഗ്) ഉപയോഗിക്കുന്നു എന്ന് നിർണ്ണയിക്കുന്നു. സോഴ്സ് കോഡിൽ ഇത് "മാപ്പ് ചെയ്ത മെമ്മറി മോഷ്ടിക്കാനുള്ള പ്രവണത" എന്നും നിർവചിച്ചിരിക്കുന്നു. ഉയർന്ന സ്വാപ്പിനസ്സ് എന്നതിനർത്ഥം മാപ്പ് ചെയ്‌ത പേജുകൾ സ്വാപ്പ് ചെയ്യാൻ കേർണൽ കൂടുതൽ ചായ്‌വ് കാണിക്കും എന്നാണ്. കുറഞ്ഞ സ്വാപ്പിനസ് മൂല്യം വിപരീതമാണ് അർത്ഥമാക്കുന്നത്: കേർണൽ മെമ്മറിയിൽ നിന്ന് പേജ് കുറയും. മറ്റൊരു വിധത്തിൽ പറഞ്ഞാൽ, ഉയർന്ന മൂല്യം vm.swappiness, കൂടുതൽ സിസ്റ്റം സ്വാപ്പ് ഉപയോഗിക്കും.

വലിയ അളവിലുള്ള ഡാറ്റകൾ റാമിലേക്ക് ലോഡ് ചെയ്യുകയും അൺലോഡ് ചെയ്യുകയും ചെയ്യുന്നതിനാൽ, സ്വാപ്പിംഗിന്റെ വലിയ ഉപയോഗം അഭികാമ്യമല്ല. സ്വാപ്പിനസ് മൂല്യം വലുതായിരിക്കണമെന്ന് പലരും വാദിക്കുന്നു, എന്നാൽ എന്റെ അനുഭവത്തിൽ, ഇത് "0" ആയി സജ്ജീകരിക്കുന്നത് മികച്ച പ്രകടനത്തിലേക്ക് നയിക്കുന്നു.

നിങ്ങൾക്ക് ഇവിടെ കൂടുതൽ വായിക്കാം - lwn.net/Articles/100978

പക്ഷേ, വീണ്ടും, ഈ ക്രമീകരണങ്ങൾ ശ്രദ്ധയോടെ പ്രയോഗിക്കണം, ഒരു പ്രത്യേക ആപ്ലിക്കേഷൻ പരിശോധിച്ചതിന് ശേഷം മാത്രം. വളരെയധികം ലോഡ് ചെയ്ത സ്ട്രീമിംഗ് ആപ്ലിക്കേഷനുകൾക്ക്, ഈ പരാമീറ്റർ "0" ആയി സജ്ജീകരിക്കണം. "0" ആയി മാറ്റുമ്പോൾ, സിസ്റ്റം പ്രതികരണശേഷി മെച്ചപ്പെടുന്നു.

vm.vfs_cache_pressure

ഈ ക്രമീകരണം ഡയറക്‌ടറി, ഐനോഡ് ഒബ്‌ജക്‌റ്റുകൾ (ഡെൻട്രി, ഐനോഡ്) എന്നിവയ്‌ക്കായി കേർണൽ ഉപയോഗിക്കുന്ന മെമ്മറി നിയന്ത്രിക്കുന്നു.

100 ന്റെ സ്ഥിര മൂല്യം ഉപയോഗിച്ച്, പേജ് കാഷിലേക്കും സ്വാപ്‌കാഷിലേക്കും "ഫെയർ" അടിസ്ഥാനത്തിൽ ഡെൻട്രി, ഐനോഡ് കാഷെകൾ സ്വതന്ത്രമാക്കാൻ കേർണൽ ശ്രമിക്കും. vfs_cache_pressure കുറയുന്നത് കേർണലിന് ഡെൻട്രി, ഐനോഡ് കാഷെകൾ സൂക്ഷിക്കാൻ കാരണമാകുന്നു. മൂല്യം "0" ആയിരിക്കുമ്പോൾ, മെമ്മറി മർദ്ദം കാരണം കേർണൽ ഒരിക്കലും ഡെന്ററി, ഐനോഡ് കാഷെ ഫ്ലഷ് ചെയ്യില്ല, ഇത് എളുപ്പത്തിൽ മെമ്മറിക്ക് പുറത്തുള്ള പിശകിലേക്ക് നയിച്ചേക്കാം. vfs_cache_pressure 100-ന് മുകളിൽ വർദ്ധിക്കുന്നത് കേർണലിന് ഡെന്ററിക്കും ഐനോഡ് ഫ്ലഷിംഗിനും മുൻഗണന നൽകുന്നു.

GlusterFS ഉപയോഗിക്കുമ്പോൾ, വലിയ അളവിലുള്ള ഡാറ്റയും നിരവധി ചെറിയ ഫയലുകളുമുള്ള നിരവധി ഉപയോക്താക്കൾക്ക് ഐനോഡ്/ഡെൻട്രി കാഷിംഗ് കാരണം സെർവറിൽ ഗണ്യമായ അളവിലുള്ള റാം എളുപ്പത്തിൽ ഉപയോഗിക്കാനാകും, ഇത് കേർണലിന് ഒരു സിസ്റ്റത്തിലെ ഡാറ്റാ ഘടനകൾ പ്രോസസ്സ് ചെയ്യേണ്ടതിനാൽ പ്രകടന നിലവാരത്തകർച്ചയിലേക്ക് നയിച്ചേക്കാം. കൂടെ 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-യ്‌ക്കായി കാത്തിരിക്കുന്നത് തടഞ്ഞിരിക്കുന്നു. ഇത് വലിയ തോതിൽ തൂങ്ങിക്കിടക്കുന്ന പ്രക്രിയകൾ, ഉയർന്ന ലോഡ്, സിസ്റ്റം അസ്ഥിരത, മോശം പ്രകടനം എന്നിവയിലേക്ക് നയിക്കുന്നു.

ഈ ക്രമീകരണങ്ങൾ കുറയ്ക്കുന്നത് ഡാറ്റ കൂടുതൽ തവണ ഡിസ്കിലേക്ക് ഫ്ലഷ് ചെയ്യപ്പെടുകയും റാമിൽ സംഭരിക്കപ്പെടാതിരിക്കുകയും ചെയ്യുന്നു. 45-90 GB പേജ് കാഷെകൾ ഡിസ്കിലേക്ക് ഫ്ലഷ് ചെയ്യുന്നത് സാധാരണമായ മെമ്മറി-ഹെവി സിസ്റ്റങ്ങളെ ഇത് സഹായിക്കും, ഇത് ഫ്രണ്ട് എൻഡ് ആപ്ലിക്കേഷനുകൾക്ക് വലിയ ലേറ്റൻസിക്ക് കാരണമാകുന്നു, മൊത്തത്തിലുള്ള പ്രതികരണശേഷിയും ഇന്ററാക്ടിവിറ്റിയും കുറയ്ക്കുന്നു.

"1" > /proc/sys/vm/pagecache

ഫയലുകളുടെയും എക്സിക്യൂട്ടബിൾ പ്രോഗ്രാമുകളുടെയും ഡാറ്റ സംഭരിക്കുന്ന ഒരു കാഷെയാണ് പേജ് കാഷെ, അതായത്, ഇവ ഫയലുകളുടെയോ ബ്ലോക്ക് ഡിവൈസുകളുടെയോ യഥാർത്ഥ ഉള്ളടക്കമുള്ള പേജുകളാണ്. ഡിസ്ക് റീഡുകളുടെ എണ്ണം കുറയ്ക്കാൻ ഈ കാഷെ ഉപയോഗിക്കുന്നു. "1" എന്നതിന്റെ മൂല്യം അർത്ഥമാക്കുന്നത്, RAM-ന്റെ 1% കാഷെയ്‌ക്കായി ഉപയോഗിക്കുന്നു, കൂടാതെ RAM-ൽ നിന്നുള്ളതിനേക്കാൾ കൂടുതൽ റീഡുകൾ ഡിസ്‌കിൽ നിന്ന് ഉണ്ടാകും എന്നാണ്. ഈ ക്രമീകരണം മാറ്റേണ്ട ആവശ്യമില്ല, എന്നാൽ പേജ് കാഷെ നിയന്ത്രിക്കുന്നതിൽ നിങ്ങൾക്ക് പരിഭ്രാന്തി ഉണ്ടെങ്കിൽ, നിങ്ങൾക്കത് ഉപയോഗിക്കാം.

"ഡെഡ്‌ലൈൻ" > /sys/block/sdc/queue/scheduler

I/O ഷെഡ്യൂളർ ഒരു ലിനക്സ് കേർണൽ ഘടകമാണ്, അത് വായനയും എഴുത്തും ക്യൂകൾ കൈകാര്യം ചെയ്യുന്നു. സിദ്ധാന്തത്തിൽ, ഒരു സ്മാർട്ട് റെയിഡ് കൺട്രോളറിനായി "noop" ഉപയോഗിക്കുന്നതാണ് നല്ലത്, കാരണം ലിനക്സിന് ഡിസ്കിന്റെ ഭൗതിക ജ്യാമിതിയെക്കുറിച്ച് ഒന്നും അറിയില്ല, അതിനാൽ ഡിസ്ക് ജ്യാമിതിയെക്കുറിച്ച് നന്നായി അറിയാവുന്ന കൺട്രോളറെ അഭ്യർത്ഥന വേഗത്തിൽ പ്രോസസ്സ് ചെയ്യാൻ അനുവദിക്കുന്നത് കൂടുതൽ കാര്യക്ഷമമാണ്. സാധ്യമാണ്. എന്നാൽ "ഡെഡ്‌ലൈൻ" പ്രകടനം മെച്ചപ്പെടുത്തുന്നതായി തോന്നുന്നു. ലിനക്സ് കേർണൽ സോഴ്സ് കോഡ് ഡോക്യുമെന്റേഷനിൽ ഷെഡ്യൂളറുകളെക്കുറിച്ച് നിങ്ങൾക്ക് കൂടുതൽ വായിക്കാം: linux/Documentation/block/*osched.txt. കൂടാതെ മിക്സഡ് ഓപ്പറേഷനുകളിൽ (പല റൈറ്റ് ഓപ്പറേഷനുകളും) റീഡ് ത്രൂപുട്ടിൽ വർദ്ധനവ് ഞാൻ കണ്ടിട്ടുണ്ട്.

"256" > /sys/block/sdc/queue/nr_requests

ഷെഡ്യൂളർക്ക് കൈമാറുന്നതിന് മുമ്പ് ബഫറിലെ I/O അഭ്യർത്ഥനകളുടെ എണ്ണം. ചില കൺട്രോളറുകളുടെ ആന്തരിക ക്യൂ വലുപ്പം (ക്യൂ_ഡെപ്ത്) I/O ഷെഡ്യൂളറുടെ nr_requests-നേക്കാൾ വലുതാണ്, അതിനാൽ I/O ഷെഡ്യൂളറിന് അഭ്യർത്ഥനകൾ ശരിയായി മുൻ‌ഗണന നൽകാനും ലയിപ്പിക്കാനുമുള്ള സാധ്യത കുറവാണ്. ഡെഡ്‌ലൈനും CFQ ഷെഡ്യൂളർമാർക്കും, കൺട്രോളറിന്റെ ആന്തരിക ക്യൂവിന്റെ 2 മടങ്ങ് nr_requests ആയിരിക്കുമ്പോൾ ഇത് നല്ലതാണ്. അഭ്യർത്ഥനകൾ ലയിപ്പിക്കുന്നതും പുനഃക്രമീകരിക്കുന്നതും കനത്ത ലോഡിൽ കൂടുതൽ പ്രതികരിക്കാൻ ഷെഡ്യൂളറെ സഹായിക്കുന്നു.

echo "16" > /proc/sys/vm/page-cluster

പേജ്-ക്ലസ്റ്റർ പാരാമീറ്റർ ഒരു സമയം സ്വാപ്പിൽ എഴുതിയ പേജുകളുടെ എണ്ണം നിയന്ത്രിക്കുന്നു. മുകളിലെ ഉദാഹരണത്തിൽ, 16 KB ന്റെ RAID സ്ട്രൈപ്പ് വലുപ്പം അനുസരിച്ച് മൂല്യം "64" ആയി സജ്ജീകരിച്ചിരിക്കുന്നു. swappiness = 0 എന്നതിൽ അർത്ഥമില്ല, എന്നാൽ നിങ്ങൾ swappiness 10 അല്ലെങ്കിൽ 20 ആയി സജ്ജീകരിക്കുകയാണെങ്കിൽ, RAID സ്ട്രിപ്പ് വലുപ്പം 64K ആയിരിക്കുമ്പോൾ ഈ മൂല്യം ഉപയോഗിക്കുന്നത് നിങ്ങളെ സഹായിക്കും.

blockdev --setra 4096 /dev/<ദേവനാമം> (-sdb, hdc അല്ലെങ്കിൽ dev_mapper)

പല റെയിഡ് കൺട്രോളറുകൾക്കുമുള്ള ഡിഫോൾട്ട് ബ്ലോക്ക് ഡിവൈസ് ക്രമീകരണം പലപ്പോഴും മോശം പ്രകടനത്തിന് കാരണമാകുന്നു. മുകളിലുള്ള ഓപ്‌ഷൻ ചേർക്കുന്നത് 4096 * 512-ബൈറ്റ് സെക്ടറുകൾക്കായി റീഡ്-എഹെഡ് സജ്ജമാക്കുന്നു. കുറഞ്ഞത്, സ്ട്രീമിംഗ് പ്രവർത്തനങ്ങൾക്കായി, I/O തയ്യാറാക്കാൻ കേർണൽ ഉപയോഗിക്കുന്ന കാലയളവിൽ ഓൺ-ചിപ്പ് ഡിസ്ക് കാഷെ റീഡ്-എഹെഡ് ഉപയോഗിച്ച് പൂരിപ്പിക്കുന്നതിലൂടെ വേഗത വർദ്ധിപ്പിക്കുന്നു. അടുത്ത വായനയിൽ ആവശ്യപ്പെടുന്ന ഡാറ്റ കാഷെയിൽ അടങ്ങിയിരിക്കാം. വളരെയധികം പ്രീഫെച്ച്, ഉപയോഗപ്രദമായ ഡിസ്ക് സമയം ഉപയോഗിക്കുകയോ കാഷെയ്ക്ക് പുറത്ത് ഡാറ്റ ലോഡ് ചെയ്യുകയോ ചെയ്താൽ വലിയ ഫയലുകൾക്കായി ക്രമരഹിതമായ I/O നശിപ്പിക്കും.

ഫയൽ സിസ്റ്റം തലത്തിൽ കുറച്ചുകൂടി ശുപാർശകൾ ചുവടെയുണ്ട്. എന്നാൽ അവരെ ഇതുവരെ പരീക്ഷിച്ചിട്ടില്ല. നിങ്ങളുടെ ഫയൽസിസ്റ്റത്തിന് സ്ട്രൈപ്പിന്റെ വലുപ്പവും അറേയിലെ ഡിസ്കുകളുടെ എണ്ണവും അറിയാമെന്ന് ഉറപ്പാക്കുക. ഉദാഹരണത്തിന്, ഇത് ആറ് ഡിസ്കുകളുടെ 5K സ്ട്രൈപ്പ് റെയ്ഡ്64 അറേയാണ് (യഥാർത്ഥത്തിൽ അഞ്ച്, കാരണം പാരിറ്റിക്ക് ഒരു ഡിസ്ക് ഉപയോഗിക്കുന്നു). ഈ ശുപാർശകൾ സൈദ്ധാന്തിക അനുമാനങ്ങളെ അടിസ്ഥാനമാക്കിയുള്ളതും റെയ്‌ഡ് വിദഗ്ധരുടെ വിവിധ ബ്ലോഗുകൾ/ലേഖനങ്ങളിൽ നിന്ന് സമാഹരിച്ചതുമാണ്.

-> 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))

വലിയ ഫയലുകൾക്കായി, മുകളിൽ ലിസ്റ്റുചെയ്തിരിക്കുന്ന സ്ട്രൈപ്പ് വലുപ്പങ്ങൾ വർദ്ധിപ്പിക്കുന്നത് പരിഗണിക്കുക.

ശ്രദ്ധിക്കുക! മുകളിൽ വിവരിച്ചതെല്ലാം ചില തരത്തിലുള്ള ആപ്ലിക്കേഷനുകൾക്ക് വളരെ ആത്മനിഷ്ഠമാണ്. ബന്ധപ്പെട്ട ആപ്ലിക്കേഷനുകളുടെ മുൻകൂർ ഉപയോക്തൃ പരിശോധന കൂടാതെ ഈ ലേഖനം മെച്ചപ്പെടുത്തലുകൾക്ക് ഉറപ്പുനൽകുന്നില്ല. സിസ്റ്റത്തിന്റെ മൊത്തത്തിലുള്ള പ്രതികരണശേഷി മെച്ചപ്പെടുത്താൻ അത് ആവശ്യമാണെങ്കിൽ അല്ലെങ്കിൽ നിലവിലെ പ്രശ്നങ്ങൾ പരിഹരിക്കുകയാണെങ്കിൽ മാത്രമേ ഇത് ഉപയോഗിക്കാവൂ.

അധിക മെറ്റീരിയലുകൾ:

• dom.as/2008/02/05/linux-io-schedulers
• www.nextre.it/oracledocs/oraclemyths.html
• lkml.org/lkml/2006/11/15/40
• misterd77.blogspot.com/2007/11/3ware-hardware-raid-vs-linux-software.html

കൂടുതൽ വായിക്കുക

• Red Hat Enterprise Linux 8-ൽ nftables ഉപയോഗിക്കുന്നു

അവലംബം: www.habr.com