HestiaCP માં હું inode નો ઉપયોગ કેવી રીતે તપાસી શકું? ડિસ્ક પર પુષ્કળ જગ્યા હોવા છતાં ફાઇલો લખવામાં અસમર્થતાનું કારણ શું છે?

થોડા દિવસ પહેલા, એક મિત્રએ મને મોડી રાત્રે મેસેજ કર્યો કે તેનું સર્વર ક્રેશ થઈ ગયું છે.

ચોક્કસ લક્ષણો ખાસ કરીને વિચિત્ર હતા: વેબસાઇટ અચાનક ભૂલો આપવા લાગી, લોગ લખી શકાતા નહોતા, અને નવી ફાઇલો બનાવવાથી તરત જ ખબર પડી જતી હતી કે ડિસ્ક ભરાઈ ગઈ છે.

પરંતુ જ્યારે તેણે `df -h` સાથે તપાસ કરી, ત્યારે તેને એ જાણીને આઘાત લાગ્યો કે ડિસ્કમાં સ્પષ્ટપણે દસ ગીગાબાઇટ્સ ખાલી જગ્યા હતી. તે કેવી રીતે ભરાઈ શકે?

મેં તેને તરત જ કહ્યું, "ભાઈ, તમે ફક્ત સ્ટોરેજ સ્પેસથી ભરેલા નથી, તમારા ઇનોડ ઓવરલોડ છે."

તેમણે પ્રશ્નાર્થ ચિહ્ન સાથે જવાબ આપ્યો: ઇનોડ ખરેખર શું છે?

હકીકતમાં, ઘણા લોકો જ્યારે પહેલી વાર આ જાળમાં ફસાયા ત્યારે તેમણે જે રીતે પ્રતિક્રિયા આપી હતી તે જ રીતે પ્રતિક્રિયા આપે છે, કારણ કે શાળામાં કોઈએ તેમને ક્યારેય આ વાત શીખવી ન હતી.

ચાલો પહેલા સ્પષ્ટ કરીએ કે Inode શું છે.

તેને લાઇબ્રેરી ઇન્ડેક્સ કાર્ડ તરીકે વિચારો, અને તે સમજવામાં સરળ રહેશે.

ડિસ્ક સ્પેસ એક બુકશેલ્ફ જેવી છે; તમે તેના પર કેટલી પુસ્તકો મૂકી શકો છો તે તેની ક્ષમતા પર આધાર રાખે છે, જે દરેક માટે સમજવામાં સરળ છે.

આઈનોડ એ દરેક પુસ્તક માટે એક ઇન્ડેક્સ કાર્ડ જેવું છે, જેમાં તેનું નામ, સ્થાન અને તેને કોણે ખસેડ્યું તે નોંધવામાં આવે છે.

Linux માં , દરેક ફાઇલ અને દરેક ડિરેક્ટરીએ એક ઇનોડ રાખવો જ જોઇએ, પછી ભલે તે ફાઇલ ગમે તેટલી નાની હોય.

ભલે તે ખાલી ફાઇલ હોય, પણ સિસ્ટમ તેના માટે ઇન્ડેક્સ કાર્ડનો ઉપયોગ કરશે.

સિસ્ટમમાં કુલ કેટલી ફાઇલો બનાવી શકાય તેની મર્યાદા છે; આ મર્યાદા ઇનનોડ્સની કુલ સંખ્યા છે.

એકવાર આઇનોડનો ઉપયોગ થઈ જાય, પછી ભલે તમારી ડિસ્કમાં સેંકડો ગીગાબાઇટ્સ ખાલી જગ્યા હોય, ઓપરેટિંગ સિસ્ટમ કોઈપણ નવી ફાઇલો બનાવવાનો ઇનકાર કરશે.

લોગ લખી શકાતા નથી, કેશ બનાવી શકાતા નથી, અને વેબસાઇટ સંપૂર્ણપણે ક્રેશ થઈ જાય છે - આ એક વિચિત્ર દૃશ્ય છે જે તમે જોઈ રહ્યા છો.

સાચું કહું તો, આ ખૂબ જ મુશ્કેલ પરિસ્થિતિ છે કારણ કે ભૂલ સંદેશ એવા સ્થાનથી મોકલવામાં આવે છે જ્યાં તમે જોઈ રહ્યા નથી.

પહેલી યુક્તિ એ છે કે સંપૂર્ણ ઝાંખી મેળવવા માટે `df -i` નો ઉપયોગ કરવો.

