Closed vmech closed 1 month ago
Как вы проверяете потребление памяти ядром?
Как вы проверяете потребление памяти ядром?
Как проверить потребление именно ядром я не знаю. Ориентируюсь на общие показатели памяти. Инструментов много: Process Explorer, wmic, много других утилит.
покажите скриншот с активным Гудбай и этого мониторщика мощности. Потом врите с пруфами, я ушел в игнор
Ориентируюсь на общие показатели памяти.
Какие именно показатели вы учитываете? Какие цифры вы видите в paged pool/non-paged pool?
Какие именно показатели вы учитываете? Какие цифры вы видите в paged pool/non-paged pool?
Запущен только Process Explorer. windivert остановлен.
Сделайте такой же скриншот в момент, когда, по вашему мнению, начинаются проблемы от goodbyedpi.
Сделайте такой же скриншот в момент, когда, по вашему мнению, начинаются проблемы от goodbyedpi.
Они уже есть.
Погодите, забыл куда положил скриншоты тестов. Нашёл.
Это тест 7zG в тот день, когда я впервые обратил внимание, что с ОС творится что то неладное:
Это тот же тест, в тот же день, сразу после перезагрузки (дал сервисам ОС 15 минут угомониться, и запустил тест):
Точных параметров аптайма уже конечно же не вспомню, и записать не удосужился. Да и причину происходящего в тот момент даже не предполагал.
В данный момент: Аптайм ОС 8 дней ~8 часов. Тест 7zG имеет такие же показатели, как на первом (N1) скриншоте.
PS. Меня беспокоит не потребление памяти, а снижение быстродействия. Что то загружает процессор, но этой нагрузки не видно ни в одной программе мониторинга.
В том числе System Idle Process
показывает, что никакой нагрузки нет вовсе - ОС простаивает.
В System Monitor так же видно, что 2 ядра из 4-ёх постоянно припаркованы. Ядро 0 не паркуется никогда. Ядро 1 изредка распарковывается на очень короткие промежутки времени - от одной до пары-тройки секунд.
CPU-Z показывает, что частота ЦП падает до минимума
PPS. Чуть больше часа назад запускал игру, только для проверки - фпс скачет, геймплей рваный, играть неприятно.
Тесты производительности не имеют смысла — производительность может меняться по совершенно разным причинам. Если вы утверждаете, что в windivert утекает память, приведите хотя бы цифры, чтобы можно было выдвигать какие-либо предположения о причинах.
Это тот же тест, в тот же день, сразу после перезагрузки
На скриншотах разные версии 7zip (24.08 и 24.06).
Тесты производительности не имеют смысла — производительность может меняться по совершенно разным причинам. Если вы утверждаете, что в windivert утекает память, приведите хотя бы цифры, чтобы можно было выдвигать какие-либо предположения о причинах.
Мне сложно утверждать, потому что я не могу обнаружить причин. Поэтому только предполагаю. Предположение могу подкрепить только одним фактом: Как несложно заметить по аптайму, ПК перезагружался на прошлой неделе, в среду. До воскресенья я ни разу не запускал goodbyedpi - сначала не было времени, а в субботу провёл тесты, чтобы убедиться что ОС в порядке. И всё было нормально, 7zG показал результаты как на втором (N2) скриншоте. В воскресенье, впервые после перезагрузки, решил посмотреть ютуб, и вот сейчас имею то, что имею... Производительность не падает одним скачком, она деградирует постепенно. Чем больше раз запускается goodbyedpi, тем всё больше и больше деградация.
На скриншотах разные версии 7zip (24.08 и 24.06).
Поверьте мне на слово - это не имеет никакого значения. Просто я сначала подумал что проблема в 7-zip, но после перезагрузки понял, что дело вовсе не в нём.
@ValdikSS у меня появилась идея.
Я пробовал 0.2.3rc1 с ключом -5
, и ютуб нормально открывался и работал (вроде бы).
М.б. стОит попробовать версию 0.2.2 с ключом -5
. В ней же более старая версия windivert ?
Чем больше раз запускается goodbyedpi, тем всё больше и больше деградация.
Тогда это должно быть легко отладить — запустите программу много раз. Как это связано с утечкой памяти? Она есть, или вы предположили, не основываясь ни на чём? Утечки памяти обычно никак не связаны с производительностью.
Тогда это должно быть легко отладить — запустите программу много раз.
Одного запуска недостаточно. Необходимо чтобы пакеты через фильтр бегали. Т.е. чтобы код драйвера исполнялся.
Как это связано с утечкой памяти? Она есть, или вы предположили, не основываясь ни на чём? Утечки памяти обычно никак не связаны с производительностью.
Потому что кроме падения производительности увеличивается потребление памяти в простое. В те дни, когда я не пользовался goodbyedpi, потребление памяти в простое (когда закрыты все программы) оставалось неизменным: 1,4-1,5 Гбайт сразу после перезагрузки, и до 1,7-1,8 Гбайт после использования множества программ (vscode/vscodium, Opera, Edge, архиваторы, парочка игр). Повторюсь - на протяжении нескольких дней. Но как только я начал запускать goodbyedpi, чтобы посмотреть ютуб, потребление памяти в простое и снижение производительности начали монотонно нарастать. С воскресенья, и до сегодняшнего дня.
Если это ядерная память, то это можно отладить — https://learn.microsoft.com/en-us/windows-hardware/drivers/debugger/using-poolmon-to-find-a-kernel-mode-memory-leak
Если это не ядерная память, ну, вряд ли это GoodbyeDPI.
Если это ядерная память, то это можно отладить — https://learn.microsoft.com/en-us/windows-hardware/drivers/debugger/using-poolmon-to-find-a-kernel-mode-memory-leak
Если это не ядерная память, ну, вряд ли это GoodbyeDPI.
О! Отлично! Изучу, и обязательно попробую.
А что скажете про идею с версией 0.2.2 ? СтОит попробовать, или «мёртвому припарки» ?
Не стоит
Если это не ядерная память, ну, вряд ли это GoodbyeDPI.
Запустил goodbyedpi
Запустил poolmon
Открыл ролик на ютуб.
Отсчёт страниц в пуле для отмеченного драйвера начался со значения 10.007.121
(точки поставил для ясности)
Посмотрел с десяток видосов и стримов, в среднем по 15-30 минут. Показатели изменились на следующие: Всё в порядке ? Так и должно быть ?
Так и должно быть, потребление памяти только уменьшилось. Смотреть нужно в верхний правый угол (Krnl и Pool N/P). Ничего необычного нет.
Возможно оффтоп, но на win 10 версий 17xxx были проблемы с драйверами сетевых карт. Их было сложно отследить, но симптомы были такие же. Чинилось обновлением драйверов или установкой более старой их версии.
Так и должно быть, потребление памяти только уменьшилось. Смотреть нужно в верхний правый угол (Krnl и Pool N/P). Ничего необычного нет.
Понятно, что с драйвером всё в порядке. Напрямую он никак не влияет на ситуацию. М.б. косвенно влияет... Но как это понять. И разобраться с этой чехардой.
PS. Сегодня не выдержал, и перезагрузил ПК - ОС начала ощутимо тормозить. Я конечно не мангуст, но было отчётливо видно как по очереди отрисовываются элементы интерфейса в Code/Codium и браузерах. При чём ОС тормозит абсолютно одинаково со схемами энергосбережения Balanced (разрешены снижение частоты и парковка ядер ЦП) и Ultimate Performance (всё железо жарит на полную). Несколько дней не буду запускать gbdpi, в понедельник отпишусь - изменилось ли хоть что то.
Пора на 22H2. Даже если Вы докажете косяк в работе windivert вряд ли кто-то будет переотлаживать драйвер под неподдерживаемую более версию системы
Прошу прощения, что ничего не написал в прошлый понедельник.
Писать было не о чем - как и ожидалось, без gbdpi
ничего не изменилось.
Полистав интернеты, в нескольких местах обнаружил рекомендацию попробовать отключить драйвер NDU (Network Data Usage), что он может вызывать утечки памяти.
Перед перезагрузкой в пятницу, 6-го сентября, отключил. И всё даже было хорошо.
Ровно до вчерашнего дня. Вчера снова случился всплеск потребления памяти и падение быстродействия, в точности как ранее.
6.09 | 9.09 | 15.09 |
---|---|---|
Скриншоты poolmon
приводить нет смысла, наверное. Там ничего криминального нет. Основные потребители памяти всё те же, значения потребления так же не отличаются от скриншотов выше.
Но есть нюанс: около 20 драйверов +/- имеют гигантские значения, в десятки мегабайт, выделенной (allocated) памяти в non-paged пуле. Видимо они его и раздули на последнем скриншоте RAMMap
.
ЗЫ. Вобщем, не сегодня/завтра перезагружу винду, и продолжу поиски безобразник[а|ов].
Здравствуйте снова.
Вобщем уже месяц прошёл, проблема вроде бы ушла/больше не проявляется.
Не могу со 100% уверенностью сказать, что именно исправило ситуацию - установка родного драйвера сетевого адаптера из пакета драйверов nForce (его версия чуть ниже, чем комплектного из Windows, но он того же года издания), или обновлённая версия gbdpi
(rc3 которая), или и то и другое вместе.
Думаю, на этом топик можно закрывать. Не вижу причин держать его открытым и дальше.
Operating system / операционная система
Windows 10.0.17763.4499
Running as service / Запуск программы как сервис
I run it as a regular program / Запускаю программу обычным образом
Describe the bug / Опишите ошибку программы
После порядка 10 запусков программы ядро системы распухает до 2,2-2,5 Гбайт. Снижается быстродействие всей системы как минимум на ~15-20%. Очевидно, что утечка памяти в ядре.
Обычные условия (goodbyedpi ни разу не запускался): Ядро системы занимает 1,5-1,8 Гбайт. Быстродействие стабильное, в пределах погрешности (доли процента). Аптайм системы от двух недель до месяца, и больше. На ночь система отправляется в сон (НЕ гибернация - она отключена полностью).
Additional information / Дополнительная информация
При увеличении числа запусков goodbyedpi распухание ядра и снижение быстродействия продолжают нарастать. Остановка драйвера WinDivert не приносит результатов - деградация системы монотонно прогрессирует. Быстродействие проверялось как синтетикой: тест быстродействия 7zG со словарём 512 МБайт, тест памяти TestMem5, тесты AIDA64; так и реальными приложениями (игры) - падение фпс до 50%, фреймтайм рваный (пила), играть крайне неприятно, вне зависимости от того сколько ядер ЦП задействует игра.
После перезагрузки ПК симптомы деградации полностью исчезают. Если не запускать goodbyedpi - не появляются. Про аптайм написал выше.