मैक के लिए डॉकर पर उच्च CPU उपयोग का निदान

Question

मैं मैकओएस पर डॉकर के कारण का निदान कैसे करूं, विशेष रूप से com.docker.hyperkit100% सीपीयू का उपयोग करके?

डॉकटर आँकड़े

डॉकटर आँकड़े दिखाता है कि सभी चालू कंटेनरों में कम सीपीयू, मेमोरी, नेट आईओ और ब्लॉक आईओ हैं।

iosnoop

iosnoop दिखाता है कि com.docker.hyperkitफ़ाइल में प्रति सेकंड कुल 500KB प्रति सेकंड लगभग 50 लिखते हैं Docker.qcow2। Docker.qcow2 के अनुसार क्या है? , Docker.qcow2एक विरल फ़ाइल है जो सभी डॉकर कंटेनरों के लिए लगातार भंडारण है।

मेरे मामले में फ़ाइल वह विरल नहीं है। भौतिक आकार तार्किक आकार से मेल खाता है।

dtrace (dtruss)

dtruss sudo dtruss -p $DOCKER_PIDबड़ी संख्या में psynch_cvsignalऔर psynch_cvwaitकॉल दिखाता है ।

psynch_cvsignal(0x7F9946002408, 0x4EA701004EA70200, 0x4EA70100)          = 257 0
psynch_mutexdrop(0x7F9946002318, 0x5554700, 0x5554700)           = 0 0
psynch_mutexwait(0x7F9946002318, 0x5554702, 0x5554600)           = 89474819 0
psynch_cvsignal(0x10BF7B470, 0x4C8095004C809600, 0x4C809300)             = 257 0
psynch_cvwait(0x10BF7B470, 0x4C8095014C809600, 0x4C809300)               = 0 0
psynch_cvwait(0x10BF7B470, 0x4C8096014C809700, 0x4C809600)               = -1 Err#316
psynch_cvsignal(0x7F9946002408, 0x4EA702004EA70300, 0x4EA70200)          = 257 0
psynch_cvwait(0x7F9946002408, 0x4EA702014EA70300, 0x4EA70200)            = 0 0
psynch_cvsignal(0x10BF7B470, 0x4C8097004C809800, 0x4C809600)             = 257 0
psynch_cvwait(0x10BF7B470, 0x4C8097014C809800, 0x4C809600)               = 0 0
psynch_cvwait(0x10BF7B470, 0x4C8098014C809900, 0x4C809800)               = -1 Err#316

अपडेट: topडॉकर होस्ट पर

से https://stackoverflow.com/a/58293240/30900 :

docker run -it --rm --pid host busybox top

Docker एम्बेडेड होस्ट पर CPU उपयोग ~ 3% है। मेरे मैकबुक पर सीपीयू का उपयोग ~ 100% था। तो, होस्टेड होस्ट होस्ट CPU उपयोग स्पाइक का कारण नहीं बन रहा है।

अद्यतन: सबसे आम स्टैक निशान की dtrace स्क्रिप्ट चल रहा है

नीचे दिए गए उत्तर में dtrace स्क्रिप्ट से स्टैक का पता लगाएं: https://stackoverflow.com/a/58293035/30900 ।