HestiaCP વાતાવરણમાં , તમે ફક્ત ટર્મિનલમાં SSH કરી શકો છો અને આ લાઈન લખી શકો છો.

df -i

તે દરેક માઉન્ટ થયેલ પાર્ટીશન માટે કુલ ઇનનોડ્સ, વપરાયેલ સંખ્યા અને બાકી રહેલી સંખ્યાની યાદી આપશે.

આઉટપુટમાં, IUse% નામનો એક કોલમ છે, જે એક મુખ્ય મેટ્રિક છે જેના પર તમારે નજર રાખવી જોઈએ.

જો પાર્ટીશનનો IUse% 100% સુધી પહોંચે છે, તો ભલે તે પાર્ટીશનમાં હજુ પણ પુષ્કળ ડિસ્ક જગ્યા હોય, તે હવે કોઈપણ નવી ફાઇલો અથવા લોગ બનાવી શકશે નહીં.

મેં મારા મિત્રને સૂચન કર્યું કે તે પહેલા આ ચલાવે, જેથી તે એક સેકન્ડમાં નક્કી કરી શકે કે સમસ્યા આઈનોડમાં છે કે નહીં , જે અનુમાન લગાવવા કરતાં ઘણી ઝડપી હશે.

બીજી પદ્ધતિ એ છે કે ચોક્કસ વપરાશકર્તાની ચોક્કસ ગણતરી કરવા માટે `find` નો ઉપયોગ કરવો.

સમસ્યા ઇનોડમાં છે તેની પુષ્ટિ કર્યા પછી, આગળનું પગલું એ શોધવાનું છે કે કોણ ઇન્ડેક્સ કાર્ડનો વધુ પડતો ઉપયોગ કરી રહ્યું છે.

HestiaCP પાસે દરેક વપરાશકર્તા માટે એક અલગ હોમ ડિરેક્ટરી છે. તમે ચોક્કસ વેબસાઇટ ડિરેક્ટરી હેઠળ ફાઇલો અને ડિરેક્ટરીઓની કુલ સંખ્યા ગણતરી કરી શકો છો.

find /home/用户名/web/你的域名/public_html | wc -l

"username" અને "your domain name" ને તમારા વાસ્તવિક પાથથી બદલો. ટર્મિનલ દ્વારા પરત કરવામાં આવતો શુદ્ધ નંબર એ ડિરેક્ટરીમાંની બધી ફાઇલો અને ફોલ્ડર્સનો સરવાળો છે.

દરેક ફાઇલ અથવા ડિરેક્ટરી એક આઇનોડને અનુરૂપ છે, તેથી આ સંખ્યા આઇનોડના ઉપયોગને દર્શાવે છે.

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

