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જો તમને ખરેખર પેલોડ લેખનની શંકા હોય, તો એવો ઘટક શોધો જેનું કામ પેલોડ સંગ્રહ કરવાનું છે: પેકેટ કેપ્ચર સાધન, બોડી કેશ કરતો પ્રોક્સી, આર્કાઇવ કરતું પ્લગઇન. તે સ્ટોરેજ ટ્રાફિક પેદા કરે છે જે તેમને જે રેકોર્ડ કરવાનું કહેવાય તેની સાથે વધે છે, અને તે જાળવણી તથા ઍક્સેસ અંગેના અલગ નીતિ નિર્ણયનો ભાગ છે.
યોગ્ય સંખ્યા સાથે ક્ષમતા આયોજન
પેકેટ માર્ગને નેટવર્ક આંકડાથી માપો: થ્રુપુટ, ક્રિપ્ટોગ્રાફિક પ્રોસેસિંગ અને મેમરીની હિલચાલ. સ્ટોરેજને તમે ખરેખર કરેલા અવલોકનક્ષમતાના નિર્ણયોથી માપો: લોગ સ્તર, જાળવણી, સ્ટેટસ અંતરાલ, અને ઇરાદાપૂર્વક ચાલુ કરેલું કોઈપણ કેપ્ચર.
આ બે બજેટ અલગ રાખવાથી ઘટનાઓ વાંચવી પણ સહેલી બને છે. સાધારણ ટનલ ટ્રાફિક સાથે ભરાયેલી ડિસ્ક લોગ, કેપ્ચર કે કોઈ અસંબંધિત વસ્તુ તરફ સંકેત કરે છે, અને ઇન્ટરફેસ કાઉન્ટર તેને ક્યારેય સમજાવશે નહીં. શાંત લોગ સાથે સંતૃપ્ત લિંક બીજી દિશા તરફ સંકેત કરે છે.
જે સરખામણી કરવા યોગ્ય છે તે એક જ પ્રકારનાં માપ વચ્ચેની છે. સમય સાથે ઇન્ટરફેસ બાઇટ સામે ઇન્ટરફેસ બાઇટ તમને માર્ગ વિશે કહે છે. સ્ટોરેજ લેખન સામે સ્ટોરેજ ક્ષમતા તમને જાળવણી વિશે કહે છે. આડી સરખામણી, ટ્રાફિક સામે ડિસ્ક, ફક્ત અર્થપૂર્ણ લાગે છે અને ક્યારેય હોતી નથી.