Chẩn đoán sử dụng CPU cao trên Docker cho Mac

Làm cách nào để chẩn đoán nguyên nhân của Docker trên MacOS, cụ thể là com.docker.hyperkitsử dụng 100% CPU?

Thống kê Docker

Thống kê Docker cho thấy tất cả các container đang chạy có CPU, bộ nhớ, IO mạng thấp và IO khối.

iosnoop

iosnoop cho thấy com.docker.hyperkitthực hiện khoảng 50 lần ghi mỗi giây với tổng số 500KB mỗi giây vào tệp Docker.qcow2. Theo Docker.qcow2 là gì? , Docker.qcow2là một tệp thưa thớt lưu trữ liên tục cho tất cả các container Docker.

Trong trường hợp của tôi, tập tin không phải là thưa thớt. Kích thước vật lý phù hợp với kích thước hợp lý.

dtrace (dtruss)

dtruss sudo dtruss -p $DOCKER_PIDcho thấy một số lượng lớn psynch_cvsignalvà psynch_cvwaitcác cuộc gọi.

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

Cập nhật: toptrên máy chủ Docker

Từ https://stackoverflow.com/a/58293240/30900 :

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

Việc sử dụng CPU trên máy chủ nhúng docker là ~ 3%. Sử dụng CPU trên MacBook của tôi là ~ 100%. Vì vậy, máy chủ nhúng docker không gây ra việc sử dụng CPU tăng đột biến.

Cập nhật: chạy tập lệnh dtrace của hầu hết các dấu vết ngăn xếp phổ biến

Ngăn xếp dấu vết từ các tập lệnh dtrace trong câu trả lời dưới đây: https://stackoverflow.com/a/58293035/30900 .

Những dấu vết ngăn xếp hạt nhân trông vô hại.

              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

Các dấu vết ngăn xếp phổ biến nhất trong không gian người dùng trong hơn 17 giây ngụ ý rõ ràng com.docker.hyperkit. Có 1365 dấu vết ngăn xếp trong 17 giây, trong đó com.docker.hyperkittạo ra các luồng trung bình tới 80 luồng mỗi giây.

              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

Các vấn đề liên quan

Github - docker / for-mac: com.docker.hyperkit Việc sử dụng cpu 100% đã trở lại # 3499 . Một nhận xét đề nghị thêm bộ nhớ đệm âm lượng được mô tả ở đây: https://www.docker.com/blog/user-guided-caching-in-docker-for-mac/ . Tôi đã thử điều này và đã giảm ~ 10% mức sử dụng CPU.

Tôi có cùng một vấn đề. % CPU của tôi đã trở lại bình thường sau khi tôi loại bỏ tất cả các ổ đĩa của mình.

docker system prune --volumes

Tôi cũng tự xóa một số tập có tên:

docker volume rm NameOfVolumeHere

Điều đó không giải quyết được vấn đề chung là không thể sử dụng âm lượng với Docker cho mac. Ngay bây giờ tôi chỉ cẩn thận về số lượng tôi sử dụng và đóng máy tính để bàn Docker khi không sử dụng.

Sự nghi ngờ của tôi là vấn đề có liên quan đến IO. Với khối lượng MacOS, điều này liên quan đến osxfs nơi có một số điều chỉnh hiệu suất bạn có thể thực hiện. Chủ yếu, nếu bạn có thể chấp nhận kiểm tra tính nhất quán ít hơn, bạn có thể đặt chế độ âm lượng để có delegatedhiệu suất nhanh hơn. Xem tài liệu để biết thêm chi tiết: https://docs.docker.com/docker-for-mac/osxfs-caching/ . Tuy nhiên, nếu hình ảnh của bạn chứa một số lượng lớn các tệp nhỏ, hiệu suất sẽ bị ảnh hưởng, đặc biệt là nếu bạn cũng có nhiều lớp hình ảnh.

Bạn cũng có thể thử lệnh sau để gỡ lỗi mọi sự cố quy trình trong VM được nhúng mà docker sử dụng:

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

(Để thoát, sử dụng <ctrl>-c)

Để theo dõi nếu đó là IO, bạn cũng có thể thử các cách sau:

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

Điều đó sẽ chạy bên trong thùng chứa alpine chạy trong không gian tên VM pid, hiển thị bất kỳ IO nào xảy ra từ bất kỳ quy trình nào, cho dù quá trình đó có ở trong một container hay không. Các số liệu thống kê cứ sau 5 giây trong một phút (12 lần) và sau đó nó sẽ cung cấp cho bạn một bảng trung bình cho mỗi quy trình. Sau đó bạn có thể <ctrl>-dphá hủy thùng chứa núi cao.

Từ các bình luận và chỉnh sửa, các số liệu thống kê có thể kiểm tra. Một MBP 4 lõi có 8 luồng, vì vậy mức sử dụng CPU đầy đủ phải là 800% nếu MacOS báo cáo giống như các hệ thống dựa trên Unix khác. Bên trong VM có tải hơn 100% được hiển thị trong lệnh cao nhất cho mức trung bình trong phút vừa qua (mặc dù ít hơn so với mức trung bình 5 và 15), gần như là những gì bạn thấy đối với quy trình hyperkit trên máy chủ. Việc sử dụng tức thời là hơn 12% từ đầu, không phải 3%, vì bạn cần thêm tỷ lệ phần trăm của hệ thống và người dùng. Và các số IO được hiển thị trong pidstat phù hợp với những gì bạn thấy được ghi vào hình ảnh qcow2.

Nếu chính động cơ docker đang đập (ví dụ: khởi động lại container hoặc chạy nhiều kiểm tra sức khỏe), thì bạn có thể gỡ lỗi bằng cách xem đầu ra của:

docker events

Đây là một tập lệnh dTrace nhỏ mà tôi sử dụng để tìm nơi nhân sử dụng thời gian của nó (nó đến từ Solaris và xuất hiện từ những ngày đầu của Solaris 10):

#!/usr/sbin/dtrace -s

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

Nó chỉ đơn giản là lấy mẫu dấu vết ngăn xếp hạt nhân và đếm từng cái mà nó gặp trong @hottập hợp.

Chạy nó dưới quyền root:

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

Hãy để nó chạy trong một khoảng thời gian kha khá trong khi bạn gặp vấn đề về CPU, sau đó nhấn CTRL-Cđể phá vỡ tập lệnh. Nó sẽ phát ra tất cả các dấu vết ngăn xếp kernel mà nó gặp phải, phổ biến nhất cuối cùng. Nếu bạn cần nhiều hơn (hoặc ít hơn) các khung xếp chồng từ mặc định với

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

Điều đó sẽ hiển thị một khung stack 15 cuộc gọi sâu.

Một vài dấu vết ngăn xếp cuối cùng sẽ là nơi kernel của bạn dành phần lớn thời gian. Điều đó có thể hoặc không thể là thông tin.

Kịch bản lệnh này sẽ làm tương tự đối với dấu vết ngăn xếp không gian người dùng:

#!/usr/sbin/dtrace -s

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

Chạy nó tương tự:

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

ustack() chậm hơn một chút - để phát ra tên hàm thực tế, dTrace phải thực hiện nhiều công việc khác để lấy chúng từ không gian địa chỉ của các quy trình thích hợp.

Vô hiệu hóa Bảo vệ toàn vẹn hệ thống có thể giúp bạn có được dấu vết ngăn xếp tốt hơn.

Xem thông tin cơ bản về hành động của DTrace để biết thêm chi tiết.