Macos 诊断Mac Docker上的高CPU使用率

如何使用100%的CPU诊断MacOS上Docker的原因，特别是

com.Docker.hyperkit

Docker统计数据 Docker统计显示所有正在运行的容器都具有低CPU、内存、网络IO和块IO

伊斯努普 iosnoop显示，

com.docker.hyperkit

每秒对文件

docker.qcow2

执行大约50次写入，总计每秒500KB。根据，

Docker.qcow2

是一个稀疏文件，它是所有Docker容器的持久存储

在我的情况下，文件不是那么稀疏。物理大小与逻辑大小匹配

dtrace（dtruss） dtruss

sudo dtruss-p$DOCKER\u PID

显示大量的

psynch\u cvsignal

和

psynch\u 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

在Docker主机上 发件人：

docker嵌入式主机上的CPU使用率约为3%。我的MacBook上的CPU使用率约为100%。因此，docker嵌入式主机不会导致CPU使用量激增

更新：运行最常见堆栈跟踪的dtrace脚本 以下答案中的dtrace脚本的堆栈跟踪：

这些内核堆栈跟踪看起来是无害的

              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:。一条评论建议添加此处描述的卷缓存：。我尝试了这一点，CPU使用率降低了约10%。

这是一个小型dTrace脚本，我使用它来查找内核在哪里花费时间（它来自Solaris，可以追溯到Solaris 10的早期）：

它只是对内核堆栈跟踪进行采样，并统计它在

@hot

聚合中遇到的每个跟踪

以root用户身份运行它：

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

当您遇到CPU问题时，让它运行相当长的时间，然后点击

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必须做更多的工作才能从相应进程的地址空间中获取它们

可能会帮助您获得更好的堆栈跟踪

---

有关更多详细信息，请参阅。

我怀疑该问题与IO有关。对于MacOS卷，这涉及到osxfs，您可以在其中执行一些性能调整。主要是，如果可以接受较少的一致性检查，则可以将卷模式设置为

delegate

，以提高性能。有关更多详细信息，请参阅文档：。但是，如果图像包含大量小文件，性能将受到影响，尤其是如果图像层过多

您还可以尝试使用以下命令调试docker使用的嵌入式VM中的任何进程问题：

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

（要退出，请使用

-c

）

---

要查找是否为IO，还可以尝试以下操作：

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

它将在运行在VM-pid名称空间中的alpine容器内运行，显示来自任何进程的任何IO，无论该进程是否在容器内。统计数据是每5秒一分钟（12次），然后它将为您提供每个进程的平均表。然后您可以

-d

销毁alpine容器

---

从评论和编辑中，这些统计数据可以检查出来。4核MBP有8个线程，因此，如果MacOS报告的CPU利用率与其他基于Unix的系统相同，则CPU利用率应为800%。在虚拟机内部，top命令中显示了过去一分钟的平均负载超过100%（虽然比5和15的平均负载要少），这大致就是主机上hyperkit进程的负载。即时使用率比顶部高出12%，而不是3%，因为您需要添加系统和用户百分比。pidstat中显示的IO号与您看到的写入qcow2图像的大致一致

---

如果docker引擎本身正在颠簸（例如，重新启动容器，或运行大量运行状况检查），则您可以通过观察以下输出进行调试：

docker events

---

我也有同样的问题。删除所有卷后，我的CPU%恢复正常

docker system prune --volumes

我还手动删除了一些命名卷：

docker volume rm NameOfVolumeHere

---

这并不能解决Docker for mac无法使用卷的总体问题。现在，我只是在小心使用的卷数量，并在不使用时关闭Docker desktop。

将卷更改为使用委派配置对我来说很有效，导致CPU使用率大幅下降。 见文件：

如何在my docker-compose.yml中设置：

version: "3"
services: 
  my_service:
    image: python3.6
    ports:
      - "80:10000"
    volumes:
      - ./code:/www/code:cached

对我来说，macOS 10.15.5、Docker Desktop 2.3.0这一切都奏效了编辑：几周后，我的cpu问题又出现了——所以下面的解决方案可能不值得

我的CPU总是高得离谱，它不是I/O，这是由docker统计数据确定的

我做了很多事情，但在做了以下事情后，它突然下降到合理水平，并保持了一个多星期：

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

• 确保您拥有正确的CPU设置—不是您拥有的，而是该数量的一半。我的超过一半，我觉得这才是真正的问题，在

  Preferences|Resources

• 尽可能减少文件共享-

  首选项|资源

  ，/private，/tmp/，/var/文件夹
• 禁用

  使用gRPC FUSE进行文件共享

  -

  首选项|资源

---

就我的情况而言，我有一个MBP 2017，它是双核的，但是

version: "3"
services: 
  my_service:
    image: python3.6
    ports:
      - "80:10000"
    volumes:
      - ./code:/www/code:cached

So we'll look into that. However, 
osxfs will not be supported long term. 
We can't maintain two solutions.