GlusterFS માટે Linux કર્નલ સુયોજિત કરી રહ્યા છીએ

લેખનો અનુવાદ કોર્સની શરૂઆતની પૂર્વસંધ્યાએ તૈયાર કરવામાં આવ્યો હતો "એડમિનિસ્ટ્રેટર Linux. વ્યવસાયિક".

સમય સમય પર, કર્નલ કસ્ટમાઇઝેશન સંબંધિત ગ્લુસ્ટરની ભલામણો અને તે જરૂરી છે કે કેમ તે વિશે અહીં અને ત્યાં પ્રશ્નો ઉભા થાય છે.

આ જરૂરિયાત ભાગ્યે જ ઊભી થાય છે. મોટાભાગના વર્કલોડ હેઠળ કોર ખૂબ જ સારી રીતે કાર્ય કરે છે. જોકે ત્યાં એક નુકસાન છે. ઐતિહાસિક રીતે, જો તક આપવામાં આવે તો Linux કર્નલ સહેલાઈથી ઘણી બધી મેમરી વાપરે છે, જેમાં પ્રદર્શનને સુધારવાના પ્રાથમિક માધ્યમ તરીકે કેશીંગનો સમાવેશ થાય છે.

મોટા ભાગના કિસ્સાઓમાં આ મહાન કામ કરે છે, પરંતુ ભારે ભાર હેઠળ તે સમસ્યાઓનું કારણ બની શકે છે.

અમારી પાસે એવી સિસ્ટમ્સ સાથે કામ કરવાનો બહોળો અનુભવ છે જે ઘણી બધી મેમરીનો ઉપયોગ કરે છે, જેમ કે CAD, EDA અને તેના જેવી, જે ઊંચા ભાર હેઠળ ધીમી થવા લાગી છે. અને કેટલીકવાર અમને ગ્લુસ્ટરમાં સમસ્યાઓનો સામનો કરવો પડ્યો. એક દિવસથી વધુ સમય માટે વપરાયેલી મેમરી અને ડિસ્ક રાહ જોવાના સમયનું કાળજીપૂર્વક નિરીક્ષણ કર્યા પછી, અમને ડિસ્ક ઓવરલોડ, વિશાળ આયોવેટ, કર્નલ ભૂલો (કર્નલ અરે), ફ્રીઝ વગેરે મળી.

આ લેખ વિવિધ પરિસ્થિતિઓમાં કરવામાં આવેલા ઘણા પેરામીટર ટ્યુનિંગ પ્રયોગોનું પરિણામ છે. આ પરિમાણો માટે આભાર, સામાન્ય રીતે માત્ર પ્રતિભાવમાં સુધારો થયો નથી, પણ ક્લસ્ટરની કામગીરી પણ નોંધપાત્ર રીતે સ્થિર થઈ હતી.

જ્યારે મેમરીને રૂપરેખાંકિત કરવાની વાત આવે છે, ત્યારે જોવાનું પ્રથમ સ્થાન વર્ચ્યુઅલ મેમરી સબસિસ્ટમ (VM) છે, જેમાં મોટી સંખ્યામાં વિકલ્પો છે જે તમને મૂંઝવણમાં મૂકી શકે છે.

vm.swappiness

પેરામીટર vm.swappiness RAM ની સરખામણીમાં કર્નલ સ્વેપનો કેટલો ઉપયોગ કરે છે તે નક્કી કરે છે. તેને સ્રોત કોડમાં "મેપ કરેલી મેમરી ચોરી કરવાની વૃત્તિ" તરીકે પણ વ્યાખ્યાયિત કરવામાં આવી છે. ઉચ્ચ અદલાબદલી મૂલ્યનો અર્થ એ છે કે કર્નલ મેપ કરેલ પૃષ્ઠોને સ્વેપ કરવા માટે વધુ સંવેદનશીલ હશે. ઓછી અદલાબદલી કિંમતનો અર્થ વિપરીત છે: કર્નલ ઓછી મેમરીમાંથી પૃષ્ઠોને સ્વેપ કરશે. બીજા શબ્દોમાં કહીએ તો, મૂલ્ય જેટલું ઊંચું છે vm.swappiness, વધુ સિસ્ટમ સ્વેપનો ઉપયોગ કરશે.

અદલાબદલીનો વ્યાપક ઉપયોગ અનિચ્છનીય છે, કારણ કે ડેટાના વિશાળ બ્લોક્સ RAM માં લોડ અને અનલોડ થાય છે. ઘણા લોકો એવી દલીલ કરે છે કે સ્વેપીનેસ મૂલ્ય ઊંચું હોવું જોઈએ, પરંતુ મારા અનુભવમાં, તેને "0" પર સેટ કરવાથી સારું પ્રદર્શન થાય છે.

તમે અહીં વધુ વાંચી શકો છો - lwn.net/Articles/100978

પરંતુ ફરીથી, આ સેટિંગ્સનો ઉપયોગ સાવધાની સાથે અને વિશિષ્ટ એપ્લિકેશનનું પરીક્ષણ કર્યા પછી જ થવો જોઈએ. અત્યંત લોડ થયેલ સ્ટ્રીમિંગ એપ્લિકેશનો માટે, આ પરિમાણ "0" પર સેટ હોવું જોઈએ. જ્યારે "0" માં બદલાય છે, ત્યારે સિસ્ટમની પ્રતિભાવમાં સુધારો થાય છે.

vm.vfs_cache_pressure