ये कर्नेल स्टैक के निशान अहानिकर लगते हैं।

              AppleIntelLpssGspi`AppleIntelLpssGspi::regRead(unsigned int)+0x1f
              AppleIntelLpssGspi`AppleIntelLpssGspi::transferMmioDuplexMulti(void*, void*, unsigned long long, unsigned int)+0x91
              AppleIntelLpssSpiController`AppleIntelLpssSpiController::transferDataMmioDuplexMulti(void*, void*, unsigned int, unsigned int)+0xb2
              AppleIntelLpssSpiController`AppleIntelLpssSpiController::_transferDataSubr(AppleInfoLpssSpiControllerTransferDataRequest*)+0x5bc
              AppleIntelLpssSpiController`AppleIntelLpssSpiController::_transferData(AppleInfoLpssSpiControllerTransferDataRequest*)+0x24f
              kernel`IOCommandGate::runAction(int (*)(OSObject*, void*, void*, void*, void*), void*, void*, void*, void*)+0x138
              AppleIntelLpssSpiController`AppleIntelLpssSpiDevice::transferData(IOMemoryDescriptor*, void*, unsigned long long, unsigned long long, IOMemoryDescriptor*, void*, unsigned long long, unsigned long long, unsigned int, AppleIntelSPICompletion*)+0x151
              AppleHSSPISupport`AppleHSSPIController::transferData(IOMemoryDescriptor*, void*, unsigned long long, unsigned long long, IOMemoryDescriptor*, void*, unsigned long long, unsigned long long, unsigned int, AppleIntelSPICompletion*)+0xcc
              AppleHSSPISupport`AppleHSSPIController::doSPITransfer(bool, AppleHSSPITransferRetryReason*)+0x97
              AppleHSSPISupport`AppleHSSPIController::InterruptOccurred(IOInterruptEventSource*, int)+0xf8
              kernel`IOInterruptEventSource::checkForWork()+0x13c
              kernel`IOWorkLoop::runEventSources()+0x1e2
              kernel`IOWorkLoop::threadMain()+0x2c
              kernel`call_continuation+0x2e
               53

              kernel`waitq_wakeup64_thread+0xa7
              pthread`__psynch_cvsignal+0x495
              pthread`_psynch_cvsignal+0x28
              kernel`psynch_cvsignal+0x38
              kernel`unix_syscall64+0x27d
              kernel`hndl_unix_scall64+0x16
               60

              kernel`hndl_mdep_scall64+0x4
              113

              kernel`ml_set_interrupts_enabled+0x19
              524

              kernel`ml_set_interrupts_enabled+0x19
              kernel`hndl_mdep_scall64+0x10
             5890

              kernel`machine_idle+0x2f8
              kernel`call_continuation+0x2e
            43395

17 सेकंड से अधिक उपयोगकर्ता के अंतरिक्ष में सबसे आम स्टैक निशान com.docker.hyperkit को स्पष्ट रूप से जोड़ते हैं। 17 सेकंड में 1365 स्टैक के निशान मिले, जिसमें com.docker.hyperkitधागे बने जो औसतन 80 धागे प्रति सेकंड थे।

              com.docker.hyperkit`0x000000010cbd20db+0x19f9
              com.docker.hyperkit`0x000000010cbdb98c+0x157
              com.docker.hyperkit`0x000000010cbf6c2d+0x4bd
              libsystem_pthread.dylib`_pthread_body+0x7e
              libsystem_pthread.dylib`_pthread_start+0x42
              libsystem_pthread.dylib`thread_start+0xd
               19

              Hypervisor`hv_vmx_vcpu_read_vmcs+0x1
              com.docker.hyperkit`0x000000010cbd4c4f+0x2a
              com.docker.hyperkit`0x000000010cbd20db+0x174a
              com.docker.hyperkit`0x000000010cbdb98c+0x157
              com.docker.hyperkit`0x000000010cbf6c2d+0x4bd
              libsystem_pthread.dylib`_pthread_body+0x7e
              libsystem_pthread.dylib`_pthread_start+0x42
              libsystem_pthread.dylib`thread_start+0xd
               22

              Hypervisor`hv_vmx_vcpu_read_vmcs
              com.docker.hyperkit`0x000000010cbdb98c+0x157
              com.docker.hyperkit`0x000000010cbf6c2d+0x4bd
              libsystem_pthread.dylib`_pthread_body+0x7e
              libsystem_pthread.dylib`_pthread_start+0x42
              libsystem_pthread.dylib`thread_start+0xd
               34

              com.docker.hyperkit`0x000000010cbd878d+0x36
              com.docker.hyperkit`0x000000010cbd20db+0x42f
              com.docker.hyperkit`0x000000010cbdb98c+0x157
              com.docker.hyperkit`0x000000010cbf6c2d+0x4bd
              libsystem_pthread.dylib`_pthread_body+0x7e
              libsystem_pthread.dylib`_pthread_start+0x42
              libsystem_pthread.dylib`thread_start+0xd
               47

              Hypervisor`hv_vcpu_run+0xd
              com.docker.hyperkit`0x000000010cbd20db+0x6b6
              com.docker.hyperkit`0x000000010cbdb98c+0x157
              com.docker.hyperkit`0x000000010cbf6c2d+0x4bd
              libsystem_pthread.dylib`_pthread_body+0x7e
              libsystem_pthread.dylib`_pthread_start+0x42
              libsystem_pthread.dylib`thread_start+0xd
              135

संबंधित मुद्दों

Github - docker / for-mac: com.docker.hyperkit 100% सीपीयू का उपयोग फिर से # 3499 है । एक टिप्पणी में यहाँ वर्णित मात्रा कैशिंग जोड़ने का सुझाव दिया गया है: https://www.docker.com/blog/user-guided-caching-in-docker-for-mac/ । मैंने यह कोशिश की और CPU उपयोग में एक छोटी ~ 10% की कमी आई।

