मेरे पास कुछ लिनक्स सर्वर हैं जो अपाचे ट्रैफिकर्सवर चला रहे हैं और लगभग 1/20 के अनुरोधों को कई मिलीसेकंड लेते हैं जो अपेक्षा से अधिक लंबे समय तक (1-2ms होना चाहिए)।copy_to_user कई सैकड़ों मिलीसेकंड क्यों खर्च करता है?
सिस्टमटैप द्वारा ट्रेस करने के बाद, मुझे लगता है कि समय लिनक्स कर्नेल copy_to_user() कॉल में बिताया गया है। (accept-> inet_csk_accept-> move_addr_to_user-> copy_to_user)
सर्वर लोड कम छोड़ने जाता है (< 100qps) और copy_to_user() सिर्फ 16 बाइट्स 'डेटा (struct sockaddr) की प्रतिलिपि लेकिन मिलीसेकंड के सैकड़ों खर्च करते हैं।
जैसा कि मैं सिस्टमटैप और कर्नेल ट्रेस तकनीक के लिए नया छोड़ चुका हूं, मैं आगे के कारण की जांच नहीं कर सकता। मैंने सीपीयू उपयोग की जांच की है, स्वैप उपयोग
किसी भी सलाह के लिए धन्यवाद।
हार्डवेयर:
- CPU: इंटेल (आर) जिऑन (आर) सीपीयू E5-2640 v3 @ 2.60GHz
- स्मृति: 64G
- डिस्क: 11 * 6T HDD
सॉफ्टवेयर:
- centos6 2.6.32-696.el6.x86_64 # 1 SMP मंगल मार्च 21 19:29:05 यूटीसी 2017 x86_64 x86_64 x86_64 जीएनयू/लिनक्स
- अपाचे trafficserver 5.3.2 कॉन्फ़िगर 10G राम
nginx 1.10.2, प्रॉक्सी उपयोगकर्ता अनुरोध trafficserver को
// systemtap probe kernel.function("move_addr_to_user") { ts["move_addr_to_user", pid()] = gettimeofday_ms() } probe kernel.function("move_addr_to_user").return { printf("[%d]move_addr_to_user done:%d %s %d\n", gettimeofday_ms(), pid(), execname(), gettimeofday_ms()-ts["move_addr_to_user", pid()]) } probe kernel.function("copy_to_user") { ts["copy_to_user", pid()] = gettimeofday_ms() } probe kernel.function("copy_to_user").return { printf("[%d]copy_to_user done:%d %s %d %d\n", gettimeofday_ms(), pid(), execname(), gettimeofday_ms()-ts["copy_to_user", pid()], gettimeofday_ms()-ts["__copy_to_user", pid()]) } // output: [1495630190767] 16 16 move_addr_to_user done:24145 [ACCEPT 0:8080] 0 [1495630191164]copy_to_user done:24145 [ACCEPT 0:8080] 0 [1495630191164] 16 16 move_addr_to_user done:24145 [ACCEPT 0:8080] 0 [1495630192172]copy_to_user done:24145 [ACCEPT 0:8080] 861 [1495630192172] 16 16 move_addr_to_user done:24145 [ACCEPT 0:8080] 861 [1495630192173]copy_to_user done:24145 [ACCEPT 0:8080] 0 [1495630192173] 16 16 move_addr_to_user done:24145 [ACCEPT 0:8080] 0 [1495630192173]copy_to_user done:24145 [ACCEPT 0:8080] 0 [1495630192173] 16 16 move_addr_to_user done:24145 [ACCEPT 0:8080] 0 [1495630192173]copy_to_user done:24145 [ACCEPT 0:8080] 0 free -g total used free shared buffers cached Mem: 62 55 6 0 0 32 -/+ buffers/cache: 23 39 Swap: 15 0 15 top - 20:57:39 up 24 days, 19:26, 2 users, load average: 7.70, 9.43, 9.62 Tasks: 643 total, 1 running, 642 sleeping, 0 stopped, 0 zombie Cpu(s): 0.1%us, 1.0%sy, 0.0%ni, 97.5%id, 1.1%wa, 0.0%hi, 0.3%si, 0.0%st Mem: 65560992k total, 58525192k used, 7035800k free, 365084k buffers Swap: 16777212k total, 0k used, 16777212k free, 33957572k cached PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 24145 traffics 20 0 21.7g 12g 6212 S 24.7 19.3 212:42.85 [ET_NET 0] 22173 root 20 0 677m 325m 1180 S 3.6 0.5 0:41.10 nginx 22161 root 20 0 677m 325m 1184 S 2.6 0.5 0:47.50 nginx 22168 root 20 0 677m 326m 2076 S 2.6 0.5 0:28.31 nginx 22150 root 20 0 677m 325m 1208 S 1.6 0.5 0:42.75 nginx 22165 root 20 0 677m 325m 1200 S 1.6 0.5 0:31.77 nginx
अद्यतन:
__do_page_fault पर कुछ जांच जोड़ने के बाद, महीने के कर्मचारी @ महीने की सलाह देते हैं, मुझे पता चला कि समय __do_page_fault -> डाउन_read () पर खर्च किया गया थामिमी-> mmap_sem);
[1495677639202]copy_to_user done:24145 [ACCEPT 0:8080] 1
[1495677639202] 16 16 move_addr_to_user done:24145 [ACCEPT 0:8080] 1
[1495677639314]copy_to_user done:24145 [ACCEPT 0:8080] 0
[1495677639314] 16 16 move_addr_to_user done:24145 [ACCEPT 0:8080] 0
[1495677641329]do page fault done:24145 [ACCEPT 0:8080] 622
[1495677641329]copy_to_user done:24145 [ACCEPT 0:8080] 622
[1495677641329] 16 16 move_addr_to_user done:24145 [ACCEPT 0:8080] 622
@ रिकार्डो बीहल पासक्वली आपकी सलाह के लिए धन्यवाद। अपाचे ट्रैफिकर्स अलग-अलग धागे में एचडीडी को पढ़/लिखते हैं। Trafficserver कनेक्शन को स्वीकार करने के लिए 1 धागा है, 88 (8 धागे प्रति एचडीडी) धागे को पढ़ने/लिखने (कैश सामग्री) को अवरुद्ध करने के लिए धागे, लेकिन मुझे समझ में नहीं आता कि अन्य धागे में पढ़ने/लिखने को अवरुद्ध करने से __do_page_fault() की उच्च विलंबता हो सकती है। ।
Device: rrqm/s wrqm/s r/s w/s rsec/s wsec/s avgrq-sz avgqu-sz await r_await w_await svctm %util
sda 0.00 16.00 0.00 4.00 0.00 160.00 40.00 0.05 13.50 0.00 13.50 7.75 3.10
sdi 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00
sde 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00
sdd 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00
sdj 0.00 0.00 6.00 0.00 4326.00 0.00 721.00 0.06 10.50 10.50 0.00 6.83 4.10
sdc 0.00 0.00 2.00 0.00 1472.00 0.00 736.00 0.04 18.50 18.50 0.00 9.50 1.90
sdh 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00
sdg 0.00 0.00 14.00 0.00 10464.00 0.00 747.43 0.04 2.71 2.71 0.00 1.79 2.50
अद्यतन:
समस्या हल! रूट कारण एक प्राचीन प्लगइन में बैकअप फ़ाइल में ट्रैफिकर्सवर समय-समय पर कॉल सिस्टम() है।
शायद समय अंतर कई संदर्भ स्विच का परिणाम है - या अवरुद्ध करने और लिखने के साथ एक उच्च थ्रूपुट। 'copy_to_user()' बहुत तेज़ है, मुझे लगता है कि सामान्य रूप से इसे पूरा करने के लिए माइक्रोसॉन्ड से कम लेता है। मुझे नहीं पता कि आप एक बग का सामना कर रहे हैं या नहीं। वैसे भी, आपको अपने लिनक्स कर्नेल को अद्यतित रखना चाहिए। –