👦🏼 👨🏼‍💻 🤞🏼 सर्वर पर किस तरह का लोड नेटवर्क तंत्र बनाता है? 💇🏾 👨‍❤️‍💋‍👨 👩🏽

जब सर्वर के नेटवर्क सबसिस्टम के संचालन का विश्लेषण करते हैं, तो आमतौर पर इस तरह के संकेतक जैसे कि विलंबता, सिस्टम के थ्रूपुट और पैकेटों की संख्या प्रति सेकंड (पीपीएस, पैकेट्स प्रति सेकंड) संसाधित की जा सकती है। इन संकेतकों का उपयोग यह समझने के लिए किया जाता है कि अध्ययन के तहत कंप्यूटर अधिकतम लोड क्या काम कर सकता है। और यद्यपि ये मैट्रिक्स महत्वपूर्ण हैं और अक्सर सिस्टम के बारे में बहुत कुछ कहने में सक्षम होते हैं, वे सर्वर पर चलने वाले कार्यक्रमों पर नेटवर्क पैकेट के प्रसंस्करण पर क्या प्रभाव डालते हैं, इसकी जानकारी नहीं देते हैं। यह सामग्री सर्वर पर नेटवर्क तंत्र द्वारा बनाए गए भार का अध्ययन करने के उद्देश्य से है। विशेष रूप से, हम इस बारे में बात करेंगे कि लिनक्स सिस्टम पर चल रही विभिन्न प्रक्रियाओं से नेटवर्क समस्याओं का समाधान प्रोसेसर समय कितना "चुरा" सकता है।

लिनक्स पर नेटवर्क पैकेट प्रसंस्करण

Linux, संगत IRQ को संसाधित करने के समय प्रोसेसर द्वारा निष्पादित किसी भी प्रक्रिया के संदर्भ में पैकेट की एक महत्वपूर्ण संख्या को संसाधित करता है। सिस्टम अकाउंटिंग इंजन इसके लिए उपयोग किए जाने वाले प्रोसेसर चक्र को किसी भी प्रक्रिया के लिए असाइन करेगा जो वर्तमान में निष्पादित हो रहा है। यह तब भी किया जाएगा जब इस प्रक्रिया का नेटवर्क पैकेट प्रसंस्करण से कोई लेना-देना नहीं है। उदाहरण के लिए, एक टीम topयह संकेत दे सकती है कि प्रोसेसर के 99% से अधिक संसाधनों का उपयोग करने के लिए एक प्रक्रिया दिखाई देती है, लेकिन वास्तव में प्रोसेसर के 60% समय पैकेट के प्रसंस्करण पर खर्च किए जाएंगे। और इसका मतलब यह है कि प्रक्रिया स्वयं, अपनी समस्याओं को हल करते हुए, केवल 40% CPU संसाधनों का उपयोग करती है।

भीतर का हैंडलरnet_rx_actionआमतौर पर बहुत, बहुत तेजी से प्रदर्शन किया। उदाहरण के लिए, 25 μ से कम में। (यह डेटा eBPF का उपयोग करते हुए माप से प्राप्त किया गया था। यदि आप विवरणों में रुचि रखते हैं, तो यहां देखें net_rx_action ।) प्रोसेसर किसी अन्य सॉफ्टआईआरक्यू चक्र को कार्य स्थगित करने से पहले NAPI उदाहरण (NIC या RPS) प्रति 64 पैकेट तक संसाधित कर सकता है। एक के बाद एक, बिना ब्रेक के, 10 सॉफ्टरक्यू चक्र तक का पालन कर सकते हैं, जो लगभग 2 एमएस लेता है (आप इसके बारे में पढ़कर इसके बारे में अधिक जानकारी प्राप्त कर सकते हैं __do_softirq)। यदि सॉफ्टरक्यू वेक्टर, चक्रों की अधिकतम संख्या बीत जाने के बाद, या समय बीत गया है, अभी भी अनसुलझी समस्याएं हैं, तो इन समस्याओं के समाधान को थ्रेड में निष्पादन में देरी हो रही हैksoftirqdविशिष्ट CPU। जब ऐसा होता है, तो सिस्टम नेटवर्क संचालन द्वारा निर्मित प्रोसेसर लोड के बारे में जानकारी प्राप्त करने के अर्थ में थोड़ा अधिक पारदर्शी हो जाता है (हालांकि इस तरह के विश्लेषण को इस धारणा पर किया जाता है कि इसका अध्ययन किया गया सॉफ्टरक्यू है, जो पैकेट प्रसंस्करण से संबंधित हैं, और कुछ और नहीं) ।

