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