Что такое время ядра
Вы неверно измеряете загрузку процессора
Та метрика, которую мы называем «загрузкой процессора» на самом деле многими людьми понимается не совсем верно. Что же такое «загрузка процессора»? Это то, насколько занят наш процессор? Нет, это не так. Да-да, я говорю о той самой классической загрузке CPU, которую показывают все утилиты анализа производительности — от диспетчера задач Windows до команды top в Linux.
Вот что может означать «процессор загружен сейчас на 90%»? Возможно, вы думаете, что это выглядит как-то так:
А на самом деле это выглядит вот так:
«Работа вхолостую» означает, что процессор способен выполнить некоторые инструкции, но не делает этого, поскольку ожидает чего-то — например, ввода-вывода данных из оперативной памяти. Процентное соотношение реальной и «холостой» работы на рисунке выше — это то, что я вижу изо дня в день в работе реальных приложений на реальных серверах. Есть существенная вероятность, что и ваша программа проводит своё время примерно так же, а вы об этом и не знаете.
Что это означает для вас? Понимание того, какое количество времени процессор действительно выполняет некоторые операции, а какое — лишь ожидает данные, иногда даёт возможность изменить ваш код, уменьшив обмен данных с оперативной памятью. Это особенно актуально в нынешних реалиях облачных платформ, где политики автоматического масштабирования иногда напрямую завязаны на загрузку CPU, а значит каждый лишний такт «холостой» работы стоит нам вполне реальных денег.
Что же такое загрузка процессора на самом деле?
Та метрика, которую мы называем «загрузкой процессора» на самом деле означает нечто вроде «время не-простоя»: то есть это то количество времени, которое процессор провёл во всех потоках кроме специального «Idle»-потока. Ядро вашей операционной системы (какой бы она ни была) измеряет это количество времени при переключениях контекста между потоками исполнения. Если произошло переключение потока выполнения команд на не-idle поток, который проработал 100 милисекунд, то ядро операционки считает это время, как время, потраченное CPU на выполнение реальной работы в данном потоке.
Эта метрика впервые появилась в таком виде одновременно с появлением операционных систем с разделением времени. Руководство программиста для компьютера в лунном модуле корабля «Апполон» (передовая на тот момент система с разделением времени) называла свой idle-поток специальным именем «DUMMY JOB» и инженеры сравнивали количество команд, выполняемых этим потоком с количеством команд, выполняемых рабочими потоками — это давало им понимание загрузки процессора.
Так что в этом подходе плохого?
Сегодня процессоры стали значительно быстрее, чем оперативная память, а ожидание данных стало занимать львиную долю того времени, которое мы привыкли называть «временем работы CPU». Когда вы видите высокий процент использования CPU в выводе команды top, то можете решить, что узким местом является процессор (железка на материнской плате под радиатором и кулером), хотя на самом деле это будет совсем другое устройство — банки оперативной памяти.
Ситуация даже ухудшается со временем. Долгое время производителям процессоров удавалось наращивать скорость их ядер быстрее, чем производители памяти увеличивали скорость доступа к ней и уменьшали задержки. Где-то в 2005-ом году на рынке появились процессоры с частотой 3 Гц и производители сконцентрировались на увеличении количества ядер, гипертрейдинге, много-сокетных конфигурациях — и всё это поставило ещё большие требования по скорости обмена данных! Производители процессоров попробовали как-то решить проблему увеличением размера процессорных кэшей, более быстрыми шинами и т.д. Это, конечно, немного помогло, но не переломило ситуацию кардинально. Мы уже ждём память большую часть времени «загрузки процессора» и ситуация лишь ухудшается.
Как же понять, чем на самом деле занят процессор
Используя аппаратные счетчики производительности. В Linux они могут быть прочитаны с помощью perf и других аналогичных инструментов. Вот, например, замер производительности всей системы в течении 10 секунд:
Ключевая метрика здесь это «количество инструкций за такт» (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:
Другие причины неверной трактовки термина «загрузка процессора»
Процессор может выполнять свою работу медленнее не только из-за потерь времени на ожидание данных из ОЗУ. Другими факторами могут быть:
Как понимать отображение загрузки ядер в диспетчере?
Я знаком с диспетчерами задач уже лет 20, но только недавно понял что не знаю как надо воспринимать загрузку дополнительных ядер. Возьмем процессор i7-8700k, у него есть 6 ядер на которых 12 виртуальных. В ОС показываются все 12 с загрузкой каждого.
Для примера диспетчер винды:
Мне стало казаться что для фиктивных ядер указывается не конкретно их загрузка, а их загрузка + существующая загрузка физического ядра. Обычно, если посмотреть на их графики то заметно что многие из них имеют похожую картинку. На мой картинке это хорошо видно по 3 самым правым. При этом, нет запущенных программ которые бы грузили сразу 12 потоков. Ожидание что будут загружены, например, 1-4, но не 12.
Еще в диспетчере винды есть «показать время ядра». Тоже не ясно что это.
Как все таки работает отображение:
— для каждого отдельно;
— для каждого отдельно, но дополнительные виртуальные вместе с нагрузкой от основного виртуального;
— физическая загрузка + виртуальное, для дополнительных.
Где можно об этом прочитать чтобы стало понятно?
для диспетчера задач существуют 12 ядер для исполнения программ.
что они эмулированы через HT из 6 физических он даже не подозревает. да и пофих ему до таких тонкостей.
Он просто двенадцать ядер загружает работой и считает время использования.
и собственно это и отображается.
ты не совсем правильно понимаешь, нет разделения ядер на физическое + виртуальное.
на физическом ядре просто параллельно выполняются два потока инструкций, так эффективнее получается использовать многостадийный конвеер исполнения физ.ядра.
т.е из одного физического ядра получаются два абсолютно эквивалетных виртуальных ядра.
При этом, нет запущенных программ которые бы грузили сразу 12 потоков.
Операционке всегда есть, чем заняться 🙂 Так что 12 потоков вполне могут быть заняты.
Насколько быстры компьютеры
Время для компьютеров течет не так, как для людей. То, что человеческим мозгом воспринимается как мгновение, для компьютеров растягивается на долгие эпохи. Данная статья — это метафора, в попытке осознать этот простой и в общем-то очевидный факт.
Известный комикс (https://xkcd.ru/505/), которым и навеяна идея статьи
Инфляция временных единиц
Для большинства программистов прикладного уровня время, которым измеряется производительность программ, останавливается на масштабе миллисекунд: ну какая разница, будет ли элемент в браузере рендериться 50 или 200 микросекунд, если это всё равно ничтожно малое значение? Какая разница, выполняется ли запрос в базу данных за 200 или за 500 микросекунд, если сетевые издержки на порядок больше? Безусловно, есть области программирования, где приходится спуститься на уровень наносекунд и единичных тактов, но в большей своей части программисты не думают такими временными понятиями. Я предлагаю подумать.
Компьютерная секунда
Я предлагаю подумать, как выглядела бы работа современного компьютера, если бы каждому такту процессора соответствовала одна секунда в субъективном мироощущении каких-нибудь существ, которые, как мы знаем, и управляют всей техникой («гарантийные человечки» или, на современный лад, «фиксики»). Для таких человечков частота процессора будет равно ровно 1 Hz.
Я пишу эту статью на ноутбуке с восьмиядерным процессором базовой частотой в 2.4 GHz, то есть один такт раз в
0,4 наносекунды (округление очень грубое). Это значение и будет нашей «компьютерной секундой».
Что же происходит за время, равное такой секунде?
Восемь ядер процессора успевают выполнить несколько элементарных операций вроде сложения чисел.
Свет проходит около 12 сантиметров (в вакууме).
За пять секунд процессор может получить данные из кэша первого уровня.
Компьютерная минута
Этот промежуток времени интереснее. За минуту может произойти многое. По человеческим меркам эта минута равна примерно 24 наносекундам.
Что же может произойти за компьютерную минуту?
Электрический сигнал пройдет всю длину кабеля от компьютера до монитора.
За две минуты произойдет обращение к данным в оперативной памяти.
За несколько минут JVM сможет сделать объект String из маленького массива байтов.
Компьютерный час
На этом этапе мы переходим от человеческих наносекунд к микросекундам: компьютерный час равен 1.44 мкс.
Может выполниться пузырьковая сортировка небольшого массива, когда-то написанная мной в образовательных целях. (вдумайтесь: если процессор каждую секунду делает по простому действию, то для сортировки маленького массива ему понадобятся часы!)
За десяток-другой часов процессор может запросить и получить данные у достаточно производительного SSD.
Компьютерный год
Предлагаю перескочить через сутки и месяцы и сразу перейти к годам (
12мс), за год может произойти очень много разных событий:
Запрос, обрабатываемый базой данных несколько месяцев, можно считать быстрым.
Примерно раз в компьютерный год должно меняться изображение на мониторе, чтобы соответствовать частоте 60 Hz.
Около трех лет уходит на выполнение пинга 8.8.8.8 (три года, Карл! человек за это время может пешком дойти до сервера и вернуться!)
Десяток лет может пройти от нажатия на клавиатуру до появления символа на экране монитора.
Компьютерное столетие
Именно на таком уровне (человеческие секунды) мы общаемся с компьютером. Например, главная страница Хабра будет загружаться около пяти столетий. Вдумайтесь! Полтысячи лет! Если во времена Шекспира начать, секунда за секундой, работать над загрузкой страницы, работа всё ещё может быть не закончена в XXI веке!
Надеюсь, что данный мысленный эксперимент вам показался настолько же захватывающим и невероятным, как и мне. Многие вещи становятся более понятными и осязаемыми, если перевести их в компьютерные секунды. Например, читая «Операционные системы» Танненбаума, я недоумевал, как компьютер может вообще успевать что-то делать, если переключение в/из ядра ОС — такая сложная операция? Но если перевести это в «компьютерное» время, то это всего-то час труда раз в пару месяцев.
Вывод времени ядра в Диспетчере задач
Кроме того, я обязательно включаю в Диспетчере задач отображение времени ядра. Для этого нужно открыть вкладку «Быстродействие» (Performance) и выбрать опцию «Вывод времени ядра» (Show kernel times) в меню «Вид» (View). После этого на графике появляется красная кривая, которая отображает активность приложений, работающих в режиме ядра. На рис. A показан Диспетчер задач Windows Server с выводом времени ядра.
Верхние точки графика указывают на пользовательскую активность в консоли. С приложениями консоли взаимодействуют и процессы базы данных, но главная особенность графика заключается в разнице между временем ядра (красная линия) и временем пользователя (зеленая линия).
Когда привилегированные процессы или приложения, работающие в режиме ядра, потребляют ресурсы процессора, разрыв между двумя кривыми уменьшается. На рис. B показан как раз такой случай.
Вывод времени ядра позволяет выявить случаи чрезмерной активности сервера в ходе административного сеанса. При запуске инструментов администрирования на локальном сервере можно отследить, не слишком ли много на это уходит пользовательских ресурсов процессора. Лучше всего это видно при 100-процентной загрузке процессора. Если кривая времени ядра на пике — значит, основную нагрузку на сервер создают системные процессы. Если кривая времени ядра не совпадает с кривой времени пользователя — значит, административный сеанс потребляет слишком много ресурсов процессора.
А вы пользуетесь этой функцией? Помогает ли вам вывод времени ядра при диагностике? Поделитесь своим опытом в комментариях!
Автор: Rick Vanover
Перевод SVET
Оцените статью: Голосов
Сравнение времени работы в режима ядра и в пользовательском режиме
Чтобы посмотреть, сколько времени ваша система работает в режиме ядра по сравнению с работой в пользовательском режиме, можно воспользоваться Системным монитором (Performance Monitor).
Выполните следующие действия:
6. По окончании работы закройте окно инструментального средства. Такую же картину можно быстро просмотреть с помощью Диспетчера задач (Task Manager). Щелкните на вкладке Производительность (Performance), а затем выберите в меню Вид (View) пункт Вывод времени ядра (Show Kernel Times). На графике загруженности центрального процессора зеленым цветом будет показана его общая загруженность, а красным — загруженность в режиме ядра.
Чтобы увидеть, сколько времени в режиме ядра и в пользовательском режиме использует сам Системный монитор (Performance Monitor), запустите его еще раз, но при этом добавьте отдельные счетчики процесса % работы в пользовательском режиме (% User Time) и % работы в привилегированном режиме (% Privileged Time) для каждого процесса в системе:
Вы должны увидеть (найдя в столбце Экземпляр (Instance) процесс mmc), что график времени выполнения процесса, принадлежащего Системному монитору, в режиме ядра и в пользовательском режиме при перемещении мыши пошел вверх, поскольку в нем выполняется прикладной код в пользовательском режиме, и вызываются Windows-функции, запускаемые в режиме ядра. Обратите также внимание на активность потока, принадлежащего процессу csrss и выполняемого в режиме ядра при перемещении мыши.
Эта активность возникает благодаря тому, что этому процессу принадлежит исходный поток ввода той подсистемы Windows, выполняемой в режиме ядра, которая обрабатывает ввод с клавиатуры и с мыши. И наконец, процесс Idle, который, как можно заметить, тратит почти 100 % своего времени на работу в режиме ядра, на самом деле процессом не является, это ложный процесс, используемый для подсчета холостых циклов центрального процессора.
Судя по режиму, в котором запускаются потоки процесса Idle, когда Windows нечего делать, процесс ожидания происходит в режиме ядра.