У нас есть два контроллера домена Windows Server 2008 с пакетом обновления 2 (к сожалению, не 2008 R2) в небольшом 150 клиентском домене, которые демонстрируют очень «пиковую» загрузку ЦП. Контроллеры домена демонстрируют одинаковое поведение и размещаются на vSphere 5.5.0, 1331820. Каждые две или три секунды загрузка ЦП увеличивается до 80-100%, а затем быстро падает, остается низкой на секунду или две, а затем поднимается вверх опять таки.
Просмотр исторических данных о производительности для виртуальной машины показывает, что это состояние продолжается не менее года, но частота возросла с марта.
Нарушающим процессом является SVChost.exe, который упаковывает службы DHCP-клиента (dhcpcsvc.dll), EventLog (wevtsvc.dll) и LMHOSTS (lmhsvc.dll). Я, конечно, не эксперт по внутренним компонентам Windows, но я не могу найти что-то особенно неправильное при просмотре процесса с помощью Process Explorer, за исключением того, что EventLog вызывает тонну вызовов RpcBindingUnbind .
На данный момент у меня нет кофе и идей. Как мне продолжать устранять эту проблему?
mmc.exeоткрытым окном «Диспетчер серверов» (возможно, по умолчанию)?Ответы:
TL; DR: файл EventLog переполнен. Перезапись записей обходится дорого и / или не очень хорошо реализована в Windows Server 2008.
На @pk. и предложение @joeqwerty, и, посмотрев вокруг, я решил, что, скорее всего, забытая реализация мониторинга очищает журналы событий.
Я установил сетевой монитор Microsoft на одном из контроллеров домена и начал фильтровать MSRPC с помощью
ProtocolName == MSRPCфильтра. Было много трафика, но все это было между RODC нашего удаленного сайта и, к сожалению, не использовало тот же порт назначения, что и прослушивающий процесс EventLog. Штопать! Там идет эта теория.Чтобы упростить задачу и упростить запуск программного обеспечения для мониторинга, я решил развернуть службу EventLog из SVCHost. Следующая команда и перезагрузка контроллера домена выделяют один процесс SVCHost для службы EventLog. Это немного облегчает расследование, поскольку к этому PID не подключено несколько служб.
Затем я прибегнул к ProcMon и настроил фильтр, чтобы исключить все, что не использовало этот PID. Я не видел тонны неудачных попыток EventLog для открытых отсутствующих ключей реестра , как указано в качестве возможной причины здесь ( по- видимому , дрянные приложения могут зарегистрироваться в качестве источников событий в крайне плохих отношениях). Как и ожидалось, я видел множество успешных записей ReadFile в журнале событий безопасности (C: \ Windows \ System32 \ WinEvt \ Logs \ Security.evtx).
Вот взгляд на стек на одном из этих событий:
Вы заметите сначала RPCBinding, а затем RPCBindingUnbind. Их было много . Как тысячи в секунду. Либо журнал безопасности действительно занят, либо что-то не работает с
Security.evtxжурналом.В EventViewer журнал безопасности регистрировал только 50-100 событий в минуту, что казалось подходящим для домена такого размера. Штопать! Есть теория номер два, что у нас было какое-то приложение с очень подробным аудитом событий, включенным слева в забытом углу, все еще покорно пыхтя. Было записано еще много (~ 250 000) событий, хотя частота регистрируемых событий была низкой. Размер журнала возможно?
Журналы безопасности - (Щелкните правой кнопкой мыши) - Свойства ... и максимальный размер журнала был установлен для 131 072 КБ, а размер журнала в настоящее время удерживается на уровне 131 072 КБ. Был установлен переключатель «Перезаписать события по мере необходимости». Я подумал, что постоянное удаление и запись в файл журнала, вероятно, была тяжелой работой, особенно когда он был настолько заполнен, поэтому я решил очистить журнал (я сохранил старый журнал на тот случай, если он понадобится для последующего аудита) и позволил службе EventLog создать новый пустой файл. Результат: загрузка ЦП вернулась к нормальному уровню около 5%.
источник
Вы можете найти это, создав небольшой набор сборщиков данных.
tracerpt –l “file.etl” –of CSVЕсли моя догадка верна, вы увидите, что некоторые устройства (IP: порт) работают с вашим DC.
источник
Конечно, сложный. Помимо того, что вы оставили его в покое (1 процессор / 50% нагрузки ... кого это волнует?), Вы можете попытаться настроить новый контроллер домена и через несколько дней посмотреть, будет ли этот режим работать так же. Если это произойдет, вы можете попробовать использовать трассировку Wireshark (очевидно, что-то из Сети вызывает это)
Следующее, что приходит на ум, - это простой звонок в Microsoft.
источник
Трэвис, «архив» тебе не помог. На самом деле, даже очистка журнала событий, когда он вырос на 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%, не обращая внимания на юридические причины, почему это здесь неуместно или нет. Г-н Лазурный, пожалуйста, проявляйте доброту и воздерживайтесь от моих комментариев в плохом свете Просто преодолеть это и проявить сдержанность и не комментировать еще раз. пожалуйста, проявляйте доброту и воздерживайтесь от моих комментариев в плохом свете. Просто преодолеть это и проявить сдержанность и не комментировать еще раз. пожалуйста, проявляйте доброту и воздерживайтесь от моих комментариев в плохом свете. Просто преодолеть это и проявить сдержанность и не комментировать еще раз.
Гарри
источник