VPN સર્વરની ડિસ્ક વૃદ્ધિ ક્યાંથી આવે છે અને તેને કેવી રીતે મર્યાદિત કરવી

ટનલ સંપર્ક સ્વીકારવાનું બંધ કરે છે, સેવા બે વાર ફરી શરૂ થાય છે, અને પછી તેના લોગમાં કંઈ દેખાતું નથી. એ મૌન જ સંકેત છે, કારણ કે ડિસ્ક ભરનારો લોગ જ છે અને તમે જે ભૂલની રાહ જુઓ છો તે લખવા માટે ડેમન પાસે જગ્યા નથી. કોઈપણ લાંબા સમય ચાલતી સેવા એ સ્થિતિમાં પહોંચી શકે છે, અને logs નામની ડિરેક્ટરી કાઢી નાખવાથી તે ભાગ્યે જ સુધરે છે. ટકાઉ ઉકેલ એ છે કે જાણવું કયું ભંડાર વધ્યું, તેની જાળવણી નીતિ કોની છે, અને લેખકે ખરેખર જગ્યા છોડી છે કે નહીં.

જે ભંડાર વધ્યું અને જે દરે વધ્યું તે શોધો

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

df -h /var
df -i /var

પછી વૃદ્ધિને માલિકને આભારી ગણો. journalની પોતાની વપરાશ સંખ્યા ફક્ત journalને જ આવરે છે, અને તે કદી એ ડેમનને જોશે નહીં જે તેના કન્ફિગરેશન ફાઇલના પાથ પર લખે છે.

journalctl --disk-usage

સમય સાથેની વૃદ્ધિ કોઈપણ એકલ રીડિંગ કરતાં વધુ કહે છે. ચાલુ રહી ગયેલ ડિબગ સ્તર, દરેક પ્રયાસ લોગ કરતું પુનઃપ્રયાસ લૂપ, અથવા કોઈએ ન રોકેલી કેપ્ચર ફાઇલ: દરેક એક ક્ષણે સામાન્ય અને એક કલાક પછી ચિંતાજનક લાગી શકે છે. એક રીડિંગ લો, વ્યસ્ત સમય પસાર થવા દો, બીજું લો, અને અંતરાલથી ભાગો. જે દર તમે કહી શકો તે ક્ષમતાને આગને બદલે નિર્ણયમાં ફેરવે છે.

રોટેશન ખુલ્લી ફાઇલ સાથે શું કરે છે

લોગ ફાઇલ એ inode તરફ ઈશારો કરતું નામ છે, અને જગ્યા ફક્ત ત્યારે પાછી આવે છે જ્યારે છેલ્લું ખુલ્લું હેન્ડલ બંધ થાય. ફાઇલનું નામ બદલો તો લેખક એ જ inode ભરતો રહે છે; તેને કાઢી નાખો તો લેખક નામ વિનાનું inode ભરતો રહે છે. એ સ્થિતિને કારણે જ 'મેં ફાઇલ કાઢી નાખી અને ડિસ્ક ભરેલી જ રહી' એ વાક્ય ફાઇલ ડિસ્ક્રિપ્ટરનું વર્ણન કરે છે, તૂટેલી ફાઇલસિસ્ટમનું નહીં. લેખકને ફરી શરૂ કરવો, અથવા ફાઇલને ફરી ખોલતી રોટેશન રીત પસંદ કરવી, એ જ બ્લોક ખરેખર પાછા આપે છે.

lsof +L1 | head

નીતિ એ ઘટકની છે જે ફાઇલ લખે છે. journal તેના કન્ફિગરેશન ફાઇલમાંથી પોતાની સંગ્રહ મર્યાદા લાગુ કરે છે, જ્યારે ફાઇલ-આધારિત સેવા સામાન્ય રીતે logrotate પર આધાર રાખે છે, ક્યાં તો બનાવવાના નિયમ સાથે ફરી ખોલવાનો સંકેત, કે પછી લેખક ફરી ખોલી ન શકે ત્યારે સ્થળ પર જ કાપવાની રીત. પહેલાં કંઈ બદલ્યા વિના નિર્ણયની પુષ્ટિ કરો:

logrotate -d /etc/logrotate.conf

મર્યાદા ક્યાં હોવી જોઈએ અને કેટલી મોટી હોવી જોઈએ

મર્યાદા ત્યાં મૂકો જ્યાં લેખક ગોઠવાયેલ છે, માઉન્ટ પોઇન્ટ પર નહીં. આખા વોલ્યુમ પરનો કોટા હોસ્ટને રક્ષે છે પણ કઈ સેવા પહેલાં નિષ્ફળ જશે તે કહેતો નથી, અને વૈશ્વિક સફાઈ સ્ક્રિપ્ટ આગલી ઘટનાને જરૂરી પુરાવા કાઢી નાખવાનું વલણ ધરાવે છે. journal મર્યાદા, મહત્તમ કદ સાથેની રોટેશન સંખ્યા, અને એપ્લિકેશન સ્તરની જાળવણી, દરેક એક ઉત્પાદકને બાંધે છે. સાથે મળીને તેઓ કુલને બાંધે છે; એકલા દરેક એક અનુમાન છે.

એ મર્યાદા તમે વાજબી ઠેરવી શકો તે જાળવણી અવધિથી નક્કી કરો, ઉપલબ્ધ મુક્ત જગ્યાથી નહીં. જો સમીક્ષાને એક અઠવાડિયાના સંપર્ક પ્રયાસોની જરૂર હોય, તો journalને સૌથી વ્યસ્ત અપેક્ષિત દરે એક અઠવાડિયું રાખવું પડશે, અને એ દર પહેલાં માપેલી સંખ્યા છે.

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

રીસ્ટાર્ટ પછી મર્યાદા ચકાસો

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

systemctl restart systemd-journald
journalctl --disk-usage

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

આગલી રીડિંગની આ સાથે સરખામણી કરો

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

બેકઅપ એ જ વોલ્યુમની બહાર રાખો, અથવા સ્વીકારો કે એક ભરેલી ડિસ્ક બેકઅપને પણ લઈ જશે. જે હોસ્ટનું તે રક્ષણ કરે છે તેના પર લખાયેલી નકલ પુનઃપ્રાપ્તિ યોજના નથી, અને તેની જાળવણીને પોતાનો જવાબ જોઈએ.

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