Тревіс, "архів" вам не допоміг. Насправді, навіть очищення журналу подій, коли він був 2/3-й, не допомогло вам. Але "архів" справді допоміг KraigM.
kce: очищено файл "перезаписати" 131 Мб і побачив зниження продуктивності від скажімо 55% o 5%, але ЗАПИТАННЯ: можливо, ви врешті-решт знову побачили високу ефективність, оскільки це може (а) спрацьовувати лише тоді, коли буде досягнуто умова перезапису або (b) це може стати лінійно гіршим, оскільки очищений файл збільшується з розміру 0mb до 131MB.
Деякі бачать це для security.evtx, а одні бачили це в операційному журналі планувальників завдань. Я пропоную повністю видалити AV-файл (який ви використовуєте) та спробувати. Зловмисникам потрібно приховати свої доріжки, і їхні треки вносяться в планові завдання, які вони встановлюють, або входи в систему. Таким чином вони заховатимуть свої треки, ламаючи ручки до цих журналів подій та переписуючи їх, щоб пропустити їхні треки. АВ-студії, можливо, виявляють це помилково, оскільки, якби це було Microsoft, про таке високе використання було б повідомлено, але я бачу лише незначну кількість публікацій під час Гугла. Я також бачу це на сервері 2008 R2 для журналу security.evtx. Немає передплатників журналу подій, немає зовнішніх моніторів. Я спостерігав, як працює декілька AV-сервісів (McAfee), і вони мали дуже низьке загальне використання сервера аж стільки днів, тому я підозрюю, що його видалено і лише частково (можливо, потрібен спеціальний деінсталятор McAfee), і мені цікаво, чи є гачки в послуга McAfee або драйвери фільтрів McAfee, що виконуються (або навіть нормально встановлені), які якимось чином приймають звичайне записування до журналу подій і вирішують у процесі їх фільтрації, що вони повинні перетворити це на повне зчитування всього журналу подій. Повірте мені, сторонні драйвери фільтрів деяких AV-компаній є помилковими і, безумовно, 10000-кратними помилками, ніж впровадження Microsoft журналів подій, що, ймовірно, ідеально. Підсумовуючи, 100% видалення ВСІХ ВАШЕВ І ВИДАЙТЕ, якщо проблема вирішена. Якщо так, співпрацюйте зі своєю AV-компанією, щоб виправити їх AV. Недоцільно робити винятки з файлів для.
Також, використовуючи прокмен, зверніть увагу на виклики WriteFile, оскільки Writefile - це те, що запустить менеджер фільтру прочитати весь файл. У моєму випадку зчитування було ініційовано приблизно через 30 секунд після завершення запису, що може бути задумано. Але це було послідовно, і в моєму випадку файл склав 4 Гб, а читання файлу включало 64 К читання у довжину кожні 64 КБ в довжину, і для цього було використано 35% ЦП. Дуже сумно.
Оновлення 23.03.2016 Я переглянув драйвери фільтрів на цій машині після висновку, що це повинно бути викликано одним з них (механізм журналу подій ніколи не може бути помилковим, або кількість звітів такого роду буде приголомшливою і це не так). Я побачив деяких драйверів фільтрів з AV та від відомої сторонньої компанії, яка підвищує продуктивність диска віртуальної машини з поглядом наперед, читає і запитала їх головного архітектора (який був дуже добрий і милостивий), чи може його продукт надмірно агресивно читати весь журнал подій безпеки (що, очевидно, відбувається за промовою). Це було б корисно для менших журналів безпеки, але не для тих розмірів, про які тут повідомляється. Ні в якому разі він не сказав. Він погодився, що це може бути АВ.
Як я вже казав колезі Azure нижче, у нас немає подальших публікацій з оригінального Плаката, якщо проблема повторно з’явилася після очищення журналу подій, оскільки це поширене і помилкове рішення, оскільки продуктивність з часом погіршується. Це називається "продовження", і я бачу, що з перших рук оригінальне рішення плаката може обдурити тих, хто не продовжує вважати, що вони вирішили проблему. Я теж майже не обдурив. Я очистив журнал подій і покращив ефективність роботи, - але я застосував промоунд і побачив, що проблема буде рости і повільно зростати з часом, поки це не стане проблематичним. Чомусь колега Лазурного різко критикує мене, коли оригінальний плакат не підписався (можливо, загинув, звільнився, кинув службу або зайнявся). Нижній колега Azure вважає, що якщо оригінальний плакат не підписався, це має бути виправлена проблема. Це неприємно і дивовижно, тому що я не можу придумати того, хто настільки високо оцінений технічно, хто зайняв би цю посаду. Прошу вибачення, якщо уколов нерв. Можливо, в моїй активності в іншому просторі в Інтернеті, куди я телефоную людям, я натрапив на його нерви - тут (сервер за замовчуванням) я просто доброзичливий і ділюсь глибокими технічними знаннями, і результат містера Лазура знущається над тим, чи є мій технічний внесок рівним необхідний або є для мого блогу (у мене немає такого блогу). Я поки не збираюся надсилати це посилання на близько півдесятка ключових друзів в Microsoft і запитати їх, що відбувається з цим типом знущань з боку ключового співробітника MSFT, оскільки я особливо орієнтований на те, щоб зацікавити себе громада на увазі, і відповіді, наведені нижче від пана Azure, є кількома словами, неймовірними, життєлюбними, нетерпіння та знущання - що я впевнений, що деяким людям подобається робити іншим. Я спочатку ображався, але переживаю за це і знаю, що пасивні чи активні читачі оцінять те, що я говорю, і оціню мої коментарі. Я стою на 100% поза цим, не враховуючи юридичних причин, чому це десь недоречно чи ні. М. Лазурний, будь ласка, проявляйте доброту і утримуйтесь від того, щоб викладати мої коментарі в поганому світлі. Просто перейміть це і проявіть стриманість, а не коментуйте ще раз. будь ласка, практикуйте доброту і утримуйтесь від того, щоб викладати мої коментарі в поганому світлі. Просто перейміть це і проявіть стриманість, а не коментуйте ще раз. будь ласка, практикуйте доброту і утримуйтесь від того, щоб викладати мої коментарі в поганому світлі. Просто перейміть це і проявіть стриманість, а не коментуйте ще раз.
Гаррі
