Что такое thread usage
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.
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, разницы нет. Если при этом еще и выставить низкий приоритет, то процесс точно перестанет грузить комп. Однако стоит учесть, что данная процедура увеличит время выполнения задачи процессом. То есть выполнять будет дольше, но зато нагрузка на проц будет максимально снижена
Надеюсь предоставленная информация была полезной. Удачи и до новых встреч ребята!
Анализ ключевых показателей производительности — часть 3, последняя, про системные и сервисные метрики
Мы заканчиваем публикацию перевода по тестированию и анализу производительности от команды Patterns&Practices о том, с чем нужно есть ключевые показатели производительности. За перевод спасибо Игорю Щегловитову из Лаборатории Касперского. Остальные наши статьи по теме тестирования можно найти по тегу mstesting
В первой статье цикла по анализу ключевых показателей производительности мы наладили контекст, теперь переходим к конкретным вещам. Во второй посмотрели на анализ пользовательских, бизнесовых показателей/метрик и показателей, необходимых к анализу внутри приложения. В этой, заключительной — про системные и сервисные (в т.ч. зависимых сервисов) метрики.
Итак,
Системные метрики.
Системные метрики позволяют определять, какие системные ресурсы используются и где могут возникать конфликты ресурсов. Эти метрики направлена на отслеживание ресурсов уровня машины, таких как память, сеть, процессор и утилизация диска. Эти метрики могут дать представление о внутренних конфликтах лежащих в основе компьютера.
Вы также можете отслеживать данные метрики для определения аспектов производительности – нужно понимать, если ли зависимость между системными показателями и нагрузкой на приложение. Возможно, вам потребуются дополнительные аппаратные ресурсы (виртуальные или реальные). Если при постоянной нагрузке происходит увеличение значений данных метрик, то это может быть обусловлено внешними факторами — фоновыми задачами, регулярно-выполняющимися заданиями, сетевой активностью или I/O устройства.
Как собирать
Вы можете использовать Azure Diagnostics для сбора данных диагностики для для отладки и устранения неполадок, измерения производительности, мониторинга использования ресурсов, анализа трафика, планирования необходимых ресурсов и аудита. После сбора диагностики ее можно перенести в Microsoft Azure Storage для дальнейшей обработки.
Другой способ для сбора и анализа диагностических данных — это использование PerfView. Этот инструмент позволяет исследовать следующие аспекты:
Изначально PerfView был предназначен для локального запуска, но теперь он может быть использован для сбора данных из Web и Worker ролей облачных сервисов Azure. Вы можете использовать NuGet-пакет AzureRemotePerfView для установки и запуска PerfView удаленно на серверах ролей, после чего скачать и проанализировать полученные данные локально.
Windows Azure Diagnostics и PerfView полезны для анализа используемых ресурсов “постфактум”. Однако, при применении таких практик как DevOps, необходимо мониторить “живые” данные производительности для обнаружения возможных проблем производительности еще до того, как они произойдут. APM-инструменты могут предоставлять такую информацию. Например, утилиты Troubleshooting tools для веб-приложений на портале Azure могут отображать различные графики, показывающие память, процессор и утилизацию сети.
На портале Azure есть “health dashboard”, показывающий общие системные метрики.
Аналогичным образом, панель Diagnostic позволяет отслеживать заранее настроенный набор наиболее часто используемых счетчиков производительности. Здесь вы можете определить специальные правила, при выполнении которых оператор будет получать специальные нотификации, например, когда значение счетчика сильно превысит определенное значение.
Веб-портал Azure может отображать данные о производительности в течении 7 дней. Если вам нужен доступ данных за более длительный период, то данные о производительности нужно выгружать напрямую в Azure Storage.
Websites Process Explorer позволяет вам просматривать детали отдельных процессов запущенных на веб-сайте, а также отслеживать корреляции между использованием различных системных ресурсов.
New Relic и многие другие APM имеют схожие функции. Ниже приведено несколько примеров.
Мониторинг системных ресурсов делится на категории, которые охватывают утилизацию памяти (физической и управляемой), пропускную способность сети, работу процессора и операции дискового ввода вывода (I/O). В следующих разделах описано, на что следует обратить внимание.
Использование физической памяти
Существует две основные причины ошибки OutOfMemory – процесс превышает выделенное для него пространство виртуальной памяти либо операционная система оказывается неспособной выделить дополнительную физическую память для процесса. Второй случай является самым распространенным.
Вы можете использовать описанные ниже счетчики производительности для оценки нагрузки на память:
Также следует учитывать, что большие объемы памяти могут привести к фрагментации (когда свободной физической памяти в соседних блоках недостаточно), поэтому система, которая показывает, что имеет достаточно свободной памяти, может оказаться не в состоянии выделить эту память для конкретного процесса.
Многие APM-инструменты предоставляют сведения об использовании процессами системной памяти без необходимости глубокого понимания о принципах работы памяти. На графике ниже показана пропускная способность (левая ось) и время отклика (правая ось) для приложения, находящегося под постоянной нагрузкой. Примерно после 6 минут производительность внезапно падает, и время отклика начинает “прыгать”, по прошествии нескольких минут происходит показателей.
Результаты нагрузочного тестирования приложения
Записанная с помощью New Relic телеметрия показывает избыточное выделение памяти, которое вызывает сбой операций с последующим восстановлением. Использованная память растет за счет файла подкачки. Такое поведение является классическим симптомом утечки памяти.
Телеметрия, показывающая избыточное выделение памяти
Примечание: В статье Investigating Memory Leaks in Azure Web Sites with Visual Studio 2013 содержится инструкция, показывающая как использовать Visual Studio и Azure Diagnostics для мониторинга использования памяти в веб-приложении в Azure.
Использование управляемой памяти
.NET приложения используют управляемую память, которая контролируется CLR (Common Language Runtime). Среда CLR проецирует управляемую память на физическую. Приложения запрашивают у CLR управляемую память, и CLR отвечает за выделение требуемой и освобождение неиспользуемой памяти. Перемещая структуры данных по блокам, CLR обеспечивает компоновку этого типа памяти, уменьшая тем самым фрагментацию.
Управляемые приложения имеют дополнительный набор счетчиков производительности. В статье Investigating Memory Issues содержится детальное описание ключевых счетчиков. Ниже описаны наиболее важные счетчики производительности:
Что такое 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 и как эта функция работает?». Буду признателен всем, кто расшарит этот пост в социальных сетях. До скорой встречи!