Como os Bytes Privados de um processo podem ser significativamente menores do que o seu efeito na taxa de commit do sistema?

Question

Em um Windows Server 2003 de 64 bits, é possível ver usando taskmgr ou process explorer que a carga total de confirmação gira em torno de 3,5 GB, mas quando somar os Bytes privados consumidos por cada processo (executando pslist -m e adicionando todos valores sob a coluna Priv ), o total é de 1,6 GB.

Eu sei qual processo parece estar causando isso (sqlservr.exe) como quando eu mato o processo, a taxa de commit cai drasticamente. No entanto, o processo em questão está consumindo apenas ~ 220MB de Bytes Privados, mas matar o processo reduz a taxa de commit em ~ 1,6GB.

Como isso é possível? Como a taxa de commit pode ser significativamente maior do que Private Bytes, o que deve representar a quantidade de memória comprometida? Se algum outro fator contribui para o encargo de commit, qual é esse fator e como posso visualizar seu impacto no explorador de processos?

Nota: Eu afirmo que eu já entendo a diferença entre memória reservada e comprometida : minhas investigações acima se referem especificamente a Bytes privados que incluem somente confirmados memória e exclui a memória reservada. o tamanho virtual do processo, neste caso, é superior a 4 GB, mas isso deve ser irrelevante - o Virtual Size em procexp representa uma memória reservada, não comprometida, e não deve contribuir para a taxa de commit.

Estou particularmente interessado em respostas generalizadas a essa pergunta: Suponho que, se o sqlservr.exe puder se comportar dessa maneira, qualquer processo poderia fazê-lo.

Investigações adicionais

Noto que apontar o Sysinternals VMMap nesse processo relata um committed "Private Dados " de 1,6 GB, apesar do Procexp ter informado um byte particular de 220MB. Isso é particularmente estranho, já que a documentação desse campo na "Referência do Administrador do Windows® Sysinternals" declara que:

Private Data memory is memory that is allocated by VirtualAlloc and that is not further handled by the Heap Manager or the .NET runtime, or assigned to the Stack category... VMMap’s definition of “Private Data” is more granular than that of Process Explorer’s “private bytes.” Procexp’s “private bytes” includes all private committed memory belonging to the process.

i.e. que os "Dados Privados" confirmados do VMMap devem ser menores que os "Bytes Privados" do procexp.

Além disso, depois de ler a seção 'Process committed memory' do excelente Mark Russinovich Empurrando os limites do Windows: Memória Virtual , ele destaca dois casos que não aparecem em Bytes Privados:

• Exibições de mapeamento de arquivo com semântica de copy-on-write (no entanto, de acordo com o VMMap, não há espaço significativo alocado para Arquivos mapeados).
• memória virtual suportada pelo arquivo de paginação (no entanto, tentei testlimit com o -l sinalizador conforme sugerido e nenhuma memória significativa é consumida pelas seções com backup do arquivo de paginação)

Answer 1

Editar: Por favor, note que a seção de comentários agora é irrelevante porque minha resposta original se foi.

Sua pergunta:

How can the Private Bytes of a process be significantly less than its effect on the system commit charge?

Isso pode ser respondido com uma citação direta de Mark Russinovich:

There are two types of process virtual memory that do count toward the commit limit: private and pagefile-backed.

Os bytes privados atribuídos ao processo podem ser (e geralmente são) menores do que o efeito dos processos na carga de confirmação do sistema, porque o processo também pode alocar memória virtual suportada pelo arquivo de paginação.

A memória virtual suportada pelo arquivo de paginação é difícil de atribuir a um processo específico porque é compartilhável entre processos. Não há um contador de desempenho específico do processo que possa informar quanto de memória virtual suportada pelo arquivo de paginação qualquer processo alocou ou está fazendo referência, mas ainda conta contra o limite de confirmação.

Este artigo é o artigo oficial sobre o assunto, e Nesse artigo, ele demonstra especificamente um caso em que um processo alocou toneladas de VMs suportadas pelo arquivo de paginação e, no entanto, os bytes particulares do processo permanecem muito baixos.

Ele também mostra como usar handle.exe para detectar o tamanho da alocação de alças para objetos de seção. É assim que você pode detectar qual processo está tendo um efeito tão grande na taxa de commit.

Você mencionou que já examinou sqlservr.exe com handle.exe e que ele não tem alças abertas para uma quantidade significativa de objetos de seção que seriam responsáveis pela cobrança de confirmação que é liberada quando você mata sqlservr.exe .

Coincidentemente, há também alocações de memória no espaço do kernel que são carregadas contra o limite de confirmação do sistema, como pools paginados e não paginados e memória bloqueada do driver, incluindo itens como drivers de balão de máquina virtual etc. Eu não acredito é relevante para este caso, mas eu não queria deixar de dizer.

O SQL Server é um produto enorme e complexo que consiste em vários processos diferentes que trabalham juntos no sistema para fornecer todos os serviços do SQL Server. Na verdade, o SQL Server tem seu próprio gerenciador de memória interna que pode fazer com que pareça atípico do ponto de vista das ferramentas projetadas para medir as alocações de memória virtual do Windows.

sqlservr.exe não age sozinho. Há também

• msmdsrv.exe (Analysis Services)
• sqlwriter.exe (gravador de VSS do SQL)
• sqlagent.exe (agente SQL)
• fdlauncher.exe (Iniciador do Daemon do Filtro de Texto Completo)
• fdhost.exe (host de texto completo)
• ReportingServicesService.exe
• SQLBrowser.exe

Quando eu mato sqlservr.exe , sqlagent.exe também morre automaticamente. Isso significa que o encargo de confirmação do sistema será reduzido pelo valor contribuído pelos processos ambos . Os outros processos relacionados ao SQL também podem liberar seções com backup do arquivo de paginação quando sqlservr.exe é eliminado, mesmo que os processos permaneçam em execução. Tudo isso faria com que a taxa de commit atual do sistema caísse quando sqlservr.exe fosse eliminado, mesmo que eles nunca fizessem parte dos bytes privados de sqlservr.exe .