Ocioso silencioso: segundo plano do Windows antes e depois da otimização
Nesta página
Resposta curta
Seção intitulada “Resposta curta”Desativar componentes em segundo plano do Windows realmente torna o idle mais silencioso: em duas séries independentes de medições, o número de processos caiu 49–56 %, o uso de CPU em idle — 17–67 %, e o volume de commit de memória — 52 % na segunda série. Mas sob carga total de CPU, a taxa de transferência cresceu apenas 0,2–0,5 %. “Idle silencioso” é uma redução confirmada do trabalho em segundo plano e da competição por recursos, e não um ganho de FPS: o efeito final em jogos não foi medido neste estudo.
Status: a direção do efeito foi reproduzida em duas séries independentes na mesma build do Windows 11 em uma máquina virtual. Os valores entre as séries diferem porque o trabalho em segundo plano do Windows vem em picos: em uma janela com verificação do Microsoft Defender, a diferença de uso de CPU chega a −67 %; em uma janela já silenciosa — −17 %.
Afirmação verificável
Seção intitulada “Afirmação verificável”Verificamos quatro afirmações:
- Desativar componentes em segundo plano reduz visivelmente a atividade do sistema em idle.
- Reduz visivelmente a atividade nos primeiros minutos após a inicialização.
- Reduz visivelmente o consumo de memória.
- Proporciona um ganho de desempenho mensurável sob carga total de CPU.
Escopo do estudo
Seção intitulada “Escopo do estudo”- Windows 11 Pro, build 26300.9457 (26H2);
- máquina virtual: 4 vCPU, 8 GB de RAM, virtualização VMware;
- dois estados de uma mesma instalação: original (“antes”) e após aplicar o perfil de otimização do BoosterX (build vigente nas datas das medições);
- duas séries independentes de medições: 2026-09-18 e 2026-09-19; os estados foram comparados em cópias independentes do disco, para que as medições não influenciassem umas às outras;
- fases: 5 minutos após a inicialização, 5 minutos de estabilização, 5 minutos de idle;
- cargas sintéticas curtas: 1, 4 e 8 threads, carga de memória, carga com pausas e misturas de prioridades.
As medições não incluíram jogos reais, carga de GPU, hardware físico nem janelas longas (horas e dias).
Metodologia
Seção intitulada “Metodologia”O protocolo corresponde a «Como pesquisamos o Windows»:
- cada fase foi registrada com rastreamento ETW (Windows Performance Recorder, perfis leves de CPU, disco, arquivos e rede) e contadores de desempenho com intervalo de 5 segundos (sistema) e 15 segundos (por processo);
- a fase “após a inicialização” foi iniciada com uma reinicialização controlada e ativada com uptime de cerca de um minuto;
- em cada rastreamento foi verificado o número de eventos perdidos — em todas as janelas apresentadas ele é igual a zero;
- a média foi calculada apenas sobre intervalos completos de cinco segundos dentro dos limites da fase (59 intervalos por fase);
- na série 2, a primeira execução “antes” foi excluída por a máquina virtual ter entrado em suspensão; foi usada a repetição;
- as provas de carga foram executadas duas vezes, apresentadas as medianas; o uso de CPU foi normalizado para quatro vCPU.
“Antes” e “depois” são estados de uma mesma instalação do Windows: “depois” foi obtido aplicando o perfil de otimização, “antes” é o estado original. O conjunto de configurações foi alterado por inteiro, portanto a contribuição isolada de uma desativação específica não foi avaliada.
Resultados
Seção intitulada “Resultados”Série 1 (2026-09-18) — idle consolidado sem manutenção ativa:
| Métrica | Antes | Depois | Alteração |
|---|---|---|---|
| Uso de CPU, % | 2,48 | 2,06 | −17 % |
| DPC + ISR, % CPU | 1,73 | 1,59 | −8 % |
| Trocas de contexto, /s | 469 | 381 | −19 % |
| Processos (média) | 134,9 | 69,3 | −49 % |
| Threads (média) | 1 444,6 | 738,7 | −49 % |
| CPU total de todos os processos, % | 1,22 | 1,06 | −13 % |
| Memória disponível, MB | 5 490 | 6 518 | +1 028 |
| Leitura de disco, KB/s | 22,6 | 24,4 | +8 % |
| Gravação em disco, KB/s | 311,3 | 262,1 | −16 % |
| Rede (recebimento), KB/s | 132,6 | 2,2 | −98 % |
| Rede (envio), KB/s | 43,2 | 4,7 | −89 % |
Série 2 (2026-09-19) — a mesma janela de idle, mas no estado “antes” havia uma verificação em segundo plano do Microsoft Defender em execução:
| Métrica | Antes | Depois | Alteração |
|---|---|---|---|
| Uso de CPU, % | 33,37 | 11,03 | −67 % |
| Trocas de contexto, /s | 3 737 | 291 | −92 % |
| Processos (média) | 142,3 | 61,9 | −56 % |
| Threads (média) | 1 494,7 | 637,1 | −57 % |
| Memória disponível, MB | 5 174 | 6 653 | +1 479 |
| Memória física ocupada, MB | 3 017 | 1 538 | −49 % |
| Commit de memória, MB | 2 617 | 1 249 | −52 % |
| Nonpaged pool, MB | 298,2 | 212,9 | −29 % |
| Paged pool, MB | 258,5 | 86,0 | −67 % |
| DPC, % CPU | 0,89 | 0,19 | −78 % |
| Leitura de disco, MB/s | 7,42 | 0,01 | −99,9 % |
| Gravação em disco, MB/s | 4,57 | 0,23 | −95,0 % |
Quase não houve rede em idle na série 2 em ambos os estados (dezenas de bytes por segundo), por isso as linhas de rede não são apresentadas para ela. A diferença entre as séries não é uma contradição, mas uma propriedade do próprio segundo plano: quando o Windows executa manutenção, desativar os componentes em segundo plano economiza mais; quando a janela já está silenciosa — menos.
Primeiros minutos após a inicialização
Seção intitulada “Primeiros minutos após a inicialização”| Métrica | Série 1 (antes → depois) | Série 2 (antes → depois) |
|---|---|---|
| Uso de CPU, % | 3,42 → 2,59 | 14,62 → 11,88 |
| Trocas de contexto, /s | 1 114 → 600 | 1 257 → 393 |
| Processos | 132 → 74 | 139 → 64 |
| Threads | — | 1 719 → 746 |
| Memória física ocupada, MB | — | 2 821 → 1 581 |
| Memória disponível, MB | — | 5 370 → 6 610 |
| Leitura de disco, KB/s | — | 826 → 433 |
| Gravação em disco, KB/s | 634 → 418 | 709 → 298 |
| Rede (recebimento), KB/s | — | 1,15 → ~0 |
O travessão significa que, nessa série, a métrica não foi registrada para a fase.
Composição e memória
Seção intitulada “Composição e memória”Instantâneo do inventário em idle (série 1):
| Antes | Depois | |
|---|---|---|
| Processos | 136 | 70 |
| Threads | 1 679 | 842 |
| Working set total, MB | 3 841 | 1 868 |
| Private bytes totais, MB | 1 524 | 660 |
Maiores consumidores de memória antes da otimização: o processo antivírus MsMpEng.exe (257 MB), explorer.exe (213 MB), StartMenuExperienceHost (144 MB), msedge.exe (133 MB), SearchHost.exe (122 MB). Após a otimização, a lista passou a ser encabeçada por explorer.exe (170 MB), msedgewebview2 (119 MB), SearchHost.exe (115 MB) e StartMenuExperienceHost (106 MB).
A memória disponível cresceu 1,0–1,5 GB, e o volume de commit caiu 52 %. O que disso realmente pode ser “liberado” e por que a soma do working set dos processos não é o mesmo que memória livre é analisado em «Quanta memória é possível realmente liberar no Windows».
Sob carga total
Seção intitulada “Sob carga total”Provas sintéticas curtas (série 2, medianas de duas repetições):
| Cenário | Alteração da taxa de transferência | Uso de CPU: antes / depois |
|---|---|---|
| Um thread | +5,4 % | 21,9 / 22,6 % |
| Quatro threads (total) | +0,19 % | 88,9 / 89,4 % |
| Oito threads (total) | +0,50 % | 88,9 / 88,8 % |
| Carga de memória | +11,2 % | 84,8 / 87,5 % |
| Com pausas (pausas de 1 ms) | +5,4 % | 64,3 / 67,7 % |
| Prioridades mistas | +8,5 % | 21,2 / 22,5 % |
| Prioridade em segundo plano | +77,1 % | 38,8 / 65,2 % |
Sob carga total de quatro threads, o processo útil recebeu cerca de 89 % da capacidade de quatro vCPU tanto antes quanto depois da otimização. Os ~11 % restantes na máquina virtual não podem ser declarados “ruído do Windows” eliminável: o escalonamento do hipervisor não é visível a partir do rastreamento do convidado. As threads de trabalho foram distribuídas uniformemente (variação do volume de trabalho entre elas — 0,994–0,997), não houve inanição, e a fila de CPU em idle após a otimização está praticamente vazia.
Para onde vai o segundo plano
Seção intitulada “Para onde vai o segundo plano”Fontes medidas de atividade em segundo plano no estado “antes”:
- verificação antivírus — principal fonte na janela da série 2: o processo
MsMpEng.execonsumiu 212 segundos de CPU em uma janela de cinco minutos de idle; - no estado original estavam em execução o serviço de pesquisa, o serviço SysMain, a telemetria, o gerenciador de impressão e outros componentes — o perfil de otimização coloca cerca de 50 serviços em segundo plano e 58 tarefas agendadas no estado desativado;
- após a inicialização, a atividade acompanha o orquestrador de atualizações do Windows.
Desativar os componentes em segundo plano não elimina o segundo plano por completo: no estado otimizado, a avaliação de compatibilidade de aplicativos continuava em execução (cerca de 3,7 ms de CPU por segundo na janela de manutenção), e o segundo plano residual total em idle consolidado foi de 4,8 ms de CPU por segundo — cerca de 0,12 % da capacidade de quatro vCPU (medido por rastreamento).
O que foi confirmado
Seção intitulada “O que foi confirmado”- Reproduzido (duas séries independentes): número de processos −49…−56 %, threads −49…−57 %, memória disponível +1,0–1,5 GB.
- Medido (série 2): commit −52 % em idle; memória física ocupada −49 % em idle e −44 % na fase após a inicialização.
- Medido: uso de CPU em idle −17 % em janela silenciosa e −67 % em janela com verificação; trocas de contexto −19 % e −92 %; DPC −78 % (janela da série 2); atividade após a inicialização menor em ambas as séries.
- Medido: sob carga total de CPU, ganho de taxa de transferência de +0,19 % (4 threads) e +0,50 % (8 threads); sob carga parcial e mista — de +5,4 a +11,2 %.
- Medido: a carga de classe de prioridade em segundo plano acelerou 77,1 % — no estado “antes” ela competia com o trabalho em segundo plano do próprio Windows, incluindo a verificação antivírus.
- Observado: as principais fontes de segundo plano são a verificação antivírus, a manutenção e as tarefas de compatibilidade; após a otimização, o segundo plano residual é próximo de zero, mas não nulo.
O que não foi confirmado
Seção intitulada “O que não foi confirmado”- Ganho de FPS, redução de input lag ou frametime em jogos reais: não foi medido. As provas sintéticas de CPU não modelam um jogo com GPU e não provam efeito em jogos.
- Contribuição isolada de cada desativação específica: foi aplicado um conjunto de alterações.
- Transposição dos valores absolutos para hardware físico, outras builds e outros perfis de otimização.
- Estabilidade em janelas longas: cada fase tem 5 minutos; o trabalho em segundo plano do Windows vem em picos, por isso o “dia médio” não foi medido.
Limitações
Seção intitulada “Limitações”- As medições foram realizadas em uma máquina virtual. A virtualização introduz sua própria parcela de DPC/ISR e oculta o escalonamento do host; em hardware físico os valores absolutos serão diferentes. As proporções e a direção da comparação “antes/depois” em condições idênticas se mantêm.
- A métrica ISR foi excluída das tabelas: em uma máquina virtual, o contador ISR via PDH diverge dos manipuladores de interrupção via ETW em cerca de 10 % e não fecha em uma soma exata.
- A janela “antes” da série 2 continha uma verificação ativa do Defender, e a carga do host entre as janelas era diferente (em média 44 % contra 24 %). Por isso os valores estão vinculados a janelas específicas; a direção foi confirmada por duas séries.
- Na série 1, parte da fase de idle foi interrompida por uma pausa externa da máquina virtual de cerca de 26 segundos; a captura terminou após a retomada, sem eventos perdidos.
- As provas de carga têm duas repetições: é estatística descritiva, a significância estatística não foi avaliada.
- Parte do ganho em idle está relacionada à desativação de componentes de proteção do Microsoft Defender. Um sistema sem proteção antivírus é um compromisso consciente, e não uma otimização sem custos; desativar a proteção exige entender o preço.
- A camada de medição (rastreamento e contadores) ela mesma cria uma pequena carga em segundo plano; ela está presente em ambos os estados.
O estudo e as ferramentas utilizadas pertencem ao desenvolvedor do BoosterX, portanto o desenvolvedor tem interesse direto nos resultados. A metodologia e os limites de aplicabilidade estão descritos acima, e as conclusões podem ser verificadas pelos dados abertos e pelas fontes públicas listadas.
Conclusão prática
Seção intitulada “Conclusão prática”A redução do ruído em segundo plano é um efeito real, reproduzido duas vezes: metade dos processos e threads, metade do commit de memória, uma ordem de grandeza menos atividade de disco e rede em idle. Isso é útil por si só — para a responsividade do sistema, tarefas em segundo plano, temperatura, ruído das ventoinhas e tempo de bateria — e não exige promessas de FPS.
O que não se deve esperar disso: ganho de desempenho sob carga total. Se a CPU já está carregada com trabalho útil em ~89 % da capacidade, desativar a atividade em segundo plano não adicionará os 11 % restantes — na máquina virtual eles não pertencem ao Windows. Quanto mais ocupado o sistema estiver no momento da comparação, maior o efeito visível: em uma janela de manutenção a diferença é múltipla; em uma janela silenciosa — moderada.
Recomendação: avalie o segundo plano antes e depois de quaisquer alterações no seu computador (Task Manager → “Desempenho” e “Processos”, Monitor de Recursos), em vez de se orientar por porcentagens de terceiros. Se o objetivo é o FPS em um jogo específico, meça exatamente ele antes e depois da alteração.
Restauração do estado
Seção intitulada “Restauração do estado”Ambas as séries foram realizadas em máquinas virtuais isoladas em cópias independentes do disco; após as medições, as máquinas retornaram aos estados originais. O artigo não exige que o leitor altere parâmetros, portanto nenhuma ação de restauração separada é necessária no computador do usuário.
Fontes primárias públicas
Seção intitulada “Fontes primárias públicas”- Microsoft: Windows Performance Recorder — ferramenta de gravação de rastreamentos ETW usada na metodologia; verificado em 2026-09-20.
- Microsoft: About Event Tracing — modelo ETW e verificação de eventos perdidos; verificado em 2026-09-20.
- Microsoft: Microsoft Defender Antivírus no Windows — processos e serviços do Defender, incluindo
MsMpEng.exe(“Antimalware Service Executable” no Task Manager); verificado em 2026-09-20. - Como pesquisamos o Windows — níveis de evidência e protocolo de medições.
- Service Host e componentes em segundo plano do Windows 11 — como o Windows distribui os serviços em segundo plano pelos processos.
- Quanta memória é possível realmente liberar no Windows — análise detalhada da memória deste mesmo experimento.
- Desktop contra tela de logon — continuação: do que é composto o ruído da sessão do usuário.
Histórico de alterações
Seção intitulada “Histórico de alterações”- 2026-09-20: primeira publicação — duas séries independentes de medições de idle, fases após a inicialização, inventário e provas de carga.
- 2026-09-20: atribuição dos resultados por séries refinada (commit e memória física ocupada — apenas série 2; processos −49…−56 %); o aviso sobre conflito de interesses foi trazido para a formulação canônica.