Как частные байты процесса могут быть значительно меньше, чем его влияние на системный коммит?
На 64-битной Windows Server 2003, я вижу, используя taskmgr или Process Explorer, что общая сумма за коммит составляет около 3,5 ГБ, но когда я суммирую частные байты, потребляемые каждым процессом (запустив pslist -m и добавив все значения под Priv колонка) итого входит в 1.6ГБ.
Я знаю, какой процесс, по-видимому, вызывает это (sqlservr.exe), так как, когда я завершаю процесс, плата за коммит резко падает. Однако рассматриваемый процесс потребляет всего ~220 МБ приватных байтов, но при его уничтожении процесс загрузки уменьшается на ~1,6 ГБ.
Как это возможно? Как плата за фиксацию может быть значительно больше, чем частные байты, которые должны представлять объем выделенной памяти? Если какой-то другой фактор влияет на плату за фиксацию, что это за фактор и как я могу увидеть его влияние в Process Explorer?
Примечание: я утверждаю, что я уже понимаю разницу между зарезервированной и зарезервированной памятью: мои исследования, приведенные выше, относятся конкретно к закрытым байтам, которые включают только зафиксированную память и исключают зарезервированную память. Виртуальный размер процесса в этом случае превышает 4 ГБ, но это не имеет значения - виртуальный размер в procxp представляет зарезервированную, а не зафиксированную память, и не должен вносить вклад в плату за фиксацию.
Меня особенно интересуют обобщенные ответы на этот вопрос: я предполагаю, что если sqlservr.exe может вести себя таким образом, то любой процесс потенциально может.
Дальнейшие исследования
Я заметил, что указание Sysinternals VMMap на этот процесс сообщает о выделенных "личных данных" объемом 1,6 ГБ, несмотря на то, что Procexp сообщил о личных байтах размером 220 МБ. Это особенно странно, учитывая, что документация для этого поля в "Справочнике администратора Windows® Sysinternals" гласит:
Память личных данных - это память, которая выделяется VirtualAlloc и не обрабатывается далее диспетчером кучи или средой выполнения.NET или присваивается категории стека... Определение "Частные данные" в VMMap более детализировано, чем в Process Explorer. "Частные байты". "Частные байты" Procexp включают в себя всю частную зафиксированную память, принадлежащую процессу.
т. е. что "частные данные" в VMMap должны быть меньше, чем "частные байты" procxp.
Кроме того, после прочтения раздела "Обработка выделенной памяти" в прекрасном " Раздвигая границы Windows: виртуальная память" Марка Руссиновича, он выделяет два случая, которые не будут отображаться в "Частных байтах":
- Представления сопоставления файлов с семантикой копирования при записи (однако, согласно VMMap, в Mapped Files не выделяется значительное пространство).
- виртуальная память на основе файла подкачки (однако я попытался использовать testlimit с
-lпомечать как предложено, и значительная часть памяти не используется разделами на основе файла подкачки)
1 ответ
Редактировать: Обратите внимание, что раздел комментариев теперь не имеет значения, потому что мой первоначальный ответ исчез.
Ваш вопрос:
Как частные байты процесса могут быть значительно меньше, чем его влияние на системный коммит?
На это можно ответить прямой цитатой от Марка Руссиновича:
Существует два типа виртуальной памяти процесса, которые учитываются при ограничении фиксации: частная и с подкачкой файла подкачки.
Приватные байты, приписываемые процессу, могут быть (и часто меньше), чем влияние этих процессов на плату за фиксацию системы, поскольку процесс также может выделять виртуальную память на основе файла подкачки.
Виртуальную память на основе файла подкачки трудно отнести к конкретному процессу, поскольку она разделяется между процессами. Не существует счетчика производительности, специфичного для процесса, который мог бы сказать вам, сколько виртуальной памяти на основе файла подкачки выделил или на которую ссылается какой-либо процесс, однако он все равно считается с пределом фиксации.
Эта статья является авторитетной статьей на эту тему, и в этой статье он специально демонстрирует случай, когда процесс выделил тонны виртуальной машины с поддержкой файла подкачки, и, тем не менее, частные байты процесса остаются очень низкими.
Он также показывает, как использовать handle.exe определить размер выделения дескрипторов для объектов раздела. Вот как вы можете определить, какой процесс оказывает такое большое влияние на комиссионный сбор.
Вы упоминаете, что вы уже смотрели на sqlservr.exe с handle.exe и что он не имеет дескрипторов, открытых значительному количеству объектов раздела, которые могли бы учитывать плату за фиксацию, которая освобождается при удалении sqlservr.exe,
По совпадению, есть также выделения памяти в пространстве ядра, которые оплачиваются по лимиту системного коммита, такие как выгружаемый и невыгружаемый пулы и заблокированная память драйвера, включая такие вещи, как всплывающие драйверы виртуальной машины и т. Д. Я не думаю, что это имеет отношение к это дело, но я не хотел оставлять это невысказанным.
SQL Server - это массивный, сложный продукт, состоящий из множества различных процессов, которые работают вместе в системе для предоставления всех служб SQL Server. На самом деле SQL Server имеет свой собственный менеджер внутренней памяти, который может сделать его нетипичным с точки зрения инструментов, предназначенных для измерения распределения виртуальной памяти Windows.
sqlservr.exe не действует в одиночку. Есть также
msmdsrv.exe(Аналитические услуги)sqlwriter.exe(SQL VSS Writer)sqlagent.exe(Агент SQL)fdlauncher.exe(Полнотекстовый фильтр Daemon Launcher)fdhost.exe(Полнотекстовый хост)ReportingServicesService.exeSQLBrowser.exe
Когда я убью sqlservr.exe, sqlagent.exe также умирает автоматически. Это означает, что плата за коммит системы упадет на сумму, внесенную в него обоими процессами. Другие процессы, связанные с SQL, могут также освобождать разделы на основе файла подкачки, когда sqlservr.exe убит, хотя сами процессы остаются запущенными. Все это может привести к падению текущего коммит-заряда системы, когда sqlservr.exe убит, даже если они никогда не были частью частных байтов sqlservr.exe,