VPN सर्वर लोड की व्याख्या: उपयोगकर्ता, CPU या अपलिंक?
कम लोड स्कोर का मतलब निष्क्रिय उपयोगकर्ता, बचा हुआ CPU या चौड़ा अपलिंक हो सकता है। इसे तेज़ कहने से पहले loadavg, इंटरफ़ेस काउंटर और स्टेटस फ़ाइल पढ़ें।
0.4 लोड पर बैठा गेटवे अपने पीछे के हर उपयोगकर्ता के लिए फिर भी रेंग सकता है। औसत लोड उन कार्यों को गिनता है जो चलाए जा सकते हैं या जो अटूट निद्रा में फँसे हैं, और चार कोर वाले होस्ट पर एक ही संतृप्त प्रक्रिया उसे 1.0 की ओर धकेलने के लिए काफ़ी है जबकि तीन कोर बेकार बैठे रहते हैं। उस संख्या को अतिरिक्त क्षमता के रूप में पढ़ना एंडपॉइंट चुनने में सबसे आम गलती है। टनल को असल में सीमित करने वाली चीज़ आम तौर पर चार में से एक होती है: एक व्यस्त कोर, अपलिंक, उसके आगे की कतार, या किसी ऐसी प्रति-सत्र नीति जिसे किसी ने प्रलेखित नहीं किया।
औसत लोड कार्य गिनता है, थ्रूपुट नहीं
कर्नेल रन क्यू और इनपुट-आउटपुट की प्रतीक्षा कर रहे कार्यों की संख्या का नमूना लेता है, फिर दोनों को एक, पाँच और पंद्रह मिनट में समतल करता है। उस परिभाषा में बाइट, पैकेट या टनल का कोई ज़िक्र नहीं है। जिस होस्ट का स्टोरेज अटका हुआ है वह लगभग बिना ट्रैफ़िक के उच्च लोड बता सकता है, और कर्नेल डेटा पथ से गीगाबिट धकेलने वाला होस्ट आरामदायक लोड बता सकता है।
इसलिए लोड को टनल प्रदर्शन से जोड़ने के लिए प्रति-कोर दृष्टि चाहिए। अगर एक कोर पूरी तरह भरा है, तो डैशबोर्ड पर समग्र प्रतिशत फिर भी ठीक दिखेगा:
cat /proc/loadavg
mpstat -P ALL 1 1
top -H -b -n 1 | head -n 20तीसरा कमांड VPN होस्ट पर सबसे ज़्यादा मायने रखता है। OpenVPN 2.x में उपयोगकर्ता-स्थान पर पैकेट प्रोसेसिंग बड़े हिस्से में प्रति प्रक्रिया क्रमिक है, इसलिए एक ही व्यस्त थ्रेड छत बन सकता है जबकि डैशबोर्ड भरपूर खाली क्षमता बताता है। अगर आपकी धीमी अवधि में एक थ्रेड एक कोर का ज़्यादातर हिस्सा पकड़े रहता है, तो होस्ट समग्र रूप से कम-सुसज्जित नहीं है; वह उस आयाम में सीमित है जो संयोग से मायने रखता है।
समय पर भी ध्यान दें। पंद्रह मिनट के औसत उस विस्फोट को छिपा देते हैं जिसने किसी कॉल को बर्बाद किया, इसलिए शिकायत के बाद लिया गया स्क्रीनशॉट कमज़ोर सबूत है। समस्या के दौरान नमूने लें, और टाइमस्टैम्प आउटपुट के साथ रखें।
अपलिंक और उसके आगे की कतार
इंटरफ़ेस काउंटर बैंडविड्थ के उस सवाल का जवाब देते हैं जो CPU के आँकड़े नहीं दे सकते। वे क्षमता को हानि से भी अलग करते हैं, और ये अलग-अलग विफलताएँ हैं जिनके अलग-अलग उपाय हैं:
ip -s link show dev eth0
tc -s qdisc show dev eth0
nstat -az TcpRetransSegs TcpExtTCPLostRetransmitआपके परीक्षण के दौरान अपनी आवंटित दर के करीब बैठा लिंक ही व्याख्या है, और बचे हुए CPU की कोई भी मात्रा उसे नहीं बदलती। qdisc पंक्ति वह विवरण जोड़ती है जो इंटरैक्टिव ट्रैफ़िक के लिए मायने रखता है: बैकलॉग और ड्रॉप बताते हैं कि पैकेट निकलने से पहले कतार में रुकते हैं या नहीं। भारी अपलोड के नीचे भरने वाली कतार ठीक वही लक्षण पैदा करती है जिसका दोष लोग दूर के सर्वर पर डालते हैं, यानी ऐसे कनेक्शन पर धीमी कॉल जो बेंचमार्क में अब भी अच्छा दिखता है।
रीट्रांसमिशन काउंटर उस स्थिति को पकड़ते हैं जहाँ पैकेट निकलते हैं पर कभी साफ़ पहुँचते नहीं। अगर धीमी खिड़की में रीट्रांसमिशन बढ़ते हैं और इंटरफ़ेस क्षमता के कहीं करीब नहीं है, तो समस्या होस्ट पर नहीं पथ में है, और उसी शहर में दूसरे एंडपॉइंट पर जाने से मदद नहीं मिलेगी।
सत्र संख्या माँग बताती है, अतिरिक्त क्षमता नहीं
हर सार्वजनिक निर्देशिका कुछ संख्या में जुड़े उपयोगकर्ता दिखाती है, और उनमें से लगभग कोई भी आपको नहीं बताता कि वे उपयोगकर्ता क्या कर रहे हैं। इंटरैक्टिव काम करते बीस सत्र और बड़ी फ़ाइलें खींचते चार सत्र एक ही हार्डवेयर पर बहुत अलग लोड पैदा करते हैं। दूसरा पैटर्न उपयोगकर्ता संख्या में अदृश्य है, और वही एक शाम बर्बाद करता है। इसलिए सत्र संख्या को माँग का संकेत पढ़ना बेहतर है, कभी भी बची हुई क्षमता के बयान के रूप में नहीं।
| Number on the page | What it is really measuring | What it cannot tell you |
|---|---|---|
| Connected users | How many sessions hold an address | How much each one is transferring |
| Load or score | Whatever the operator chose to publish | Whether that definition matches your task |
| Uptime | How long since the process started | Current capacity, queue depth or packet loss |
| Distance or ping | Round-trip time on a small probe | Throughput under sustained transfer |
जिस होस्ट को आप नियंत्रित करते हैं, वहाँ स्टेटस फ़ाइल वह गुमशुदा आयाम देती है। OpenVPN समय-समय पर स्नैपशॉट लिखता है जिसमें प्रति-क्लाइंट बाइट काउंटर शामिल होते हैं, और यह देखने के लिए काफ़ी है कि क्या एक ही सत्र पूरे अपलिंक के लिए ज़िम्मेदार है:
status /run/openvpn/server.status 10
# then, after at least one interval
grep -E "^CLIENT_LIST" /run/openvpn/server.statusदस सेकंड के अंतर पर दो नमूने उन संचयी गणनाओं को प्रति क्लाइंट दर में बदल देते हैं। यही वह माप है जिसकी जगह उपयोगकर्ता संख्या लेती है, और इसी तरह आप पाते हैं कि एक ग़लत कॉन्फ़िगर क्लाइंट हर रात उसी घंटे लिंक को संतृप्त करता है।
प्रति-सत्र सीमाएँ नीति में छिपी रहती हैं
सर्वर निष्क्रिय हो सकता है और फिर भी आपको बैंडविड्थ देने से मना कर सकता है। दर सीमाएँ, प्रति-क्लाइंट बैंडविड्थ कैप और ट्रैफ़िक शेपिंग अक्सर साझा नाम या पूल के अनुसार लागू होते हैं, इसलिए एक ही गेटवे पर दो उपयोगकर्ताओं को बहुत अलग परिणाम मिल सकते हैं। तंत्र सूक्ष्म नहीं है, पर बाहर से अदृश्य है क्योंकि दोनों ही स्थितियों में टनल सामान्य रूप से उठता है।
शेपिंग टनल इंटरफ़ेस पर खोजें, भौतिक पर नहीं। जाँचें कि सीमा उपयोगकर्ता, प्रमाणपत्र या पता पूल का अनुसरण करती है या नहीं। अगर आपका परीक्षण खाता बिना सीमा वाले पूल में पड़ता है, तो आप निष्कर्ष निकालेंगे कि सर्वर ठीक है और शिकायत करने वाला उपयोगकर्ता ग़लत है। वह निष्कर्ष किसी भी निष्कर्ष से बुरा है, क्योंकि वह टिकट बंद कर देता है।
एक निश्चित कार्य से दो एंडपॉइंट की तुलना करें
क्लाइंट-पक्ष का प्रयोग अब भी करने लायक है, पर केवल तब जब चर स्थिर हों। वही डिवाइस, वही एक्सेस नेटवर्क, वही प्रोटोकॉल और वही गंतव्य फ़ाइल इस्तेमाल करें, फिर समान दूरी पर दूसरे एंडपॉइंट के विरुद्ध दोहराएँ। रनों के बीच जो कुछ भी बदलता है, दिन का समय भी शामिल, परिणाम को दूषित करता है।
विफलताओं को सफलताओं जितनी ही सावधानी से दर्ज करें। जिस श्रृंखला में तीन एंडपॉइंट चलते हैं और एक समय-सीमा पर पहुँच जाता है, वह चार गति आँकड़ों से ज़्यादा जानकारीपूर्ण है, क्योंकि वह क्षमता की नहीं बल्कि पथ या नीति की समस्या की ओर इशारा करती है। हर मामला कम से कम दो बार चलाएँ; साझा नेटवर्क पर एक धीमा नमूना कुछ साबित नहीं करता।
अंत में, जो आँकड़े आपने जुटाए हैं उन्हें उस दावे के साथ रखें जिसका वे समर्थन करते हैं। "इस एंडपॉइंट ने वह स्थानांतरण उसी अवधि में निपटाया जिसमें दूसरा अटक गया" रक्षात्मक है, जबकि "यह एंडपॉइंट तेज़ है" ऐसी बहस का न्योता देता है जिसे होमपेज स्कोर से नहीं जीता जा सकता। OpenVPN 2.6 मैनुअल स्टेटस फ़ाइल और शेपिंग विकल्पों का दस्तावेज़ीकरण करता है अगर आपको होस्ट पक्ष के सटीक निर्देश चाहिए।