Travis, "arquivo" não ajudou. De fato, mesmo limpar o log de eventos quando era 2 / 3rd crescido não ajudava. Mas o "arquivo" ajudou o KraigM.
kce: limpou um arquivo de "substituição" de 131MB e viu o desempenho cair de, digamos, 55% a 5%, mas PERGUNTA: talvez você eventualmente tenha visto alta utilização novamente, pois isso (a) só pode (a) ser acionado quando a condição de substituição for alcançada ou (b) pode ficar linearmente pior à medida que o arquivo limpo aumenta de 0 MB para 131 MB.
Alguns veem isso no security.evtx e outro no log operacional do Agendador de tarefas. Sugiro desinstalar completamente o seu AV (qual você está usando) e tentar. Os invasores precisam ocultar suas trilhas e elas são feitas em tarefas agendadas que eles configuram ou em logins que eles fazem. Portanto, eles ocultam suas faixas quebrando alças nesses logs de eventos e reescrevendo-as para pular suas faixas. Os AVs podem estar detectando isso de maneira incorreta, pois se fosse a Microsoft, mais dessa alta utilização teria sido relatada, mas estou vendo apenas algumas poucas publicações no Google. Também estou vendo isso no servidor 2008 R2 para o log security.evtx. Sem assinantes de log de eventos, sem monitores externos. Observei alguns serviços AV (McAfee) em execução e eles tiveram uma utilização total muito baixa de um servidor por tantos dias, por isso desconfio que ele tenha sido desinstalado e apenas parcialmente (provavelmente o desinstalador especial da McAfee) e me pergunto se há ganchos. o serviço da McAfee ou os drivers de filtro da McAfee em execução, que de alguma forma fazem uma gravação normal no log de eventos e decidem em sua filtragem que precisam transformar isso em uma leitura completa de todo o log de eventos. Confie em mim, drivers de filtro de terceiros de algumas empresas de antivírus são bugs e certamente 10000x mais bugs do que a implementação da Microsoft de log de eventos, o que provavelmente é perfeito. Em resumo, o problema de desinstalação 100% TODOS OS SEUS E VEJA SE resolve. Nesse caso, trabalhe com sua empresa de antivírus para corrigir o AV deles. Não é aconselhável criar exceções para arquivos.
Além disso, ao usar o procmon, preste atenção às chamadas WriteFile porque o Writefile é o que acionará o gerenciador de filtros para ler o arquivo inteiro. No meu caso, a leitura foi iniciada aproximadamente 30 segundos após a conclusão da gravação, que pode ser por design. Mas era consistente e, no meu caso, o arquivo tinha 4 GB e a leitura do arquivo envolvia arquivos de leitura de 64K cada um com 64 KB de comprimento e utilizava 35% da CPU para fazer isso. Muito triste.
Atualização 03/23/2016 Olhei para os drivers de filtro nesta máquina depois de concluir que isso tinha que ser causado por um deles (o mecanismo do log de eventos nunca poderia ser buggy por si só ou o número de relatórios desse tipo seria impressionante e não é). Eu vi alguns drivers de filtro de um antivírus e de uma empresa de terceiros bem conhecida que aumenta o desempenho do disco da máquina virtual com leituras antecipadas e perguntei ao arquiteto-chefe (que era muito gentil e gentil) se o produto dele poderia ser excessivamente agressivo durante toda a leitura. log de eventos de segurança (que estava acontecendo claramente por procmon). Isso seria útil para logs de segurança menores, mas não para os tamanhos relatados aqui. De jeito nenhum ele disse. Ele concordou que poderia ser o AV.
Como eu disse ao colega do Azure abaixo, não temos um acompanhamento do Pôster original se o problema ressurgir após a limpeza do log de eventos, porque essa é uma solução comum e equivocada, pois o desempenho diminui com o tempo novamente. Isso é chamado de "acompanhamento" e vejo em primeira mão que a solução do pôster original pode enganar aqueles que não o fazem acreditar que resolveram o problema. Eu quase fui enganado também. Limpei o log de eventos e o desempenho melhorou - mas usei procmon e vi que o problema aumentava lentamente ao longo do tempo até que se tornasse problemático. Por alguma razão, o colega do Azure me critica duramente quando o pôster original não é seguido (pode ter morrido, sido demitido, encerrado ou ocupado). O colega do Azure abaixo pensa que, se o pôster original não seguiu, deve ser um problema corrigido. Isso é irritante e intrigante, porque não consigo pensar em alguém que seja tão conceituado tecnicamente e que assuma essa posição. Peço desculpas se piquei um nervo. Talvez no meu ativismo em outro lugar na Internet, onde chamo as pessoas, tenha me irritado - aqui (falha no servidor), estou simplesmente sendo gentil e compartilhando profundo conhecimento técnico, e o resultado do Sr. Azure é intimidador sobre se minha contribuição técnica é uniforme. necessário ou é para algum blog meu (não tenho esse blog). Ainda não pretendo enviar esse link para cerca de meia dúzia de parceiros da Microsoft e perguntar a eles o que está acontecendo com esse tipo de bullying de um funcionário importante da MSFT, porque estou singularmente focado em ter o melhor interesse de todos. a comunidade em mente e as respostas abaixo do Sr. Azure são, em poucas palavras, inacreditáveis, vitriódicas, enervante e intimidador - o que tenho certeza de que algumas pessoas gostam de fazer com outras. Inicialmente fiquei ofendido, mas superei e sei que leitores passivos ou ativos apreciarão o que estou dizendo e apreciarão meus comentários - estou 100% por trás disso, sem levar em consideração as razões legalistas pelas quais é sutilmente inapropriado aqui ou não. M. Azure, por favor, pratique a gentileza e evite comentar meus comentários com pouca luz. Apenas supere isso e mostre contenção e não comente mais uma vez. por favor, pratique a bondade e evite comentar meus comentários com pouca luz. Apenas supere isso e mostre contenção e não comente mais uma vez. por favor, pratique a bondade e evite comentar meus comentários com pouca luz. Apenas supere isso e mostre contenção e não comente mais uma vez.
Harry
