Діагностика високого використання процесора на Docker для Mac

Як діагностувати причину Docker на MacOS, зокрема, com.docker.hyperkitвикористовуючи 100% ЦП?

Статистика Докера

Статистика Docker показує, що всі запущені контейнери мають низький процесор, пам'ять, чистий IO та блок IO.

iosnoop

iosnoop показує, що com.docker.hyperkitвиконує близько 50 записів в секунду, що становить 500 КБ в секунду до файлу Docker.qcow2. Відповідно до Що таке Docker.qcow2? , Docker.qcow2- це розріджений файл, який є стійким сховищем для всіх контейнерів Docker.

У моєму випадку файл не такий рідкий. Фізичний розмір відповідає логічному розміру.

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

Використання процесора на вбудованому хості докер становить ~ 3%. Використання процесора на моєму MacBook становило ~ 100%. Отже, вбудований хост докер не викликає сплеск використання процесора.

Оновлення: запуск сценаріїв 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. Там 1365 стежок слідів за 17 секунд, в яких 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 - докер / для-mac: com.docker.hyperkit 100% використання процесора знову повертається # 3499 . Один коментар пропонує додати кешування обсягу, описане тут: https://www.docker.com/blog/user-guided-caching-in-docker-for-mac/ . Я спробував це і отримав невелике ~ 10% зменшення використання процесора.

У мене така ж проблема. Мій відсотковий процесор повернувся до норми після того, як я видалив усі обсяги.

docker system prune --volumes

Я також вручну видалив кілька названих томів:

docker volume rm NameOfVolumeHere

Це не вирішує загальну проблему неможливості використання томів з Docker для mac. Зараз я просто пильную кількість обсягів, які використовую, і закриваю робочий стіл Docker, коли він не використовується.

Я підозрюю, що це питання пов'язане з IO. Що стосується томів MacOS, це включає osxfs, де ви можете виконати налаштування продуктивності. В основному, якщо ви можете прийняти менше перевірок узгодженості, ви можете встановити режим гучності delegatedдля швидшої роботи. Докладніше див. У документах: https://docs.docker.com/docker-for-mac/osxfs-caching/ . Однак якщо ваше зображення містить велику кількість невеликих файлів, продуктивність буде погіршена, особливо якщо у вас також багато шарів зображення.

Ви також можете спробувати наступну команду для налагодження будь-яких проблем з процесом у вбудованій VM, яку використовує докер:

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, що відбувається з будь-якого процесу, незалежно від того, чи є цей процес всередині контейнера. Статистика проводиться кожні 5 секунд протягом однієї хвилини (12 разів), і тоді вона дасть вам середню таблицю за процес. Потім <ctrl>-dможна знищити альпійський контейнер.

З коментарів та редагувань ці статистики можуть перевіритись. 4-ядерний MBP має 8 потоків, тому повне використання процесора має становити 800%, якщо MacOS повідомляє так само, як і інші системи на базі Unix. Всередині ВМ є понад 100% навантаження, показане в верхній команді в середньому за минулу хвилину (хоча менше від 5 і 15 середніх значень), що приблизно те, що ви бачите для процесу гіперкітів на хості. Миттєве використання перевищує 12% зверху, а не 3%, оскільки вам потрібно додати відсоток системи та користувачів. І цифри вводу-виводу, показані в pidstat, приблизно узгоджуються з тим, що ви бачите написаним на зображенні qcow2.

Якщо двигун докера сам поштовх (наприклад, перезапуск контейнерів або запущена велика кількість перевірок здоров’я), ви можете це налагодити, переглядаючи вихід:

docker events

Це невеликий сценарій dTrace, який я використовую, щоб знайти місце, де ядро ​​проводить свій час (це від Solaris, і датується першими днями Solaris 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 повинен зробити набагато більше роботи, щоб отримати їх з адресних просторів відповідних процесів.

Відключення захисту цілісності системи може допомогти вам отримати кращі сліди стека.

Детальнішу інформацію див. У розділі Основи дій DTrace .