Изменилось ли поведение svchost.exe в обновлении для создателей Windows 10 (сборка 1703)?


3

Сегодня я обновился до Creators Update, запустив установку из локально установленного ISO. Вернувшись к своему компьютеру, я открыл диспетчер задач и увидел, что использование моей памяти было намного выше, чем было раньше (теперь это почти 6 ГБ памяти в режиме ожидания после входа в систему вместо 2-3 ГБ в предыдущей сборке Windows) - процессы Вкладка показала, что было более 60 различных случаев svchost.exeбега. Эта цифра 6 ГБ предназначена только для памяти процесса - не включая память, используемую для кэширования или «ожидания».

Я побежал, tasklist /svcчтобы получить список служб, в каких процессах, и он перечисляет почти каждый экземпляр svchost.exe как содержащий только одну работающую службу (за исключением нескольких экземпляров, которые выполняют несколько системных служб).

Вот мой вывод:

Image Name                     PID Services
========================= ======== ============================================
System Idle Process              0 N/A
System                           4 N/A
smss.exe                       440 N/A
csrss.exe                      612 N/A
wininit.exe                    700 N/A
csrss.exe                      708 N/A
services.exe                   776 N/A
lsass.exe                      784 KeyIso, Netlogon, SamSs, VaultSvc
svchost.exe                    888 PlugPlay
svchost.exe                    908 BrokerInfrastructure, DcomLaunch, Power,
                                   SystemEventsBroker
fontdrvhost.exe                936 N/A
svchost.exe                   1000 RpcEptMapper, RpcSs
svchost.exe                    104 LSM
winlogon.exe                   544 N/A
fontdrvhost.exe                420 N/A
svchost.exe                   1072 DeviceInstall
dwm.exe                       1136 N/A
svchost.exe                   1164 BFE, CoreMessagingRegistrar, MpsSvc
svchost.exe                   1424 lmhosts
svchost.exe                   1432 W32Time
svchost.exe                   1440 nsi
svchost.exe                   1448 wudfsvc
svchost.exe                   1528 hidserv
svchost.exe                   1628 Dhcp
svchost.exe                   1716 Dnscache
svchost.exe                   1748 EventLog
WUDFHost.exe                  1792 N/A
svchost.exe                   1908 TimeBrokerSvc
svchost.exe                   1952 NlaSvc
NVDisplay.Container.exe       1968 NVDisplay.ContainerLocalSystem
svchost.exe                   1324 Themes
svchost.exe                   1596 ProfSvc
svchost.exe                   1944 EventSystem
svchost.exe                   1052 netprofm
svchost.exe                   2116 StateRepository
svchost.exe                   2256 SENS
svchost.exe                   2296 AudioEndpointBuilder
svchost.exe                   2304 FontCache
(etc)...

Я знаю, что вы можете настроить отдельные службы для запуска в своем собственном экземпляре svc с помощью sc config <serviceName> type= ownкоманды, но, насколько мне известно, я никогда не запускал эту команду.

Я быстро взглянул на Computer\HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Servicesэто, и похоже, что в Typeзначениях ключей для большинства этих служб отсутствует бит флага, на 0x10котором контролируется, работает ли служба в своем собственном svchost.exeэкземпляре или нет. Интересно, что могло повлиять на это изменение?

Кто-нибудь еще наблюдал такое поведение до или после установки Windows 10 Creators Update? Если это изменение конфигурации по умолчанию, повлияет ли это на производительность или стабильность системы?

Я подозреваю, что это повысит стабильность системы, потому что в случае сбоя службы это не приведет к остановке других служб - но это связано с огромными затратами оперативной памяти - но я никогда не сталкивался с ошибкой службы - или, по крайней мере, когда-либо замечал это ( вместо этого наихудшая проблема, с которой я столкнулся, - это wuauservиспользование 100% ЦП в течение нескольких часов подряд - и это не проблема, которую решит изоляция процесса)

(Я только что заметил: они наконец добавили адресную строку в редактор реестра!)

