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 पुस्तिका स्टेटस फाइल आणि आकारण पर्यायांचे दस्तऐवजीकरण करते, जर तुम्हाला होस्ट बाजूच्या अचूक सूचना हव्या असतील।