उपरोक्त संकेतक प्राप्त करने का एक तरीका उपयोग करना है perf:

sudo perf record -a \
        -e irq:irq_handler_entry,irq:irq_handler_exit
        -e irq:softirq_entry --filter="vec == 3" \
        -e irq:softirq_exit --filter="vec == 3"  \
        -e napi:napi_poll \
        -- sleep 1

sudo perf script

यहाँ परिणाम है:

swapper     0 [005] 176146.491879: irq:irq_handler_entry: irq=152 name=mlx5_comp2@pci:0000:d8:00.0
swapper     0 [005] 176146.491880:  irq:irq_handler_exit: irq=152 ret=handled
swapper     0 [005] 176146.491880:     irq:softirq_entry: vec=3 [action=NET_RX]
swapper     0 [005] 176146.491942:        napi:napi_poll: napi poll on napi struct 0xffff9d3d53863e88 for device eth0 work 64 budget 64
swapper     0 [005] 176146.491943:      irq:softirq_exit: vec=3 [action=NET_RX]
swapper     0 [005] 176146.491943:     irq:softirq_entry: vec=3 [action=NET_RX]
swapper     0 [005] 176146.491971:        napi:napi_poll: napi poll on napi struct 0xffff9d3d53863e88 for device eth0 work 27 budget 64
swapper     0 [005] 176146.491971:      irq:softirq_exit: vec=3 [action=NET_RX]
swapper     0 [005] 176146.492200: irq:irq_handler_entry: irq=152 name=mlx5_comp2@pci:0000:d8:00.0

इस स्थिति में, प्रोसेसर निष्क्रिय है (इसलिए swapperप्रक्रिया के लिए प्रविष्टियों की उपस्थिति ), आईआरक्यू को सीपीयू 5 पर आरएक्स कतार के लिए कहा जाता है, सॉफ्टिरक्यू प्रसंस्करण को दो बार कहा जाता है, 64 पैकेट पहले संसाधित होते हैं, फिर 27. अगले आईआरक्यू को 229 μs के बाद बुलाया जाता है और फिर से चक्र शुरू होता है।

यह डेटा निष्क्रिय प्रणाली पर प्राप्त किया गया था। लेकिन प्रोसेसर पर, कोई भी कार्य किया जा सकता है। इस स्थिति में, घटनाओं का उपरोक्त क्रम होता है, इस कार्य को बाधित करना और IRQ / SoftIRQ कार्य करना। इसी समय, सिस्टम अकाउंटिंग प्रोसेसर द्वारा बनाए गए लोड को बाधित प्रक्रिया को बताता है। नतीजतन, नेटवर्क पैकेट प्रसंस्करण कार्य आमतौर पर पारंपरिक प्रोसेसर लोड मॉनिटरिंग टूल से छिपे होते हैं। उन्हें "पीड़ित प्रक्रिया" के संदर्भ में कुछ यादृच्छिक रूप से चयनित प्रक्रिया के संदर्भ में निष्पादित किया जाता है। यह हमें कुछ सवालों की ओर ले जाता है। पैकेट के प्रसंस्करण के लिए किस समय प्रक्रिया बाधित होती है, इसका अनुमान कैसे लगाया जाए? कंप्यूटर पर हल किए गए विभिन्न कार्यों पर उनके कम प्रभाव को समझने के लिए 2 विभिन्न नेटवर्क समाधानों की तुलना कैसे करें?

