Commit charge что это
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
Этот блок разбирать пока не буду. Он будет описан в уроке посвящённом физическим страницам памяти. У физических страниц есть свои состояния и в этом блоке они описаны. В общем читайте дальше и все станет понятнее.
Commit charge что это
This forum has migrated to Microsoft Q&A. Visit Microsoft Q&A to post new questions.
Answered by:
Question
Answers
In short, my understanding is Virtual Memory is combined with Physical Memory and page files on disk. Committed Memory, also called committed virtual memory, is used or allocated Virtual Memory.
The amount of committed virtual memory for all the active processes is called the current commit charge. When a process commits a region of virtual memory, the operating system guarantees that it can maintain all the data the process stores in the memory either in physical memory or on disk. That means that a process can run up against another limit: the commit limit.
I suggest reading the following article, especially the «Committed Memory» section.
Pushing the Limits of Windows: Virtual Memory
http://blogs.technet.com/markrussinovich/archive/2008/11/17/3155406.aspx
Thanks.
This posting is provided «AS IS» with no warranties, and confers no rights.
All replies
Also you have to understand the process architecture ( not processor ) along with thread architecuture ( major ones are understanding process control block and thread control block.)
But i would like to simplify the concepts and try to give out my best.
windows operating system uses 2 major memory models
a) main memory model
b) virtual memroy model
virtual memroy is nothing but using the disk space to provide applicatoins a feel of using contiguous memory address space. windows OS has 4GB reserved for user mode and 4GB for kernel mode.
to simplify you need to understand major concepts like
page : A page is a ocntiguous block of address space / virtual memory they are divided into 4kbytes. So internally applications are divided into pages in a broader picture.
By said this there is a corresponding page table which is a datastructure which stores logical to physical address mappings ( virtual memory to physical memory )
So now commit charge is nothing but total amount of virtual address space and in other words you can think of commit charge as maximum pagefile usage.
when you open any application the commit charge increases and closed it decreases because its just the usage of the total pagefile.
some of the important issue which one might look with respect to commit charge is
a) commit charge keeps increasing but not decreasing even when applications are opened or closed.
b) commit charge increases and decreases with only some applications installed
at this point you need to check how the page file is configured.
is there any issue with the process / application which might not close the handles etc.
hope this info is useful.
Sainath IRP_MJ_CREATE
«Committed Memory – When an application touches a virtual memory page (reads/write/programmatically commits) the page becomes a committed page. It is now backed by a physical memory page. This will usually be a physical RAM page, but could eventually be a page in the page file on the hard disk, or it could be a page in a memory mapped file on the hard disk. The memory manager handles the translations from the virtual memory page to the physical page. A virtual page could be in located in physical RAM, while the page next to it could be on the hard drive in the page file.»
But is lower in comments David Solomon gives the corrections:
Committed Memory – «When an application touches a virtual memory page the page becomes a committed page. It is now backed by a physical memory page»
Not quite: a page becomes a «committed page» when an application commits virtual memory. At that time, the Memory Manager deducts from the system commit limit and charges it to the Commit Charge Total. If and when it is actually touched, then the memory manager backs it with a physical page (that part you had correctly).
Now I have completely got confused 🙂 What is commit memory? Just virtual memory? These two terms are equivalent? And «total commit memory» == «total virtual memory» of all app and OS which now in use? But by screenshot from my server it not so. (http://img38.imageshack.us/img38/3619/commitcharge2.gif)
What ideas? I will be glad to any explanations.
Мониторинг физической против значения выделенной памяти
Доброго времени суток! Текущий блог я бы хотел посветить цифрам потребления оперативной памяти и немного рассказать о вариантах мониторинга и различиях в потреблении.
Натолкнул меня на эту мысль мой хороший коллега под ником М., у которого я так же обнаружил некорректные цифры потребления оперативной памяти. Да, они часто встречаются в видео и комментариях, где ребята тщетно пытаются выяснить у кого больше FPS и, в частности, показать работоспособность данной игры на конкретно выбранном компьютере. Но ровно как FPS, без показателей минимальных значений 0.1/1, времени кадра и максимального значение, это всего лишь среднее значение в данный момент, так и потребление озу, в варианте «физической», цифра, что не отражает реального потребления оперативной памяти всех процессов. Да да, у нас есть две цифры на выбор в программах и даже в диспетчере задач, в разделе «производительность» и вкладке «память», есть используемая (сжатая) и выделенная. Обратите внимание, что эти цифры отличаются, при том выделенная заметно больше. Сразу скажу, что в силу своего непрофессионализма данной области, блог будет иметь характер, с точки зрения простого пользователя.
Итак, в английском языке «выделенная память» в windows 10 называется commit charge (в диспетчере задач просто committed). Если интересует подробности данного термина и его характеристика, то вы теперь всегда можете узнать больше в интернете. Однако здесь, я попробую вкратце охарактеризовать простыми словами. Конечно этот параметр можно найти, к примеру в MSI Afterburner, сразу под строчкой Загрузка ОЗУ (RAM Usage) и в HWiNFO, части сенсоров, подраздела System: X System Product Name, где X название ваше материнской платы, а сама строчка Virual memory Committed и Virual memory Available, т.е. занятая и свободная виртуальная память (всё верно, виртуальная или выделенная память). Стоит внести ясность, что если у вас есть файл подкачки, то это значение будет просуммировано с объёмом вашей оперативной памяти.
Итак, к цифрам. Начнём с наиболее яркого примера – RDR2, где в моём бенчмарке указано 18 Гб потребления оперативной памяти. Чего не скажешь о моём коллеге М. (скриншот), где только 9,6 Гб, зато яркая строчка DDR4 – 32Gb (4000MHz).
Зачем там 32 Гб, если потребление не больше 10-ти? И можно подумать, что я специально излишне нагружаю оперативную память бразуером с 300 вкладками. Последнее опровергается просто – в конце видео (ниже под спойлером) продемонстрирован диспетчер задач, в том числе видно время работы ПК и вкладка памяти – используется (сжатая), которая соответствует 10,5 Гб и выделено уже 18Гб. Да, значение используемой память похоже на значение со скриншота товарища М. Выделенная больше физической всегда, и об этом дальше.
Стоит напомнить, что файл подкачки (ФП) служит для расширения оперативной памяти, т.е. используется при её нехватке. Система может отправлять неактивные или свёрнутые программы в ФП, так у меня как то оказалась Far Cry: New Dawn там. В моём случае 18 Гб превратятся 16 в оперативной и 2 Гб занято в ФП. Хотя нет, сейчас у меня 32Гб (2х16) и отключенный ФП, а значит всё в оперативной памяти. Проблем с этим нет вот уже многие годы. А это значит, если у тебя 16 Гб (или меньше), то отключать его не стоит, поскольку при неправильном мониторинге (выбранной загрузка озу или мониторинг физической памяти), в данной игре будет вылет с последующим сообщением о нехватке памяти, и удивлённым, вопрошающим лицом – «почему же при 10 Гб потребления ОЗУ в RDR2 у меня нехватка памяти?». Наконец перейдём к определению и всё что я нашёл о выделенной памяти и причинах, почему данное значение больше.
Как гласит сайт майкрософт, выделенная (так же виртуальная) – максимально доступная память, включающая все файлы подкачки, которую система может поддерживать. Если это значение достигает предела, система и процессы могут не получить выделенную память. Это состояние может вызвать зависание, сбой и другие неисправности.
Попросту это виртуальное адресное пространство частного процесса, часть которого может находится как в ОЗУ, так и файле подкачки. Так существуют и неиспользуемые, выделенные, области для будущих обращений программ. Поэтому это значение больше, чем физическая (используемая). Т.е. по сути, это место зарезервировано операционной системой под кэш, драйвера, программу и т.д. Не забывайте, что очистку кэша можно произвести и такой программой, как Empty tandbyList, прописав её в планировщик заданий. В итоге, когда запускаешь windows, то уже увидишь порядка 4 Гб в ОЗУ реально занятного пространства, а спустя, условно, часов 5 порядка 5-6 Гб. И совсем необязательно это строго область файла подкачки (пространство в HDD/SSD). Личное наблюдение в течении суток (и более при системе 32 и 16 Гб) показало, что у меня был занят в простое файл подкачки порядка 50 мегабайт, максимум 300. Сам файл подкачки «по выбору системы» и объём автоматически увеличивался, по мере необходимости. При фиксации 2Гб (наличии планок 8+8) вылетела ошибка нехватки, т.к. объём перевалил уже за 18Гб. Для меня наиболее ярким примером являются вышеупомянутая RDR2, а так же ARK, Tom Clancy’s The Division 2, Horizon Zero Dawn К последним играм, прогулявшись по youtube, я даже нашёл пару роликов, где кто-то всё же догадался добавить верные значения потребления ОЗУ. Не забывайте, что игра кэширует данные в оперативную память, и всего да 10 минут в игре можно потерять порядка 2Гб уже, легко. За 2 часа игры в ARK я терял 6Гб (к доступных 16 ОЗУ + файл подкачки), а начиналось всё с 14.
Приходим к выводу, что большинство роликов, хоть здесь, хоть на youtube, и конечно комментарии, связанные с величиной FPS (и всё?), а тем более потреблением ОЗУ, с красивыми цифрами, как у моего коллеги М., это видео, которые не несут большой ценности, элементарно из-за озу, просто вводят в заблуждение. Отслеживайте правильно, отмечая верные значения, если хотите показать действительную картину работу и оптимизацию на конкретно твоей конфигурации пк. Это будет хороший пример и приятное зрелище.
Грамотные и приятные комментарии по делу, критика, всегда приветствуется. Всем спасибо!
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-диск, использующий физическую память, невидимую остальной системе написать можно, но такое очень маловероятно.