Движение мыши грузит процессор
pr0n1x, к сожалению проц под ХР не оптимизирован, но есть два пути решения этой проблемы:
Второй: сменить операциооную среду, увы ХР не может работать с кластерами и плохо компилирует ядра приложений на лету для оптимизации под мультипоточность приложения, которое работает в однопоточном режиме.
Ну а теперь серьезно.
Проц не может быть оптимизирован под ХР, т.к. проц это аппаратная часть, а ХР програмная и вся оптимизация строится наоборт: это ХР можно оптимизировать, но не процессор.
Что делать - если потока два, то ХР видит обя ядра. А если при работе приложения загрузка составляет 50-55% от обоих ядер, это згначит что само приложение не поддерживает мультипоточность.
Скачайте Winrar версии 3,61 или старше (лучше 3,7) или последню ювересию 7zip - вот эти архиваторы понимают мультиядерность и имеют в настройках вкладку - использовать мультипоточность.
Если winrar 3.61-3.7 и всеравно не работает, значит убран флажек с использования мультипоточности.
__________________
В этой жизни можно абсолютно все, было-бы желание.
P8P67 EVO, 2600k@4.7, 2х4096 DDR3 PC12800, GTX570, Creative X-fi EG, Hiper 620 + TT VGA 250W
Здесь ниже размещен список необходимых действий для стабильной работы двухъядерных процессоров под управлением OS Microsoft Windows XP (Для Windows 2003 и XP 64Bit требуется только правка boot.ini):
1) Необходима установка пакета обновлений Windows XP SP2!
2) Правка boot.ini:
Мой компьютер (свойства) -> Дополнительно -> Загрузка и восстановление(параметры) -> отредактировать список загрузки вручную -> должно быть примерно так - multi(0)disk(0)rdisk(0)partition(1)\WINDOWS="Micro soft Windows XP Professional RU" /noexecute=optin /fastdetect /usepmtimer (недостающие строчки необходимо дописать).
4) Правка реестра для данного патча:
Так же можно установить, естественно, только если процессор - Athlon 64 X2, последнюю версию драйвера AMD - она даёт поддержку CnQ (Внимание! Старая, а точнее - самая первая версия замечена в приношении не только поддержки CnQ, но и нестабильности всей системы).
Здравствуйте после обновления windows 10 на рабочем столе и в играх переодически мышь начинает плохо реагировать на команды и тормозить. Мышь беспроводная, но исправная, так как я еще использую её на ноуте и там таких проблем нет совсем. До обновления винды таких проблем не было и на стационарном компе. С помощью программ тестировала температуру процессора и видеокарты всё в пределах нормы и ниже. Компьютер новый в общей сложности пользуюсь несколько месяцев.
Processor: Intel(R) Core(TM) i5-6500 CPU @ 3.20GHz (4 CPUs), ~3.2GHz
Memory: 8192MB RAM
Card name: NVIDIA GeForce GTX 1070
Мышь 4tech model g10-810h (батарейку менять пробовала, как и перетыкивания в др. USB гнёзда).
Эта цепочка заблокирована. Вы можете просмотреть вопрос или оставить свой голос, если сведения окажутся полезными, но вы не можете написать ответ в этой цепочке.
Оскорбление — это любое поведение, которое беспокоит или расстраивает человека или группу лиц. К угрозам относятся любые угрозы самоубийством, насилием, нанесением ущерба и др. Любое содержимое для взрослых или недопустимое на веб-сайте сообщества. Любое изображение, обсуждение наготы или ссылка на подобные материалы. Оскорбительное, грубое или вульгарное поведение и другие проявления неуважения. Любое поведение, нарушающее лицензионные соглашения, в том числе предоставление ключей продуктов или ссылок на пиратское ПО. Незатребованная массовая рассылка или реклама. Любые ссылки или пропаганда сайтов с вирусным, шпионским, вредоносным или фишинговым ПО. Любое другое неуместное содержимое или поведение в соответствии с правилами использования и кодексом поведения. Любое изображение, ссылка или обсуждение, связанные с детской порнографией, детской наготой или другими вариантами оскорбления или эксплуатации детей.
У Вас круче - USB 3.0! У меня 2.0;
Попробуйте обновить вот эти "дела" (драйверами для Ваших чипов). Может появится вкладка. У меня Intel.
После установки проверьте обновление их и. еще раз каждый "автоматически" или из списка. Если не лень, конечно!
Может и появится, вкладочка. ("CMOS системы и часы реального времени" не надо!) Хотя. "это уже другая история". Но попробовать стоит.
P.S. Ща посмотрел и еще больше стал уверен в своем убеждении и совете. Смотрите:
Оскорбление — это любое поведение, которое беспокоит или расстраивает человека или группу лиц. К угрозам относятся любые угрозы самоубийством, насилием, нанесением ущерба и др. Любое содержимое для взрослых или недопустимое на веб-сайте сообщества. Любое изображение, обсуждение наготы или ссылка на подобные материалы. Оскорбительное, грубое или вульгарное поведение и другие проявления неуважения. Любое поведение, нарушающее лицензионные соглашения, в том числе предоставление ключей продуктов или ссылок на пиратское ПО. Незатребованная массовая рассылка или реклама. Любые ссылки или пропаганда сайтов с вирусным, шпионским, вредоносным или фишинговым ПО. Любое другое неуместное содержимое или поведение в соответствии с правилами использования и кодексом поведения. Любое изображение, ссылка или обсуждение, связанные с детской порнографией, детской наготой или другими вариантами оскорбления или эксплуатации детей.
18 польз. нашли этот ответ полезным
Был ли этот ответ полезным?
К сожалению, это не помогло.
Отлично! Благодарим за отзыв.
Насколько Вы удовлетворены этим ответом?
Благодарим за отзыв, он поможет улучшить наш сайт.
Насколько Вы удовлетворены этим ответом?
Благодарим за отзыв.
Кажись, нашел решение. Думаю, что и для беспроводных "мышов" тоже самое будет, т.к. ППУ подключены к USB портам.
Итак, БЫЛА ПРОБЛЕМА:
Еще до недавнего большого обновления W10 начала тормозить мышь. Даже при "никакой" загрузке ЦП и OC, просто при запуске Chrome, например, или чего-нибудь там другого. Раздражало, естественно очень. Чего только не делал - ноль эффекта. И вот, буквально только что нашел решение!
РЕШЕНИЕ:
Диспетчер устройств -> Контроллеры USB -> Корневой USB Концентратор ( у меня их два показывает)
1. USB\ROOT_HUB20&VID8086&PID1C26&REV0005
2. USB\ROOT_HUB20&VID8086&PID1C2D&REV0005
Сработало на втором (хотя и первый тоже самое делал сначала):
Свойства -> Дополнительно -> Сброс концентратора
И. УРРРРАААА! Мыша летает, как и ранее. Чего и всем желаю.
Три раза перезагружал ПК. Нагружал дисковую систему и Wi-Fi - все отлично. Мышь четко отрабатывает.
На данный момент, прямо сейчас:
Процессор 4-ядерный i5-750, мышь - HP Laser Gaming Mouse with VoodooDNA (1000Гц, 3200 DPI) - порт USB
При быстром движении мышью довольно сильно загружается одно из ядер процессора - это видно на гаджете МОНИТОРИНГ ЦП - до 90% (обычно одно ядро, остальные меньше)! Так должно быть?
А если бы проц слабенький был - вообще бы тормоза начались? Когда не трогаешь мышь - загрузка 2-4%
Может дрова корявые? Кто че знает, скажите пжлста.
Вот еще: память - 4Гб, и кстати при перемещении мыши в системнике слышны слабые скрипы (потрескивание, шуршание) - видать при загрузке ЦП - что это может быть? Звук точно не из колонок - может из БП?
Видяха - HD5770, была известная проблема с увеличивающимся курсором (стрелкой) , решена с пом. установки драйверов 10.2 Hotfix
поменял на обычную офисную мышку USB - загрузка ЦП прекратилась! Хоть задергайся! :) все же лазерная игровая нагружает! или софт на нее, дрова
Современные мышки очень даже грузят процессор, особенно топовые игровые. Например выставьте 3000 dpi и выше на мышке и резко поводите по столу, нагрузка на проц конкретная, а об этом мало кто задумывается
Мышь не должна жрать ЦП вообще. Это ест программа с которой работает мышь.
Лучше обратитесь к мастеру, тут могут быть проблемы с куллером процессора, процессор сам по себе не скрипит
Современные мышки очень даже грузят процессор, особенно топовые игровые. Например выставьте 3000 dpi и выше на мышке и резко поводите по столу, нагрузка на проц конкретная, а об этом мало кто задумывается
Современные мышки очень даже грузят процессор, особенно топовые игровые. Например выставьте 3000 dpi и выше на мышке и резко поводите по столу, нагрузка на проц конкретная, а об этом мало кто задумывается
так же нагружает как и твоя клавиатура. Нужно вообще постараться так мышкой двигать, чтобы нагрузить 4-ядерный проц. Смотри причину в другом, как правильно заметил, либо в обновлений драйверов, либо глобальнее, проверь на вирусы, почисть комп. И смотри, какой процесс нагружает систему.
Современные мышки очень даже грузят процессор, особенно топовые игровые. Например выставьте 3000 dpi и выше на мышке и резко поводите по столу, нагрузка на проц конкретная, а об этом мало кто задумывается
очень просто проверить что грузит твой проц: 2 варианта
1) простой - выведи диспетчер задач, двигай мышью и смотри какое из приложений его грузит
2) установи прогу Everest и сделай то же самое, там заодно и температура проца пишется
Современные мышки очень даже грузят процессор, особенно топовые игровые. Например выставьте 3000 dpi и выше на мышке и резко поводите по столу, нагрузка на проц конкретная, а об этом мало кто задумывается
у меня мышь A4 tech, процессор pentium d 945, видяха 7300T, windows7, 1.5 Гб оперативки, в покое загрузка колеблется в районе 2% , при дерганье мыши в районе 6 %. но у меня 2 ядра грузятся примерно одинаково и скорее всего загрузка из-за оперативки и видяхи
Современные мышки очень даже грузят процессор, особенно топовые игровые. Например выставьте 3000 dpi и выше на мышке и резко поводите по столу, нагрузка на проц конкретная, а об этом мало кто задумывается
Современные мышки очень даже грузят процессор, особенно топовые игровые. Например выставьте 3000 dpi и выше на мышке и резко поводите по столу, нагрузка на проц конкретная, а об этом мало кто задумывается
Здравствуйте. Столкнулся с интересной проблемой. При перемещении курсора по рабочему столу, самом диспетчере задач и в любом другом окне, они начинают нагружать проц слишком сильно. Если открыт только ДЗ, то при быстром перемещении МЫШИ ИЛИ ПЕРА проводник с 0-0.5% нагрузки поднимается до 12-16%. Если открыты несколько программ в окне, то они тоже нагружают проц и в итоге нагрузка на ЦП в около 30-45% А проц силен(Характеристики пк ниже).
Теперь о играх играх, играю в шутеры вроде (Fortnite. COL MW.) Мышь не хочет плавно поворачиваться, иногда рывками или просто не поворачивается, так же это влечет на резкое падение ФПС из 100+ до 40+-.Я уверен на 100% эти проблемы связаны друг с другом.(Никаких лишних задач и вирусов на компе нет, которые могут повлечь за собой эту нагрузку).
P.S. Возможно это из за старого древнего монитора, который такие быстрые моменты не вывозит.
Производитель процессора: Intel(R) Core(TM) i5-7600 CPU @ 3.50(авто разгон до 4.1)GHz
Логических процессоров: 4
Физических процессоров: 4
Версия ОС:
Windows 10 (64 бит)
NTFS: Поддерживается
Коды Crypto Provider: Поддерживается 311 0x0 0x0 0x0
Монитор:
Flatron w2042T
Видеокарта:
Модель: NVIDIA GeForce GTX 1660
Драйвер DirectX: nvldumd.dll
Версия драйвера: 26.21.14.4166
Версия драйвера DirectX: 26.21.14.4166
Версия OpenGL: 4.6
Глубина цвета: 32 бит/пиксель
Частота обновления: 59 Гц
Карта DirectX: NVIDIA GeForce GTX 1660
Кол-во экранов: 1
Количество логических видеокарт: 1
Разрешение осн. экрана: 1680 x 1050
Разрешение рабочего стола: 1680 x 1050
Размер осн. экрана: 17.09" x 10.63" (20.12" diag)
43.4cm x 27.0cm (51.1cm diag)
Осн. шина: PCI Express 16x
Осн. видеопамять: 6143 МБ
Поддерживаемое сглаживание: 2x 4x 8x
Мышь
Logitach G102P(наблюдения такие, если понизить частоту опроса с 1000 до 125, то нагрузка на Диспетчер окон рабочего стола падает с 14% до 6%) Но это все равно очень много.
Всё началось, как это часто бывает, когда моя машина стала подтормаживать. На рабочем компьютере Windows 10 c 24-ядерным процессором (48 потоков), который на 50% простаивал. Из 64 ГБ памяти использовалось меньше половины. Быстрый SSD тоже не особо использовался. И всё же, когда я двигал мышкой, курсор реагировал не сразу — иногда с задержкой в несколько секунд.
Так что я сделал то, что и всегда — записал и проанализировал трассировку событий с помощью ETW. В результате я обнаружил баг Windows 10, серьёзно влияющий на производительность завершения процессов.
Трассировка ETW показала, что UI зависает во многих программах. Я решил исследовать 1,125-секундное зависание в Диспетчере задач:
На скриншоте внизу вы можете видеть использование системой CPU во время зависания, сгруппированное по названиям процессов — обратите внимание, что использование CPU редко поднимается выше 50%.
Таблица CPU Usage (Precise) показывает, что поток UI Диспетчера задач постоянно блокировался вызовами функций вроде SendMessageW, видимо, ожидающих в критическом регионе ядра (это версия критических секций в режиме ядра), глубоко в стеке вызовов в win32kbase.sys!EnterCrit (не показано здесь):
Я вручную прошёл по цепочке ожидания через полдесятка процессов, чтобы найти, кто заграбастал ресурсы моего UI. В результате анализа мои заметки выглядят примерно так:
Taskmgr.exe (72392) завис на 1,125 с (MsgCheckDelay) на треде 69,196. Наибольшая задержка была 115,6 мс на win32kbase.sys!EnterCrit, который был подготовлен к исполнению процессом conhost.exe (16264), тред 2560 на 3.273101862. conhost.exe (16264), 2560 был подготовлен на 3.273077782 после ожидания 115,640.966 мс, процессом mstsc.exe (79392), 71272. mstsc.exe был подготовлен (то же время, та же задержка) процессом TabTip.exe (8284), 8348, который был подготовлен к исполнению процессом UIforETW.exe (78120), 79584, который был подготовлен процессом conhost.exe (16264), 58696, который был подготовлен процессом gomacc.exe (93668), 59948, который был подготовлен процессом gomacc.exe (95164), 76844.
Я вынужден был продолжать, потому что большинство процессов отпускали блокировку всего через несколько микросекунд. Но в итоге я нашёл несколько процессов (процессы gomacc.exe), которые как будто держали блокировку несколько сотен микросекунд. Или, по крайней мере, они были подготовлены кем-то, кто удерживал блокировку, а затем через несколько микросекунд они готовили кого-то ещё для её снятия. Все эти процессы снимали блокировку в пределах NtGdiCloseProcess.
Я устал вручную ходить по этим цепочкам ожидания, так что решил посмотреть, как часто встречается такой же стек вызовов. Я сделал это, перетащив колонку Ready Thread Stack налево и поискав там NtGdiCloseProcess. Затем я использовал опцию View Callers -> By Function в WPA, чтобы отобразить все стеки Ready Thread Stacks, которые встречались с этой функцией — в этом окне родительские стеки внизу.
Произошло 5768 контекстных переключений, когда процесс NtGdiCloseProcess был в стеке Ready Thread Stack, и каждый из них означает момент, когда освобождается критическая секция. Потоки на этих стеках вызовов провели в ожидании в общей сложности 63,3 секунды — неплохо для задержки в 1,125 с! И если каждое из этих событий случилось после того, как поток удержал блокировку всего на 200 микросекунд, то 5768 событий будет достаточно, чтобы сложиться в подвисание на 1,125 с.
Я не знаком с этой частью Windows, но сочетание PspExitThread и NtGdiCloseProcess ясно показывает, что такое поведение наблюдается при завершении процесса.
Это происходило во время сборки Chrome, а сборка Chrome порождает много процессов. Я использовал нашу распределённую систему сборки, то есть процессы создавались — и завершались — очень быстро.
Следующим шагом было найти, сколько времени потрачено внутри NtGdiCloseProcess. Так что я перенёс таблицу CPU Usage (Sampled) в WPA и получил граф «бабочка», на этот раз вызовов NtGdiCloseProcess. На скриншоте внизу показано, что из всего времени 1,125 с около 1085 мс было потрачено внутри процесса NtGdiCloseProcess, то есть 96% всего времени:
Очень плохо, если блокировку 95% времени удерживает одна функция, особенно, если ту же блокировку нужно получить для вызовов GetMessage или обновления положения курсора. Ради эксперимента я написал тестовую программу, которая с максимальной скоростью создаёт 1000 процессов, ждёт 0,5 секунды, а затем командует всем процессам завершиться одновременно. На скриншоте показано использование этой программой CPU на моём четырёхъядерном (восемь потоков) домашнем ноутбуке:
Итак, что мы видим. Создание процессов ограничено по CPU, как и должно быть. А вот закрытие процессов ограничено по CPU только в начале и в конце, а в середине есть длительный промежуток (около секунды), где оно идёт последовательно — используя всего один из восьми доступных потоков в системе, поскольку 1000 процессов борются за единственную блокировку внутри NtGdiCloseProcess. Это серьёзная проблема. Данный промежуток представляет собой время, когда программы зависнут, а движения курсора будут задерживаться — а иногда этот промежуток растягивается на несколько секунд.
Я заметил, что проблема как будто усугубляется, когда компьютер работал некоторое время, так что я перезагрузил ноутбук и снова запустил тест после загрузки. Последовательность завершения процессов была не такой тяжёлой, но проблема явно присутствовала даже на только что загруженной машине:
Если запустить такой же тест на старом компьютере Windows 7 (Intel Core 2 Q8200, образца 2008 года), то вот результаты:
Создание процессов здесь идёт медленнее, как и можно было ожидать на гораздо более слабом CPU, но завершение процессов настолько же быстрое, как на моём новом ноутбуке, и полностью распараллелено.
Это указывает на то, что сериализация завершения процессов — новая проблема, которая появилась где-то между Windows 7 и Windows 10.
Материалы
Если вам понравилась эта статья, вам могут понравиться и другие расследования:
48 потоков, 47 из них простаивают
Закон Амдала говорит, что если вы распределите свою задачу среди достаточного количества ядер, то суммарное время её выполнения будет равно времени выполнения самого длинного фрагмента, который нельзя распараллелить. Если я интенсивно использовал свой рабочий компьютер в течение нескольких дней, то эта проблема сериализации проявляла себя достаточно явно, когда завершение процессов было значительной частью времени распределённой сборки — и большее количество ядер тут не помогало. Чтобы максимально ускорить сборку (и чтобы курсор начал двигаться во время её проведения), нужно было перезагружать компьютер каждые несколько дней. И даже тогда скорость сборки была не такой высокой, какой должна быть, так что Windows 7 выглядела всё заманчивее.
На самом деле добавление ядер в мою систему замедляло скорость реакции UI. Это потому что система сборки Chrome довольно умная и порождает больше процессов, если у вас больше ядер, так что ещё больше завершающихся процессов борются за глобальную блокировку. Поэтому здесь не просто «24-ядерный CPU, а я не могу сдвинуть курсор», а здесь «24-ядерный CPU, и поэтому я не могу сдвинуть курсор».
О проблеме сообщили в Microsoft, они проводят расследование.
И ещё кое-что.
Вот как выглядит моя тестовая программа по созданию и завершению процессов на 24-ядерной машине:
Видите эту маленькую горизонтальную красную линию в правом нижнем углу? Это наглядная иллюстрация закона Амдала, когда 98% ресурсов моей машины простаивают почти две секунды, в то время как процедура завершения процессов заграбастала блокировку, которая мне нужна, чтобы переместить курсор.
Читайте также: