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खरे पेलोड लेखन असल्याची शंका असल्यास, ज्याचे काम पेलोड साठवणे आहे असे घटक शोधा: पॅकेट कॅप्चर साधन, बॉडी कॅशे करणारा प्रॉक्सी, संग्रह करणारे प्लगइन। हे त्यांना जे रेकॉर्ड करायला सांगितले जाते त्यानुसार वाढणारी स्टोरेज रहदारी निर्माण करतात आणि ते टिकवणे व प्रवेश याबाबतच्या स्वतंत्र धोरण निर्णयात येतात।
योग्य संख्येने क्षमता नियोजन
पॅकेट मार्ग नेटवर्कच्या आकड्यांनी मोजा: थ्रूपुट, क्रिप्टोग्राफिक प्रक्रिया आणि स्मृतीची हालचाल। स्टोरेज तुम्ही प्रत्यक्षात घेतलेल्या निरीक्षणक्षमतेच्या निर्णयांनी मोजा: लॉग पातळी, टिकवणे, स्टेटस अंतर आणि जाणीवपूर्वक सुरू केलेले कोणतेही कॅप्चर।
ही दोन बजेट वेगळी ठेवल्याने घटना वाचणेही सोपे होते। माफक टनेल रहदारीसह भरलेली डिस्क लॉग, कॅप्चर किंवा असंबंधित कशाकडे निर्देश करते आणि इंटरफेस काउंटर ते कधीही स्पष्ट करणार नाही। शांत लॉगसह संपृक्त दुवा दुसऱ्या दिशेने निर्देश करतो।
करण्यासारखी तुलना एकाच प्रकारच्या मापांमधील असते। काळानुसार इंटरफेस बाइट विरुद्ध इंटरफेस बाइट तुम्हाला मार्गाबद्दल सांगतात। स्टोरेज लेखन विरुद्ध स्टोरेज क्षमता तुम्हाला टिकवण्याबद्दल सांगतात। आडवी तुलना, रहदारी विरुद्ध डिस्क, फक्त अर्थपूर्ण दिसते आणि कधीही अर्थपूर्ण नसते।