આ સેટિંગ ડિરેક્ટરી ઑબ્જેક્ટ્સ અને ઇનોડ્સ (ડેન્ટ્રી અને ઇનોડ) ને કૅશ કરવા માટે કર્નલ દ્વારા વપરાશમાં લેવાયેલી મેમરીને નિયંત્રિત કરે છે.

100 ની ડિફૉલ્ટ મૂલ્ય સાથે, કર્નલ પેજકેશ અને સ્વેપકેશ માટે યોગ્ય રીતે ડેન્ટ્રી અને ઇનોડ કેશ મુક્ત કરવાનો પ્રયાસ કરશે. vfs_cache_pressure ઘટવાથી કર્નલ ડેન્ટ્રી અને inode caches સાચવવા માટેનું કારણ બને છે. જ્યારે મૂલ્ય "0" હોય, ત્યારે કર્નલ મેમરી દબાણને કારણે ડેન્ટ્રી અને ઇનોડ કેશને ક્યારેય ફ્લશ કરશે નહીં, અને આ સરળતાથી મેમરીની બહારની ભૂલ તરફ દોરી શકે છે. 100 ઉપર vfs_cache_pressure વધારવાથી કર્નલ ડેન્ટ્રી અને inode પેજઆઉટને પ્રાથમિકતા આપે છે.

GlusterFS નો ઉપયોગ કરતી વખતે, મોટી માત્રામાં ડેટા અને ઘણી નાની ફાઇલો ધરાવતા ઘણા વપરાશકર્તાઓ ઇનોડ/ડેન્ટ્રી કેશીંગને કારણે સર્વર પર નોંધપાત્ર પ્રમાણમાં 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

પૃષ્ઠ કેશ એ એક કેશ છે જે ફાઇલો અને એક્ઝિક્યુટેબલ પ્રોગ્રામ્સમાંથી ડેટા સ્ટોર કરે છે, એટલે કે, આ ફાઇલો અથવા બ્લોક ઉપકરણોની વાસ્તવિક સામગ્રી સાથેના પૃષ્ઠો છે. આ કેશનો ઉપયોગ ડિસ્ક રીડની સંખ્યા ઘટાડવા માટે થાય છે. "1" ની કિંમતનો અર્થ છે કે કેશ 1% RAM નો ઉપયોગ કરે છે અને RAM કરતાં ડિસ્કમાંથી વધુ વાંચન થશે. આ સેટિંગ બદલવી જરૂરી નથી, પરંતુ જો તમે પેજ કેશને નિયંત્રિત કરવા વિશે પેરાનોઈડ છો, તો તમે તેનો ઉપયોગ કરી શકો છો.

"ડેડલાઇન" > /sys/block/sdc/queue/scheduler

I/O શેડ્યૂલર એ Linux કર્નલનો એક ઘટક છે જે વાંચવા અને લખવાની કતારોનું સંચાલન કરે છે. સિદ્ધાંતમાં, સ્માર્ટ RAID નિયંત્રક માટે "noop" નો ઉપયોગ કરવો વધુ સારું છે, કારણ કે Linux ડિસ્કની ભૌતિક ભૂમિતિ વિશે કશું જ જાણતું નથી, તેથી તે નિયંત્રક, જે ડિસ્ક ભૂમિતિ સારી રીતે જાણે છે, વિનંતીને પ્રક્રિયા કરવા દેવા વધુ કાર્યક્ષમ છે. શક્ય તેટલી ઝડપથી. પરંતુ એવું લાગે છે કે "ડેડલાઈન" પ્રદર્શન સુધારે છે. શેડ્યુલર્સ વિશે વધુ માહિતી 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

પૃષ્ઠ-ક્લસ્ટર પરિમાણ એક સમયે સ્વેપ પર લખેલા પૃષ્ઠોની સંખ્યાને નિયંત્રિત કરે છે. ઉપરના ઉદાહરણમાં, 16 KB ના RAID સ્ટ્રાઇપ કદ સાથે મેળ કરવા માટે મૂલ્ય "64" પર સેટ કરેલ છે. જ્યારે swappiness = 0 હોય ત્યારે આનો કોઈ અર્થ નથી, પરંતુ જો તમે સ્વેપ્પીનેસ 10 અથવા 20 પર સેટ કરો છો, તો જ્યારે RAID સ્ટ્રાઇપનું કદ 64 KB હોય ત્યારે આ મૂલ્યનો ઉપયોગ તમને મદદ કરશે.

બ્લોકદેવ --સેટ્રા 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))

મોટી ફાઇલો માટે, તમે ઉપરોક્ત પટ્ટાઓના કદમાં વધારો કરવાનું વિચારી શકો છો.

ધ્યાન! ઉપર વર્ણવેલ દરેક વસ્તુ અમુક પ્રકારની એપ્લિકેશનો માટે અત્યંત વ્યક્તિલક્ષી છે. આ લેખ વપરાશકર્તા દ્વારા સંબંધિત એપ્લિકેશનોનું પ્રથમ પરીક્ષણ કર્યા વિના કોઈપણ સુધારાની ખાતરી આપતો નથી. તેનો ઉપયોગ ફક્ત ત્યારે જ થવો જોઈએ જો ત્યાં એકંદર સિસ્ટમ પ્રતિભાવને સુધારવાની જરૂર હોય અથવા જો તે વર્તમાન સમસ્યાઓ હલ કરે.

વધારાની સામગ્રી:

• 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