Трэвис, «архив» тебе не помог. На самом деле, даже очистка журнала событий, когда он вырос на 2/3, не помогла вам. Но «архив» действительно помог KraigM.
kce: очистил 131-мегабайтный файл «перезаписи» и увидел снижение производительности, скажем, с 55% до 5%, но ВОПРОС: возможно, вы в конечном итоге снова увидели высокое использование, так как это может (а) сработать только при достижении условия перезаписи или (б) Это может линейно ухудшаться, когда размер очищаемого файла увеличивается с 0 МБ до 131 МБ.
Некоторые видят это для security.evtx, а другие - для журнала операций планировщика задач. Я предлагаю полностью удалить ваш AV (который вы используете) и попробовать. Злоумышленники должны скрывать свои треки, а их треки выполняются в запланированных задачах, которые они устанавливают, или при входе в систему. Поэтому они будут скрывать свои треки, ломая дескрипторы этих журналов событий и переписывая их, чтобы пропустить их треки. Возможно, AV обнаруживают это с ошибкой, поскольку, если бы это была Microsoft, было бы сообщено о большем использовании, но я вижу лишь несколько сообщений, когда Google гуглит. Я также вижу это на сервере 2008 R2 для журнала security.evtx. Нет подписчиков журнала событий, нет внешних мониторов. Я наблюдал, как работало несколько AV-сервисов (McAfee), и у них очень низкое общее использование сервера в течение многих дней, поэтому я подозреваю, что он был удален и только частично (вероятно, требуется специальный деинсталлятор McAfee), и мне интересно, есть ли зацепки работающие драйверы службы (или даже обычно установленные) службы McAfee или фильтра McAfee, которые каким-то образом выполняют нормальную запись в журнал событий и в своей фильтрации принимают решение, что им нужно превратить это в полное чтение всего журнала событий. Поверьте мне, сторонние драйверы фильтров от некоторых AV-компаний глючат и, конечно, в 10000 раз хуже, чем реализация журналирования событий Microsoft, что, скорее всего, идеально. Таким образом, 100% удалить ВСЕ из ваших AV и Увидеть, если проблема решена. Если так, работайте с вашей компанией AV, чтобы исправить их AV. Не рекомендуется делать исключения для файлов.
Кроме того, при использовании procmon обратите внимание на вызовы WriteFile, потому что именно Writefile заставит менеджер фильтров прочитать весь файл. В моем случае чтение было начато приблизительно через 30 секунд после завершения записи, что может быть задуманно. Но это было непротиворечиво, и в моем случае файл занимал 4 ГБ, а чтение файла занимало 64 КБ Readfiles длиной по 64 КБ, и для этого использовалось 35% ЦП. Очень грустный.
Обновление 23.03.2016 Я посмотрел на драйверы фильтров на этом компьютере после того, как пришел к выводу, что это должно быть вызвано одним из них (механизм журнала событий никогда не может быть неисправен сам по себе, или количество отчетов такого рода будет ошеломляющим и Нет). Я видел некоторые драйверы фильтров от AV и от известной сторонней компании, которая повышает производительность диска виртуальной машины с помощью заблаговременного чтения, и спросил их главного архитектора (который был очень добрым и любезным), может ли его продукт чрезмерно агрессивно читать все журнал событий безопасности (который явно происходил по procmon). Это было бы полезно для небольших журналов безопасности, но не для размеров, указанных здесь. Ни за что не сказал. Он согласился, что это может быть AV.
Как я сказал собеседнику по Azure ниже, у нас нет продолжения из исходного плаката, если проблема вновь возникла после очистки журнала событий, потому что это распространенное и ошибочное решение, поскольку производительность со временем снова падает. Это называется «продолжение», и я вижу, что собственное решение автора из первых рук может обмануть тех, кто не верит, что они решили проблему. Меня тоже почти одурачили. Я очистил журнал событий и улучшил производительность, но я использовал procmon и увидел, что проблема будет расти и расти со временем, пока не станет проблематичной. По какой-то причине сотрудник Azure резко критикует меня, когда оригинальный постер не последовал (возможно, умер, был уволен, ушел или занялся). Парень из Azure ниже думает, что если оригинальный постер не последовал, это должно быть исправлено. Это досадно и озадачивает, потому что я не могу думать ни о ком, кто так технически высоко ценится, кто занял бы эту позицию. Прошу прощения, если я укололся. Возможно, из-за моей активности в Интернете, где я вызываю людей, я действовал ему на нервы - здесь (ошибка сервера) я просто проявляю доброту и делюсь глубокими техническими знаниями, и в результате г-н Лазур запугивает вопрос, является ли мой технический вклад даже необходимо или для некоторого моего блога (у меня нет такого блога). Я пока не собираюсь разослать эту ссылку примерно полдюжине ключевых знакомых в Microsoft и спросить их, что происходит с этим типом издевательств со стороны ключевого сотрудника MSFT, потому что я в основном сосредоточен на том, чтобы иметь наилучшие интересы о сообществе и ответах г-на Азура ниже, в нескольких словах, это невероятно, яростно, нервировать и издеваться - что я уверен, что некоторые люди любят делать с другими. Я был изначально обижен, но нахожусь над этим и знаю, что пассивные или активные читатели оценят то, что я говорю, и оценят мои комментарии - я поддерживаю это на 100%, не обращая внимания на юридические причины, почему это здесь неуместно или нет. Г-н Лазурный, пожалуйста, проявляйте доброту и воздерживайтесь от моих комментариев в плохом свете Просто преодолеть это и проявить сдержанность и не комментировать еще раз. пожалуйста, проявляйте доброту и воздерживайтесь от моих комментариев в плохом свете. Просто преодолеть это и проявить сдержанность и не комментировать еще раз. пожалуйста, проявляйте доброту и воздерживайтесь от моих комментариев в плохом свете. Просто преодолеть это и проявить сдержанность и не комментировать еще раз.
Гарри
