IIS Worker Process — что это? (грузит процессор)
Приветствую уважаемые друзья! 
Сегодня мы поговорим про один процесс… который можно заметить в диспетчере задач операционной системы Windows. Постараюсь все написать простыми словами. Поехали разбираться))
Описание
IIS Worker Process — компонент веб-сервера, который позволяет запускать сайты, доступ к которым возможно из интернета.
Разбираемся
Нашел такую рекомендацию — выберите сперва сервер, потом перейдите в IIS > Рабочие процессы:
Потом появится меню, при помощи которого вы сможете определить какой пул приложений работает не в порядке:
Проблемный пул можно попробовать перезапустить, после чего проблемы могут исчезнуть.
Вообще IIS — это веб-сервер, при помощи которого могут функционировать сайты.
Надеюсь данная информация оказалась полезной. Удачи и добра 
Добавить комментарий Отменить ответ
Этот сайт использует Akismet для борьбы со спамом. Узнайте как обрабатываются ваши данные комментариев.
filecheck .ru
Вот так, вы сможете исправить ошибки, связанные с w3wp.exe
Информация о файле w3wp.exe
Описание: w3wp.exe важен для Windows. Файл w3wp.exe находится в подпапках C:\Windows\System32. Известны следующие размеры файла для Windows 10/8/7/XP 19,968 байт (37% всех случаев), 21,504 байт, 24,064 байт, 20,992 байт или 22,016 байт. 
Это системный процесс Windows. Приложение не видно пользователям. Это файл, подписанный Microsoft. Поэтому технический рейтинг надежности 1% опасности.
Если w3wp.exe находится в подпапках C:\Windows, тогда рейтинг надежности 18% опасности. Размер файла 44,544 байт. Это не файл Windows. Приложение не видно пользователям. Процесс слушает или шлет данные на открытые порты в сети или по интернету. Это заслуживающий доверия файл от Microsoft.
Важно: Некоторые вредоносные программы маскируют себя как w3wp.exe, особенно, если они расположены в каталоге c:\windows или c:\windows\system32. Таким образом, вы должны проверить файл w3wp.exe на вашем ПК, чтобы убедиться, что это угроза. Мы рекомендуем Security Task Manager для проверки безопасности вашего компьютера.
Комментарий пользователя
Лучшие практики для исправления проблем с w3wp
Если у вас актуальные проблемы, попробуйте вспомнить, что вы делали в последнее время, или последнюю программу, которую вы устанавливали перед тем, как появилась впервые проблема. Используйте команду resmon, чтобы определить процесс, который вызывает проблемы. Даже если у вас серьезные проблемы с компьютером, прежде чем переустанавливать Windows, лучше попробуйте восстановить целостность установки ОС или для Windows 8 и более поздних версий Windows выполнить команду DISM.exe /Online /Cleanup-image /Restorehealth. Это позволит восстановить операционную систему без потери данных.
w3wp сканер
Security Task Manager показывает все запущенные сервисы Windows, включая внедренные скрытые приложения (например, мониторинг клавиатуры или браузера, авто вход). Уникальный рейтинг надежности указывает на вероятность того, что процесс потенциально может быть вредоносной программой-шпионом, кейлоггером или трояном.
Бесплатный aнтивирус находит и удаляет неактивные программы-шпионы, рекламу, трояны, кейлоггеры, вредоносные и следящие программы с вашего жесткого диска. Идеальное дополнение к Security Task Manager.
Reimage бесплатное сканирование, очистка, восстановление и оптимизация вашей системы.
Процесс W3wp.exe потребляет 100% ресурсов ЦП на компьютере под управлением Windows Vista или Windows Server 2008
Симптомы
Запуск служб (IIS) 7.0 на компьютере под управлением Windows Vista или Windows Server 2008. На компьютере имеется более 64 ГБ ОЗУ. Неожиданно процесс W3wp.exe IIS занимает 100% ресурсов ЦП. Таким образом на компьютере происходит низкой производительности.
Причина
Эта проблема возникает, так как драйвер HTTP режима ядра (Http.sys) наибольший адрес памяти определяется как 64 ГБ.
Решение
Сведения об исправлении
Существует исправление от корпорации Майкрософт. Однако данное исправление предназначено для устранения только проблемы, описанной в этой статье. Применяйте это исправление только в тех случаях, когда наблюдается проблема, описанная в данной статье. Это исправление может проходить дополнительное тестирование. Таким образом если вы не подвержены серьезно этой проблеме, рекомендуется дождаться следующего пакета обновления, содержащего это исправление.
Если исправление доступно для скачивания, имеется раздел «Пакет исправлений доступен для скачивания» в верхней части этой статьи базы знаний. Если этот раздел не отображается, обратитесь в службу поддержки для получения исправления.
Примечание. Если наблюдаются другие проблемы или необходимо устранить неполадки, вам может понадобиться создать отдельный запрос на обслуживание. Стандартная оплата за поддержку будет взиматься только за дополнительные вопросы и проблемы, которые не соответствуют требованиям конкретного исправления. Чтобы получить полный список телефонов поддержки и обслуживания клиентов корпорации Майкрософт или создать отдельный запрос на обслуживание, посетите следующий веб-сайт корпорации Майкрософт:
Примечание. В форме «Пакет исправлений доступен для скачивания» отображаются языки, для которых доступно исправление. Если нужный язык не отображается, значит исправление для данного языка отсутствует.
Предварительные условия
Данное исправление на компьютере должна быть установлена одной из следующих операционных систем Windows:
Пакет обновления 1 (SP1) для Windows Vista
Windows Vista с пакетом обновления 2 (SP2)
Windows Server 2008
Windows Server 2008 с пакетом обновления 2 (SP2)
Чтобы получить дополнительные сведения о получении пакета обновления для Windows Vista, щелкните следующий номер статьи базы знаний Майкрософт:
как получить последний пакет обновления для Windows Vista
Дополнительные сведения о том, как получить пакет обновления для Windows Server 2008, щелкните следующий номер статьи базы знаний Майкрософт:
Как получить последний пакет обновления для Windows Server 2008
Необходимость перезагрузки
После установки исправления компьютер необходимо перезагрузить.
Сведения о замене исправлений
Это исправление не заменяет ранее выпущенные исправления.
Инструкции по установке
Сведения о файлах
Английский (США) версия данного исправления устанавливает файлы с атрибутами, указанными в приведенных ниже таблицах. Дата и время для файлов указаны в формате UTC. Дата и время для файлов на локальном компьютере отображаются в местном времени с вашим текущим смещением летнего времени (DST). Кроме того, при выполнении определенных операций с файлами, даты и время могут изменяться.
Примечания к сведениям о файле Windows Vista и Windows Server 2008
Важно. Исправления для Windows Server 2008 и Windows Vista исправления включены в те же пакеты. Однако только «Windows Vista» отображается на странице запрос исправления. Для получения пакета исправлений, который применяется к одной или обеих операционных систем, установите исправления, перечисленные в разделе «Windows Vista» на странице. Всегда смотрите раздел «Информация в данной статье относится к следующим продуктам» статьи для определения фактических операционных систем, к которым применяется каждое исправление.
Файлы, относящиеся к определенному продукту, этапу разработки (RTM, SPn) и обслуживания (LDR, GDR) можно определить по номерам версий, как показано в следующей таблице.
Файлы MANIFEST (.manifest) и MUM (.mum), устанавливаемые для каждой среды, указаны отдельно в разделе «Сведения о дополнительных файлах для системы Windows Vista и Windows Server 2008». MUM и файлы МАНИФЕСТА и связанные файлы каталога безопасности (.cat), очень важны для поддержания состояния обновляемого компонента. Файлы каталога безопасности, для которых не перечислены атрибуты, подписаны цифровой подписью корпорации Майкрософт.
Оптимизация ASP.NET — практические советы по работе с IIS
Введение
Приходилось ли вам когда-нибудь самим настраивать производственные веб-сервера (production servers) под управлением ОС Windows Server 2008 R2/IIS 7.5 и выше? Для системных администраторов, имеющих большой опыт работы с IIS, скорее всего, это тривиальная задача, но вот для веб-разработчиков, которым по различным причинам порой приходится самим участвовать в настройке «боевых» серверов, данная информация может оказаться весьма полезной.
Предыстория
В конце прошлого года в одной крупной организации мы столкнулись с проблемами производительности веб-серверов при резко увеличившейся пользовательской нагрузке. В веб-приложении на тот момент было зарегистрировано более 200 000 клиентов. В обычном режиме одновременно работает около 1000 пользователей, за день примерно 10-15% уникальных посетителей от общего числа зарегистрированных, поэтому нагрузка относительно невысокая. Однако существуют пиковые нагрузки, при которых система оказывается практически неработоспособной.
1. Параметры конфигурации IIS
Начиная с IIS 7, все настройки конфигурации ASP.NET хранятся в XML-файлах (*.config). Они заменили метабазу, которая использовалась в IIS 6.0 и более ранних версиях.
Схема конфигурационных файлов для IIS 7.x и выше выглядит так:
Рис. 1. Схема конфигурационных файлов
Здесь же находится файл machine.config.comments, который позволяет узнать, какие параметры используются по умолчанию. С помощью этих данных в machine.config можно добавить параметры с переопределенными значениями.
Корнем иерархии конфигурации ASP.NET является файл web.config, расположенный в том же каталоге, что и machine.config. Этот файл включает в себя параметры, которые используются для всех приложений ASP.NET.
Прежде чем начинать настройку конфигурации IIS, обратите внимание на счетчики производительности ASP.NET, оцените текущую и пиковую загрузки системы, зафиксируйте имеющиеся показатели. Проверьте логи на наличие ошибки “HTTP Error 503.2 — Service Unavailable”. Постарайтесь определить, не блокируется ли часть запросов в очереди.
Если производительность системы удовлетворяет потребностям заказчика, то лучше оставить параметры по умолчанию, ведь они рассчитаны для большинства ASP.NET приложений.
При конфигурации IIS можно выделить два основных параметра, влияющих на доступность приложения и его производительность.
1. Параметр appConcurrentRequestLimit — максимальное количество одновременных запросов в приложении. Увеличение числа одновременных запросов IIS расширит доступные ресурсы веб-сервера для обслуживания запросов. Значение по умолчанию — 5000.
Наиболее быстро изменить параметр appConcurrentRequestLimit можно утилитой appcmd.exe через командную строку. Сделать это можно как глобально для всех сайтов IIS через файл ApplicationHost.config, так и для отдельного сайта (приложения).
Выполняем команду, затем открываем в IIS раздел «Configuration Editor» для корневого каталога и проверяем новое значение установленного параметра appConcurrentRequestLimit. Причём здесь же можно вручную изменить это значение.
Рис. 2. Установка параметра appConcurrentRequestLimit
Для установки данного параметра наиболее часто используется формула:
, где usersCount — количество одновременно работающих пользователей.
2. Параметр QueueLength — максимальное количество запросов, которые драйвер Http.sys размещает в очереди пула приложений. Когда очередь заполнена, новые запросы получают ошибку «503.2 — Service Unavailable». Значение по умолчанию — 5000.
Выполняем команду, затем открываем в IIS раздел «Application Pools», выбираем в списке пул «DefaultAppPool », заходим в меню «Advanced Settings» и проверяем.
Рис. 3. Установка параметра queueLength
В диспетчере IIS выберите узел сервера в дереве, затем нажмите на иконку «Worker Processes»:
Рис. 4. Меню Worker Processes в диспетчере IIS
В появившемся списке вы можете видеть загрузку всех запущенных в текущий момент пулов.
Рис. 5. Просмотр работающих пулов через Worker Processes
При нажатии “View Current Request” появляется таблица со списком адресов обрабатываемых страниц и другими полезными параметрами. Для обновления списка можно нажимать F5 на экране. Таким образом, вы сможете найти «подвисшие» запросы:
Рис. 6. Список текущих запросов в пуле
Для просмотра показателей производительности, конечно, лучше использовать счётчики Performance Monitor, но они не покажут вам, как Requests Monitor, URL-адреса текущих запросов.
2. Настройка ASP.NET
ASP.NET ограничивает число рабочих потоков и потоков портов завершения вызова, используемых для выполнения запросов. Если веб-приложение на стороне сервера активно использует вызовы внешних веб-сервисов, стандартные классы из пространства имён System.NET для организации запросов по сети, то могут возникнуть конфликты низкой производительности и взаимоблокировок. Вначале часть запросов может просто “подвисать”, время выполнения будет значительно возрастать. В худшем случае, если используется классический режим настройки пула (classic pipeline), это вообще может привести к перезагрузке пула (recycle). Обнаружение взаимоблокировки ASP.NET не выполняется для пула, запущенного в integrated mode (по умолчанию в IIS 7 и выше).
Работа пулов приложений в интегрированном режиме имеет несколько преимуществ по сравнению с работой в классическом режиме. Рекомедуется запускать пулы приложений в integrated mode.
На рисунке ниже наглядно видно, как происходит обработка запросов в ASP.NET и какие параметры имеют наиболее важное значение:
Рис. 7. Процесс обработки запросов в ASP.NET
Для оптимальной работы веб-приложений по умолчанию включен режим автоконфигурации настроек пула. В этом случае, cвойство autoConfig равно «true» для секции в файле machine.config, а другие ключевые параметры не заданы вообще.
Таким образом, на сервере с 4-х ядерным процессором максимальное кол-во одновременных подключений к конечному IP-адресу равно 48=12*4 (по умолчанию).
Самый простой способ обойти данное ограничение — это прямо в коде своего ASP.NET приложения в методе Application_Start в файле global.asax указать следующее:
Важно: Схема для адреса параметра maxconnection должна быть такой:
Увеличение maxconnection позволяет делать больше одновременных вызовов к удаленным сервисам. Этот атрибут не влияет на локальные вызовы веб-служб! Необходимо понимать, что недостаточно только обойти ограничение на количество одновременных подключений к сервису. Так как увеличение числа одновременных вызовов приводит к увеличению использования потоков CLR, которые используются для создания удаленных и обработки обратных вызовов.
ASP.NET через параметр maxWorkerThreads устанавливает ограничения потоков на рабочем процессе w3wp.exe (начиная с IIS 7). В связи с тем, что ASP.NET встроена в IIS, процессы ASP.NET формируют запросы на рабочих потоках. Из-за недостаточного количества потоков в CLR ThreadPool запросы будут становиться в очередь и “подвисать”.
Аттрибуты, заданные в секции :
1. Параметр maxWorkerThreads — указывает максимальное количество рабочих потоков для каждого процессора в пуле потоков среды CLR. Значение по умолчанию — 20. Максимальное значение — 100.
2. Параметр maxIoThreads — указывает максимальное количество потоков ввода/вывода для каждого процессора в пуле потоков среды CLR. Значение по умолчанию — 20. Максимальное значение — 100.
3. Параметр minWorkerThreads — указывает минимальное количество рабочих потоков для каждого процессора, которые могут быть предоставлены немедленно для обслуживания удаленного запроса. Значение по умолчанию — 1.
4. Параметр minIoThreads — указывает минимальное количество потоков ввода/вывода для каждого процессора, которые могут быть предоставлены немедленно для обработки обратного вызова. Значение по умолчанию — 1.
Параметры minWorkerThreads/minIoThreads позволяют оперативно справиться с внезапно возросшим количеством одновременных подключений, когда в случае бездействия пул потоков может не иметь достаточно времени, чтобы достичь оптимального уровня потоков.
Аттрибуты, заданные в секции :
1. Параметр minFreeThreads — определяет количество потоков, которые могут быть использованы для работы, кроме обработки входящих запросов к рабочему процессу. Этот параметр не дает процессу ASP.NET использовать потоки из пула для обработки нового HTTP-запроса, если общее число потоков в пуле опустится ниже этого предела. Значение по умолчанию — 8.
2. Параметр minLocalRequestFreeThreads — определяет минимальное количество свободных потоков, которые ASP.NET держит доступными для выполнения новых локальных запросов. Значение по умолчанию — 4.
Обратите внимание, параметры maxWorkerThreads, minWorkerThreads, maxIoThreads, minIoThreads неявно умножаются на число процессоров, а параметры minFreeThreads и minLocalRequestFreeThreads — нет.
ASP.NET не будет выполнять более, чем следующее количество одновременных запросов:
(maxWorkerThreads * число ЦП) — minFreeThreads
Обратите внимание: на весь пул приложения, то есть на каждый рабочий процесс w3wp.exe, обслуживающий пул, имеется один пул потоков CLR ThreadPool. Для всех доменов приложений (сайтов), настроенных на один пул, используется общий набор потоков. Следовательно, для требовательных к ресурсам приложений лучше использовать отдельные пулы.
3. Рекомендации по оптимизации базовой конфигурации
Рис. 8. Окно загрузки процессоров в TaskManager
Также можно попробовать воспользоваться следующими командами в командной строке:
или
Например, на сервере с 4-мя процессорами и свойством autoConfig=»true» ASP.NET будет иметь следующие параметры по умолчанию:
maxConnection – 48; maxWorkerThreads – 80; maxIoThreads – 80, minFreeThreads – 8, minLocalRequestFreeThreads – 4.
Если веб-страница на backend-части делает несколько сетевых вызовов для каждого запроса, то MSDN рекомендует использовать следующие настройки конфигурации:
Изменения в секцию разрешено вносить только в файле machine.config из-за установленного там же атрибута allowDefinition=»MachineOnly» при добавлении секции processModel.
Чтобы иметь возможность устанавливать значения секции processModel для каждого приложения в отдельности через web.config, необходимо установить свойство allowDefinition=»Everywhere«.
Важно: после внесения изменений требуется обновить Application pools.
Помните, что увеличивать данные параметры нужно только в случае необходимости при наличии достаточного количества ресурсов ЦП.
Для анализа производительности веб-серверов рекомендую настроить счётчики ASP.NET через Performance Monitor:
Возможно, что после проверки счётчиков вам придётся внести корректировки в конфигурацию вашей системы.
Дополнительно
Для лучшего понимания работы IIS рекомендую ознакомиться, как происходит процесс обработки запроса от браузера пользователя до конечного пула приложения ASP.NET в этой полезной статье «Основы архитектуры IIS, или запросопровод для ASP.NET».
Если вы используете IIS8 — не будет лишним обратить внимание на «Полноценное регулирование нагрузки CPU (CPU Throttling)».
Заключение
Для сайтов, которые не совершают частые сетевые запросы на стороне сервера, стандартных настроек пула должно хватать (processModel/autoConfig=“true”). При этом IIS выставит ограничение в 20 рабочих потоков и 12 удаленных соединений на ядро. При превышении этих значений запросы начнут становиться в очередь и производительность веб-приложения упадёт.
Если ваш сайт работает хорошо и вы можете оценить предполагаемую нагрузку на систему, то не стоит ничего менять. Если же у вас начинаются “зависания” при обработке запросов к различным сервисам — не следует сразу винить во всем железо! Лучше внести изменения в базовую конфигурацию ASP.NET. Имейте в виду, что изменение базовых параметров пула приложений непременно приведёт к увеличению загрузки процессора. Оптимальная балансировка всех параметров системы — ключ к стабильной и производительной работе оборудования. Как говорится, “предупрежден — значит вооружен”.
Приглашаю всех поделиться вашим опытом настройки и оптимизации работы производственных веб-серверов на платформе Windows Server.
Iis worker process грузит процессор
I installed eset-nod32 on my vps, but it doesn’t show any attack in the logs. I’ve tried searching about IIS and preventing DDOS, and just found an extension for banning IP addresses, but how can I find which IP address are generating traffic?
8 Answers 8
Well, this can take long time to figure out. Few points to narrow it down:
Diagnosing
In terms of diagnosing what App Pool is causing trouble, you can:
This should bring up a menu like this so you can determine which App Pool is running amok.
From there you can simply restart the the app pool and 9 times out of 10 that will fix any immediate issues you’re having.
Treating
Unless you run some sort of controversial business, this is probably not a DDOS attack. It’s likely that some code is just hanging because it couldn’t get through to another server or got stuck in a loop or mis-allocated resources or your app pool just hasn’t been recycled in a while.
You can deal with this problem programmatically without having to manually identify, log in, and recycle the app pool. Just configure the CPU property on your App Pool. You can have it kill (and automatically restart) your process anytime you reach a CPU threshold for a certain amount of time.
In your case, if you want it to restart at 80%, you can right click on the app pool and go to Advanced Settings and apply the following configurations:
NOTE: As kraken101 pointed out, different IIS GUIs have treated this differently over time. While the config value is always in 1/1000 of a %, sometimes the GUI takes the whole percent.
You can add this to your config section like this:
Preventing
The steps above will help fix some things once they’ve broken, but won’t really solve any underlying issues you have.
Here are some resources on doing performance monitoring:
Use PerfMon to collect data and DebugDiag to analyse.
Found this link while searching for similar issue.
I was facing the same issues recently and found a solution which worked for me and reduced the memory consumption level upto a great extent.
Solution:
First of all find the application which is causing heavy memory usage.
You can find this in the Details section of the Task Manager.
If this solution works for you please add a comment so that I can know.
Решение проблем с производительностью IIS
Иногда бывает, что на сервере IIS начинают происходить странные дела. Так например у меня возникла ситуация, в которой один из процессов w3wp.exe время от времени начинал занимать под свои вычисления весь ресурс одного из ядер (был бы одноядерный процессор было бы использование процессора на 99% или 100%). Для тех, кто не знает процесс w3wp.exe кроме всего прочего отвечает за исполнение серверного кода ASP, ASP.NET скриптов. Ясно было что, какой-то скрипт производит излишнюю нагрузку. Такое поведение для меня было неприемлимым и я постарался решить эту задачу.
Первым делом я захотел выяснить какое из используемых нами приложений производит эту дополнительную нагрузку. Для этого я попробовал вынести все приложения в отдельные виртуальные каталоги, задав для каждого отдельный пул приложений, они же Application pool (для каждого пула приложений используется отдельный процесс w3wp.exe), попутно определяя какой из процессов к какому пулу относится. Сделать это можно довольно просто при помощи утилиты Sysinternals Process explorer. Для этого достаточно зайти в свойства процесса (при этом подсказкой может служить то, что приложения написанные при помощи ASP.NET будут подсвечены жёлтой строкой), и на вкладке Image посмотреть строку Command line, из которой видно, что название пула приложений передаётся процессу w3wp.exe через параметр «ap». Так например команда запуска для пула приложений с именем «dotnet4» будет выглядеть так:
Впоследствие эти действия оказались по большему счёту бесполезными, но умение определять нужный процесс w3wp оказалось впоследствии полезным и мне и нашим разработчикам выполняющим удалённую отладку в Visual Studio.
We have 12 web sites on Windows 2008 R2 Standard 64 bit, 2GB RAM, 2 Processors. It is run in VMware at a hosting company and has been active about 2 months. ASP.Net code in Framework 4.0. No code changes or Windows Updates applied since 2/23/15.
On 3/5/15, one web (X.com) site started slowing down or stopping completely for users. There may be up to 25 or 50 users hitting it simultaneously. Task Manager Performance Tab showed CPU usage pegged at 100% and Processes Tab showed w3wp.exe IIS Worker Process for X.com.
This would last 15 to 120 seconds. Sometimes stopping on its own – sometimes I killed the process. It reoccurred at random times, getting more frequent as the day progressed. Resetting IIS and server reboot only provided temporary relief. All other web sites functioning normally, including one with twice the user load.
Only cure was to move x.com to a similar VM used for development. No incidents since.
So – what the heck. Thanks in advance.
Premium Content
Premium Content
1. Have you looked into the site’s http logs and analyzed them?
2. Have you looked into the server’s http error logs (different from #1)?
2a. Http Error Log location: C:WindowsSystem32LogFil esHTTPERR
3. Are there errors/warnings in the event logs?
4. Is there a database component associated with the app?
4a. If yes, was there equivalent activity on the database for the app?
5. Also, how much RAM was the process using?
I recommend that you look into the site’s http logs (in #1 and #2) to see what activity occurred during the timeframe of the issue.
Hopefully you have more than the default fields enabled in the http logging feature. Otherwise, I recommend enabling all W3C fields. In your case, there are fields that may be of help. For example, time-taken, cs-bytes and sc-bytes.
Basically these fields are defined as:
Of course the field «cs-uri-stem» is important to see what URL the client request hit. The «cs-uri-query» may also be of use if the app uses query strings instead of posting back the data.
In the HTTPERR logs, «Timer_ConnectionIdle» entries can be ignored.
Use task manager to see how much RAM a process is consuming. I would select the following columns to be visible under the Processes tab in Task Manager:
1. Image Name
2. PID – process ID
3. User Name
4. CPU – [currently CPU usage in percent]
5. CPU Time – [overall time the process has on the CPU]
6. Working Set (Memory) – [memory used by a process but can be released if needed]
7. Memory (Private Working Set) – [memory reserved exclusively for the process]
8. Handles
9. Threads
#7 is a good estimate of how much RAM a process is using. Measuring the real amount of RAM a process is a bit more complicated but Private Working Set is useful for quickly troubleshooting issues.
