Como monitorar RAM e CPU em VPS Windows sem ferramentas pagas
Guia prático pra monitorar RAM e CPU em VPS Windows usando Task Manager, Resource Monitor, PerfMon e PowerShell — sem instalar nada pago.
VPS Windows Server consome RAM e CPU de forma diferente de Linux — o overhead do sistema operacional é maior, o pagefile é mais agressivo, e processos GUI ficam residentes mesmo quando ninguém está conectado via RDP. Pra um admin que precisa diagnosticar lentidão ou planejar upgrade de plano, saber qual ferramenta nativa usar em cada situação economiza horas de debug.
Este guia cobre as quatro ferramentas nativas do Windows Server pra monitorar RAM e CPU: Task Manager pra diagnóstico imediato, Resource Monitor pra análise de 60 segundos com gráfico, Performance Monitor pra coleta histórica persistente, e PowerShell pra automação e Server Core. Nenhuma exige licença adicional, instalação de agente ou conta na nuvem.
Tempo estimado de execução: 25 a 35 minutos pra configurar todas as ferramentas e gravar o primeiro Data Collector Set com dados reais.
Pré-requisitos
Você precisa de Windows Server 2019, 2022 ou 2025 com acesso RDP usando conta administradora local ou de domínio. PowerShell 5.1 ou superior já vem por padrão. Pra Server Core, conexão via WinRM ou console direto. Cerca de 200 MB livres em disco se você for habilitar Data Collector Sets persistentes.
Windows Server 2022 3389 5.1 Administrator Task Manager pra diagnóstico imediato
Task Manager é a primeira parada quando algo está visivelmente errado — RDP lento, aplicação travando, alerta de monitoramento externo. Em três cliques você vê quem está consumindo o quê.
Conecte via RDP e abra Task Manager com Ctrl+Shift+Esc. Se aparecer a versão compacta, clique em “More details” no canto inferior esquerdo pra expandir.
Vá pra aba “Performance” — você verá gráficos de CPU, Memory, Disk e Ethernet em tempo real. Clique em “Memory” pra ver detalhes da RAM.
Identifique os números que importam no painel de memória:
- In use: RAM física ocupada agora por processos.
- Available: RAM livre + standby (cache que pode ser liberado).
- Committed: total reservado incluindo pagefile, no formato “atual/máximo”.
- Cached: dados em standby que podem ser descartados se outro processo precisar.
Se “Committed” estiver próximo do máximo, o sistema está usando pagefile pesado. Aumente RAM ou identifique o processo que está vazando memória.
Vá pra aba “Details” e clique no cabeçalho da coluna “Memory (private working set)” pra ordenar do maior pro menor. Os 5 processos no topo respondem por 80% do consumo na maioria dos servidores.
Pra CPU, ordene pela coluna “CPU” — mas atenção: o valor mostrado é instantâneo, oscila muito. Pra média confiável, use Resource Monitor.
A coluna “Memory (private working set)” mostra apenas RAM exclusiva do processo. A coluna “Memory (shared working set)” mostra DLLs compartilhadas. Pra calcular impacto real, considere o private — é o que sumiria se você matasse o processo.
Resource Monitor pra análise de 60 segundos
Resource Monitor (resmon.exe) traz visão detalhada com gráficos rolantes dos últimos 60 segundos. Use quando Task Manager mostrou que algo está alto mas você precisa entender o padrão.
Pressione Win+R, digite resmon e Enter. A janela tem 5 abas: Overview, CPU, Memory, Disk, Network. Os gráficos à direita atualizam a cada segundo.
Vá pra aba “Memory”. Você verá processos ordenados por uso, com colunas Commit, Working Set, Shareable e Private. A diferença pra Task Manager é o gráfico inferior — “Used Physical Memory” mostra hardware em modo barra horizontal: Hardware Reserved, In Use, Modified, Standby e Free.
Pra investigar CPU, vá pra aba “CPU”. Marque o checkbox de um processo na lista — o gráfico “Associated Modules” mostra quais DLLs ele está executando, e “Associated Handles” lista arquivos e chaves de registro abertos.
Esse cross-reference revela coisas que Task Manager não mostra: por exemplo, um w3wp.exe (IIS) consumindo CPU porque está travado num arquivo de log que outro processo deixou bloqueado.
O percentual mostrado em “Maximum Frequency” no Resource Monitor pode passar de 100% se o processador tiver Turbo Boost ativo. Em VPS isso pode aparecer mesmo sem Turbo real, dependendo de como a virtualização expõe os cores. Use ”% CPU Usage” como referência principal.
Performance Monitor pra histórico persistente
Resource Monitor mostra só 60 segundos e perde tudo ao fechar. Pra rastrear consumo de RAM e CPU ao longo de horas, dias ou semanas, configure Data Collector Sets no Performance Monitor.
Abra Performance Monitor (perfmon.exe). No painel esquerdo, expanda “Data Collector Sets” → “User Defined”. Clique direito → New → Data Collector Set.
Nome: RAM_CPU_Baseline. Selecione “Create manually (Advanced)” e clique Next. Marque “Performance counter” e Next.
Em “Performance counters”, clique Add e selecione estes contadores essenciais:
\Processor(_Total)\% Processor Time
\Memory\Available MBytes
\Memory\Committed Bytes
\Memory\Pages/sec
\Memory\Page Faults/sec
\Process(*)\Working Set
\Process(*)\% Processor Time
\System\Processor Queue LengthConfigure “Sample interval” pra 15 segundos. Em produção, 60 segundos é suficiente — intervalos curtos demais geram arquivos enormes sem ganho de precisão.
Escolha o diretório de saída (padrão %systemdrive%\PerfLogs\Admin\RAM_CPU_Baseline). Clique Finish. Botão direito no Data Collector Set criado → Start. A coleta começa imediatamente em formato binário .blg.
Pra parar depois de algumas horas, botão direito → Stop. O arquivo aparece em “Reports” → “User Defined” → seu set. Clique duas vezes pra abrir o gráfico histórico.
Pra abrir os dados em Excel ou enviar pra uma stack de análise, converta o .blg pra CSV: relog C:\PerfLogs\Admin\RAM_CPU_Baseline\DataCollector01.blg -f CSV -o saida.csv. O comando relog vem com Windows Server, não precisa instalar nada.
PowerShell pra automação e Server Core
Em Windows Server Core não tem GUI — PowerShell é a única opção. Mesmo em Server com GUI, scripts são úteis pra coletar métricas em vários servidores simultaneamente ou enviar pra um endpoint externo.
Pra um snapshot rápido de RAM e CPU agora, rode no PowerShell:
Get-CimInstance Win32_OperatingSystem | Select-Object `
@{N='RAM_Total_GB';E={[math]::Round($_.TotalVisibleMemorySize/1MB,2)}}, `
@{N='RAM_Livre_GB';E={[math]::Round($_.FreePhysicalMemory/1MB,2)}}, `
@{N='RAM_Uso_Pct';E={[math]::Round((($_.TotalVisibleMemorySize - $_.FreePhysicalMemory) / $_.TotalVisibleMemorySize) * 100, 2)}}
Get-CimInstance Win32_Processor | Select-Object Name, LoadPercentageO resultado mostra RAM total, livre e percentual de uso, mais a carga média da CPU no momento.
Pra identificar os top 10 processos consumindo RAM, ordenados:
Get-Process | Sort-Object WorkingSet64 -Descending |
Select-Object -First 10 `
Name, Id, `
@{N='RAM_MB';E={[math]::Round($_.WorkingSet64/1MB,2)}}, `
@{N='CPU_seg';E={[math]::Round($_.CPU,2)}} |
Format-Table -AutoSizeO campo CPU mostra segundos totais de CPU consumidos pelo processo desde que iniciou — útil pra identificar processos antigos que acumularam carga.
Pra monitoramento contínuo a cada 30 segundos, salve este script como monitor.ps1:
while ($true) {
$ts = Get-Date -Format 'yyyy-MM-dd HH:mm:ss'
$cpu = (Get-CimInstance Win32_Processor).LoadPercentage
$os = Get-CimInstance Win32_OperatingSystem
$ramPct = [math]::Round((($os.TotalVisibleMemorySize - $os.FreePhysicalMemory) / $os.TotalVisibleMemorySize) * 100, 2)
"$ts CPU=$cpu% RAM=$ramPct%" | Out-File -Append C:\PerfLogs\monitor.log
Start-Sleep -Seconds 30
}Execute em segundo plano: Start-Process powershell -ArgumentList "-File C:\scripts\monitor.ps1" -WindowStyle Hidden. O log fica em formato simples, fácil de processar com Get-Content depois.
Verificação
Pra confirmar que cada ferramenta está coletando dados corretamente:
# Confirma que o Data Collector Set está rodando
logman query RAM_CPU_Baseline
# Lista os arquivos .blg gerados
Get-ChildItem C:\PerfLogs\Admin\RAM_CPU_Baseline\ -Recurse -Filter *.blg
# Confirma que o script monitor.ps1 está gravando
Get-Content C:\PerfLogs\monitor.log -Tail 5
Saída esperada: logman query deve mostrar Status: Running, deve haver pelo menos um .blg no diretório (mesmo que pequeno), e o log do PowerShell deve mostrar linhas recentes com timestamps dos últimos minutos.
Resolução de problemas
Performance Monitor não cria o arquivo .blg
Verifique permissões na pasta de saída. O usuário “SYSTEM” precisa ter escrita em C:\PerfLogs. Rode icacls C:\PerfLogs — se faltar SYSTEM com (F), conserte com icacls C:\PerfLogs /grant SYSTEM:F /T. Também confirme que o disco tem ao menos 500 MB livres, senão o coletor para silenciosamente.
Get-Counter retorna “Path could not be found”
Acontece quando o sistema está em outro idioma (português, espanhol) e os contadores aparecem com nomes traduzidos. Use a sintaxe numérica em vez da textual: (Get-Counter '\2\6').CounterSamples.CookedValue retorna ”% Processor Time” independente do idioma. A lista completa de IDs está em HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Perflib\009\Counter.
Resource Monitor mostra processo “System” consumindo muita RAM
O processo System (PID 4) com working set alto geralmente indica driver vazando memória ou cache de filesystem agressivo. Use poolmon.exe (parte do Windows Driver Kit) pra ver qual tag de pool está crescendo. Em VPS, é comum que drivers de paravirtualização (rede ou disco) precisem update.
Próximos passos
Com as quatro ferramentas dominadas, você tem cobertura completa de monitoramento sem custo adicional. Pra avançar:
- Configure alertas no Performance Monitor (botão direito no Data Collector Set → Properties → Alerts) pra disparar quando RAM disponível cair abaixo de 500 MB.
- Use WMI Events em PowerShell pra ações automáticas — reiniciar serviço quando CPU passar de 90% por mais de 5 minutos.
- Centralize logs de vários servidores em uma única estação via Event Forwarding ou Windows Admin Center.
- Estude os contadores de Memory\Pool Paged Bytes e Pool Nonpaged Bytes pra detectar vazamentos no kernel cedo.
Se você está provisionando ambientes Windows pra produção, uma VPS Hostini com plano otimizado pra Windows Server já vem com RAM dedicada (sem oversubscription), o que torna a leitura dos contadores Available MBytes e Committed Bytes confiável — em ambientes super-alocados, os números do guest podem mentir.
Perguntas frequentes
Qual a diferença entre Memory In Use e Committed no Task Manager?
In Use é a RAM física efetivamente ocupada por processos no momento. Committed é a soma da RAM física mais o pagefile reservados pelo sistema — pode passar da RAM total porque inclui memória virtual. Se Committed cresce acima de 1.5x a RAM física, o servidor está fazendo paging pesado e a CPU vai sofrer com I/O de disco.
Por que o uso de CPU no Task Manager difere do Resource Monitor?
Task Manager mostra utilização média no intervalo de refresh (1-2s), enquanto Resource Monitor mostra média por core nos últimos 60 segundos com gráfico. Em cargas spike, Task Manager pode mostrar 100% momentâneo que o Resource Monitor suaviza. Pra debugging de processos travando, use Resource Monitor — o gráfico histórico revela padrões.
Posso rodar Performance Monitor sem impacto na produção?
Sim, contadores PerfMon têm overhead mínimo (<1% CPU) quando coletados em intervalos de 15s ou maiores. O custo aparece quando você loga centenas de contadores a cada 1 segundo. Pra produção, configure Data Collector Sets com intervalo de 60s e mantenha só os 8-10 contadores que importam pro seu caso.
Como vejo qual processo está consumindo RAM em Windows Server Core?
Sem GUI, use PowerShell: Get-Process | Sort-Object WorkingSet64 -Descending | Select-Object -First 10 Name, Id, @{N='RAM_MB';E={[math]::Round($_.WorkingSet64/1MB,2)}}. WorkingSet64 mostra RAM física real, diferente de PrivateMemorySize que inclui pagefile. Pra CPU, troque por CPU em vez de WorkingSet64.
O contador Available MBytes está alto mas o servidor está lento. Por quê?
RAM disponível alta com sistema lento geralmente indica pressão de disco ou CPU, não memória. Verifique Disk Queue Length (deve ficar abaixo de 2) e Processor Time. Outra causa é working set pequeno demais — o Windows pode estar fazendo trim agressivo de páginas que processos usam logo depois, gerando page faults constantes mesmo com RAM livre.
Quanto tempo de histórico o Resource Monitor guarda?
Resource Monitor mostra os últimos 60 segundos em tempo real e não persiste dados após fechar. Pra histórico de horas, dias ou semanas, configure Data Collector Set no PerfMon com saída em .blg — ele grava em disco e você revisa depois no próprio PerfMon ou exporta pra CSV via relog.exe.