Cpu idle time что это

Значительный CPU idle time при высоком LA

Load average 75-100, при этом local io практически отсутствует, и никто не застрял в uninterruptible sleep, при всем при этом довольно значительный idle time в vmstat.

Проверим, что количество runnable потоков примерно соответствует load average:

$ ps Hh -eo stat,pid,command |egrep '^R' |wc -l 109 

В разные моменты выдает разные значения понятное дело, но всегда в интервале 60-120

вывод mpstat -P ALL 1 (поймал момент, когда idle минимальный, обычно 10-13):

12:20:23 CPU %usr %nice %sys %iowait %irq %soft %steal %guest %idle 12:20:24 all 89.38 0.00 2.12 0.00 0.95 0.00 0.00 0.00 7.55 12:20:24 0 78.79 0.00 4.04 0.00 10.10 0.00 0.00 0.00 7.07 12:20:24 1 98.99 0.00 0.00 0.00 0.00 0.00 0.00 0.00 1.01 12:20:24 2 88.12 0.00 1.98 0.00 0.99 0.00 0.00 0.00 8.91 12:20:24 3 94.00 0.00 2.00 0.00 0.00 0.00 0.00 0.00 4.00 12:20:24 4 89.90 0.00 1.01 0.00 0.00 0.00 0.00 0.00 9.09 12:20:24 5 91.09 0.00 3.96 0.00 0.99 0.00 0.00 0.00 3.96 12:20:24 6 99.01 0.00 0.99 0.00 0.00 0.00 0.00 0.00 0.00 12:20:24 7 97.03 0.00 0.99 0.00 0.00 0.00 0.00 0.00 1.98 12:20:24 8 98.02 0.00 0.99 0.00 0.99 0.00 0.00 0.00 0.00 12:20:24 9 97.03 0.00 0.99 0.00 0.00 0.00 0.00 0.00 1.98 12:20:24 10 90.00 0.00 1.00 0.00 0.00 0.00 0.00 0.00 9.00 12:20:24 11 94.00 0.00 3.00 0.00 0.00 0.00 0.00 0.00 3.00 12:20:24 12 86.00 0.00 2.00 0.00 0.00 0.00 0.00 0.00 12.00 12:20:24 13 97.00 0.00 1.00 0.00 0.00 0.00 0.00 0.00 2.00 12:20:24 14 100.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 12:20:24 15 95.96 0.00 1.01 0.00 0.00 0.00 0.00 0.00 3.03 12:20:24 16 98.00 0.00 2.00 0.00 0.00 0.00 0.00 0.00 0.00 12:20:24 17 91.92 0.00 5.05 0.00 0.00 0.00 0.00 0.00 3.03 12:20:24 18 94.00 0.00 1.00 0.00 0.00 0.00 0.00 0.00 5.00 12:20:24 19 97.00 0.00 2.00 0.00 0.00 0.00 0.00 0.00 1.00 12:20:24 20 83.00 0.00 3.00 0.00 10.00 0.00 0.00 0.00 4.00 12:20:24 21 82.83 0.00 4.04 0.00 7.07 0.00 0.00 0.00 6.06 12:20:24 22 98.99 0.00 0.00 0.00 0.00 0.00 0.00 0.00 1.01 12:20:24 23 88.00 0.00 2.00 0.00 9.00 0.00 0.00 0.00 1.00 12:20:24 24 94.00 0.00 4.00 0.00 0.00 0.00 0.00 0.00 2.00 12:20:24 25 77.23 0.00 2.97 0.00 0.00 0.00 0.00 0.00 19.80 12:20:24 26 77.23 0.00 3.96 0.00 0.00 0.00 0.00 0.00 18.81 12:20:24 27 63.00 0.00 1.00 0.00 0.00 0.00 0.00 0.00 36.00 12:20:24 28 91.92 0.00 1.01 0.00 0.00 0.00 0.00 0.00 7.07 12:20:24 29 83.00 0.00 2.00 0.00 0.00 0.00 0.00 0.00 15.00 12:20:24 30 84.85 0.00 1.01 0.00 0.00 0.00 0.00 0.00 14.14 12:20:24 31 95.00 0.00 3.00 0.00 0.00 0.00 0.00 0.00 2.00 12:20:24 32 88.00 0.00 3.00 0.00 0.00 0.00 0.00 0.00 9.00 12:20:24 33 97.98 0.00 2.02 0.00 0.00 0.00 0.00 0.00 0.00 12:20:24 34 76.00 0.00 2.00 0.00 0.00 0.00 0.00 0.00 22.00 12:20:24 35 83.17 0.00 2.97 0.00 0.00 0.00 0.00 0.00 13.86 12:20:24 36 73.00 0.00 3.00 0.00 1.00 0.00 0.00 0.00 23.00 12:20:24 37 86.00 0.00 5.00 0.00 0.00 0.00 0.00 0.00 9.00 12:20:24 38 83.00 0.00 1.00 0.00 0.00 0.00 0.00 0.00 16.00 12:20:24 39 92.00 0.00 4.00 0.00 0.00 0.00 0.00 0.00 4.0 

