Оптимизируем Windows 10 версии 21H2 — быстро, эффективно и безопасно
реклама
Большинство опытных пользователей стараются избавиться от этих «полезных нововведений» и «восхитительных функций», как их любят называть маркетологи из Microsoft, и делают это разными способами. Кто-то манипулирует с установочным образом Windows 10, вырезая этот хлам в зародыше, еще до его установки, например, с помощью утилиты NTLite.
реклама
Способ трудоемкий, непростой и имеющий один минус, редакции Windows 10 устаревают довольно быстро и настроенный образ системы рано или поздно теряет актуальность. Да и учитывая заметно возросшую самодеятельность Windows 10, не стоит удивляться, если она включит отключенные вами службы и доустановит удаленные компоненты.
Второй путь оптимизации, это установка различных сторонних твикеров системы, например, O&O ShutUp10++ или Ashampoo WinOptimizer, где пользователь с помощью довольно простых интерфейсов отключает ненужные функции Windows 10 и включает оптимизации. Минусов у этого способа предостаточно, твикеры быстро устаревают и их настройки могут не срабатывать в новых версиях ОС, откатить сделанные изменения зачастую невозможно и иногда Windows после них просто необратимо ломается и требует переустановки.
реклама
реклама
В главном окне утилиты нас встречает список доступных действий. А начать стоит с удаления предустановленных UWP-приложений. Не все из них можно назвать бесполезными, я, к примеру, активно пользуюсь «Записками», так что здесь все на ваш вкус. Плюсом удаления приложений через Dism++ станвится скорость процесса и удаление тех приложений, которые система не дает удалить обычными способами, например, Кортану.
Вот такой список приложений я оставляю в системе.
В разделе «Возможности» можно удалить не нужные вам компоненты Windows 10. Удаление производится безопасно и вы всегда можете вернуть и компоненты и UWP-приложения, если они вам понадобятся, средствами системы.
В разделе «Оптимизация» можно настроить множество параметров в одном месте, не «бегая» за ними по различным меню и панелям в самой Windows 10.
Отключив все ненужное, можно сразу очистить систему от мусора, на свежеустановленной Windows 10 Dism++ очистила почти 900 МБ.
Все эти действия займут у вас не более 5 минут, и теперь можно дополнить их более традиционными настройками. Например, удалить раздражающий виджет «Новости и интересы».
Не помешает и отключить некоторые ненужные службы, например, «Диспетчер печати», если у вас нет принтера.
Я обычно отключаю и службу SysMain (SuperFetch), но более глубокое отключение служб не провожу из-за риска потерять стабильность ОС.
Если вы пользуетесь небольшим набором проверенных сайтов с репутацией, например, соцсетями и Ютубом, и не устанавливаете много программ, можно «поумерить пыл» Защитника Windows. Но полностью отключать его не стоит, как и не стоит устанавливать сторонний антивирус, особенно бесплатный. Неплохо показало себя на практике добавление папок с играми и их процессов в исключения Защитника Windows.
После моего тюнинга потребление ОЗУ упало до 1.3 ГБ, запущено всего 95 процессов, а на SSD освободилось пара гигабайт.
Заметно снизилась и нагрузка на процессор и накопитель в простое, ничего не «дергает» систему и при этом мы не потеряли ни капли стабильности и надежности, почти достигнув показателей потребления ресурсов у Windows 10 LTSC.
Итоги
Как видите, Windows 10 легко заставить работать быстрее и выглядеть лаконичнее довольно простыми способами, доступными и начинающему пользователю. Конечно, если у вас 32 ГБ быстрой оперативной памяти и мощный восьмиядерный процессор, можно и не обращать внимания на кучу предустановленного «мусора». Но владельцы слабых ПК и ноутбуков начального и среднего уровня эту разницу в производительности сразу заметят. Особенно, если пользуются жестким диском, что в 2021 году становится просто мучением, ведь Windows 10 постоянно загружает его, дергая проверками на вирусы и телеметрией.
Выход прост, купить SATA III SSD, который можно установить в любой старый бюджетный ноутбук или ПК, заметно прибавив им производительности. Надежная модель WD Blue (WDS250G2B0A), объемом 250 ГБ, стоит в Регарде 4620 рублей. А совсем немного доплатив, можно взять WD Blue (WDS500G2B0A) на 500 ГБ.
Пишите в комментарии, а как вы оптимизируете Windows 10 и были ли у вас случаи, когда оптимизация проходила настолько неудачно, что требовала переустановки?
Внутреннее устройство памяти Microsoft Hyper-V
В статье были описаны методы доступа к памяти гостевых разделов Hyper-V, создаваемых в самых разных случаях
Память гостевых ОС.
Программное обеспечение, используемое в статье (операционные системы с патчами от августа 2019):
Windows 10, build 1903 x64
Windows Server 2019
Windows Server 2016
Visual Studio 2019
PyKd плагин для WinDBG
Термины и определения:
— WDAG – Windows Defender Application Guard.
— Full VM (виртуальная машина) – обычная полноценная виртуальная машина, созданная в Hyper-V manager. В отличие от контейнеров WDAG, Windows Sandbox, docker в режиме изоляции Hyper-V.
— Root ОС – операционная система, в которой установлена серверная часть Hyper-V.
— Гостевая ОС – операционная система, которая работает в контексте эмуляции Hyper-V, в т.ч. используя виртуальные устройства, предоставляемые гипервизором. В контексте статьи, это могут быть как Full VM, так и контейнеры.
— TLFS – документ Hypervisor Top-Level Functional Specification 5.0.
— GPA (guest physical address) – физический адрес памяти гостевой операционной системы.
— SPA (system physical address) – физический адрес памяти root ОС.
— Гипервызов (hypercall) – сервис гипервизора, вызываемый посредством выполнения команды vmcall с указанием номера гипервызова.
Исходники драйвера доступны на github.com:
Python-скрипт для вывода информации о GPAR и MBlock-объектах
Технологии виртуализации компании Microsoft давно и прочно вошли в нашу жизнь как в серверном сегменте, так и в клиентских ОС. Они используются не только для запуска гостевых ОС, но и для работы защитных механизмов, таких как Virtualization Based Security (VBS), Credential Guard, Device Guard, Hypervisor Code integrity (HVCI).
Компонент Hyper-V впервые появился в Windows Server 2008 и предоставлял достаточно простые на тот момент возможности по созданию гостевых операционных систем. Но Microsoft активно развивает эту технологию, и в настоящее время она глубоко интегрирована в ядро операционной системы Windows. Корневым компонентом является модуль hvix64.exe для процессоров Intel, hvax64.exe для процессоров Amd и hvaa64.exe для ARM.
Также описание архитектуры памяти Hyper-V (помимо TLFS) было сделано Andrea Allievi (www.andrea-allievi.com/files/Recon_2017_Montreal_HyperV_public.pptx) на конференции Recon 2017. Но слайды довольно абстрактно описывают модель реализации, и сопоставить эту информацию с реальным кодом, понять, что и как работает, очень сложно. Презентация была сделана до того, как Microsoft опубликовала символьную информацию компонентов виртуализации, так что, возможно, причина в этом.
В 2018 году Microsoft выпустила WDAG, которые представляет из себя надстройку к браузеру, запускающую браузер Microsoft Edge в контейнере Hyper-V со slim RDP-фронтендом, что создаёт ощущение, как будто вы работаете непосредственно в браузере. Подобные технологии очень давно использовала компания Citrix в своих терминальных решениях. У меня появилось желание понять, как же работает WDAG.
Доработка этой утилиты помогла лучше понять, каким образом работают виртуальные машины и контейнеры Hyper-V, а также каким образом получить доступ к памяти гостевых ОС различными способами.
Сперва я планировал написать отдельную статью про контейнеры Hyper-V, но учитывая количество компонентов (см. скриншот), провести полное исследование слишком трудоёмко.
Сам гипервизор находится в изолированной области памяти, память root-ОС отображается 1 в 1, возможность чтения памяти средствами гипервизора с помощью гипервызова HvReadGpa отсутствует (отдельная блокировка в коде для раздела с идентификатором, равным 0, т.е. для root-ОС). Основные моменты работы подсистемы памяти описаны в TLFS.
Так что основной упор будет сделан на методы доступа к памяти гостевых ОС. Будут описаны механизмы работы памяти для обычных виртуальных машин Microsoft и контейнеров WDAG и Windows Sandbox. Docker будет упомянут кратко и только в контексте Hyper-V, т.к. это отдельная экосистема, которой и так посвящено огромное количество ресурсов.
В ходе исследования был создан драйвер hvmm.sys, который может читать содержимое памяти гостевой ОС напрямую из root-ОС минуя интерфейсы гипервизора и драйвера vid.sys. Драйвер hvmm.sys был интегрирован в проект LiveCloudKd.
В целом статья представляет материал в стиле Windows Internals и описывает то, как работает память ОС. Зачем? Чтобы узнать, как работает достаточно популярная технология Microsoft. Также может пригодиться специалистам, увлекающимся форензикой и разбирающим дампы памяти. Andrea Allievi готовит детальное описание актуальной версии Hyper-V для 2-й части 7-й версии книги Windows Internals, но пока книга не была издана, можно будет почитать эту статью и кратко ознакомиться с архитектурой памяти.
К сожалению, информация о структурах в символах для vid.sys отсутствует, поэтому название таких структур в статье выполнено произвольно исходя из сигнатур, которые в них присутствуют. Andrea Allievi упоминал “bucket” структуры в своей презентации, но как конкретно они реализованы в драйвере vid.sys – неизвестно. Если в следующей части Windows Internals будет детальное описание этих структур, то наименования будут исправлены, технические детали работы от этого не изменятся.
Работа с памятью Full VM и контейнеров посредством прямого доступа
Основным процессом, который управляет работой виртуальной машины, является vmwp.exe. Его запускает vmms.exe в случае запуска полноценной виртуальной машины, или vmcompute.exe в случае запуска контейнеров. При запуске процесс vmwp.exe через интерфейс vid.dll обращается к интерфейсам гипервизора – гипервызовам (hypercalls). Я собрал статистику гипервызовов для VM Windows Server 2019, контейнера Docker в режиме изоляции Hyper-V (образ nanoserver:1809) и контейнера WDAG. WDAG-контейнер генерирует слишком много гипервызовов, поэтому из-за торможения, вызванным записью результатов отладчиком, контейнер сразу начал выключаться после включения (управляющее приложение контролирует таймауты выполнения некоторых процедур), в связи с чем результаты по WDAG содержат общий показатель (надеюсь попробовать dtrace, относительно недавно доработанный под Windows, для сбора подобной статистики – по идее, он должен снизить издержки на запись собранных данных). Отдельно зафиксирован показатель по выключению, так что порядок оценить можно. По сравнению с обычными виртуальными машинами он достаточно большой:
Какие категории гипервызовов можно выделить? Создание раздела, установка его свойств, создание, виртуальных процессоров, виртуальных портов (используются для отправки сигналов, сообщений), установка перехватов (interceptions), и различные гипервызовы для работы с памятью.
Функция winhvr!WinHvMapGpaPagesFromMbpArrayScanLargePages. В Rdx указывается номер страницы, в rsi – размер (так же в страницах).
При запуске Windows Server 2019 с 1500 Mb оперативной памяти получаем.
При запуске Windows Server 2019 с 2300 Mb оперативной памяти получаем
1-й вызов: rdx=0000000000000000 rsi=000000000008fc00
2-й вызов: rdx=00000000000f8000 rsi=0000000000000800
3-й вызов: rdx=0000000000fff800 rsi=000000000000024a
Что делать, если невыгружаемый пул в Windows 10 занимает всю память
Просмотр запущенных приложений в Диспетчере задач — это первое, с чего всякий пользователь начинает поиск причин медленной работы компьютера. И вроде бы и с процессами всё нормально, и с дисками, но на вкладке «Производительность», если выбрать «Память», можно увидеть, что она практически вся занята и уходит в невыгружаемый пул памяти. Это означает, что имеет место утечка памяти и неважно какой объем ОЗУ имеется на ПК, в невыгружаемый пул она может уйти вся без остатка.
Основной причиной утечки в таких случаях является некорректное взаимодействие сетевых драйверов с драйверами мониторинга использования сети, хотя нельзя исключать наличия проблем с другими драйверами аппаратных компонентов ПК.
Неполадка может показаться серьёзной, на самом же деле она легко устраняется. Способов исправления существует несколько. Самый простой заключается в отключении службы мониторинга сетевой активности. Для этого откройте командой regedit редактор реестра и перейдите по следующему пути:
Эту же настройку следует проверить в ключе:
Результат будет аналогичным.
В обеих случаях для вступления новых настроек в силу потребуется перезагрузка компьютера. После этого утечка в невыгружаемый пул памяти должна прекратиться. Это самый простой и эффективный способ, но есть также и другие варианты. Например, можно установить приложение Killer Network Manager, найти в его настройках опцию управления пропускной способностью и отключить её.
Если драйвера для сетевой карты скачивались с сайта производителя, попробуйте их удалить и дать Windows 10 установить свои драйвера. Если проблема наблюдается с драйверами Microsoft, поступаем наоборот, скачиваем для карты Killer Network драйвера с официального ресурса производителя и устанавливаем их. Выше упоминалось, что утечку памяти могут вызывать не только сетевые драйвера. Определить проблемный драйвер можно с помощью утилиты Poolmon, но для этого потребуется установить набор инструментов разработки драйверов для Windows.
Скачав WDK для вашей версии Windows 10 с официальной страницы Microsoft.
Теперь откройте командную строку от имени администратора, перейдите в расположение C:\Windows\System32\drivers и выполните команду:
findstr /m /l /s Name *.sys
Где Name — имя, то есть тэг записи.
В результате вы получите список драйверов, которые с большей или меньшей долей вероятности являются источниками проблемы. Далее уже решаем, что с ними делать: удалять, заменять или откатывать к более ранним версиям.
2 комментария
Здравствуйте. в моем случае невыгружаемый пул остановился на 1,7 гб, это так и должно? У меня мат.плата от MSI
Смотря по тому, сколько у Вас имеется памяти. Если 8 Гб, то в общем терпимо. Ну и учитывайте, что невыгружаемый пул растет при скачивании чего-либо, проверьте, закрыв все программы, что используют интернет-соединение.
Процесс Vmmem — что это?
Приветствую друзья! 
Сегодня мы поговорим про один процесс, который вы можете заметить в диспетчере задач… название его — Vmmem. Постараемся выяснить — зачем он нужен? Это может быть процесс вполне легальной программы, но это может быть и вирус.. поэтому давайте разбираться))
Описание
Процесс Vmmem — это оперативная память, которая выделена для использования виртуальной машиной (Hyper-V).
Простыми словами — виртуальная машина, это в некотором смысле виртуальный компьютер, который имеет свой процессор, свою оперативку. Сколько виртуальная машина (или несколько) потребляет памяти — столько примерно и будет кушать оперативы процесс Vmmem.
Разбираемся
Чтобы отключить процесс Vmmem, попробуйте следующее:
Можно также ограничить ресурсы Vmmem путем создания файла %UserProfile%\.wslconfig, внутри которого прописать:
[wsl2]
memory=6GB # Ограничиваем память для WSL2 VM.
processors=5 # Ограничиваем количество процессов для WSL2 VM.
Вот пример сколько процесс может потреблять оперативки (это еще далеко немного):
Картина может быть и такой, здесь уже намного больше используется:
Заключение
Удачи и добра, до новых встреч друзья! 
Добавить комментарий Отменить ответ
Этот сайт использует Akismet для борьбы со спамом. Узнайте как обрабатываются ваши данные комментариев.
Vmmem using over 10gb memory and around 50% CPU #7033
Comments
DanielWhite21 commented Jun 3, 2020
Expected behavior
To run docker jobs in a timely manner
Actual behavior
Its taking over 2 hrs to build an R application, using over 10gb mem, and up to 50% CPU
I have to keep restarting my laptop in between build jobs and some of these are requiring minor tweaks to the R app.
I understand its a large build out but it takes around 20 mins on my Mac
Information
Steps to reproduce the behavior
The text was updated successfully, but these errors were encountered:
4O4 commented Jun 4, 2020
I have the same issue when running docker-compose setup on windows 10. CPU usage of vmmem is insane and It’s also consuming tons of RAM, but somehow the task manager always shows 0 for RAM usage of vmmem.
I can’t provide diagnostics ID right now, because it takes forever to finish for some reason and my computer is burning hot during that. I also can’t publish my docker-compose.yml right now and I don’t know yet if this also happens when running some specific single container. I need to check it out yet.
However, what I can provide is my observation of some of the internals of the VM the docker stuff is running on. In the Hyper-V manager I’ve seen that the docker machine is eating up to 20% CPU (at least it was claiming so) and the usage was rapidly changing like there was a lot of intensive stuff running, then stopping for a very short time, then spinning up again. The normal CPU usage for my current setup should be 1% max. I am sure none of my apps are causing such usage spikes, so I’ve decided to dig into the VM to see what is it doing.
I’ve done the following to gain access to the VM (found the commands somewhere on the internet):
then I’ve ran top to see what processes are running and what I’ve seen was /usr/bin/lifecycle-server being on top of the CPU and RAM usage stats, together with memlog daemon (although the values of the memlog were jumping a lot, lifecycle server was constantly on the top).
I’ve killed the lifecycle-server process and everything turned back to normal, my CPU fans stopped spinning like crazy, the temperatures went back to normal. This problem comes back from time to time, sometimes after I reboot the computer, sometimes after restarting the docker engine.
I’m repeating the steps described above every time this happens to kill the lifecycle-server and stop that massive heat generator. Everything in docker is working absolutely normal after that and my room becomes completely quiet with no fans spinning 
My guess is that lifecycle-server is spamming a lot of error / warning/ debug / whatever logs, these logs are then filling lots of RAM and the intensity of writes causes lots of CPU usage too. Although that is only my blind guess since I have no idea what exactly is this process responsible for and sadly there is no source code available for Docker Desktop stuff.
I hope this helps to narrow down the problem a bit.