for d in /home/*; do echo -n "$d: "; find "$d" 2>/dev/null | wc -l; done

આ લાઇન /home હેઠળ દરેક વપરાશકર્તા ડિરેક્ટરીમાં ફાઇલોની કુલ સંખ્યા છાપશે, જેનાથી તે શોધવાનું સરળ બનશે કે કઈ વપરાશકર્તા ડિરેક્ટરીમાં ફાઇલોની સંખ્યા અસામાન્ય રીતે વધુ છે.

ત્રીજી વ્યૂહરચના એ છે કે સૌથી વધુ આયોડિનનો વપરાશ કરતી સબડિરેક્ટરીઝને ઓળખવી.

ક્યારેક તમને ખબર પડે છે કે કોઈ વેબસાઇટમાં હાસ્યાસ્પદ રીતે ઊંચા Inode મૂલ્યો છે, પરંતુ તમે હજુ પણ સમજી શકતા નથી કે ફાઇલોથી ભરેલી સ્ક્રીનમાં શું ખોટું છે.

આવા કિસ્સાઓમાં, તમારે એવા સબફોલ્ડર્સ શોધવા માટે એક સ્તર નીચે ડ્રિલ કરવાની જરૂર છે જેમાં મોટી સંખ્યામાં નાની ફાઇલો હોય, જેમ કે કેશ ડિરેક્ટરીઓ, સત્ર ડિરેક્ટરીઓ અને લોગ ડિરેક્ટરીઓ - આ સૌથી સમસ્યારૂપ ક્ષેત્રો છે.

find /home/用户名/web/你的域名/public_html -type d -exec sh -c 'echo -n "{}: "; find "{}" -maxdepth 1 | wc -l' \; | sort -n -r -k 2 | head -n 10

આ આદેશ ટોચના 10 સબફોલ્ડર્સની યાદી આપશે જે સૌથી વધુ ફાઇલોનો ઉપયોગ કરે છે.

યાદીની ટોચ પરનો રસ્તો એ છે જ્યાં મોટી સંખ્યામાં નાની ફાઇલો એકસાથે ક્લસ્ટર થયેલ છે.

મેં મારા મિત્રને કહ્યું કે કદાચ કોઈ કેશીંગ પ્લગઇન ગુપ્ત રીતે નાની ફાઇલો જનરેટ કરી રહ્યું હતું, અને આ લાઇન ચલાવવાથી મૂળભૂત રીતે તેની પુષ્ટિ થશે.

ચોથી ટિપ એ છે કે repquota નો ઉપયોગ કરીને ક્વોટા મર્યાદા તપાસો.

જો તમારા સર્વરમાં Linux ફાઇલ સિસ્ટમ ક્વોટા સક્ષમ હોય, તો તમે સમસ્યાને અલગ દ્રષ્ટિકોણથી જોઈ શકો છો.

repquota -a

આ આદેશ બધા વપરાશકર્તાઓ માટે ફાઇલ મર્યાદા અને વાસ્તવિક ફાઇલ વપરાશ વધારશે.

આઉટપુટમાં ફાઇલ મર્યાદા વિભાગ પર ધ્યાન આપો; વપરાયેલ કોલમ દર્શાવે છે કે કેટલી ફાઇલોનો ઉપયોગ થયો છે.

"સોફ્ટ" અને "હાર્ડ" કૉલમ સોફ્ટ અને હાર્ડ મર્યાદા થ્રેશોલ્ડનું પ્રતિનિધિત્વ કરે છે. એકવાર "વપરાયેલ" "હાર્ડ" સુધી પહોંચી જાય, પછી સિસ્ટમ સીધી નવી ફાઇલો બનાવવાનો ઇનકાર કરશે.

તમારી ડિસ્ક પર કેટલી જગ્યા બાકી છે તેનાથી આ સંપૂર્ણપણે અલગ વાર્તા છે.

વાતને પૂર્ણ કરવા માટે, ચાલો તપાસના બિંદુઓને જોડીએ.

ચાલો એ મિત્ર વિશે પાછા જઈએ જેણે શરૂઆતમાં મધ્યરાત્રિએ સર્વર ક્રેશ કર્યું હતું.

તેણે મેં વર્ણવેલ ચાર પગલાંઓનું પાલન કર્યું, `df -i` થી શરૂ કરીને ખાતરી કરી કે ઇનોડ ખરેખર ભરાઈ ગયો છે.

પછી, find નો ઉપયોગ કરીને, અમે એક ત્યજી દેવાયેલી જૂની વેબસાઇટની કેશ ડિરેક્ટરી શોધી કાઢી જે ક્રેઝીની જેમ નાની ફાઇલો જનરેટ કરી રહી હતી.

અંતે, `repquota` તપાસવાથી પુષ્ટિ થઈ કે તે ખરેખર સખત મર્યાદા સુધી પહોંચી ગયું છે.

જંક કેશના ઢગલા સાફ કર્યા પછી, વેબસાઇટ તરત જ પાછી જીવંત થઈ ગઈ.

તો આગલી વખતે જ્યારે તમને આ વિચિત્ર પરિસ્થિતિનો સામનો કરવો પડે જ્યાં "ડિસ્કમાં સ્પષ્ટ રીતે જગ્યા છે પણ તમે ફાઇલો લખી શકતા નથી," ત્યારે હાર્ડ ડ્રાઇવ ઉમેરવા માટે ઉતાવળ કરશો નહીં.

સૌ પ્રથમ, આઇનોડ જોવા માટે `df -i` નો ઉપયોગ કરો; સત્ય તે ઇન્ડેક્સ કાર્ડ પર છુપાયેલું હોઈ શકે છે જે તમે પહેલાં ક્યારેય જોયું નથી.

હું ખરેખર માનું છું કે સિસ્ટમના મૂળમાં છુપાયેલા આ નાના-નાના સામાન્ય જ્ઞાન સો ઑપ્ટિમાઇઝેશન યાદીઓ યાદ રાખવા કરતાં વધુ ઉપયોગી છે.