что это может быть? грешу на scheduler, но непонятно как его крутить, чтобы он успевал занимать CPU под задачи. Не очень приято терять 10% CPU на задаче, которая как раз очень жадная до этого CPU.

Метрика загруженности процессора (CPU utiliztion) — это не то что вы думаете

Всем привет. Предлагаю вашему вниманию свой перевод поста “CPU Utilization is Wrong” из блога Брендана Грегга. Метрика загруженности процессора (CPU utiliztion), которую все мы привыкли использовать, обычно понимается неправильно. Что такое загруженность процессора? То насколько процессор сейчас занят работой? Нет, это не так, и да, я говорю о метрике %CPU , которая используется всегда и везде, в каждой утилите мониторинга производительности, например в top(1) . Как вы думаете, что значит нагрузка на процессор 90% на картинке ниже? Вот что это значит на самом деле: Stalled, то есть “приостановлено” значит, что в данный момент процессор не обрабатывает инструкции, обычно это означает, что он ожидает завершения операций ввода/вывода связанных с памятью (здесь и далее речь о RAM, а не дисковом вводе/выводе). Соотношение между “занято” и “приостановлено” (busy/stalled), которое я привел выше, это то что я обычно вижу в продакшене. Вероятно, что ваш процессор тоже большую часть времени находится в stalled состоянии, но вы об этом и не догадываетесь. Что это значит для вас? Понимание того насколько много ваш процессор находится в приостановленном состоянии может помочь вам понять куда направить усилия по оптимизации производительности приложения: на ускорение кода или уменьшение числа операций ввода/вывода связанных с памятью. Всем кто заинтересован в оптимизации нагрузки на процессор, в особенности в облаках с настроенным автомасштабированием на основе нагрузки на CPU, будет полезно знать насколько долго процессор находится в приостановленном состоянии.

Что такое нагрузка на процессор на самом деле?

Метрика, которую мы называем нагрузкой на процессор (CPU utilization) на самом деле это “не-idle время”, то есть время, которое процессор не выполняет idle-тред. Ядро вашей операционной системы (какую бы ОС вы не использовали) обычно следит за этим во время переключения контекста. Если не-idle тред запустился, а затем спустя 100 милисекунд остановился, то ядро посчитает, что процессор был использован в течение всего этого времени. Эта метрика так же стара как и системы совместного использования времени (time sharing systems). В бортовом компьютере лунного модуля Apollo (это пионер среди систем совместного использования времени) idle-тред назывался “DUMMY JOB” и инженеры мониторили циклы выполняющие его в сравнении с реальными задачами, это было важной метрикой измерения нагрузки. (Я писал об этом ранее). Что же с этой метрикой не так? В наши дни процессоры работают значительно быстрее памяти, поэтому время ожидания памяти доминирует в метрике “нагрузка на процессор”. Когда вы видите большие значение %CPU в top(1) , вы, должно быть, думаете, что процессор является бутылочным горлышком, когда на самом деле проблема в DRAM. Со временем все становится только хуже. Долгое время производители процессоров увеличивали тактовые частоты своих процессоров быстрее чем производители памяти уменьшали задержки доступа к памяти (CPU DRAM gap). Примерно в 2005 году процессоры достигли частот в 3 GHz и с тех пор мощность процессоров растет не за счет увеличения тактовой частоты, а за счет большего числа ядер, гипертрединга и многопроцессорных конфигураций. Все это предъявляет еще больше требований к памяти. Производители процессоров пытались снизить задержки связанные с памятью за счет больших по размеру и более умных CPU-кешей, более быстрых шин и соединений. Но проблема со stalled-состоянием все еще не решена.