Ответы:


6

Да, это изменение в обновлении Creators, если вы используете компьютер с более чем 3,5 ГБ ОЗУ . Здесь все службы запускаются в своем собственном svchost.exe, чтобы лучше увидеть, какая служба вызывает проблему или предотвратить сбой других служб, если служба вызывает сбой svchost.exe.

Если ваш компьютер имеет 3,5 ГБ памяти, вы можете заметить увеличение количества процессов в диспетчере задач. Хотя это изменение может показаться на первый взгляд, многие будут рады узнать мотивы этого изменения. По мере роста числа предустановленных служб они начали группироваться в процессы, известные как узлы служб (svchost.exe) в Windows 2000. Обратите внимание, что рекомендуемая для этого выпуска оперативная память для ПК составляла 256 МБ, а минимальная ОЗУ - 64 МБ. Из-за резкого увеличения объема доступной памяти с годами преимущество сервис-хостов в экономии памяти уменьшилось. Соответственно, разгруппирование сервисов на ПК с большим объемом памяти (3,5 ГБ ОЗУ) под управлением Windows теперь дает нам возможность делать следующее:

  • Повышение надежности: при сбое одной службы на узле службы происходит сбой всех служб на узле службы. Другими словами,
    процесс узла службы завершается, что приводит к завершению всех запущенных
    служб в этом процессе.

  • Увеличьте прозрачность: диспетчер задач теперь даст вам лучшее представление о том, что происходит за кулисами. Теперь вы можете видеть, сколько ресурсов процессора, памяти, диска и сети потребляют отдельные службы.

    введите описание изображения здесь

  • Повышение безопасности: изоляция процессов и отдельные наборы разрешений для служб повысят безопасность.

Так что не волнуйтесь, это хорошее изменение в v1703, и все в порядке.

Но есть способ вернуть его. Это было обнаружено пользователем веб-сайта, который занимается настройкой Windows.

Итак, запустите regedit.exe, перейдите HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Controlи создайте 32-битный DWORD SvcHostSplitThresholdInKBи установите его на большое количество (больше по сравнению с установленной оперативной памятью).


1
Я не согласен с тем, что это «хорошее изменение», потому что я никогда не сталкивался с svchost.exeнепреднамеренным сбоем, и я обеспокоен тем, что запуск каждого сервиса в своем собственном процессе приведет к ненужной трате памяти (несмотря на то, что память общего процесса используется для таких общих вещей, как общие библиотеки) и может даже нанести ущерб производительности, если учесть всю дополнительную память, которая должна быть инициализирована и сериализована (при спящем режиме или просто при перемещении по t-диску). Я планирую перенастроить свой компьютер, чтобы вернуться к использованию общих процессов для служб и выполнить тесты, чтобы увидеть.
Дай

2
так что давайте снова снимем ремень безопасности и подушку безопасности с автомобиля, потому что у вас никогда не было автомобильной аварии. Какая дурацкая логика. У меня были сбои svchost.exe, которые убили несколько других сервисов, и это хорошее изменение, независимо от того, нравится вам это или нет. Я правильно ответил на вопрос , больше нечего сказать по этому поводу. То, что вы видите, это дизайн, поэтому я не в этой теме.
magicandre1981,

2
Я принял ваш ответ, и я доволен им - я просто лично не согласен с позицией Microsoft, когда речь идет о моем собственном персональном компьютере (я бы не стал менять эту настройку на компьютере, которым я не владею, и использовать для своего собственного персональное использование). Я понимаю аналогию с подушкой безопасности, но мой рабочий стол не является критически важной для безопасности системой, и я готов принять этот риск :)
Dai

@Dai - В основном это был сервис для Linux в течение многих лет. Конечно, как правило, эти службы, как правило, значительно экономнее, а функциональность, которую охватывает каждый данный сервис, больше, поэтому их не так много. Я бы очень нервничал из-за идеи, что целая куча несвязанных вещей работает в одном и том же адресном пространстве. Кошмар безопасности.
всевозможный
Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.