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 ഇപ്പോഴും പിടിച്ചിരിക്കുന്നു എന്നാണ്.

അടുത്ത വായന ഇതുമായി താരതമ്യം ചെയ്യുക

ഒരു ആഴ്ച കഴിഞ്ഞ് തിരിച്ചുവന്ന് വളർച്ചാ നിരക്ക് രേഖപ്പെടുത്തിയതുമായി താരതമ്യം ചെയ്യുക. യോജിക്കുന്ന നിരക്ക് പരിധി നിലനിൽക്കുന്നു, ഭാരം സ്ഥിരമാണ് എന്നർത്ഥം; ഇരട്ടിയായ നിരക്ക് എന്തോ മാറി എന്നർത്ഥം, ഉപയോഗപ്രദമായ ചോദ്യം എന്താണ് എന്നതാണ്. ആദ്യം ആവർത്തിച്ചുള്ള പരാജയങ്ങൾക്കായി ലോഗിന്റെ ഉള്ളടക്കം വായിക്കുക, കാരണം വീണ്ടും-ശ്രമിക്കൽ ലൂപ്പ് ഒരേസമയം ലക്ഷണവും അളവിന്റെ കാരണവുമാണ്. പിന്നീട് പുതുതായി സജീവമാക്കിയ എല്ലാം പരിശോധിക്കുക, സംഭവസമയത്ത് ഓണാക്കി ഒരിക്കലും ഓഫാക്കാത്ത ഡീബഗ് നിലകളും ഉൾപ്പെടെ.

ബാക്കപ്പുകൾ അതേ വോളിയത്തിന് പുറത്ത് സൂക്ഷിക്കുക, അല്ലെങ്കിൽ ഒരു നിറഞ്ഞ ഡിസ്ക് ബാക്കപ്പിനെയും കൊണ്ടുപോകും എന്ന് അംഗീകരിക്കുക. അത് സംരക്ഷിക്കുന്ന ഹോസ്റ്റിലേക്ക് തന്നെ എഴുതുന്ന പകർപ്പ് വീണ്ടെടുക്കൽ പദ്ധതിയല്ല, അതിന്റെ സൂക്ഷിപ്പിന് സ്വന്തം ഉത്തരം വേണം.

എന്താണ്, എവിടെ, എത്രകാലം സൂക്ഷിക്കുന്നത്, ആരാണ് അത് നീക്കംചെയ്യുന്നത് എന്ന് എഴുതിവയ്ക്കുക. ആ വാക്യമാണ് ഫലം, അടുത്ത പുനരാരംഭത്തെ അതിജീവിക്കുന്ന ഈ ജോലിയുടെ ഏക ഭാഗവും അതുതന്നെ.