Как понять, что процессор на самом деле делает

Сделать это можно используя Performance Monitoring Counters (PMC-счетчики): хардверные счетчики, которые могут быть прочитаны с помощью Linux pref (пакет linux-tools-generic в Линуксе) и других утилит. Для примера понаблюдаем за всей системой в течение 10 секунд:

# perf stat -a -- sleep 10 Performance counter stats for 'system wide': 641398.723351 task-clock (msec) # 64.116 CPUs utilized (100.00%) 379,651 context-switches # 0.592 K/sec (100.00%) 51,546 cpu-migrations # 0.080 K/sec (100.00%) 13,423,039 page-faults # 0.021 M/sec 1,433,972,173,374 cycles # 2.236 GHz (75.02%) stalled-cycles-frontend stalled-cycles-backend 1,118,336,816,068 instructions # 0.78 insns per cycle (75.01%) 249,644,142,804 branches # 389.218 M/sec (75.01%) 7,791,449,769 branch-misses # 3.12% of all branches (75.01%) 10.003794539 seconds time elapsed 

Ключевая метрика здесь instructions per cycle (insns per cycle: IPC, число инструкций за один цикл), которая показывает сколько в среднем инструкций было выполнено за каждый такт. Чем больше, тем лучше. В примере выше значение 0.78 кажется очень неплохим (нагрузка 78%?) до тех пор пока вы не узнаете, что максимальная скорость процессора это IPC 4.0. Такие процессоры называют 4-wide, это название пошло от особенностей пути извлечения/декодирования инструкций в процессоре (подробнее об этом в Википедии). Это означает, что процессор может выполнить 4 операции за каждый такт, поэтому значение 0.78 для 4-wide системы означает, что процессор работает на 19,5% от своих возможностей. Новый процессор Skylake от Intel — это 5-wide процессор. Существуют сотни PMC-счетчиков, которые позволяют детальнее разобраться с производительностью системы, например, посчитать число приостановленных циклов по типам.

В облаках

Если вы работаете в виртуальном окружении, то вероятно у вас нет доступа к PMC-счетчикам, это зависит от поддержки этой фичи гипервизором. Я недавно писал о том, что PMC-счетчики теперь доступны в AWS EC2 в виртуальных машинах базирующихся на Xen.

Как интерпретировать и что делать

Если ваш IPC < 1.0 , то вероятнее всего, процессор приостановлен из-за медленной памяти, поэтому нужно оптимизировать софт так, чтобы он требовал меньше операций с памятью, совершенствовать кеширование в процессоре и локальность памяти, особенно в NUMA системах. Оптимизация железа в таком случае подразумевает использование процессоров с большим объемом кешей, более быстрой памятью, шинами и соединениями. Если ваш IPC > 1.0 , то вероятно, вы ограничены числом инструкций, которые может выполнять процессор. Попробуйте найти способ уменьшить число выполняемых инструкций: уменьшить число ненужной работы, кешировать операции и т.п. CPU flame графы — отличная утилита для этих целей. С точки зрения тюнинга железа, попробуйте использовать процессор с большей тактовой частотой и большим числом ядер и гипертредов. Для моих правил выше я выбрал значение IPC 1.0, почему именно его? Я пришел к нему из своего опыта работы с PMC-счетчиками. Вы можете выбрать для себя другое значение. Сделайте два тестовых приложения, одно упирающееся по производительности в процессор, другое — в память. Посчитайте IPC для них и возьмите среднее значение.

Что инструменты мониторинга производительности должны сообщать вам?

Каждая такая утилита должны показывать IPC вместе с нагрузкой на процессор. Или разделять нагрузку на процессор на instruction-retired и циклы stalled циклы, то есть, %INS и %STL . Кроме утилиты top(1) для Линукса есть утилита tiptop(1) , которая показывает IPC для каждого процесса:

tiptop - [root] Tasks: 96 total, 3 displayed screen 0: default PID [ %CPU] %SYS P Mcycle Minstr IPC %MISS %BMIS %BUS COMMAND 3897 35.3 28.5 4 274.06 178.23 0.65 0.06 0.00 0.0 java 1319+ 5.5 2.6 6 87.32 125.55 1.44 0.34 0.26 0.0 nm-applet 900 0.9 0.0 6 25.91 55.55 2.14 0.12 0.21 0.0 dbus-daemo 

Другие причины почему CPU utilization вводит в заблуждение

• изменение температуры может влиять на приостановленность процессора,
• турбобуст может менять тактовую частоту процессора,
• ядро варьирует частоту процессора с определенным шагом,
• проблема с усреднением: 80% нагрузки в течение минуты скроет кратковременный всплеск до 100%,
• спинлоки: процессор нагружен, имеет высокий IPC, но приложение ничего не делает.

Заключение

Нагрузка на процессор (CPU utilization) это обычно неправильно интерпретируемая метрика, так как она включает циклы, потраченные на ожидание ответа от основной памяти, которые могут доминировать в современных нагрузках. Вы можете понять что на самом деле стоит за %CPU используя дополнительные метрики, включая число инструкций за цикл (IPC). Если IPC < 1.0 , то вероятно вы упираетесь в память, если IPC >1.0 , то в скорость процессора. Я писал про IPC в своем предыдущем посте, в том числе написал и о использовании PMC-счетчиках, необходимых для измерения IPC.

Инструменты мониторинга производительности, которые показывают %CPU должны показывать PMC-счетчики, чтобы не вводить пользователей в заблуждение. Например, они могут показывать %CPU с IPC и/или число instruction-retired и stalled циклов. Вооруженные этими метриками разработчики и админы могут решить как правильнее тюнинговать их приложения и системы.

System Idle Process

Бездействие системы (System Idle Process) — процесс ядра операционной системы семейства Windows, представляющий собой отдельный поток (или несколько потоков на многоядерных системах), работающий тогда, когда процессор не выполняет других потоков. Например, в системе может не быть работающих потоков, либо все они могут выполнятся на другом процессоре.

Бездействие системы используется Windows для понижения энергопотребления процессора. Конкретная схема пониженного энергопотребления определяется аппаратным обеспечением и возможностями микропрограммы системы. Например, на доисторических x86 процессорах, этот процесс будет выполнять в цикле инструкцию HLT, которая указывает процессору отключить некоторые внутренние компоненты и ждать аппаратного прерывания. На процессорах с поддержкой пониженного энергопотребления этот процесс переключит процессор в более экономный режим, например при помощи Intel Speedstep.

См. также

Aero • ClearType • Desktop Window Manager • DirectX • Проводник (Explorer) • Панель задач («Пуск» • трей) • Shell (namespace • Special Folders • File associations) • Search (Saved search • iFilters) • Graphics Device Interface • WIM • Next Generation TCP/IP stack (Server Message Block) • .NET Framework • Audio • Printing (XML Paper Specification) • Active Scripting (WSH • VBScript • JScript) • COM (OLE • OLE Automation • DCOM • ActiveX • ActiveX Document • Structured storage • Transaction Server) • Previous Versions • WDDM • UAA • Win32 console

Backup and Restore Center • COMMAND.COM • cmd.exe • Easy Transfer • Event Viewer • Installer • Netsh • PowerShell • Problem Reports and Solutions • Sysprep • Настройка системы (msconfig) • System File Checker • WinSAT • Windows Update • Восстановление системы • Дефрагментация диска • Диспетчер задач • Диспетчер устройств • Консоль управления • Очистка диска • Панель управления (функции)

Актуальные: Contacts • DVD Maker • Fax and Scan • Internet Explorer • Journal • Magnifier • Media Center • Media Player • Meeting Space • Mobile Device Center • Mobility Center • Narrator • Paint • Private Character Editor • Remote Assistance • Speech Recognition • WordPad • Блокнот • Боковая панель • Звукозапись • Календарь • Калькулятор • Ножницы • Почта • Таблица символов

Chess Titans • Hold ‘Em • InkBall • Mahjong Titans • Purble Place • Пасьянс «Косынка» • Пасьянс «Паук» • Сапёр • Пасьянс «Свободная ячейка» • Пинбол • Червы

Ntoskrnl.exe • hal.dll • System Idle Process • Svchost.exe • Registry (реестр) • Windows service • Service Control Manager • DLL • EXE • NTLDR • Boot Manager • Winlogon • Recovery Console • I/O • WinRE • WinPE • Kernel Patch Protection

