Mac için Docker'da yüksek CPU kullanımı tanılama

MacOS'ta Docker'ın nedenini, özellikle com.docker.hyperkitCPU'nun% 100'ünü kullanarak nasıl teşhis edebilirim ?

Docker istatistikleri

Docker istatistikleri, çalışan tüm kapsayıcıların düşük CPU, bellek, net IO ve blok IO'ya sahip olduğunu gösterir.

iosnoop

iosnoop, com.docker.hyperkitsaniyede yaklaşık 50 yazma gerçekleştirdiğini ve dosyada saniyede toplam 500 KB olduğunu gösterir Docker.qcow2. Göre Docker.qcow2 nedir? , Docker.qcow2tüm Docker kapsayıcıları için kalıcı depolama alanı olan seyrek bir dosyadır.

Benim durumumda dosya o kadar seyrek değil. Fiziksel boyut mantıksal boyutla eşleşir.

dtrace (dtruss)

dtruss sudo dtruss -p $DOCKER_PIDçok sayıda psynch_cvsignalve psynch_cvwaitçağrı gösterir.

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

Güncelleme: topDocker ana bilgisayarında

Gönderen https://stackoverflow.com/a/58293240/30900 :

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

Docker katıştırılmış ana bilgisayarda CPU kullanımı ~% 3'tür. MacBook'umda CPU kullanımı ~% 100 idi. Bu nedenle, docker katıştırılmış ana bilgisayarı CPU kullanım artışına neden olmaz.

Güncelleme: en yaygın yığın izlerinin dtrace komut dosyalarını çalıştırma

Aşağıdaki yanıtta dtrace komut dosyalarından izler yığını: https://stackoverflow.com/a/58293035/30900 .

Bu çekirdek yığını izleri zararsız görünüyor.

              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

Kullanıcı alanındaki 17 saniyenin üzerindeki en yaygın yığın izleri, com.docker.hyperkit'i açıkça gösterir. 17 saniyede 1365 yığın izi vardır, burada saniyede com.docker.hyperkit80 iş parçacığı ortalaması olan iş parçacıkları oluşturulur.

              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

İlgili konular

Github - docker / for-mac: com.docker.hyperkit% 100 işlemci kullanımı tekrar # 3499 . Bir yorum, burada açıklanan hacim önbelleği eklemeyi önerir: https://www.docker.com/blog/user-guided-caching-in-docker-for-mac/ . Bunu denedim ve CPU kullanımında ~% 10'luk küçük bir azalma aldım.

Aynı problemim var. Tüm hacimlerimi kaldırdıktan sonra% CPU'm normale döndü.

docker system prune --volumes

Ayrıca bazı adlandırılmış birimleri el ile kaldırdım:

docker volume rm NameOfVolumeHere

Bu, Mac için Docker ile birimleri kullanamamanın genel sorununu çözmez. Şu anda kullandığım birim miktarına dikkat ediyorum ve kullanılmadığında Docker masaüstünü kapatıyorum.

Şüphem, sorunun IO ile ilgili olmasıdır. MacOS birimlerinde, gerçekleştirebileceğiniz bazı performans ayarlarının bulunduğu osxfs içerir. Temel olarak, daha az tutarlılık denetimi kabul edebiliyorsanız delegated, daha hızlı performans için ses modunu olarak ayarlayabilirsiniz . Daha fazla ayrıntı için dokümanlara bakın: https://docs.docker.com/docker-for-mac/osxfs-caching/ . Ancak, görüntünüzde çok sayıda küçük dosya varsa, özellikle de çok sayıda görüntü katmanınız varsa performans düşecektir.

Ayrıca, docker'ın kullandığı katıştırılmış VM'deki işlem sorunlarında hata ayıklamak için aşağıdaki komutu deneyebilirsiniz:

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

(Çıkmak için kullanın <ctrl>-c)

IO olup olmadığını izlemek için aşağıdakileri de deneyebilirsiniz:

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

Bu, VM pid ad alanında çalışan alp kabının içinde çalışacak ve bu işlem bir kabın içinde olsun ya da olmasın, herhangi bir işlemden kaynaklanan GÇ'leri gösterecektir. İstatistikler her 5 saniyede bir dakika (12 kez) ve daha sonra işlem başına ortalama bir tablo verecektir. Daha sonra <ctrl>-dAlp kabını yok edebilirsiniz .

Yorumlar ve düzenlemelerden bu istatistikler kontrol edilebilir. 4 çekirdekli bir MBP'de 8 iş parçacığı vardır, bu nedenle MacOS diğer Unix tabanlı sistemlerle aynı durumu bildiriyorsa tam CPU kullanımı% 800 olmalıdır. VM içinde, ana bilgisayarda hiperkit işlemi için gördüğünüz kabaca gördüğünüz gibi, son dakikada ortalama için üst komutta gösterilen% 100'ün üzerinde yük var (5 ve 15 ortalamalardan daha az olsa da). Sistem ve kullanıcı yüzdelerini eklemeniz gerektiğinden, anlık kullanım% 3 değil, üstten% 12'nin üzerindedir. Ve pidstat'ta gösterilen IO numaraları kabaca qcow2 görüntüsüne yazdıklarınızı gösterir.

Liman işçisi motorun kendisi çökerse (örn. Kapları yeniden başlatmak veya çok sayıda sağlık denetimi çalıştırıyorsa), çıktısını izleyerek hata ayıklayabilirsiniz:

docker events

Bu, çekirdeğin zamanını nerede harcadığını bulmak için kullandığım küçük bir dTrace betiğidir (Solaris'ten gelir ve Solaris 10'un ilk günlerine kadar uzanır):

#!/usr/sbin/dtrace -s

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

Sadece çekirdek yığını izlerini örnekler ve @hottoplamada karşılaştığı her birini sayar .

Kök olarak çalıştırın:

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

CPU sorunları yaşarken iyi bir süre çalışmasına izin verin, ardından CTRL-Ckomut dosyasını kırmak için vurun. Karşılaştığı tüm çekirdek yığını izlerini, en yaygın olanı yayar. Varsayılan ile daha fazla (veya daha az) yığın kareye ihtiyacınız varsa

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

Bu, bir yığın çerçevesinin 15 derin çağırdığını gösterecektir.

Son birkaç yığın izi, çekirdeğinizin zamanının çoğunu geçirdiği yerdir. Bu bilgilendirici olabilir veya olmayabilir.

Bu komut dosyası, kullanıcı alanı yığın izleri için de aynısını yapar:

#!/usr/sbin/dtrace -s

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

Benzer şekilde çalıştırın:

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

ustack() biraz daha yavaştır - gerçek işlev adlarını yayınlamak için, dTrace bunları uygun işlemlerin adres alanlarından almak için çok daha fazla iş yapmak zorundadır.

Sistem Bütünlüğü Korumasını devre dışı bırakmak daha iyi yığın izleri elde etmenize yardımcı olabilir.

Daha fazla ayrıntı için DTrace Eylem Temelleri bölümüne bakın .