thread usage что это
990x.top
Простой компьютерный блог для души)
CPU Usage что это такое?
Приветствую друзья. Тема сегодня о процессорах, а вернее о том что означает словосочетание CPU Usage. Значит смотрите, CPU это процессор, эта аббревиатура расшифровывается как central processing unit, ну типа центральный процессор юнит, последнее слово не знаю что значит. Слово Usage означает использовать. То есть можно сделать вывод, что CPU Usage означает использование процессора.
Словосочетание CPU Usage вы можете встретить где угодно, начиная от самой винды и заканчивая всякими программами. И почти всегда это словосочетание необходимо чтобы проинформировать пользователя об уровне загрузки процессора 
Часто пользователей интересует почему CPU Usage 100, что это имеется ввиду? Нагрузка процессора равна 100%. То есть какая-то программа грузит адски процессор. Я дам несколько советов что можно в таком случае предпринять. Узнавать какая именно программа, а вернее какой процесс грузит проц, нужно в диспетчере задач. Для примера я создам искусственную нагрузку при помощи архиватора WinRAR, я просто в нем запущу тест производительности. Первое что нужно сделать, узнать точно процесс, который грузит, для этого жмем на ЦП в диспетчере (вкладка процессы):
После этого нам сразу станет ясно, какой засранец грузит ПК. По крайней мере увидим имя процесса. Если это имя нам ни о чем не говорит, тогда смотрим в колонку описание. В моем случае сразу понятно кто этот засранец:
Это WinRAR archiver. Если нажать правой кнопкой по процессу и выбрать пункт Открыть место хранения файла:
То будет открыта папка, откуда запускается процесс, обычно это и есть папка программы.
Как успокоить процесс, который грузит нереально проц?
Вы можете возразить, мол зачем успокаивать, если можно просто нажать правой кнопкой по процессу и выбрать пункт Завершить. Логично, но не всегда корректно. Если принудительно завершить процесс, то это может повлечь за собой ошибку или прерывание важной задачи. Например процесс TrustedInstaller.exe у многих вызывает большую нагрузку, но не все знают, за что отвечает процесс. TrustedInstaller.exe выполняет установку модулей Windows, на деле это имеется ввиду установка обновлений. Разумеется что при завершение данного процесса прерывается установка обновлений. Как следствие будут ошибки в журнале, которые не факт что будут исправлены центром обновления. Я отвлекся, прошу прощения.
Итак, всего есть два варианта, при которых вы не завершаете грузящий процесс, но снижаете его нагрузку на проц. Первый, это приоритет. Вы можете задать низкий приоритет грузящему процессу, чтобы все остальные процессы получили на фоне его приоритет выше. Для этого нажмите правой кнопкой по процессу и выберите в меню Приоритет > Низкий:
Данная процедура эффективная и в большинстве случаев приносит желаемый эффект.
Второй вариант более агрессивный, поэтому его стоит использовать в крайних случаях. И еще данный вариант не подходит, если у вас одноядерный процессор, однако это редкость. Способ заключается в том, что процесс будет использовать не два ядра процессора, ну или больше, а одно. Если у вас 4 ядра, то можете отдать процессу 2 ядра, или 1, тут уже сами смотрите по ситуации. Чтобы это дело провернуть, нажимаете правой кнопкой по процессу и выбираете пункт Задать соответствие:
У меня в процессоре 2 ядра, поэтому я оставляю процессу 1 ядро:
Если галочка стоит, то ядро будет использоваться. Я поставил галочку на ЦП 0, но можно было и на ЦП 1, разницы нет. Если при этом еще и выставить низкий приоритет, то процесс точно перестанет грузить комп. Однако стоит учесть, что данная процедура увеличит время выполнения задачи процессом. То есть выполнять будет дольше, но зато нагрузка на проц будет максимально снижена
Надеюсь предоставленная информация была полезной. Удачи и до новых встреч ребята!
Что такое CPU Usage и за что отвечает этот показатель?
Всем здравствуйте! Сегодня разберем термин CPU usage — что это такое в компьютере, где используется и на что влияет. Также рассмотрим — за что отвечает и что делать если параметр достигает 100%.
CPU, как вы, вероятно знаете, не что иное, как центральный процессор компьютера или ноутбука. Usage с английского переводится как «Использование».
Соответственно, CPU usage — это использование процессора системными службами и прикладными программами.
В русифицированной Aida64 любой редакции, например Extreme Edition, а также некоторых других коммерческих утилитах для мониторинга работы компьютера параметр отображается как «Использование ЦП».
В Speccy или PC Wizard такого параметра попросту нет.
Однако и в Windows 10, и в более ранних версиях это операционной системы в Диспетчере задач есть отдельная графа, которая показывает, как именно каждая программа или служба нагружает CPU.
Для запуска этой утилиту нужно нажать комбинацию клавиш Ctrl + Shift + Esc.
Замечено, что если какой-то процесс отнимает более 70% мощности ЦП, это отражается на работе компьютера: он начинает «задумываться», зависать, медленнее выполнять поставленные задачи. Исключение — процесс, который называется «Бездействие системы».
Это «холостой» цикл, который просчитывает процессор, если не запущено ни одно приложение. Как правило, и бездействие системы редко достигает 100%, так как в Windows почти всегда работают сервисные службы, отнимающие небольшой процент мощности ЦП.
Самый простой способ завершить «прожорливый» процесс — выделить его в Диспетчере задач, нажать ПКМ и выбрать опцию «Снять задачу».
Иногда это не срабатывает, если приложение перестало отвечать на запросы операционной системы. В этом случае можно воспользоваться сервисной утилитой, которая умеет «убивать» зависшие процессы — например Auslogics Boost Speed или аналогичной.
Если вы установили новую игру или приложение и заметили, что процесс забирает более 70% производительности ЦП, это свидетельствует о недостаточной вычислительной мощности и необходимости апгрейда компьютера.
Если же такой казус начинает происходить с программой, которая раньше работала корректно, не исключено, что в систему проник вирус и замаскировался под безобидное приложение.
Поможет только полная диагностика компьютера хорошим антивирусом. Защитник Виндовс, который в «Десятке» используется по умолчанию, с подобной задачей не всегда справляется.
Также советую почитать «Что такое СPU TM Function и как эта функция работает?». Буду признателен всем, кто расшарит этот пост в социальных сетях. До скорой встречи!
Thread Usage
Threads are concurrent execution environments that are lighter than full-blown processes because they share some operating system resources. Threads make it possible to do several things at the same time while using less resources and offering simpler synchronization and data exchange compared to processes.
If you move a blocking operation to a separate thread, it cannot block the event loop and keeps the user interface reactive. Blocking the event loop and using long-running callbacks means the application cannot update its graphical user interface.
While threads can be useful, they are not always the best choice:
Thread Safety
If several strings have to work on the same resources, conflicts can happen as the threads are run in parallel. For example, if thread A modifies several values while thread B is reading them, it is likely that some of the values read by B are outdated. Similar issues can happen if both threads are modifying data concurrently.
These kinds of conflicts are called race-conditions: depending on which thread is faster, the output changes and can be incorrect. Avoiding such issues is called thread safety. Thread safety involves critical sections, which are blocks of code that operate on shared resources and must not be accessed concurrently by another thread.
The usual solution for ensuring exclusive access to shared resources is mutual exclusion: only 1 thread can operate on the data at any given time. Mutual exclusion is often implemented through locks. Before attempting to operate on a shared resource, the thread waits until it can lock something called a mutex (stands for mutual exclusion), then operates on the resource, and unlocks the mutex. Operating systems guarantee that only 1 thread can lock a mutex at a given time: this ensures that only 1 thread operates on the shared resource at one time.
For more information on thread safety, see Low-level Functions.
Thread Pools
Threads are operating system resources: while much lighter than processes, they still have a cost. Moreover, spawning a thousand threads means that each of them only gets 1/1000th of the total CPU time: each thread is progressed slowly and, in the worst case, the system wastes all of its time switching between threads without doing any actual work.
Thread pools solve this problem. In thread pools, upto a maximum number of threads are created on-demand and used to execute tasks. When the tasks are finished, they are kept alive but sleeping. This avoids the cost of creating and destroying them.
In EFL, the thread pool is controlled by a thread_max parameter, which defines the maximum number of threads running at the same time. Another control feature is the func_end() callback that runs from the main loop thread after a task has completed and is typically used to extract the data from the finished task and make it available to the main loop.
To manage the maximum number of threads:
The following figures illustrate the thread pool. The first figure shows the occupancy of a hypothetical thread pool. There are several tasks, of which 4 are running. The thread_max parameter of the pool is 4, and the other tasks are waiting. There is no thread with its func_end() callback currently called.
Figure: Thread pool, step 1
When a task, applying the sepia filter on image1, finishes, the corresponding func_end() function is invoked from the main loop.
Figure: Thread pool, step 2
With the task done, one of the threads from the pool becomes available, and another thread, adding the reverberation effect on audio3, can run in it.
Figure: Thread pool, step 3
As long as there are tasks to be done, the thread pool continues the same way, running tasks in its threads whenever a thread is available.
Thread Management with Ecore
Ecore offers a simplified API for managing threads in EFL applications. The Ecore API applies to a typical scenario where the main thread creates another thread, which in turn sends data back to the main thread or calls GUI-related functions. GUI-related functions are not thread-safe.
Creating Threads with Ecore
The threads created with Ecore are by default integrated with the thread pool and offer simple callback-based ways to interact with the main loop. New threads are created as needed until the maximum capacity of the thread pool is reached.
Use the ecore_thread_feedback_run() function to send intermediate feedback from the thread to the main loop.
To create and run a thread, use the ecore_thread_run() function. It runs a function inside a thread from the thread pool and takes care of all the low-level work. It returns the corresponding thread handler or NULL on failure.
The most common way to return data from one thread to the main thread is to put a pointer to it in the data. When the thread is aborted or finishes, either func_cancel() or func_end() is called from the main loop. The functions are running in the simpler context of a single thread running at once and therefore avoid race-conditions.
Running Callbacks from the Main Loop
If you are performing operations in another thread and want to update a progress bar, the update operation must be done from the main thread. The simplest way is to use the ecore_main_loop_thread_safe_call_async() function, which takes a function and some data as parameters and instructs the main loop to execute the given function with the given data.
Depending on the kind of thread the function is called from, the process differs:
If you want to wait until the callback is called and returns, use the ecore_main_loop_thread_safe_call_sync() function, which is similar but synchronous. Since it is synchronous, it can also return the value returned by the callback.
Low-level Functions
Eina offers low-level functions that are portable across the operating system, such as locks, conditions, semaphores, barriers, and spinlocks. The functions follow closely the logic of pthreads.
While these functions are useful, they are building blocks and not usually useful in EFL applications considering the higher-level functions that are available in Ecore.
For an introduction to threads and pthreads in particular, see:
If you are already familiar with threads, see the standard pthreads documentation and the Eina reference documentation, or the following function lists. Remember that the Eina functions map very closely to the pthreads functions.
| pthreads function | Eina equivalent |
|---|---|
| pthread_mutex_new() | eina_lock_new() |
| pthread_mutex_destroy() | eina_lock_free() |
| pthread_mutex_lock() | eina_lock_take() |
| pthread_mutex_trylock() | eina_lock_take_try() |
| pthread_mutex_unlock() | eina_lock_release() |
| none (prints debug information on the lock) | eina_lock_debug() |
| pthreads function | Eina equivalent |
|---|---|
| pthread_cond_init() | eina_condition_new() |
| pthread_cond_destroy | eina_condition_free() |
| pthread_cond_wait() | eina_condition_wait() |
| pthread_cond_timedwait() | eina_condition_timedwait() |
| pthread_cond_broadcast() | eina_condition_broadcast() |
| pthread_cond_signal() | eina_condition_signal() |
| pthreads function | Eina equivalent |
|---|---|
| pthread_rwlock_init() | eina_rwlock_new() |
| pthread_rwlock_destroy() | eina_rwlock_free() |
| pthread_rwlock_rwlock_rdlock() | eina_rwlock_take_read() |
| pthread_rwlock_rwlock_wrlock() | eina_rwlock_take_write() |
| pthread_rwlock_unlock() | eina_rwlock_release() |
| pthreads function | Eina equivalent |
|---|---|
| pthread_key_create() | eina_tls_new() |
| pthread_key_delete() | eina_tls_free() |
| pthread_getspecific() | eina_tls_get() |
| pthread_setspecific | eina_tls_set() |
| pthreads function | Eina equivalent |
|---|---|
| sem_init() | eina_semaphore_new() |
| sem_destroy() | eina_semaphore_free() |
| sem_wait() | eina_semaphore_lock() |
| sem_post() | eina_semaphore_release() |
| pthreads function | Eina equivalent |
|---|---|
| pthread_barrier_init() | eina_barrier_new() |
| pthread_barrier_destroy() | eina_barrier_free() |
| pthread_barrier_wait() | eina_barrier_wait() |
Thread Use Examples
The following examples display a window with a label. An auxiliary thread semi-regularly changes the text of the label. If you want to display a regular animation, use the Ecore animators described in the Main Loop guide.
To use the ecore_thread_feedback() function:
To use the ecore_main_loop_thread_safe_call_sync() function:
Except as noted, this content is licensed under LGPLv2.1+.
For details, see the Content License.
Вы неверно измеряете загрузку процессора
Та метрика, которую мы называем «загрузкой процессора» на самом деле многими людьми понимается не совсем верно. Что же такое «загрузка процессора»? Это то, насколько занят наш процессор? Нет, это не так. Да-да, я говорю о той самой классической загрузке 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:
Другие причины неверной трактовки термина «загрузка процессора»
Процессор может выполнять свою работу медленнее не только из-за потерь времени на ожидание данных из ОЗУ. Другими факторами могут быть:
Потоки и чрезмерное использование процессора в WAS for z/OS
Когда Вы замечаете, что Ваш сервер приложений на z/OS очень сильно потребляет CPU, то возникает вопрос – как найти источник (причину) такого поведения сервера? В этой статье будет рассмотрен подход, позволяющий определить источник чрезмерного потребления процессора с помощью возможностей z/OS, WebSphere Application Server и Java SDK.
Введение: в чем суть?
Первое с чего стоит начать, это понять, действительно ли сервер приложений стал чрезмерно “кушать” CPU или нет? Для этого следует обратиться к статистике по использованию CPU, собираемой такими инструментами z/OS как RMF или SMF. Проанализировав статистику, необходимо понять, связано ли увеличение использования CPU с ростом рабочей нагрузки, а так же сравнить потребление процессора за нужный временной интервал с показателями статистики за этот же интервал в прошлом. Важно убедиться, что проблемы действительно существуют, а не являются надуманными, особенно если Вы не знаете изменялся ли характер или объем нагрузки, изменялась ли среда окружения.
Если установлено, что проблемы с чрезмерным потреблением процессора сервером приложений действительно существуют, то далее необходимо воспользоваться методикой, которая состоит из двух основных этапов:
Обычно этого достаточно, что бы узнать причину чрезмерного потребления CPU и понять проблема в “системе” или в “приложении“.
Часть1. Разложение сервера приложений на потоки
В среде z/OS код приложений исполняется в серванте (Servant Region) сервера приложений, поэтому необходимо получить информацию о нитках серванта. Для этого необходимо воспользоваться возможностями SDSF (System Display and Search Facility). В меню SDSF выберите PS (Processes), найдите интересующий Вас процесс серванта (того, который чрезмерно потребляет CPU) и выдайте напротив него строчную команду ‘d’. Обратите внимание, что процессов серванта несколько, даже если у Вас выделен всего один сервант для сервера приложений, то ему соответствуют два процесса в системе. Необходимо выдать команду ‘d’ напротив того процесса, который находится в статусе ‘Running‘ и имеет значение PPID отличное от ‘1‘. Это показано на рисунке ниже (кликните для увеличения).
Хочу обратить внимание, что не всегда удобно оценивать использование процессора в SDSF PS, по столбцу CPU-Time, особенно когда сервер приложений имеет несколько сервантов. Для этого удобнее использовать SDSF DA, и анализировать столбец CPU%, который нагляднее показывает использование процессора. Поэтому, приведу еще один способ как получить информацию о потоках серванта без использования строчной команды ‘d’ в SDSF PS, но требующий больше действий руками.