Autorun • BITS • CLFS Error Reporting • Multimedia Class Scheduler • Shadow Copy • Task Scheduler • Wireless Zero Configuration •

Active Directory • Deployment Services • DFS Replication • DNS • Domains • Folder redirection • Hyper-V • IIS • Media Services • MSMQ • Network Access Protection • Print Services for UNIX • Remote Differential Compression • Remote Installation Services • Rights Management Services • Roaming user profiles • SharePoint Services • System Resource Manager • Terminal Services • WSUS • Групповая политика • Координатор распределённых транзакций

Обзор • Object Manager • I/O request packets • Kernel Transaction Manager • Logical Disk Manager • Security Accounts Manager • Windows Resource Protection • LSASS • CSRSS • SMSS • Диспетчер печати • Запуск (Vista)

Unix subsystem (Interix) • Virtual DOS Machine • Windows on Windows • WOW64

Wikimedia Foundation . 2010 .

Полезное

Смотреть что такое «System Idle Process» в других словарях:

• System Idle Process — Infobox Windows component name = System Idle Process type = Kernel included with = Windows NTIn Windows NT operating systems, the System Idle Process is a kernel thread which runs when no other runnable thread can be scheduled on a CPU. For… … Wikipedia
• Idle (CPU) — A computer processor is described as idle when it is not being used by any program.Programs which make use of CPU Idle Time mean that they run at a low priority so as not to impact programs which run at normal priority. Many programs that use CPU … Wikipedia
• System Restore — Окно восстановления системы в Windows XP‎ Восстановление системы (англ. System restore) компонент операционной системы Windows (процесс rstrui.exe), предназначенный для восстановления работоспособности ОС путем отката (восстановления предыдущего… … Википедия
• System tray — Область уведомлений в Windows NT Область уведомлений (англ. notification area) или системный трей (англ. system tray, от англ. tray «поднос, поддон») элемент панели инструментов среды рабочего стола («панель задач» в Windows), используемый для… … Википедия
• Windows NT startup process — The Windows NT startup process is the process by which Windows NT 4.0, Windows 2000, Windows XP and Windows Server 2003 operating systems initialize. In Windows Vista and later, this process has changed slightly; see Windows Vista startup process … Wikipedia
• System Architecture Evolution — (aka SAE) is the core network architecture of 3GPP s LTE wireless communication standard. SAE is the evolution of the GPRS Core Network, with some differences: simplified architecture all IP Network (AIPN) support for higher throughput and lower… … Wikipedia
• Encrypting File System — The Encrypting File System (EFS) on Microsoft Windows is a feature introduced in version 3.0 of NTFS[1] that provides filesystem level encryption. The technology enables files to be transparently encrypted to protect confidential data from… … Wikipedia
• Windows Logon Process — Winlogon компонент операционной системы Microsoft Windows, отвечающий за вход в систему. и т.д. Содержание 1 Краткий обзор 2 Критичность процесса Winlogon 3 Функции Winlogon … Википедия
• Common Log File System — (CLFS) is a general purpose logging subsystem that is accessible to both kernel mode as well as user mode applications for building high performance transaction logs. It was introduced with Windows Server 2003 R2 and included in later Windows OSs … Wikipedia
• Distributed File System (Microsoft) — This article is about Microsoft s implementation of DFS. For general discussion of the concept and other implementations, see Distributed file system. Distributed File System (DFS) is a set of client and server services that allow an organization … Wikipedia

• Обратная связь: Техподдержка, Реклама на сайте

• �� Путешествия

Экспорт словарей на сайты, сделанные на PHP,
WordPress, MODx.

• Пометить текст и поделитьсяИскать в этом же словареИскать синонимы
• Искать во всех словарях
• Искать в переводах
• Искать в ИнтернетеИскать в этой же категории

Вы неверно измеряете загрузку процессора

Та метрика, которую мы называем «загрузкой процессора» на самом деле многими людьми понимается не совсем верно. Что же такое «загрузка процессора»? Это то, насколько занят наш процессор? Нет, это не так. Да-да, я говорю о той самой классической загрузке CPU, которую показывают все утилиты анализа производительности — от диспетчера задач Windows до команды top в Linux.

Вот что может означать «процессор загружен сейчас на 90%»? Возможно, вы думаете, что это выглядит как-то так:

А на самом деле это выглядит вот так:

«Работа вхолостую» означает, что процессор способен выполнить некоторые инструкции, но не делает этого, поскольку ожидает чего-то — например, ввода-вывода данных из оперативной памяти. Процентное соотношение реальной и «холостой» работы на рисунке выше — это то, что я вижу изо дня в день в работе реальных приложений на реальных серверах. Есть существенная вероятность, что и ваша программа проводит своё время примерно так же, а вы об этом и не знаете.

Что это означает для вас? Понимание того, какое количество времени процессор действительно выполняет некоторые операции, а какое — лишь ожидает данные, иногда даёт возможность изменить ваш код, уменьшив обмен данных с оперативной памятью. Это особенно актуально в нынешних реалиях облачных платформ, где политики автоматического масштабирования иногда напрямую завязаны на загрузку CPU, а значит каждый лишний такт «холостой» работы стоит нам вполне реальных денег.

Что же такое загрузка процессора на самом деле?

Та метрика, которую мы называем «загрузкой процессора» на самом деле означает нечто вроде «время не-простоя»: то есть это то количество времени, которое процессор провёл во всех потоках кроме специального «Idle»-потока. Ядро вашей операционной системы (какой бы она ни была) измеряет это количество времени при переключениях контекста между потоками исполнения. Если произошло переключение потока выполнения команд на не-idle поток, который проработал 100 милисекунд, то ядро операционки считает это время, как время, потраченное CPU на выполнение реальной работы в данном потоке.

Эта метрика впервые появилась в таком виде одновременно с появлением операционных систем с разделением времени. Руководство программиста для компьютера в лунном модуле корабля «Апполон» (передовая на тот момент система с разделением времени) называла свой idle-поток специальным именем «DUMMY JOB» и инженеры сравнивали количество команд, выполняемых этим потоком с количеством команд, выполняемых рабочими потоками — это давало им понимание загрузки процессора.

Так что в этом подходе плохого?

Сегодня процессоры стали значительно быстрее, чем оперативная память, а ожидание данных стало занимать львиную долю того времени, которое мы привыкли называть «временем работы CPU». Когда вы видите высокий процент использования CPU в выводе команды top, то можете решить, что узким местом является процессор (железка на материнской плате под радиатором и кулером), хотя на самом деле это будет совсем другое устройство — банки оперативной памяти.

Ситуация даже ухудшается со временем. Долгое время производителям процессоров удавалось наращивать скорость их ядер быстрее, чем производители памяти увеличивали скорость доступа к ней и уменьшали задержки. Где-то в 2005-ом году на рынке появились процессоры с частотой 3 Гц и производители сконцентрировались на увеличении количества ядер, гипертрейдинге, много-сокетных конфигурациях — и всё это поставило ещё большие требования по скорости обмена данных! Производители процессоров попробовали как-то решить проблему увеличением размера процессорных кэшей, более быстрыми шинами и т.д. Это, конечно, немного помогло, но не переломило ситуацию кардинально. Мы уже ждём память большую часть времени «загрузки процессора» и ситуация лишь ухудшается.

Как же понять, чем на самом деле занят процессор

Используя аппаратные счетчики производительности. В Linux они могут быть прочитаны с помощью perf и других аналогичных инструментов. Вот, например, замер производительности всей системы в течении 10 секунд:

# perf stat -a -- sleep 10 Performance counter stats for 'system wide': 641398.723351 task-clock (msec) # 64.116 CPUs utilized (100.00%) 379,651 context-switches # 0.592 K/sec (100.00%) 51,546 cpu-migrations # 0.080 K/sec (100.00%) 13,423,039 page-faults # 0.021 M/sec 1,433,972,173,374 cycles # 2.236 GHz (75.02%) stalled-cycles-frontend stalled-cycles-backend 1,118,336,816,068 instructions # 0.78 insns per cycle (75.01%) 249,644,142,804 branches # 389.218 M/sec (75.01%) 7,791,449,769 branch-misses # 3.12% of all branches (75.01%) 10.003794539 seconds time elapsed

Ключевая метрика здесь это «количество инструкций за такт» (insns per cycle: IPC), которое показывает, сколько инструкций в среднем выполнил процессор на каждый свой такт. Упрощённо: чем больше это число, тем лучше. В примере выше это число равно 0.78, что, на первый взгляд кажется не таким уж плохим результатом (78% времени выполнялась полезная работа?). Но нет, на этом процессоре максимально возможным значением IPC могло бы быть 4.0 (это связано со способом получения и выполнения инструкций современными процессорами). То есть наше значение IPC (равное 0.78) составляет всего 19.5% от максимально возможной скорости выполнения инструкций. А в процессорах Intel начиная со Skylake максимальное значение IPC уже равно 5.0.

В облаках

Когда вы работаете в виртуальном окружении, то можете и не иметь доступа к реальным счетчикам производительности (это зависит от используемого гипервизора и его настроек). Вот статья о том, как это работает в Amazon EC2.

Интерпретация данных и реагирование

Если у вас IPC > 1.0, то ваше приложение страдает не столько от ожидания данных, сколько от чрезмерного количества выполняемых инструкций. Ищите более эффективные алгоритмы, не делайте ненужной работы, кэшируйте результаты повторяемых операций. Применение инструментов построения и анализа Flame Graphs может быть отличным способом разобраться в ситуации. С аппаратной точки зрения вы можете использовать более быстрые процессоры и увеличить количество ядер.

Как вы видите, я провёл черту по значению IPC равному 1.0. Откуда я взял это число? Я рассчитал его для своей платформы, а вы, если не доверяете моей оценке, можете рассчитать его для своей. Для этого напишите два приложения: одно должно загружать процессор на 100% потоком выполнения инструкций (без активного обращения к большим блокам оперативной памяти), а второе должно наоборот активно манипулировать данным в ОЗУ, избегая тяжелых вычислений. Замерьте IPC для каждого из них и возьмите среднее. Это и будет примерная переломная точка для вашей архитектуры.

Что инструменты мониторинга производительности на самом деле должны показывать

Я считаю, что каждый инструмент мониторинга производительности должен показывать значение IPC рядом с загрузкой процессора. Это сделано, например, в инструменте tiptop под Linux:

tiptop - [root] Tasks: 96 total, 3 displayed screen 0: default PID [ %CPU] %SYS P Mcycle Minstr IPC %MISS %BMIS %BUS COMMAND 3897 35.3 28.5 4 274.06 178.23 0.65 0.06 0.00 0.0 java 1319+ 5.5 2.6 6 87.32 125.55 1.44 0.34 0.26 0.0 nm-applet 900 0.9 0.0 6 25.91 55.55 2.14 0.12 0.21 0.0 dbus-daemo

Другие причины неверной трактовки термина «загрузка процессора»

Процессор может выполнять свою работу медленнее не только из-за потерь времени на ожидание данных из ОЗУ. Другими факторами могут быть:

• Перепады температуры процессора
• Вариирование частоты процессора технологией Turboboost
• Вариирование частоты процессора ядром ОС
• Проблема усреднённых расчётов: 80% средней загрузки на периоде измерений в минуту могут не быть катастрофой, но могут и прятать в себе скачки до 100%
• Спин-локи: процессор загружен выполнением инструкций и имеет высокий IPC, но на самом деле приложение стоит в спин-локах и не выполняет реальной работы

Выводы

Загрузка процессора стала сегодня существенно недопонимаемой метрикой: она включает в себя время ожидания данных от ОЗУ, что может занимать даже больше времени, чем выполнение реальных команд. Вы можете определить реальную загрузку процессора с помощью дополнительных метрик, таких, как количество инструкций на такт (IPC). Значения меньшие, чем 1.0 говорят о том, что вы упираетесь в скорость обмена данными с памятью, а большие — свидетельствуют о большой загруженности процессора потоком инструкций. Инструменты замера производительности должны быть улучшены для отображения IPC (или чего-то аналогичного) непосредственно рядом с загрузкой процессора, что даст пользователю полное понимание ситуации. Имея все эти данные, разработчики могут предпринять некоторые меры по оптимизации своего кода именно в тех аспектах, где это принесёт наибольшую пользу.

• Блог компании Инфопульс Украина
• Высокая производительность
• Анализ и проектирование систем
• Системное программирование
• Разработка под Linux