OpenVPN ട്രാഫിക് കൗണ്ടറുകളും ഡിസ്ക് I/Oയും: മൂന്ന് വ്യത്യസ്ത സംഖ്യകൾ
ഇന്റർഫേസ് ബൈറ്റുകൾ, പ്രോസസ്സിന്റെ പ്രതീക കൗണ്ടറുകൾ, സ്റ്റോറേജ് എഴുത്തുകൾ എന്നിവ വ്യത്യസ്ത ജോലികൾ അളക്കുന്നു. ടണലിന്റെ അളവിൽ നിന്ന് ഡിസ്കുകൾ കണക്കാക്കുന്നതിന് മുമ്പ് അവ താരതമ്യം ചെയ്യുക.
ഒരു വലിയ ഫയൽ ടണലിലൂടെ കടത്തിവിട്ടാൽ ഇന്റർഫേസ് കൗണ്ടർ ഫയലിന്റെ വലിപ്പത്തോളം ഉയരും. ആ സംഖ്യയിൽ അതേ അളവ് ഡിസ്കിൽ എത്തി എന്ന് പറയുന്ന ഒന്നും ഇല്ല. ഈ ചർച്ചകളിൽ മൂന്ന് വ്യത്യസ്ത അളവുകൾ താരതമ്യം ചെയ്യുന്നു, അവ മൂന്ന് വ്യത്യസ്ത ചോദ്യങ്ങൾക്ക് ഉത്തരം നൽകുന്നു: എത്ര ട്രാഫിക് ഒരു നെറ്റ്വർക്ക് പാളി കടന്നു, ഒരു പ്രോസസ്സ് സിസ്റ്റം കോളുകളിലൂടെ എത്ര ബൈറ്റ് വായിച്ചു എഴുതി, എത്ര ജോലി സ്റ്റോറേജ് പാളിയിൽ എത്തി.
ആദ്യത്തേതിനെ മൂന്നാമത്തേതുമായി താരതമ്യം ചെയ്യുന്നതാണ് സാധാരണ തെറ്റ്, അത് ഒരു മിഥ്യാ ഡിസ്ക് പ്രശ്നമോ യഥാർത്ഥത്തിൽ സംഭവിക്കുന്ന എഴുത്തുകളെ അവഗണിക്കുന്ന ശേഷി പദ്ധതിയോ സൃഷ്ടിക്കുന്നു. മൂന്നും വേർതിരിക്കാവുന്നതാണ്, ഓരോന്നിനും ശരിയായ ഉപയോഗമുണ്ട്.
കൂട്ടിക്കലർത്തുന്ന മൂന്ന് സംഖ്യകൾ
ഇന്റർഫേസ് കൗണ്ടറുകൾ നെറ്റ്വർക്ക് പാളിയിൽ കൈകാര്യം ചെയ്യുന്ന ട്രാഫിക്കിനെ വിവരിക്കുന്നു. ബാൻഡ്വിഡ്ത്തിനും ടണലിന്റെ വലിപ്പത്തിനും ട്രാൻസിറ്റിന് വിലയിടുന്ന ബില്ലിംഗ് മാതൃകകൾക്കും ഇതാണ് ശരിയായ സംഖ്യ.
പ്രോസസ്സിന്റെ പ്രതീക കൗണ്ടറുകൾ പൈപ്പുകൾ, ടെർമിനലുകൾ, പ്രതീക ഉപകരണങ്ങൾ എന്നിവയുൾപ്പെടെ ഏത് ഡിസ്ക്രിപ്റ്ററിലും വായന-എഴുത്ത് കോളുകളിലൂടെ നീങ്ങിയ ബൈറ്റുകളെ വിവരിക്കുന്നു. സിസ്റ്റം കോളിന്റെ അതിർത്തിയിൽ പ്രോസസ്സ് എത്ര തിരക്കിലാണെന്ന് ചോദിക്കാൻ ഇതാണ് ശരിയായ സംഖ്യ, ഇത് ഒരു സ്റ്റോറേജ് ബില്ലല്ല.
സ്റ്റോറേജ് കൗണ്ടറുകൾ കെർണൽ ഒരു ബ്ലോക്ക് ഉപകരണത്തിലേക്കോ അതിൽനിന്നോ നീക്കാൻ ശ്രമിച്ച ബൈറ്റുകളെ വിവരിക്കുന്നു. ശേഷി ആസൂത്രണത്തിന് ഇതാണ് ശരിയായ സംഖ്യ, എന്നാൽ കെർണൽ സ്വന്തം കണക്കെടുപ്പ് പരിധികൾ രേഖപ്പെടുത്തുന്നു എന്ന വ്യവസ്ഥയോടെ: കാഷെ ചെയ്ത വായനകൾ സ്റ്റോറേജ് വായനകളാകുന്നില്ല, പിന്നീട് റദ്ദാക്കപ്പെടുന്ന എഴുത്ത് പൂർത്തിയായ ഉപകരണ എഴുത്താകുന്നില്ല.
| Measurement | Question it answers |
|---|---|
| Interface bytes | How much traffic crossed this layer |
rchar and wchar | How much data the process moved through system calls |
read_bytes and write_bytes | How much work reached the storage layer |
ഫയൽ ഡിസ്ക്രിപ്റ്റർ ഡിസ്ക് എഴുത്ത് അല്ലാത്തതെന്തുകൊണ്ട്
ഉപയോക്തൃ സ്ഥലത്തെ VPN TUN ഉപകരണത്തിലൂടെ കെർണലുമായി പാക്കറ്റുകൾ കൈമാറുന്നു, അത് സാധാരണ ഫയലല്ല, പ്രതീക ഉപകരണമാണ്. അതിൽനിന്ന് വായിക്കുന്നത് ഒരു പാക്കറ്റ് കൈമാറുന്നു; അതിലേക്ക് എഴുതുന്നത് ഒരു പാക്കറ്റ് കുത്തിവയ്ക്കുന്നു. സ്റ്റോറേജിനായി തയ്യാറാക്കുന്ന ഫയൽ ഉള്ളടക്കത്തിന്റെ പേജൊന്നുമില്ല, ഫയൽസിസ്റ്റം പാത്തും ഉൾപ്പെടുന്നില്ല.
അതുകൊണ്ടാണ് തിരക്കുള്ള ഒരു ടണലിന് സ്റ്റോറേജ് കൗണ്ടറുകൾ ഇല്ലാതെതന്നെ വൻ പ്രതീക കൗണ്ടറുകൾ കാണിക്കാൻ കഴിയുന്നത്. പ്രോസസ്സ് ആ ബൈറ്റുകൾ യഥാർത്ഥത്തിൽ നീക്കി, അത് ചെയ്യാൻ കെർണലിന് യഥാർത്ഥത്തിൽ ഡിസ്ക് ആവശ്യമായിരുന്നില്ല.
cat /proc/$(pgrep -n openvpn)/io
ip -s link show tun0ആദ്യ ഔട്ട്പുട്ട് പ്രോസസ്സ് ആരംഭിച്ചതുമുതലുള്ള സഞ്ചയമായി വായിക്കുക, നിരക്കായി അല്ല. രണ്ടാമത്തേത് അതേ ട്രാഫിക്കിന്റെ ഇന്റർഫേസ് കാഴ്ച നൽകുന്നു. രണ്ടിനുമിടയിലെ വലിയ വിടവ് പ്രതീക്ഷിതമാണ്, അത് ചോർച്ചയോ ക്യൂവോ തെറ്റായ ക്രമീകരണമോ സൂചിപ്പിക്കുന്നില്ല.
ബൈറ്റുകൾ യഥാർത്ഥത്തിൽ എവിടെനിന്ന് വരുന്നു
നിരന്തര ഔട്ട്പുട്ടിന് സ്വന്തം ബജറ്റുണ്ട്, അത് പേലോഡിനല്ല, പ്രവർത്തനങ്ങൾക്കാണ് വിധേയമാകുന്നത്. വിശദമായ ലോഗ് നില, പലപ്പോഴും മാറുന്ന ക്ലയന്റ് പട്ടിക, അല്ലെങ്കിൽ ഇടുങ്ങിയ ലൂപ്പിൽ ആവർത്തിക്കുന്ന പിശക് ടണൽ വളരെ കുറഞ്ഞത് കൊണ്ടുപോകുമ്പോഴും ഗണ്യമായ എഴുത്തുകൾ സൃഷ്ടിച്ചേക്കാം.
സ്റ്റാറ്റസ് ഫയൽ ഒരു ഇടവേളയിൽ വീണ്ടും എഴുതുന്ന സ്നാപ്ഷോട്ടാണ്, അതിനാൽ അതിന്റെ ചെലവ് ഇടവേളയെയും അതിൽ എത്ര റെക്കോർഡുകൾ ഉണ്ടെന്നതിനെയും ആശ്രയിച്ചിരിക്കുന്നു. അത് ഓരോ ക്ലയന്റിന്റെയും ട്രാഫിക്കിന്റെ ഓടുന്ന പകർപ്പല്ല, ഇടവേള ചെറുതാക്കുന്നത് ട്രാഫിക്കിന്റെ അളവ് മാറ്റാതെ എഴുത്തിന്റെ അളവ് മാറ്റുന്നു.
ആ എഴുത്തുകൾ തിരയുമ്പോൾ ഉടമസ്ഥത പ്രധാനമാണ്. സേവനം സന്ദേശങ്ങൾ ഒരു ലോഗിംഗ് ഡീമണിന് കൈമാറുന്നുവെങ്കിൽ, ജേണലോ ലോഗ് ഫയലോ ആ ഡീമൺ എഴുതുന്നു, ബൈറ്റുകൾ VPN പ്രോസസ്സിന്റെ സ്വന്തം കൗണ്ടറുകളിലല്ല, ഡീമണിന്റെ കണക്കിൽ പ്രത്യക്ഷപ്പെടുന്നു. VPN പ്രോസസ്സിനെ മാത്രം നോക്കുന്നത് ഡിസ്ക് പ്രവർത്തനമോ അതിന്റെ അഭാവമോ വിശദീകരിക്കുന്നില്ല.
മറ്റ് സംഭാവനക്കാരെ വിട്ടുപോകാൻ എളുപ്പമാണ്: തുടക്കത്തിൽ സർട്ടിഫിക്കറ്റും കോൺഫിഗറേഷനും വായിക്കൽ, സ്വന്തം റെക്കോർഡുകൾ എഴുതുന്ന ഹുക്കുകൾ, അക്കൗണ്ടിംഗ് പ്ലഗിനുകൾ, ക്രാഷ് ഡമ്പുകൾ, അതേ ഹോസ്റ്റിലെ അനുബന്ധമല്ലാത്ത വർക്ക്ലോഡുകൾ. ടണൽ ട്രാഫിക്കിനെ എഴുതിയ ബൈറ്റുകൾക്ക് തുല്യമാക്കി അവയിലൊന്നും കണക്കാക്കരുത്.
ഓരോ കൗണ്ടറും ശരിയായി വായിക്കൽ
മൂന്ന് വിശദാംശങ്ങൾ താരതമ്യത്തിന് അർത്ഥമുണ്ടോ എന്ന് തീരുമാനിക്കുന്നു. പ്രോസസ്സിന്റെ ഐഡന്റിറ്റി പ്രധാനമാണ്, കാരണം പുനരാരംഭിച്ച സേവനം അതിന്റെ കൗണ്ടറുകൾ പുനഃസജ്ജമാക്കുന്നു. സമയ ഇടവേള പ്രധാനമാണ്, കാരണം സഞ്ചിത സംഖ്യയും സെക്കൻഡിലെ ഗ്രാഫും വ്യത്യസ്ത അളവുകളാണ്. യൂണിറ്റും പ്രധാനമാണ്, കാരണം ലോഗ് ഫയലിന്റെ നിലവിലെ വലിപ്പവും നിരക്കല്ല.
grep -E 'rchar|wchar|read_bytes|write_bytes' /proc/$(pgrep -n openvpn)/io
du -sh /var/log/openvpn 2>/dev/null
journalctl --disk-usageയഥാർത്ഥ പേലോഡ് എഴുത്തുകൾ സംശയിക്കുന്നുവെങ്കിൽ, പേലോഡ് സംഭരിക്കുക എന്നത് ജോലിയായ ഒരു ഘടകം തിരയുക: പാക്കറ്റ് പിടിച്ചെടുക്കുന്ന ഉപകരണം, ഉള്ളടക്കം കാഷെ ചെയ്യുന്ന പ്രോക്സി, ആർക്കൈവ് ചെയ്യുന്ന പ്ലഗിൻ. ഇവ രേഖപ്പെടുത്താൻ ആവശ്യപ്പെടുന്നതിനനുസരിച്ച് വളരുന്ന സ്റ്റോറേജ് ട്രാഫിക് സൃഷ്ടിക്കുന്നു, അവ സൂക്ഷിപ്പും പ്രവേശനവും സംബന്ധിച്ച പ്രത്യേക നയ തീരുമാനത്തിൽ പെടുന്നു.
ശരിയായ സംഖ്യ ഉപയോഗിച്ച് ശേഷി ആസൂത്രണം
പാക്കറ്റ് പാത നെറ്റ്വർക്ക് സംഖ്യകളാൽ അളക്കുക: ത്രൂപുട്ട്, ക്രിപ്റ്റോഗ്രാഫിക് പ്രോസസ്സിംഗ്, മെമ്മറി ചലനം. സ്റ്റോറേജ് നിങ്ങൾ യഥാർത്ഥത്തിൽ എടുത്ത നിരീക്ഷണ തീരുമാനങ്ങളാൽ അളക്കുക: ലോഗ് നില, സൂക്ഷിപ്പ്, സ്റ്റാറ്റസ് ഇടവേള, ബോധപൂർവം സജീവമാക്കിയ ഏതെങ്കിലും പിടിച്ചെടുക്കൽ.
ഈ രണ്ട് ബജറ്റുകൾ വേർതിരിച്ചു നിർത്തുന്നത് സംഭവങ്ങൾ വായിക്കാൻ എളുപ്പമാക്കുന്നു. മിതമായ ടണൽ ട്രാഫിക്കിനൊപ്പം ഡിസ്ക് നിറയുന്നത് ലോഗുകളെയോ പിടിച്ചെടുക്കലുകളെയോ അനുബന്ധമല്ലാത്ത എന്തിനെയോ സൂചിപ്പിക്കുന്നു, ഇന്റർഫേസ് കൗണ്ടർ അത് ഒരിക്കലും വിശദീകരിക്കില്ല. ശാന്തമായ ലോഗിനൊപ്പം ലിങ്ക് പൂരിതമാകുന്നത് എതിർദിശയെ സൂചിപ്പിക്കുന്നു.
ചെയ്യാൻ യോഗ്യമായ താരതമ്യം ഒരേ തരത്തിലുള്ള അളവുകൾക്കിടയിലാണ്. കാലക്രമേണ ഇന്റർഫേസ് ബൈറ്റുകൾ ഇന്റർഫേസ് ബൈറ്റുകൾക്കെതിരെ പാതയെക്കുറിച്ച് പറയുന്നു. സ്റ്റോറേജ് എഴുത്തുകൾ സ്റ്റോറേജ് ശേഷിക്കെതിരെ സൂക്ഷിപ്പിനെക്കുറിച്ച് പറയുന്നു. കുറുകെയുള്ള താരതമ്യം, ട്രാഫിക് ഡിസ്കിനെതിരെ, അർത്ഥവത്തായി തോന്നുന്നു മാത്രം, ഒരിക്കലും അങ്ങനെയല്ല.