Вывод времени ядра что это
Оптимизация Windows — мифы и реальность (часть 2)
Что же такое оптимизация?
Прежде чем углубляться в рассуждения, определимся с терминами.
Первое определение сразу отбрасываем, поскольку речь идет не о математических функциях. На втором стоит остановиться подробнее. Вариантов изменения настроек ОС действительно множество, сценариев использования компьютеров тоже множество. Как определить, какой из вариантов настроек оптимален? И для чего он оптимален?
Еще один термин — скорость работы системы. Он также весьма многогранен.
С одной стороны, операционная система имеет множество функций, скорость выполнения которых может иметь весьма существенное значение, а может практически не оказывать влияния на другие процессы. Причем какая-то функция может быть важной для одного класса задач, но практически не влиять на работу задач другого класса, и наоборот. Например, скорость работы диспетчера памяти может заметно влиять на работу современных игр, но не сказываться на работе обозревателей интернета или архиватора. Скорость дисковых операций имеет большое значение при обработке видеофайлов или рисунков большого размера, но практически не влияет на набор и редактирование текста, фоновую проверку правописания в Word и на скорость пересчета таблиц Excel.
С другой стороны, собственно операционная система должна работать как можно более прозрачно и незаметно, оставляя как можно больше системных ресурсов прикладным программам, ради которых люди и прибегают к помощи компьютеров.
Проведем небольшой эксперимент: запустим какую-нибудь программу, активно использующую процессор, например архиватор, и посмотрим в диспетчере задач, какую часть процессорного времени она будет использовать (для чистоты эксперимента желательно взять компьютер с одним одноядерным процессором без гиперпоточности либо отключить гиперпоточность и многоядерность).
Скорее всего программа будет использовать 97-99 процентов вычислительной мощности процессора. На первый взгляд все нормально: на свои нужды Windows использует считанные единицы процентов или даже меньше одного процента.
Немного усложним эксперимент и включим в диспетчере задач показ времени ядра.
Картина становится не такой радужной: оказывается, ядро системы работает и отнимает заметную долю ресурсов процессора — в данном случае около 10-20 процентов.
Казалось бы, вот он, резерв повышения производительности! Ведь очевидно, что, оптимизировав работу системы, можно увеличить скорость работы программы чуть ли не на те же самые 10-20 процентов! В идеале, конечно.
На самом деле этот вывод оказывается ложным. Та доля времени, которая отдается ядру, почти целиком используется опять же для нужд того самого архиватора, в частности на операции чтения с диска и записи на него, ведь эти операции выполняет не сама программа, а ОС по указаниям программы. Так что хоть в это «красное» время и исполняется код ядра системы, этот код обслуживает запросы архиватора.
Скорее всего, в этом месте у читателя сходу возникнет полувозражение-полувопрос. Но ведь в это время все же работает код ядра — наверняка можно оптимизировать его работу так, чтобы оно требовало меньше процессорного времени? Что-нибудь подкрутить, что-нибудь подстроить, что-то ненужное отключить.
Увы, сколько-нибудь заметных улучшений добиться не удастся. Прежде всего потому, что львиная доля этого «красного» времени ядра уходит на работу с железом. Проверить это проще простого: возьмите носитель с невысокой скоростью обмена, скажем, переключив контроллер диска в режим PIO. Автор не рекомендует проводить такие эксперименты на основном жестком диске из-за возможности заметного снижения скорости работы. Поэтому для эксперимента был выбран контроллер PCMCIA с модулем флеш-памяти, работающий именно в режиме программного ввода-вывода.
Как видим, доля времени ядра значительно увеличилась, соответственно, скорость работы архиватора сильно упала. Произошло это потому, что почти все ресурсы процессора тратятся на работу с медленным устройством.
Так что первоначальный вывод оказался правильным: на свои нужды ОС тратит лишь небольшую долю ресурсов современного компьютера. Впрочем, внимательный человек давно и сам мог бы сделать такой вывод, если бы вдумался в результаты сравнения производительности последних версий Windows — они различаются буквально на единицы процентов.
Есть ли в системе резервы для ускорения работы?
Каждый раз при выходе новой Windows можно услышать многочисленные возмущения очередными «свистелками» и «финтифлюшками», добавленными разработчиками. Априори подразумевается, что все эти изменения ухудшают работу системы.
Отчасти, конечно, это верно. Вопрос заключается только в том, насколько велико это ухудшение и ухудшение ли это вообще.
С одной стороны, на отображение улучшенных элементов интерфейса действительно тратится больше ресурсов процессора и памяти. Хотя и не всегда: например, включенный (в большинстве случаев) по умолчанию аэро-интерфейс в Висте и Windows 7 снижает нагрузку на процессор за счет переноса значительной части работы по формированию изображения на видеоадаптер. С другой стороны — и ресурсов этих стало гораздо больше, так что доля, «отъедаемая» ОС, практически не изменилась. С третьей… но об этом чуть позже.
Итак, ОС тратит на свои нужды некоторую долю ресурсов, в первую очередь это процессор и память. Обсуждение использования памяти в эту статью точно не влезет, так что отложим его на будущее и остановимся на процессоре. Как можно увидеть из приведенных выше рисунков, собственно ОС на свои собственные нужды в этом примере тратит единицы процентов.
Вернемся в прошлое. Незадолго до выхода Windows XP Майкл Фортин, долгое время руководивший в «Майкрософт» группой, отвечавшей за производительность системы, составил для бета-тестеров весьма любопытный документ о том, как его группа работала и какие результаты получила (выжимки из него можно найти в http://forum.ixbt.com/topic.cgi?id=67:1#22). Внутренняя оценка изменений производительности звучала так: «разница между Win2K и Windows XP временами мала, около одного процента, временами велика, 5-10 процентов или около того».
Из этого следует достаточно очевидный вывод, что сколько-нибудь заметного увеличения скорости работы при помощи твикинга и «оптимизаций» получить не удастся.
Предположим, что система отнимает на свои нужды пять процентов времени процессора (обычно эта величина все же меньше), значит, работающему в это время процессу достается 95%. Допустим, мы улучшим систему вдвое (конечно, это фантастика, но давайте все-таки предположим такую возможность), так что она отнимет только 2,5 процента времени ЦП, а приложению достанется уже 97,5 процента. Скорость работы приложения увеличится на (97,5−95)⁄95=2,6 процента, то есть прирост получится отнюдь не фантастическим и практически незаметным на глаз.
Так что утверждать, что какие-то мелкие изменения способны увеличить скорость работы на десятки процентов, может только весьма наивный или сверх меры оптимистичный человек.
Но ведь, опять же скажете вы, в интернете можно найти кучу советов по улучшению тех или иных характеристик — что они дают? Как вы, уже, наверное, поняли, у меня не возникло ни малейшего желания заниматься экспериментальным опровержением всех этих идей: пусть их доказывает тот, кто делает такие утверждения. Но вопрос Майклу Фортину я все же задал, ведь у его группы ресурсов намного больше, чем у любого человека. Ответ звучал так: «Я опросил часть нашей команды [напомню, она называется Windows performance team, то есть группа производительности Windows] и сам немного удивился. Оказалось, большинство из них обсуждало подобные рекомендации и коллективный вывод был таков: много шума из ничего. За одним-единственным исключением: совет удалять программы, которые не используются, — полезен».
Теперь о третьей стороне «свистелок»
Если нельзя добиться сколько-нибудь значительного прироста скорости работы ОС, то что же остается? Один из путей — увеличить производительность компьютера. Это самый надежный, самый дорогой, но не всегда эффективный метод. Помните старую шутку: замените в своем компьютере Pentium 100 на Pentium 200, и он начнет простаивать вдвое быстрее? Во многих случаях повышение скорости компьютера давно уже не увеличивает скорость выполнения работы человеком, сидящим за этим компьютером. Невозможно набрать текст в редакторе или ввести числа в электронную таблицу быстрее только из-за того, что в компьютере прибавилось оперативной памяти или у нового процессора выше частота.
Конечно, какие-то задачи могут эффективно использовать всё более мощные компьютеры, но отнюдь не все. И вот тут на первый план выходит совсем другой критерий — эффективность и производительность труда человека, сидящего за компьютером. И на взгляд автора, оптимизировать следует именно эту сторону, то есть не скорость работы компьютера, а скорость работы за компьютером. В конце концов, ведь компьютер для человека, а не наоборот.
Возьмем, к примеру, ту характеристику, которую можно реально улучшить некоторыми приемами: время загрузки. Если вы программист, пишете драйвер низкого уровня и при его отладке вам приходится перезагружаться каждые пять-десять минут — конечно, время загрузки для вас критично. Но для обычного пользователя, который загружает компьютер один раз в день, утром, этот параметр уже далеко не так важен. А если используется гибернация и компьютер перезагружается раз в пару недель, то время загрузки уже почти не имеет значения.
Проведем простенький расчет: допустим, вам удалось сократить время загрузки с одной минуты до 30 секунд. Казалось бы, результат весьма неплох. Но перед этим вы полдня провели, читая разные форумы, сравнивая и анализируя полученную информацию, решая, что именно следует предпринять. Итого для экономии 30 секунд на каждой перезагрузке потрачено 4 часа (14400 секунд). Нетрудно подсчитать, что эти затраты оправдаются через 480 перезагрузок, и только после этого (при загрузке раз в день — примерно через полтора года) вы начнете получать выгоду. Причем не исключено, что за эти полтора года вы купите новый компьютер или переустановите систему, и затраты на «оптимизацию» окажутся просто впустую потраченным временем. В лучшем случае вы получите косвенную выгоду за счет дополнительно приобретенных знаний, но право же, эти знания можно было приобрести и другим, более легким путем.
Но возможность увеличить скорость загрузки никто и не отрицал. А вот оценить полезный эффект от изменения настроек не удалось, насколько известно автору, еще никому. Впрочем, можно привести наглядный пример. Сравнительно недавно в форуме (и еще минимум в двух других) с целью «обсуждения системных служб Windows 7, их оптимизации и методов контроля изменения производительности (скорость загрузки ОС и т. д.) при оптимизации» была создана тема. И хотя участнику сразу говорили (на разных форумах), что проку от этого нет, он, однако, не поверил и решил перепроверить всё сам. В итоге появилась на свет статья, в которой человек после личной проверки пришел к тем же самым результатам. Остается надеяться, что гонорар за статью хотя бы частично окупил потраченное время.
И в заключение приведем несколько критериев, по которым можно определить качество работы составителей многочисленных советов по оптимизации.
Если вы видите совет установить некое значение в параметре SecondLevelDataCache, вспомните, что этот параметр перестал использоваться начиная с Win2000 SP1. Утверждения, что параметр DisablePagingExecutive увеличивает скорость работы системы, неверны: он увеличивает скорость отклика системы за счет некоторого снижения производительности в целом. Рекомендация установить число ядер в настройках Msconfig для ускорения загрузки в лучшем случае бесполезна, ведь система и так по умолчанию использует все ядра. Зато уже были примеры, когда человек, сменив двухъядерный процессор на четырехъядерный и забыв восстановить исходное значение настройки, недоумевал, куда же делись два добавленных ядра.
Заключение
Заниматься изучением и внедрением в жизнь различных советов по оптимизации Windows — значит в лучшем случае тратить время впустую, а в худшем — заботливо раскладывать на будущее грабли для себя, любимого.
Вместе с тем, изменение системы для своего удобства, комфорта, привычных условий работы — не только допустимо, но и рекомендуется. Ибо даже если какие-то рекомендации и будут иметь результатом небольшое снижение производительности системы в целом, это с лихвой компенсируется тем, что вы сами сможете сделать больше за тот же период времени.
Сравнение времени работы в режима ядра и в пользовательском режиме
Чтобы посмотреть, сколько времени ваша система работает в режиме ядра по сравнению с работой в пользовательском режиме, можно воспользоваться Системным монитором (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 нечего делать, процесс ожидания происходит в режиме ядра.
Вы неверно измеряете загрузку процессора
Та метрика, которую мы называем «загрузкой процессора» на самом деле многими людьми понимается не совсем верно. Что же такое «загрузка процессора»? Это то, насколько занят наш процессор? Нет, это не так. Да-да, я говорю о той самой классической загрузке 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:
Другие причины неверной трактовки термина «загрузка процессора»
Процессор может выполнять свою работу медленнее не только из-за потерь времени на ожидание данных из ОЗУ. Другими факторами могут быть:
Вывод времени ядра в Диспетчере задач
Кроме того, я обязательно включаю в Диспетчере задач отображение времени ядра. Для этого нужно открыть вкладку «Быстродействие» (Performance) и выбрать опцию «Вывод времени ядра» (Show kernel times) в меню «Вид» (View). После этого на графике появляется красная кривая, которая отображает активность приложений, работающих в режиме ядра. На рис. A показан Диспетчер задач Windows Server с выводом времени ядра.
Верхние точки графика указывают на пользовательскую активность в консоли. С приложениями консоли взаимодействуют и процессы базы данных, но главная особенность графика заключается в разнице между временем ядра (красная линия) и временем пользователя (зеленая линия).
Когда привилегированные процессы или приложения, работающие в режиме ядра, потребляют ресурсы процессора, разрыв между двумя кривыми уменьшается. На рис. B показан как раз такой случай.
Вывод времени ядра позволяет выявить случаи чрезмерной активности сервера в ходе административного сеанса. При запуске инструментов администрирования на локальном сервере можно отследить, не слишком ли много на это уходит пользовательских ресурсов процессора. Лучше всего это видно при 100-процентной загрузке процессора. Если кривая времени ядра на пике — значит, основную нагрузку на сервер создают системные процессы. Если кривая времени ядра не совпадает с кривой времени пользователя — значит, административный сеанс потребляет слишком много ресурсов процессора.
А вы пользуетесь этой функцией? Помогает ли вам вывод времени ядра при диагностике? Поделитесь своим опытом в комментариях!
Автор: Rick Vanover
Перевод SVET
Оцените статью: Голосов
Просмотр системных служб в диспетчере задач
На вкладке Службы (Services) диспетчера задач перечислены системные службы. Для каждой службы приводится имя, идентификатор процесса (РШ), описание, состояние и группа. Обычно несколько служб работают с одним и тем же идентификатором процесса. Чтобы быстро отсортировать службы по идентификаторам, щелкните заголовок соответствующего столбца. Щелкнув заголовок столбца Состояние (Status), вы отсортируете службы в соответствии с их состоянием: Работает (Running) или Остановлено (Stopped).
В столбце Группа (Group) содержатся дополнительные сведения об учетных записях или контекстах, в рамках которых работают службы:
• Если на учетную запись службы наложены ограничения, они указаны в этом столбце. Например, служба, работающая под учетной записью
• LocalService, может быть помечена как LocalServiceNoNetwork (служба не имеет доступа к сети) или как LocalSystemNetvvorkRestricted (служба имеет ограниченный доступ к сети).
Щелкнув правой кнопкой список служб диспетчера задач, вы откроете контекстное меню, которое позволит вам:
• запустить остановленную службу;
• остановить работающую службу;
• перейти к соответствующему процессу на вкладке Процессы (Processes). Управление быстродействием
Вкладка Быстродействие (Performance) диспетчера задач содержит сведения по использованию процессора и памяти в виде диаграмм и статистики. Эта информация поможет вам быстро проверить использование системных ресурсов. Для получения более детальных сведений, используйте Монитор производительности (Performance Monitor), описанный далее в этой главе.
Диаграммы на вкладке Быстродействие (Performance)
Диаграммы на вкладке Быстродействие (Performance) содержат следующую информацию:
• Загрузка ЦП (CPU Usage) Нa сколько процентов в данный момент используются ресурсы процессора.
• Хронология загрузки ЦП (CPU Usage History) История использования процессора. Частоту обновления диаграммы можно изменить.
• Память (Memory) Объем физической памяти, используемый системой в данный момент.
• Хронология использования физической памяти (Physical Memory Usage History) История использования памяти.
Настройка и обновление диаграмм
Для настройки и обновления диаграмм используйте следующие команды меню Вид (View):
• Скорость обновления (Update Speed) Позволяет изменить частоту обновления диаграмм, а также приостановить обновление. Скорость Низкая (Low) соответствует обновлению раз в четыре секунды, Обычная (Normal) — раз в две секунды, Высокая (High) — дважды в секунд>’.
• Загрузка ЦП (CPU History) На многопроцессорных системах позволяет указать, как следует выводить диаграммы процессоров. Можно, например, выводить отдельный график для каждого процессора (по умолчанию) или один график для всех процессоров.
• Вывод времени ядра (Show Kernel Times) Позволяет выводить время процессора, использованное ядром операционной системы. График для ядра чертится красной линией (в отличие от зеленых линий обычных диаграмм).
Ниже диаграмм приводятся некоторые численные данные:
• Физическая память (МБ) (Physical Memory (MB)) Информация об оперативной памяти системы. В поле Всего (Total) показан общий объем физической оперативной памяти, в поле Кэшировано (Cached) — объем памяти, используемой для кеширования, в поле Свободно (Free) — объем неиспользуемой оперативной памяти. Если на сервере мало доступной физической памяти, вам стоит увеличить ее объем. Вообще, всегда нужно следить, чтобы объем свободной памяти был не менее 5% от физической памяти сервера.
• Память ядра (МБ) (Kernel Memory (MB)) Информация о памяти, используемой ядром операционной системы. Самые важные фрагменты ядра должны располагаться в оперативной памяти и не могут размещаться в виртуальной памяти. Этот тип памяти обозначен как Невыгружаемая (Nonpaged). Оставшаяся часть памяти ядра может быть выгружена в виртуальную память и потому обозначена как Выгружаемая (Paged). Общий объем памяти, используемой ядром, указан в поле Всего (Total).
• Система (System) Информация об использовании процессора. В поле Дескрипторов (Handles) указано число используемых дескрипторов ввода-вывода — маркеров, предоставляющих программам доступ к ресурсам В ноле Потоков (Threads) показано число используемых потоков. Потоки являются основной единицей исполнения в рамках процессов. В поле Процессов (Processes) показано число используемых процессов — экземпляров приложений или исполняемых файлов. В поле Время работы (Up Time) указано, сколько времени прошло с момента запуска системы. В поле Файл подкачки (Page File) показана используемая в данный момент виртуальная память и общий объем доступной виртуальной памяти. Если загруженность файла подкачки постоянно находится на уровне 10% от общего объема виртуальной памяти, вам, вероятно, следует добавить физической памяти или увеличить объем виртуальной памяти (или и то, и другое).