क्या आपका VPN गेटवे CPU से सीमित है? पहले प्रति-कोर लोड पढ़ें
औसत उस थ्रेड को छिपाते हैं जो मायने रखता है। नियंत्रित ट्रांसफर के दौरान प्रति-कोर लोड पढ़ें, पथ को बाहर रखें, और फिर हर रन में एक दस्तावेज़ी सेटिंग बदलें।
बड़ा इंस्टेंस खरीदने से पहले तय करें कि आप तीन सीमाओं में से किस तक पहुँचे हैं। एक कोर पूरी तरह व्यस्त और बाकी खाली होना प्रति-फ़्लो क्रिप्टो काम की ओर इशारा करता है। ट्रांसफर के दौरान सभी कोर संतृप्त होना कुल क्षमता की ओर इशारा करता है। कम CPU और बढ़ती रीट्रांसमिट संख्या पथ की ओर इशारा करती है। हर एक का पहला कदम अलग है, और उनमें से केवल एक ही बड़े इंस्टेंस से हल होता है।
तीन सीमाएँ, एक तालिका, तीन सुधार
| Limit | Reading during a transfer | First move |
|---|---|---|
| Single thread | one core near 100%, siblings idle | spread flows across workers |
| Aggregate CPU | every core busy, load average climbs | capacity, or less work per byte |
| Path or provider | low CPU, retransmits or steal time high | MTU, loss, host contention |
पंक्तियों को चरणों के बजाय निदान के रूप में पढ़ें। एक थ्रेड 100% पर और बाकी खाली होना एक बड़ी सुरंग ले जाने वाले गेटवे पर सबसे आम परिणाम है, क्योंकि उस फ़्लो का एन्क्रिप्शन एक कोर पर चलता है। ट्रांसफर के दौरान सभी कोर व्यस्त होना मतलब मशीन पहले से ही उतना काम कर रही है जितना कर सकती है। कम CPU और बढ़ते रीट्रांसमिट का मतलब प्रोसेसर ऐसे नेटवर्क का इंतज़ार कर रहा है जो लगातार डेटा गिरा रहा है।
उन्हें सबूत के उसी क्रम में ठीक करें। फ़्लो को वर्करों में फैलाना पहले मामले में मदद करता है और दूसरे के लिए कुछ नहीं करता। बड़ा इंस्टेंस दूसरे में मदद करता है और पहले पर पैसा बर्बाद करता है। MTU या लॉस सुधार ही एकमात्र है जो तीसरे को छूता है। यह जानने से पहले क्षमता खरीदना कि आप किस पंक्ति में हैं अनुमान लगाने का महँगा संस्करण है।
फँसे थ्रेड को व्यस्त होस्ट से अलग करें
प्रति-कोर उपयोग से शुरू करें, ताकि एक फँसा कोर औसत के भीतर न छिप सके। ट्रांसफर के दौरान एक रन दिखाता है कि लोड सपाट है या शिखर वाला। दोनों आकार जानकारीपूर्ण हैं, और शिखर वाली प्रोफ़ाइल अक्सर मतलब है कि सैंपलिंग विंडो ने एन्क्रिप्शन के बजाय शेड्यूलर की गतिविधि पकड़ी।
mpstat -P ALL 1 5व्यस्त कोर को किसी प्रोसेस से, फिर थ्रेड से जोड़ें। नीचे का फ़ॉलो-अप रन पैरेंट और चाइल्ड थ्रेड को साथ रखता है, जो तब मायने रखता है जब डेमॉन हर कनेक्शन पर फ़ोर्क करता है:
pidstat -u -t -p $(pgrep -f 'openvpn|wireguard|ipsec') 1 10कर्नेल क्रिप्टो कभी भी यूज़रस्पेस प्रोसेस काउंटर में नहीं दिखता। थ्रेड को अलग से सैंपल करें और उस दृश्य की तुलना प्रोसेस लेखांकन से करें:
top -H -b -n 1 | head -20सॉकेट काउंटर सबसे अंत में पढ़ें, क्योंकि वे तय करते हैं कि ज़्यादा CPU बिल्कुल मदद करेगा या नहीं। CPU स्थिर रहते हुए रीट्रांसमिट बढ़ना प्रोसेसर की समस्या नहीं है। सैंपल करते समय ट्रांसफर चालू रखें, वरना संख्याएँ निष्क्रिय मशीन का वर्णन करेंगी:
ss -ti | grep -E 'retrans|cwnd|rtt'एक नियंत्रित ट्रांसफर, दो बार चलाया गया
निष्क्रिय काउंटर कुछ साबित नहीं करते, और किसी यादृच्छिक एंडपॉइंट के विरुद्ध बेंचमार्क बहुत कम साबित करता है। एक क्लाइंट, एक गंतव्य और एक प्रतिनिधि ट्रांसफर चुनें जिसे चलाने की आपको अनुमति है, फिर उसी विंडो में थ्रूपुट और इंटरैक्टिव विलंब कैप्चर करें। गेटवे संतृप्त हो सकता है जबकि बल्क कॉपी अभी पूरी हो रही हो, और विलंब वक्र ही वह है जो उपयोगकर्ता वास्तव में महसूस करते हैं। ट्रांसफर, क्लाइंट संख्या और डेमॉन संस्करण संख्याओं के बगल में लिखें।
कई समानांतर फ़्लो के साथ रन दोहराएँ। फ़्लो में बढ़ना प्रति-फ़्लो विंडो की ओर संकेत करता है; एक कोर फँसा होने पर भी सपाट रहना प्रोसेसिंग की ओर संकेत करता है।
फिर वैकल्पिक वर्कलोड बंद करके एक बार और दोहराएँ। उसी होस्ट पर बैकअप, लॉग शिपर या डेटाबेस व्यस्त औसत बना सकते हैं जिसका सुरंगों से कोई संबंध नहीं है। अगर होस्ट अन्यथा शांत है और CPU अभी भी फँसा है, तो सबूत VPN प्रोसेस की ओर इशारा करते हैं। अगर यह गिरता है, तो आप पड़ोसी को माप रहे थे, और गेटवे कभी समस्या नहीं था।
हार्डवेयर खरीदने से पहले पथ को बाहर रखें
बढ़ते रीट्रांसमिट, सिकुड़ती कंजेशन विंडो और बढ़ता राउंड-ट्रिप समय सब प्रोसेसर से दूर इशारा करते हैं। सुरंग के MTU की तुलना पथ के MTU से करें, अंतर्निहित लिंक में लॉस जाँचें, और पुष्टि करें कि क्लाइंट का अपना अपलिंक सीमा नहीं है। बड़ा गेटवे पैकेट गिराने वाले लिंक की मरम्मत नहीं करता, और उपयोगकर्ता दोनों खराबियों का वर्णन एक ही शब्दों में करते हैं। रीट्रांसमिट काउंटर मिनटों में उन्हें अलग कर देता है।
वर्चुअल सर्वर पर, प्रदाता के मीट्रिक गेस्ट के अपने मीट्रिक में जोड़ें। स्टील टाइम वह है जिससे अधिक बिक्री गेस्ट के अंदर दिखाई देती है, और गेस्ट के अंदर कोई ट्यूनिंग उसे हटाती नहीं। गेस्ट काउंटर होस्ट नहीं देख सकते, इसलिए साफ़ गेस्ट ग्राफ़ स्वस्थ होस्ट का सबूत नहीं है।
एक बदलाव, एक माप
वह परिकल्पना चुनें जिसे सबूत समर्थन देते हैं, फिर ठीक एक समर्थित सेटिंग बदलें: वर्कर संख्या, एक दस्तावेज़ी ऑफ़लोड विकल्प, या इंस्टेंस का आकार। OpenVPN प्रोसेसिंग और ट्रांसपोर्ट के बीच उसी विभाजन पर प्रदर्शन समस्या निवारण मार्गदर्शिका प्रकाशित करता है: OpenVPN प्रदर्शन समस्या निवारण।
पुष्टि करें कि ऑफ़लोड विकल्प वास्तव में सक्रिय है, फ़्लैग पर भरोसा करने के बजाय, फिर वही ट्रांसफर दोबारा चलाएँ और समान की समान से तुलना करें। यही एकमात्र तरीका है कि असली सुधार को शांत दोपहर से अलग पहचाना जाए। ऐसा चेकपॉइंट रखें जिसे आप बहाल कर सकें, क्योंकि दूसरे बदलाव में लोग यह भूल जाते हैं कि किसने मदद की। हर रन में एक चर एक दिन के लिए धीमा और एक महीने के लिए तेज़ है।
ग्राफ़ को बेहतर दिखाने के लिए प्रमाणीकरण या सिफ़र सूट कमज़ोर न करें। अगर CPU अब भी लक्षण का पीछा नहीं कर रहा, तो अनुमान पर अपग्रेड करने के बजाय पथ और एप्लिकेशन जाँच पर लौटें।