System commit что это
Process Explorer. Обзор некоторых возможностей
Process Explorer – альтернатива стандартному Task Manager-у. Эта утилита, как и многие другие утилиты Sysinternals, здорово расширяет возможности контроля и управления системой. Главное новшество только что вышедшей 14-ой версии — возможность мониторить сетевую активность процессов. Далее небольшой обзор возможностей этой утилиты, которые считаю наиболее полезными для себя.
Для справки. С 2006 года Sysinternals была приобретена Microsoft, а ключевая фигура этой компании – Марк Руссинович с тех пор работает в Microsoft. Марк известен своими утилитами, книгой Windows Internals, блогом и является признанным специалистом по архитектуре Windows.
Колонки в главном окне
Сервисы внутри svchost
При наведении курсора на svchost (процесс который хостит в себе сервисы) можно видеть перечень сервисов – довольно полезная фича.
Суммарные графики активности, процесс с максимальной активностью
Сверху основного окна расположены графики основных суммарных параметров – память, дисковая, сетевая и CPU активность. При перемещении курсора по истории параметра, показан процесс который дал максимальный вклад в это значение в данный момент времени. Кроме того в тултипе есть информация о мгновенном значении параметра (зависит от частоты обновления). На следующей картинке — график сетевой активности.
В окне «system information» графики собраны вместе, здесь удобнее смотреть корреляцию параметров.
Суммарные графики активности в трее, процесс с максимальной активностью
Очень удобная фича – выведение в трей иконок с графиками суммарной активности. Там могут быть графики дисковой активности, CPU и память. Я использую первые два – поглядываю туда, при возникновении вопросов достаточно навести курсор и узнать какой процесс дает максимальный вклад в параметр. К сожалению сетевую активность туда нельзя выставить, я надеюсь это вопрос времени.
Сетевые соединения процесса
В свойствах процесса в закладке TCP/IP можно посмотреть текущие активные соединения. К сожалению сетевая активность по ним не видна, эта функциональность пока доступна в другой утилите – tcpview.
Потоки процесса, их активность, стек потока с загрузкой символов
В свойствах процесса в закладке threads видны все его потоки и загрузка CPU по потокам. Допустим хочется рассмотреть стек потока, который интенсивно что-то делает или висит. Для этого сперва надо его распознать, допустим по загрузке CPU, потом полезно приостановить процесс, чтобы спокойно рассмотреть его состояние — это можно сделать прямо в этом окне по кнопке “suspend”. Далее выделяем поток и нажимаем “stack”. В большинстве случаев стек будет начинаться в недрах системы и обрываться не совсем понятным образом. Дело в том, что не имея отладочной информации по системным библиотекам не удастся корректно развернуть стек и разобраться в нем. Есть решение – нужно сконфигурировать доступ с символьной информации с сайта Microsoft. Надо проделать несколько шагов:
Информация по использованию памяти в системе
В окне «system information» закладка «memory». Здесь есть два графика – commit и physical. Physical – использование физической памяти без учета файлового кэша, под который уходит все что остается. Commit – сколько памяти выделено для процессов включая используемую виртуальную память. Под графиками в разделе «Commit Charge» есть поля Limit и Peak. Limit определяется суммой физической и виртуальной памяти, т.е. это максимальный суммарный объем памяти, который может выделить система. Peak – это максимум графика Commit за время работы утилиты. Процентные соотношения Current/Limit и Peak/Limit удобны для быстрой оценки насколько состояние системы приближалось к критическому лимиту по доступной памяти.
Handles и DLL процесса
В главном окне можно включить разделитель и снизу отображать DLL или handles выделенного процесса. При борьбе с вирусами и отладке программ это бывает очень полезно. На картинке — список handles для opera, первый handle файловой системы – это flash ролик в временном каталоге.
Для DLL можно добавить колонку с полным путем к образу, отсортировав по нему, проанализировать нет ли каких подозрительных модулей. На картинке видно, что подключен модуль от Logitech, есть подозрение что это что-то типа хука внедряющегося во все процессы. Следующим пунктом посмотрим где он еще встречается.
Поиск handles и DLL
Поиск по имени handle или DLL во всех процессах. Вводим имя DLL от Logitech из предыдущего пункта и убеждаемся что подключается он почти везде.
Другой пример – надо понять, кто блокирует файл или работает с папкой. Вводим часть пути и находим все процессы, которые открыли подобные объекты системы. Можно щелкнуть на элементе из списка и перейти к процессу, при этом будет подсвечен соответствующий handle или DLL.
PS Для отображения некоторых полей (например сетевая статистика) требуются административные привилегии. Повысить привилегии в уже запущенном Process Explorer можно с помощью команды в меню File. Только при наличии таких привилегий есть возможность добавить такие колонки. Я считаю такое поведение неверным, т.к. скрывает потенциальные возможности приложения от пользователя. Если поля добавлены и при следующем запуске нет административных прав, то они будут пустыми. Можно задать ключ «/e» в командной строке, чтобы форсировать поднятие привилегий при старте Process Explorer.
Here be dragons: Управление памятью в Windows как оно есть [1/3]
Каталог:
Один
Два
Три
Менеджер памяти (и связанные с ним вопросы контроллера кеша, менеджера ввода/вывода и пр) — одна из вещей, в которой (наряду с медициной и политикой) «разбираются все». Но даже люди «изучившие винду досконально» нет-нет, да и начинают писать чепуху вроде (не говоря уже о другой чепухе, написанной там же):
Грамотная работа с памятью. За все время использования у меня своп файл не увеличился ни на Килобайт. По этому Фаерфокс с 10-20 окнами сворачивается / разворачивается в/из трея как пуля. Такого эффекта я на винде добивался с отключенным свопом и с переносом tmp файлов на RAM диск.
Цель данной статьи — не полное описание работы менеджера памяти (не хватит ни места ни опыта), а попытка пролить хоть немного света на темное царство мифов и суеверий, окружающих вопросы управления памятью в Windows.
Disclaimer
Сам я не претендую на то, чтобы знать все и никогда не ошибаться, поэтому с радостью приму любые сообщения о неточностях и ошибках.
Введение
С чего начать не знаю, поэтому начну с определений.
Commit Size — количество памяти, которое приложение запросило под собственные нужды.
Working Set (на картинке выше он так и называется Working Set) — это набор страниц физической памяти, которые в данный момент «впечатаны» в адресное пространство процесса. Рабочий набор процесса System принято выделять в отдельный «Системный рабочий набор», хотя механизмы работы с ним практически не отличаются от механизмов работы с рабочими наборами остальных процессов.
И уже здесь зачастую начинается непонимание. Если присмотреться, можно увидеть, что Commit у многих процессов меньше Working Set-а. То есть если понимать буквально, «запрошено» меньше памяти, чем реально используется. Так что уточню, Commit — это виртуальная память, «подкрепленная» (backed) только физической памятью или pagefile-ом, в то время как Working Set содержит еще и страницы из memory mapped файлов. Зачем это делается? Когда делается NtAllocateVirtualMemory (или любые обертки над heap manager-ом, например malloc или new) — память как бы резервируется (чтоб еще больше запутать, это не имеет никакого отношения к MEM_RESERVE, который резервирует адресное пространство, в данном же случае речь идет о резервировании именно физических страниц, которые система действительно может выделить), но физические страницы впечатываются только при фактическом обращении по выделенному адресу виртуальной памяти. Если позволить приложениям выделить больше памяти, чем система реально может предоставить — рано или поздно может случиться так, что все они попросят реальную страницу, а системе неоткуда будет ее взять (вернее некуда будет сохранить данные). Это не касается memory mapped файлов, так как в любой момент система может перечитать/записать нужную страницу прямо с/на диск(а).
В общем, суммарный Commit Charge в любой момент времени не должен превышать системный Commit Limit (грубо, суммарный объем физической памяти и всех pagefile-ов) и с этим связана одна из неверно понимаемых цифр на Task Manager-ах до Висты включительно.
Commit Limit не является неизменным — он может увеличиваться с ростом pagefile-ов. Вообще говоря, можно считать, что pagefile — это такой очень специальный memory mapped файл: привязка физической страницы в виртуальной памяти к конкретному месту в pagefile-е происходит в самый последний момент перед сбросом, в остальном же механизмы memory mapping-а и swapping-а очень схожи.
Working Set процесса делится на Shareable и Private. Shareable — это memory mapped файлы (в том числе и pagefile backed), вернее те части, которые в данный момент действительно представлены в адресном пространстве процесса физической страницей (это же Working Set в конце концов), а Private — это куча, стеки, внутренние структуры данных типа PEB/TEB и т.д. (опять таки, повторюсь на всякий случай: речь идет только той части кучи и прочих структур, которые физически находятся в адресном пространстве процесса). Это тот минимум информации, с которой уже можно что то делать. Для сильных духом есть Process Explorer, который показывает еще больше подробностей (в частности какая часть вот той Shareable действительно Shared).
И, самое главное, ни один из этих параметров по отдельности не позволяет сделать более менее полноценных выводов о происходящем в программе/системе.
Task Manager
Столбец «Memory» в списке процессов и практически вся вкладка «Performance» настолько часто понимаются неправильно, что у меня есть желание, чтоб Task Manager вообще удалили из системы: те, кому надо смогут воспользоваться Process Explorer-ом или хотя бы Resource Monitor-ом, всем остальным Task Manager только вредит. Для начала, собственно о чем речь 
Начну с того, о чем я уже упоминал: Page File usage. XP показывает текущее использование pagefile-а и историю (самое забавное, что в статус баре те же цифры названы правильно), Виста — показывает Page File (в виде дроби Current/Limit), и только Win7 называет его так, чем оно на самом деле является: Commit Charge/Commit Limit.
Эксперимент. Открываем таск менеджер на вкладке с «использованием пейджфайла», открываем PowerShell и копируем в него следующее (для систем, у которых Commit Limit ближе, чем на 3 Гб от Commit Charge можно в последней строчке уменьшить 3Gb, а лучше увеличить pagefile):
Это приводит к мгновенному повышению «использования свопфайла» на 3 гигабайта. Повторная вставка «использует» еще 3 Гб. Закрытие процесса мгновенно освобождает весь «занятый свопфайл». Самое интересное, что, как я уже говорил memory mapped файлы (в том числе и pagefile backed) являются shareable и не относятся к какому либо конкретному процессу, поэтому не учитываются в Commit Size никакого из процессов, с другой стороны pagefile backed секции используют (charged against) commit, потому что именно физическая память или пейджфайл, а не какой нибудь посторонний файл, будут использоваться для того, чтобы хранить данные, которые приложение захочет разместить в этой секции. С третьей стороны, после меппинга секции себе в адресное пространство, процесс не трогает ее — следовательно, физические страницы по этим адресам не впечатываются и никаких изменений в Working Set процесса не происходит.
Строго говоря, пейджфайл действительно «используется» — в нем резервируется место (не конкретное положение, а именно место, как размер), но при этом реальная страница, для которой это место было зарезервировано может находиться в физической памяти, на диске или И ТАМ И ТАМ одновременно. Вот такая вот циферка, признайтесь честно, сколько раз глядя на «Page File usage» в Task Manager-е Вы действительно понимали, что она означает.
Что же до Processes таба — там все еще по дефолту показывается Memory (Private Working Set) и несмотря на то, что он называется совершенно правильно и не должен вызывать недоразумений у знающих людей — проблема в том, что подавляющее большинство людей, которые смотрят на эти цифры совершенно не понимают, что они означают. Простой эксперимент: запускаем утилилиту RamMap (советую скачать весь комплект), запускаете Task Manager со списком процессов. В RamMap выбираете в меню Empty->Empty Working Sets и смотрите на то, что происходит с памятью процессов.
Если кого-то все еще раздражают циферки в Task Manager-е, можете поместить следующий код в профайл павершелла:
В первую очередь отмечу, что кеш в Windows не блочный, а файловый. Это дает довольно много преимуществ, начиная от более простого поддержания когерентности кеша например при онлайн дефрагментации и простого механизма очистки кеша при удалении файла и заканчивая более консистентными механизмами его реализации (кеш контроллер реализован на основе механизма memory mapping-а), возможностью более интеллектуальных решений на основе более высокоуровневой информации о читаемых данных (к примеру интеллектуальный read-ahead для файлов открытых на последовательный доступ или возможность назначать приоритеты отдельным файловым хендлам).
В принципе из недостатков я могу назвать только значительно более сложную жизнь разработчиков файловых систем: слышали о том, что написание драйверов — это для психов? Так вот, написание драйверов файловых систем — для тех, кого даже психи считают психами.
Страница из лекции какого то токийского университета (эх, мне бы так):
На этом работа собственно кеш-менеджера заканчивается и начинается работа менедера памяти. Когда выше мы делали EmptyWorkingSet это не приводило ни к какой дисковой активности, но тем не менее, физическая память используемая процессом сокращалась (и все физические страницы действительно уходили из адресного пространства процесса делая его почти полностью невалидным). Так куда же она уходит после того, как отбирается у процесса? А уходит она, в зависимости от того, соответствует ли ее содержимое тому, что было прочитано с диска, в один из двух списков: Standby (начиная с Висты это не один список, а 8, о чем позже) или Modified:
Standby список таким образом — это свободная память, содержащая какие то данные с диска (в том числе возможно и pagefile-а).
Если Page Fault происходит по адресу, который спроецирован на часть файла, которая все еще есть в одном из этих списков — она просто возвращается обратно в рабочий набор процесса и впечатывается по искомому адресу (этот процесс называется softfault). Если нет — то, как и в случае со слотами кеш менеджера, выполняется PAGING_IO запрос (называется hardfault).
Modified список может содержать «грязные» страницы достаточно долго, но либо когда размер этого списка чрезмерно вырастает, либо по когда система видит недостаток свободной памяти, либо по таймеру, просыпается modified page writer thread и начинает частями сбрасывать этот список на диск, и перемещая страницы из modified списка в standby (ведь эти страницы опять содержат неизмененную копию данных с диска).
Upd:
Пользователь m17 дал ссылки на выступление Руссиновича на последнем PDC на ту же тему (хм, я честно его до этого не смотрел, хотя пост во много перекликается). Если понимание английского на слух позволяет, то чтение данного топика можно заменить прослушиванием презентаций:
Mysteries of Windows Memory Management Revealed, Part 1 of 2
Mysteries of Windows Memory Management Revealed, Part 2 of 2
Пользователь DmitryKoterov подсказывает, что перенос пейджфайла на RAM диск иногда действительно может иметь смысл (вот уж никогда б наверное и не догадался, если б не написал топик), а именно, если RAM-диск использует физическую память, недоступную остальной системе (PAE + x86 + 4+Gb RAM).
Пользователь Vir2o в свою очередь подсказывает что хотя при некоторых условиях и пожертвовав стабильностью системы ram-диск, использующий физическую память, невидимую остальной системе написать можно, но такое очень маловероятно.
Sysadminium
База знаний системного администратора
Process Explorer и память
Process Explorer и память. В этом уроке я покажу вам как наблюдать за расходованием памяти используя сторонний инструмент “Process Explorer”.
Process Explorer и память
Process Explorer выводит намного больше информации о физической и виртуальной памяти чем диспетчер задач. Для того чтобы открыть информацию по памяти откройте меню View, выберите команду System Information и перейдите на вкладку Memory:
Графики
В открывшемся окне мы видим 2 графика:
Из этого следует, что файл подкачки у меня занимает примерно 1,4 GB.
Отображаемые показатели
Ниже графиков вы можете увидеть обширную информацию по используемой памяти. Все показатели разбиты на определённые блоки, что делает обзор несколько удобнее.
Commit Charge
В этом блоке можно увидеть информацию по выделенной физической памяти (оперативной + swap). В этом блоке все показатели указаны в килобайтах.
Уже по этому блоку можно судить о том, хватает ли системе памяти.
Phisical Memory
В этом блоке уже не учитывается файл подкачки, а только оперативная память. Точно так же все значения в килобайтах.
Kernel Memory
Здесь дана информация по выгружаемому и невыгружаемому пулу ядра.
Эти лимиты ограничены операционной системой, но по факту будет действовать физическое ограничение. Система просто не сможет выделить 16 TB памяти, так как у меня даже на диске такого объёма нет.
Paging
В этом блоке можно наблюдать процесс свопинга. То есть когда у вас не хватает памяти и данные сбрасываются в файл подкачки (swap). Здесь данные отображаются в виде дельты, то есть количество за определённый период, который равен периоду обновления программы.
Paging List
Этот блок разбирать пока не буду. Он будет описан в уроке посвящённом физическим страницам памяти. У физических страниц есть свои состояния и в этом блоке они описаны. В общем читайте дальше и все станет понятнее.
System commit что это
Автор последнего диалога задавался вопросом, что такое доступная(available) память. Без технических подробностей, которые довольно таки сложны, память(озу), с точки зрения ее содержимого делится, на занятую, кэшированную, свободную и недоступную.
Кэшированная память – это память, которая хранит недавно использованный программами контент, файлы например, либо файлы загруженные в озу суперфетчем. Память не является выделенной, но если программе понадобилось содержимое файла, который кэширован, операционной системе не придется осуществлять долгую операцию чтения с диска, ей всего лишь понадобится поправить пару структур и эта память вновь станет занятой и принадлежать программе. Есть детали, о них в другой раз.
Свободная память – это память, которая ни кому не передана и не содержит какого-либо полезного содержимого, либо обнулена.
Доступная память эта сумма памяти свободной + памяти кэшированной. Когда очередной программе нужна чистая память, операционная система выделяет ей эту память из свободной, то есть обнуленной. Если по какой-то причине обнуленной памяти не хватает, либо уже исчерпана, операционная система чистит кэшированную память и выделяет ее приложению.
Недоступная – эта та память, адреса для которой, заняты для адресации оборудования, либо сбойная память.
1. Смотрим как растет Current System Commit при этом доступная(available) память остается прежней.
2. Смотрим как растет Current System Commit при этом доступная(available) память уменьшается.
3. Смотрим как уменьшается доступная(available) память при этом Current System Commit остается прежним.
4. Смотрим как данные по памяти testmem в программах, включяя VmMap, никак не меняются, хотя Current System Commit растет. Утечка.
Тест 1. Запускаем 64-х разрядный testmem, выбираем commit shared memory(pagefile), в поле объем вводим 1000Мб, жмем ок несколько раз и наблюдаем рост Current System Commit до того момента пока система не напишет нехватка памяти. Последний блок в зависимости от текущего выделения на вашей системе может быть не кратен 1000Мб, поэтому введите остаток.
Тест2. Запускаем 64-х разрядный testmem, выбираем commit and touch memory, в поле объем вводим 1000Мб, жмем ок и наблюдаем рост Current System Commit и уменьшение доступной памяти(рост Physical Memory)
Тест3. Запускаем любой testmem, выбираем commit shared memory(mapped file), в поле объем вводим 1000Мб, жмем один раз ок и наблюдаем уменьшение доступной памяти(рост Physical Memory) при неизменном Current System Commit.
Тест4. Запускаем 32-х разрядный testmem, выбираем commit shared memory(pagefile), потом запускаем VmMap и видим данные по памяти testmem. Нажимаем один раз ок, наблюдаем рост Current System Commit на этот объем, после чего обновляем VmMap и видим как появилось 1000МБ в поле Shereable. Снова нажимаем ок, снова наблюдаем рост Current System Commit на этот объем, после чего обновляем VmMap и видим что другого блока из 1000Мб не появилось. Можно нажать еще раз пока не дойдете до Commit Limit, но памяти так в программе и не появится. Это и есть утечка. Ловить такую очень сложно, точнее долго.
Что делает каждый из этих кусков кода по выделению памяти подробней расскажу в другой как-нить раз)
System commit что это
Этот форум закрыт. Спасибо за участие!
Спрашивающий
Вопрос
Добрый день, коллеги!
Кто может подсказать, как расследовать причину утечки физической памяти. Виртуальная память при этом в норме.
Соответственно, если смотреть память по процессам в proces explorer, то там тоже все нормально. Главное, не понятно кто, занял и чем занял.
Все ответы
> это та память, которую система всегда готова предоставить приложениям
А разве вы не про stanby память говорите? Так она как раз в Physical memory учтена в пункте Available, а не System Cache. Обычно изменение памяти System commit и Physical memory идут синхронно. System commit всегда немного больше (из-за файла подкачки). Но когда наблюдается такой дисбаланс, как на картинке из первого сообщения и когда у Physical memory кончается свободная память, а System commit при этом остается также доступной система начинает просто виснуть. Наблюдал такое уже не раз. Даже определил процесс, после удаления которого память освобождается. Просто сейчас хочется разобраться в следствие чего это происходит и как определить кто виновник, не убивая процессы)). В process explorer в дереве процессов по Private Bytes/Working Set вообще не видно кто конкретно ест память, там как будто все хорошо.
ОС Windows Server 2003.
Прикладываю скриншот Windows 7 когда память расходуется адекватно.
Вот как раз Rammap и не могу воспользоваться, т.к. он работает начиная с семейства Windows NT 6. Может вы знаете другие утилиты?
Обычно изменение памяти System commit и Physical memory идут синхронно.
Прикладываю скриншот Windows 7 когда память расходуется адекватно.
1. Вовсе не обязательно. Зависит от запущенных программ.
2. Это не «адекватное использование», а картина нехватки оперативной памяти.
2. Может не совсем удачный скрин, но для моей рабочей станции вполне адекватное использование. Это запущенная опера на движке хромиум, и еще скайп, что тут уж сделаешь. А чтобы судить есть ли нехватка или нет, нужно смотреть на очередь к диску и Page Fault, у меня пока эти показатели в норме. И трудностей в работе не ощущается.
1. Вот только на сервере, где проявляется такое поведение памяти как из 1го сообщения, наблюдаются проблемы, когда System Cache съедает все. А вот на серверах, где с памятью проблем нет, картина всегда примерно одна и та же:
и т.д. Могу еще 3-4 серверов привести примеры, везде одно и то же. Запущены примерно одни и те программы. Единственное отличие, что проблема на сервере 2003, а скриншоты с серверов WinОС более высоких версий.
Вроде ответ на свой вопрос я нашел:
А вот чем можно смотреть, кроме отладчика, я не подскажу.