आरएसएस, आरपीएस, आरएफएस तंत्र का उपयोग करते समय, पैकेट प्रसंस्करण आमतौर पर प्रोसेसर कोर के बीच वितरित किया जाता है। इसलिए, उपरोक्त पैकेट प्रसंस्करण अनुक्रम प्रत्येक विशिष्ट सीपीयू से संबंधित है। जैसे ही पैकेट आगमन की दर बढ़ती है (मुझे लगता है कि हम 100,000 पैकेट की गति प्रति सेकंड और अधिक के बारे में बात कर सकते हैं), प्रत्येक सीपीयू को प्रति सेकंड हजारों या दसियों हजार पैकेटों को संसाधित करना पड़ता है। इतने सारे पैकेटों को संसाधित करना सर्वर पर निष्पादित अन्य कार्यों को अनिवार्य रूप से प्रभावित करेगा।

इस प्रभाव का मूल्यांकन करने के एक तरीके पर विचार करें।

वितरित पैकेट प्रसंस्करण अक्षम करना

शुरू करने के लिए, चलो आरपीएस को अक्षम करके और हमारे लिए ज्ञात एकमात्र सीपीयू पर एक विशिष्ट मैक पते से संबंधित सभी पैकेटों के प्रसंस्करण को व्यवस्थित करने के उद्देश्य से आरपीएस को अक्षम करके और पैकेट नियंत्रण नियमों की स्थापना करके पैकेटों के वितरित प्रसंस्करण को रोकते हैं। मेरे सिस्टम में 802.3ad कॉन्फ़िगरेशन में 2 एनआईसी एकत्रित हैं। नेटवर्क कार्यों को एक कंप्यूटर पर चलने वाली एकल वर्चुअल मशीन को सौंपा गया है।

नेटवर्क एडॉप्टर पर आरपीएस निम्नानुसार अक्षम है:

for d in eth0 eth1; do
    find /sys/class/net/${d}/queues -name rps_cpus |
    while read f; do
            echo 0 | sudo tee ${f}
    done
done

इसके बाद, हम यह सुनिश्चित करने के लिए प्रवाह नियंत्रण नियम स्थापित करते हैं कि पैकेट एक ही सीपीयू का उपयोग करके परीक्षण वर्चुअल मशीन में मिलता है:

DMAC=12:34:de:ad:ca:fe
sudo ethtool -N eth0 flow-type ether dst ${DMAC} action 2
sudo ethtool -N eth1 flow-type ether dst ${DMAC} action 2

आरपीएस को अक्षम करना और प्रवाह नियंत्रण नियमों का उपयोग करना हमें यह सुनिश्चित करने की अनुमति देता है कि हमारी वर्चुअल मशीन के लिए किस्मत में सभी पैकेट एक ही सीपीयू पर संसाधित हैं। यह सुनिश्चित करने के लिए कि पैकेट उस कतार में भेजे जाते हैं जिस पर उन्हें भेजा जाना चाहिए, आप ethq जैसी कमांड का उपयोग कर सकते हैं । तब आप यह पता लगा सकते हैं कि यह कतार किस सीपीयू के उपयोग की है /proc/interrupts। मेरे मामले में, सीपीयू 5 के माध्यम से टर्न 2 को संसाधित किया जाता है।

Openssl स्पीड कमांड

मैं उपयोगिताओं का उपयोग कर सकता हूं perfया आने वाले ट्रैफ़िक को संसाधित करने के लिए जिम्मेदार सॉफ्टिरक्यू रनटाइम का विश्लेषण कर सकता हूं bpf, लेकिन यह दृष्टिकोण काफी जटिल है। इसके अतिरिक्त, अवलोकन प्रक्रिया निश्चित रूप से परिणामों को प्रभावित करती है। एक सरल और अधिक समझने योग्य समाधान कुछ कार्यों का उपयोग करके सिस्टम पर नेटवर्क संचालन द्वारा बनाए गए लोड की पहचान करना है, जो सिस्टम पर एक ज्ञात लोड बनाता है। उदाहरण के लिए, यह openssl speedओपनएसएसएल प्रदर्शन का परीक्षण करने के लिए उपयोग की जाने वाली एक कमांड है। यह आपको यह पता लगाने की अनुमति देगा कि प्रोग्राम वास्तविकता में कितना प्रोसेसर संसाधन प्राप्त करता है, और इसकी तुलना उन संसाधनों की मात्रा से करें जो इसे प्राप्त करने वाले हैं (यह पता लगाने में मदद करेगा कि नेटवर्क कार्यों पर कितना संसाधन खर्च होता है)।