Comments

क्या आप चित्र बना रहे हैं? मैं बहुत सारे ब्लॉक IO का प्रदर्शन करने वाले कंटेनरों पर भी ध्यान केंद्रित करूँगा। यह भी मायने रखता है कि आपने कुबेरनेट को सक्षम किया है या नहीं।

— 1

मैंने क्लस्टर बनाने और कुछ मिनटों के लिए चलने के बाद सभी मैट्रिक्स एकत्र किए। कुबेरनेट्स अक्षम है। कोई भी मशीन बहुत सारे ब्लॉक आईओ का प्रदर्शन नहीं करती है। कंटेनर कुछ भी नहीं कर रहे हैं। मैंने देखा है कि सीपीयू उपयोग कंटेनर की संख्या से काफी हद तक संबंधित है।

— जो

मशीन पर आपके पास कितने कोर / सीपीयू हैं?

— BMitch

इसके अलावा, क्या आपने कंटेनर को नहीं, बल्कि पूरे इंजन और डेस्कटॉप क्लाइंट को पुनः आरंभ करने की कोशिश की है?

— बिच

मैं 4 कोर के साथ 2018 MBP 2.8 GHz Core i7 चला रहा हूं। मैंने डॉक इंजन के लिए सीपीयू कोर की संख्या को ट्विक करने की कोशिश की। मैंने 1, 3, 4 और 6 कोर की कोशिश की। डॉकटर को प्रतिबंधित करने से सीपीयू का उपयोग 100% से 60% तक कम हो गया।

— जो

Answer 1

मेरी भी यही समस्या है। मेरे सभी संस्करणों को हटाने के बाद मेरा सीपीयू% वापस सामान्य हो गया।

docker system prune --volumes

मैंने कुछ नामांकित संस्करणों को मैन्युअल रूप से हटा दिया है:

docker volume rm NameOfVolumeHere

यह मैक के लिए डॉकर के साथ संस्करणों का उपयोग करने में सक्षम नहीं होने के समग्र मुद्दे को हल नहीं करता है। अभी मैं केवल उन संस्करणों की मात्रा के बारे में सावधान हूं जो मैं उपयोग करता हूं और उपयोग में नहीं होने पर डॉकर डेस्कटॉप को बंद करता हूं।

Answer 2

मेरा संदेह यह है कि मुद्दा IO से संबंधित है। MacOS संस्करणों के साथ, इसमें ऑक्सफ़ेट्स शामिल हैं जहां कुछ प्रदर्शन ट्यूनिंग है जो आप प्रदर्शन कर सकते हैं। मुख्य रूप से, यदि आप कम स्थिरता जांच स्वीकार कर सकते हैं, तो आप delegatedतेज़ प्रदर्शन के लिए वॉल्यूम मोड सेट कर सकते हैं । अधिक विवरण के लिए डॉक्स देखें: https://docs.docker.com/docker-for-mac/osxfs-caching/ । हालांकि, यदि आपकी छवि में बड़ी संख्या में छोटी फाइलें हैं, तो प्रदर्शन में नुकसान होगा, खासकर यदि आपके पास बहुत सारी छवि परतें हैं।

आप निम्नलिखित कमांड को भी एम्बेडेड वीएम के भीतर किसी भी प्रक्रिया के मुद्दों को डिबग करने की कोशिश कर सकते हैं जो डॉकटर उपयोग करता है:

docker run -it --rm --pid host busybox top

(बाहर निकलने के लिए, उपयोग करें <ctrl>-c)

---

नीचे ट्रैक करने के लिए यदि यह IO है, तो आप निम्नलिखित को भी आज़मा सकते हैं:

$ docker run -it --rm --pid host alpine /bin/sh
$ apk add sysstat
$ pidstat -d 5 12

यह VM pid नाम स्थान पर चल रहे अल्पाइन कंटेनर के अंदर चलेगा, किसी भी प्रक्रिया से हो रहे IO को दिखाएगा कि यह प्रक्रिया कंटेनर के अंदर है या नहीं। आँकड़े एक मिनट (12 बार) के लिए हर 5 सेकंड हैं और फिर यह आपको प्रति प्रक्रिया एक औसत तालिका देगा। तब आप <ctrl>-dअल्पाइन कंटेनर को नष्ट कर सकते हैं ।

---

