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