टीम openssl speedलगभग 100% उपयोगकर्ता अंतरिक्ष टीम है। यदि आप इसे एक निश्चित सीपीयू से जोड़ते हैं, तो यह, परीक्षणों के निष्पादन के दौरान, इसके सभी उपलब्ध संसाधनों का उपयोग करता है। टीम टाइमर को निर्दिष्ट अंतराल पर सेट करके काम करती है (यहां, उदाहरण के लिए, गणना को आसान बनाने के लिए, इसमें 10 सेकंड लगते हैं), परीक्षण चला रहा है, और फिर, जब टाइमर चालू हो जाता है, तो times()यह पता लगाने के लिए कि प्रोग्राम को कितना प्रोसेसर समय मिला है। इस दृष्टिकोण से syscallयह इस तरह दिखता है:

alarm(10)                               = 0
times({tms_utime=0, tms_stime=0, tms_cutime=0, tms_cstime=0}) = 1726601344
--- SIGALRM {si_signo=SIGALRM, si_code=SI_KERNEL} ---
rt_sigaction(SIGALRM, ...) = 0
rt_sigreturn({mask=[]}) = 2782545353
times({tms_utime=1000, tms_stime=0, tms_cutime=0, tms_cstime=0}) = 1726602344

यही है, यह पता चलता है कि alarm()कॉल करने और परिणामों की जांच करने के बीच बहुत कम सिस्टम कॉल किए गए थे। यदि कार्यक्रम बाधित नहीं हुआ था, या बहुत कम बाधित हुआ था, तो समय tms_utimeपरीक्षण समय (इस मामले में, 10 सेकंड) के साथ मेल खाएगा।

चूंकि यह विशेष रूप से उपयोगकर्ता अंतरिक्ष में किया गया एक परीक्षण है, इसलिए जो भी सिस्टम समय में प्रकट होता है, times()उसका अर्थ सिस्टम पर कुछ अतिरिक्त भार होगा। यह पता चला है कि हालांकि opensslयह सीपीयू पर चलने वाली एक प्रक्रिया है, सीपीयू खुद कुछ और के साथ व्यस्त हो सकता है। उदाहरण के लिए, नेटवर्क पैकेट को संसाधित करना:

alarm(10)                               = 0
times({tms_utime=0, tms_stime=0, tms_cutime=0, tms_cstime=0}) = 1726617896
--- SIGALRM {si_signo=SIGALRM, si_code=SI_KERNEL} ---
rt_sigaction(SIGALRM, ...) = 0
rt_sigreturn({mask=[]}) = 4079301579
times({tms_utime=178, tms_stime=571, tms_cutime=0, tms_cstime=0}) = 1726618896

यहां आप देख सकते हैं कि opensslप्रोसेसर पर 7.49 सेकंड (0.01 सेकंड के अनुरूप माप की इकाइयों में 178 + 571) के लिए काम करना संभव था । लेकिन उसी समय 5.71 एस। इस अंतराल को सिस्टम टाइम द्वारा दर्शाया जाता है। चूंकि वह opensslकर्नेल अंतरिक्ष में किसी भी व्यवसाय में व्यस्त नहीं है, इसका मतलब है कि 5.71 एस। - यह सिस्टम पर कुछ अतिरिक्त भार का परिणाम है। यही है, यह वह समय है जब सिस्टम की जरूरतों को पूरा करने के लिए प्रक्रिया "चोरी" की गई थी।

नेटवर्क तंत्र की वजह से सिस्टम लोड का पता लगाने के लिए coverssl स्पीड कमांड का उपयोग करना