टिप्पणियों और संपादन से, ये आँकड़े देख सकते हैं। 4 कोर MBP में 8 थ्रेड होते हैं, इसलिए MacOS का पूर्ण उपयोग 800% होना चाहिए यदि MacOS अन्य यूनिक्स आधारित प्रणालियों के समान है। वीएम के अंदर पिछले मिनट में औसत (हालांकि 5 और 15 औसत से कम) के लिए शीर्ष कमांड में 100% से अधिक लोड दिखाया गया है, जो कि मेजबान पर हाइपरकिट प्रक्रिया के लिए मोटे तौर पर आप देखते हैं। तात्कालिक उपयोग 12% से अधिक है, 3% नहीं, क्योंकि आपको सिस्टम और उपयोगकर्ता प्रतिशत जोड़ने की आवश्यकता है। और pidstat में दिखाए गए IO नंबर मोटे तौर पर उस पंक्ति के साथ संरेखित होते हैं, जिसे आप qcow2 छवि में लिखा हुआ देखते हैं।

---

यदि डॉक इंजन स्वयं थ्रेशिंग कर रहा है (जैसे कंटेनरों को फिर से शुरू करना, या बहुत सारे हेल्थकेयर चलाना), तो आप इसका आउटपुट डीबग कर सकते हैं:

docker events

Comments

मैंने सभी वॉल्यूम माउंट को बदल दिया, delegatedलेकिन प्रदर्शन में कोई सुधार नहीं हुआ। मैंने topएम्बेडेड VM पर कमांड चलाई लेकिन CPU उपयोग लगभग ~ 3% होवर करता है।

— जो

pidstatबेहतर आईओ मुद्दों को ट्रैक करने के लिए अद्यतन किया गया ।

— बिच

pidstatसभी पीआईडी ​​के लिए शो रीड्स 0 केबी / एस हैं। लिखते हैं: logwriteऔसतन 8.5kB / s influxdलिखता है और औसतन 0.61kB / s लिखता है। बाकी प्रक्रियाएँ 0. हैं

— जो '

Answer 3

यह एक छोटी dTrace स्क्रिप्ट है जिसका उपयोग मैं यह जानने के लिए करता हूं कि कर्नेल अपना समय कहां बिता रहा है (यह सोलारिस से है, और सोलारिस 10 के शुरुआती दिनों में वापस आता है):

#!/usr/sbin/dtrace -s

profile:::profile-1001hz
/arg0/
{
    @[ stack() ] = count();
}

यह बस कर्नेल स्टैक के निशान का नमूना लेता है और हर एक को @hotएकत्र करता है जिसका वह एकत्रीकरण में सामना करता है ।

इसे रूट के रूप में चलाएं:

... # ./kernelhotspots.d > /tmp/kernel_hot_spots.txt

सीपीयू की समस्या होने पर इसे एक सभ्य समय तक चलने दें, फिर CTRL-Cस्क्रिप्ट को तोड़ने के लिए हिट करें। यह सभी कर्नेल स्टैक के निशान का उत्सर्जन करेगा, जो सबसे आम था। यदि आपको डिफ़ॉल्ट से अधिक (या कम) स्टैक फ़्रेम की आवश्यकता है

    @[ stack( 15 ) ] = count();

यह एक स्टैक फ्रेम 15 कॉल गहरी दिखाएगा।

अंतिम कुछ स्टैक निशान होंगे जहां आपका कर्नेल अपना अधिकांश समय बिता रहा है। यह जानकारीपूर्ण हो भी सकता है और नहीं भी।

यह स्क्रिप्ट उपयोगकर्ता-स्पेस स्टैक के निशान के लिए ही करेगी:

#!/usr/sbin/dtrace -s

profile:::profile-1001hz
/arg1/
{
    @[ ustack() ] = count();
}

इसे इसी तरह चलाएं:

... # ./userspacehotspots.d > /tmp/userspace_hot_spots.txt

ustack() थोड़ा धीमा है - वास्तविक फ़ंक्शन नामों का उत्सर्जन करने के लिए, डीट्रेस को उचित प्रक्रियाओं के पते के स्थानों से उन्हें प्राप्त करने के लिए बहुत अधिक काम करना होगा।

सिस्टम इंटीग्रिटी प्रोटेक्शन को डिसेबल करने से आपको स्टैक के बेहतर निशान पाने में मदद मिल सकती है।

देखें DTrace कार्रवाई मूल बातें कुछ और जानकारी के लिए।

Comments

धन्यवाद, मैंने स्क्रिप्ट के परिणामों के साथ प्रश्न को अपडेट किया। यूजर्सस्पेस स्टैक के निशान com.docker.hyperkit बहुत सारे धागे दिखाते हैं।

— जो