तपाईंको 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 ले अझै लक्षणलाई पछ्याएको छैन भने अनुमानमा अपग्रेड गर्नुको सट्टा मार्ग र अनुप्रयोग जाँचतर्फ फर्कनुहोस्।