अब जब हमें पता चला है कि टीम कैसे काम करती है openssl speed, तो हम उन परिणामों को देखेंगे जो इसे व्यावहारिक रूप से निष्क्रिय सर्वर पर उत्पन्न करते हैं:

$ taskset -c 5 openssl speed -seconds 10 aes-256-cbc >/dev/null
Doing aes-256 cbc for 10s on 16 size blocks: 66675623 aes-256 cbc's in 9.99s
Doing aes-256 cbc for 10s on 64 size blocks: 18096647 aes-256 cbc's in 10.00s
Doing aes-256 cbc for 10s on 256 size blocks: 4607752 aes-256 cbc's in 10.00s
Doing aes-256 cbc for 10s on 1024 size blocks: 1162429 aes-256 cbc's in 10.00s
Doing aes-256 cbc for 10s on 8192 size blocks: 145251 aes-256 cbc's in 10.00s
Doing aes-256 cbc for 10s on 16384 size blocks: 72831 aes-256 cbc's in 10.00s

जैसा कि आप देख सकते हैं, हमें सूचित किया जाता है कि कार्यक्रम विभिन्न आकारों के ब्लॉक को संसाधित करने के लिए 9.99 से 10 सेकंड तक खर्च करता है। यह पुष्टि करता है कि सिस्टम तंत्र प्रोग्राम से प्रोसेसर समय नहीं लेते हैं। अब, उपयोग करते हुए netperf, हम दो स्रोतों से आने वाले पैकेटों को संसाधित करके सर्वर को लोड करेंगे। परीक्षण फिर से चलाएँ:

$ taskset -c 5 openssl speed -seconds 10 aes-256-cbc >/dev/null
Doing aes-256 cbc for 10s on 16 size blocks: 12061658 aes-256 cbc's in 1.96s
Doing aes-256 cbc for 10s on 64 size blocks: 3457491 aes-256 cbc's in 2.10s
Doing aes-256 cbc for 10s on 256 size blocks: 893939 aes-256 cbc's in 2.01s
Doing aes-256 cbc for 10s on 1024 size blocks: 201756 aes-256 cbc's in 1.86s
Doing aes-256 cbc for 10s on 8192 size blocks: 25117 aes-256 cbc's in 1.78s
Doing aes-256 cbc for 10s on 16384 size blocks: 13859 aes-256 cbc's in 1.89s

परिणाम एक निष्क्रिय सर्वर पर प्राप्त लोगों से बहुत अलग हैं। यह उम्मीद की जाती है कि प्रत्येक परीक्षण को 10 सेकंड के भीतर निष्पादित किया जाएगा, लेकिन times()रिपोर्ट करता है कि वास्तविक निष्पादन समय 1.78 से 2.1 सेकंड तक है। इसका मतलब यह है कि शेष समय, 7.9 से 8.22 सेकंड तक अलग-अलग था, पैकेट के प्रसंस्करण पर खर्च किया गया था, या तो प्रक्रिया के संदर्भ opensslमें ksoftirqd।

आइए एक नजर डालते हैं topकि लॉन्च पूरा होने पर टीम क्या विश्लेषण देगी openssl speed।

PID USER      PR  NI    VIRT    RES    SHR S  %CPU %MEM     TIME+ COMMAND              P 
 8180 libvirt+  20   0 33.269g 1.649g 1.565g S 279.9  0.9  18:57.81 qemu-system-x86     75
 8374 root      20   0       0      0      0 R  99.4  0.0   2:57.97 vhost-8180          89
 1684 dahern    20   0   17112   4400   3892 R  73.6  0.0   0:09.91 openssl              5    
   38 root      20   0       0      0      0 R  26.2  0.0   0:31.86 ksoftirqd/5          5

यहां आप सोच सकते हैं कि यह opensslसीपीयू 5 के संसाधनों का लगभग 73% उपयोग करता है, और ksoftirqdशेष संसाधन प्राप्त होते हैं। लेकिन वास्तव में, इस संदर्भ में openssl, इतनी बड़ी संख्या में पैकेजों का प्रसंस्करण किया जाता है कि प्रोग्राम को अपनी समस्याओं को हल करने के लिए प्रोसेसर समय का केवल 18-21% लगता है।

