Назад | Перейти на главную страницу

Каким образом частные байты процесса могут быть значительно меньше, чем его влияние на плату за фиксацию системы?

На 64-битной Windows Server 2003 я могу видеть с помощью taskmgr или проводника процессов, что общая стоимость фиксации составляет около 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: виртуальная память, он выделяет два случая, которые не отображаются в байтах частного доступа:

Редактировать: Обратите внимание, что раздел комментариев теперь не имеет значения, потому что мой исходный ответ исчез.

Ваш вопрос:

Каким образом частные байты процесса могут быть значительно меньше, чем его влияние на плату за фиксацию системы?

На это можно ответить прямой цитатой Марка Руссиновича:

Существует два типа виртуальной памяти процессов, которые учитываются при определении лимита фиксации: частная и с поддержкой файла подкачки.

Частные байты, приписываемые процессу, могут быть (и часто имеют) меньше, чем влияние этого процесса на плату за фиксацию системы, потому что процесс также может выделять виртуальную память, поддерживаемую файлом подкачки.

Виртуальную память, поддерживаемую файлом подкачки, трудно отнести к конкретному процессу, поскольку она разделяется между процессами. Не существует счетчика производительности для конкретного процесса, который мог бы сказать вам, сколько виртуальной памяти, поддерживаемой файлом подкачки, выделил или ссылается какой-либо процесс, тем не менее, он по-прежнему учитывается в лимите фиксации.

Эта статья является авторитетной статьей по этому вопросу, и в этой статье он специально демонстрирует случай, когда процесс выделил тонны виртуальной машины с поддержкой файла подкачки, а частные байты процесса остаются очень низкими.

Он также показывает вам, как использовать handle.exe для определения размера выделения дескрипторов для объектов раздела. Вот как вы можете определить, какой процесс так сильно влияет на комиссию за фиксацию.

Вы упомянули, что уже смотрели sqlservr.exe с участием handle.exe и что у него нет дескрипторов, открытых для значительного количества объектов раздела, которые учитывали бы плату за фиксацию, которая высвобождается, когда вы убиваете sqlservr.exe.

По совпадению, есть также выделения памяти в пространстве ядра, которые взимаются с предела фиксации системы, такие как выгружаемые и невыгружаемые пулы, и память, заблокированная драйверами, включая такие вещи, как драйверы баллонов виртуальных машин и т. Д. Я не верю, что это имеет отношение к это дело, но я не хотел оставлять его невысказанным.

SQL Server - это массивный и сложный продукт, состоящий из множества различных процессов, которые работают вместе в системе для предоставления всех служб SQL Server. Фактически, у SQL Server есть свой собственный менеджер внутренней памяти, который может сделать его нетипичным с точки зрения инструментов, предназначенных для измерения распределения виртуальной памяти Windows.

sqlservr.exe действует не в одиночку. Есть также

  • msmdsrv.exe (Службы аналитики)
  • sqlwriter.exe (Модуль записи SQL VSS)
  • sqlagent.exe (Агент SQL)
  • fdlauncher.exe (Средство запуска демона полнотекстового фильтра)
  • fdhost.exe (Полнотекстовый хост)
  • ReportingServicesService.exe
  • SQLBrowser.exe

Когда я убиваю sqlservr.exe, sqlagent.exe тоже умирает автоматически. Это означает, что комиссия за фиксацию системы снизится на сумму, внесенную в нее обе процессы. Другие процессы, связанные с SQL, также могут освобождать разделы с поддержкой файлов подкачки, когда sqlservr.exe убивается, хотя сами процессы продолжают работать. Все это приведет к падению текущего заряда системы, когда sqlservr.exe убивается, даже если они никогда не были частью частных байтов sqlservr.exe.