यदि आप नेटवर्क लोड को 1 स्ट्रीम तक कम करते हैं, तो आपको opensslयह महसूस होता है कि सिस्टम संसाधनों का 99% उपभोग किया जा रहा है।

  PID USER      PR  NI    VIRT    RES    SHR S  %CPU %MEM     TIME+ COMMAND              P
 8180 libvirt+  20   0 33.269g 1.722g 1.637g S 325.1  0.9 166:38.12 qemu-system-x86     29
44218 dahern    20   0   17112   4488   3996 R  99.2  0.0   0:28.55 openssl              5
 8374 root      20   0       0      0      0 R  64.7  0.0  60:40.50 vhost-8180          55
   38 root      20   0       0      0      0 S   1.0  0.0   4:51.98 ksoftirqd/5          5

लेकिन वास्तव में यह पता चला है कि उपयोगकर्ता अंतरिक्ष में चल रहे कार्यक्रम को 10 सेकंड में, केवल 4 सेकंड के लिए बाहर निकल जाता है:

Doing aes-256 cbc for 10s on 16 size blocks: 26596388 aes-256 cbc's in 4.01s
Doing aes-256 cbc for 10s on 64 size blocks: 7137481 aes-256 cbc's in 4.14s
Doing aes-256 cbc for 10s on 256 size blocks: 1844565 aes-256 cbc's in 4.31s
Doing aes-256 cbc for 10s on 1024 size blocks: 472687 aes-256 cbc's in 4.28s
Doing aes-256 cbc for 10s on 8192 size blocks: 59001 aes-256 cbc's in 4.46s
Doing aes-256 cbc for 10s on 16384 size blocks: 28569 aes-256 cbc's in 4.16s

पारंपरिक प्रक्रिया निगरानी उपकरण इंगित करते हैं कि कार्यक्रम लगभग सभी प्रोसेसर संसाधनों का उपयोग करता है, लेकिन वास्तव में यह पता चलता है कि CPU के 55-80% संसाधन नेटवर्क पैकेट पर खर्च किए जाते हैं। एक ही समय में सिस्टम का थ्रूपुट बहुत अच्छा लगता है (22 Gb / s प्रति 25 Gb / s लाइन से अधिक), लेकिन इस प्रणाली में चल रही प्रक्रियाओं पर इसका जबरदस्त प्रभाव पड़ता है।

सारांश

यहां हमने एक उदाहरण की जांच की कि कैसे पैकेट प्रसंस्करण तंत्र एक सरल और बहुत महत्वपूर्ण बेंचमार्क से प्रोसेसर घड़ियों को "चोरी" करता है। लेकिन एक वास्तविक सर्वर पर, समान रूप से प्रभावित होने वाली प्रक्रियाएं कुछ भी हो सकती हैं। ये वर्चुअल प्रोसेसर हो सकते हैं, एमुलेटर थ्रेड, वर्चुअल मशीनों के vhost थ्रेड हो सकते हैं। ये अलग-अलग सिस्टम प्रक्रियाएं हो सकती हैं, जिस पर इन प्रक्रियाओं और पूरे सिस्टम के प्रदर्शन पर एक अलग प्रभाव हो सकता है।

क्या आप अपने सर्वर के विश्लेषण, नेटवर्क संचालन से जुड़े लोड के उनके वास्तविक प्रदर्शन पर प्रभाव पर विचार करते हैं?

सर्वर पर किस तरह का लोड नेटवर्क तंत्र बनाता है?

लिनक्स पर नेटवर्क पैकेट प्रसंस्करण

वितरित पैकेट प्रसंस्करण अक्षम करना

Openssl स्पीड कमांड

नेटवर्क तंत्र की वजह से सिस्टम लोड का पता लगाने के लिए coverssl स्पीड कमांड का उपयोग करना

सारांश

More articles: