максимальное число процессов в windows
Как исправить слишком много фоновых процессов в Windows 10 [ЛЕГКИЕ ШАГИ]
Есть ли в вашем диспетчере задач Windows 10 список фоновых процессов? Если это так, вам может потребоваться уменьшить фоновые процессы, чтобы освободить системные ресурсы для настольного программного обеспечения.
Поскольку фоновые процессы забирают ОЗУ, их сокращение, вероятно, немного ускорит ваш ноутбук или рабочий стол.
Фоновыми процессами обычно являются службы Microsoft и стороннего программного обеспечения, перечисленные в окне «Службы». Таким образом, сокращение фоновых процессов – это скорее вопрос прекращения программных услуг.
Однако они также могут быть программами запуска и системными мониторами. Таким образом, есть несколько способов исправить слишком много фоновых процессов в Windows 10.
Как я могу уменьшить фоновые процессы в Windows 10?
1. Уменьшите загрузку Windows 10
Диспетчер задач часто перечисляет запускаемые программы на панели задач как фоновые процессы. Большинство антивирусных утилит являются программным обеспечением в системном трее.
Это программы, которые вы обычно открываете с помощью контекстных меню значков на панели задач. Таким образом, удаление программного обеспечения системного трея из автозагрузки Windows является одним из способов уменьшить фоновые процессы. Вы можете удалить программное обеспечение системного трея из автозагрузки следующим образом.
Если вы хотите узнать, как добавлять или удалять загрузочные приложения в Windows 10, ознакомьтесь с этим простым руководством.
Не удается открыть диспетчер задач? Не волнуйтесь, у нас есть правильное решение для вас.
2. Завершите фоновые процессы с помощью диспетчера задач.
Обратите внимание на процентное соотношение ОЗУ и ЦП, которое показывает использование системных ресурсов для процессов. Остановите сторонние программные процессы, которые тратят больше всего ресурсов.
Однако придерживайтесь только прекращения сторонних фоновых сервисов. Не вмешивайтесь в процессы Windows, которые более важны для ОС.
Если вы хотите узнать, как остановить все процессы в Window 10, прочитайте эту статью и узнайте, как это сделать самостоятельно в кратчайшие сроки.
Конечная задача не работает? Ознакомьтесь с этим подробным руководством, чтобы узнать, как быстро решить проблему.
3. Удалите сторонние службы программного обеспечения из автозагрузки Windows
Многие сторонние программные службы, перечисленные в фоновых службах, могут быть частью запуска Windows. Таким образом, кнопка Завершить задачу временно остановит эти службы только до тех пор, пока вы не перезапустите Windows.
Поэтому вам необходимо отключить некоторые из служб, перечисленных в фоновых процессах, чтобы они не запускались снова при запуске системы. Вот как вы можете настроить запуск для служб, перечисленных в фоновых процессах:
Хотите избавиться от повторяющихся процессов в Windows 10? Вот лучший инструмент, который сделает это за вас.
Это удалит выбранную службу из автозагрузки Windows. Прежде чем отключить службу, обратите внимание на описание в окне «Службы», в котором содержатся дополнительные сведения о ней. Затем выключите его, если он вам действительно не нужен.
Если вы не можете запустить утилиту настройки системы, ознакомьтесь с этим пошаговым руководством, чтобы оно снова заработало.
4. Отключите системные мониторы.
Диспетчер задач также отображает сторонние системные мониторы в качестве фоновых процессов. Некоторые сторонние утилиты включают системные мониторы, которые проверяют системные ресурсы и использование жесткого диска.
Эти системные мониторы работают независимо от основного программного обеспечения в качестве фонового процесса и обычно предоставляют многочисленные уведомления в системном трее.
Например, уведомления системного монитора CCleaner информируют пользователей о том, что утилита может освободить 500 мегабайт жесткого диска. Даже если системные мониторы запускаются при запуске Windows, вы не всегда можете отключить их с помощью диспетчера задач.
Таким образом, единственный способ убедиться, что некоторые системные мониторы не запускаются с Windows, – это настроить параметры для них, включенные в их служебное программное обеспечение.
Поэтому, если вы видите системный монитор, перечисленный в фоновых процессах диспетчера задач, найдите параметр в настройках программного обеспечения, который отключит его.
Таким образом, вы можете устранить избыток фоновых процессов, прежде всего, удалив сторонние программы и их службы из автозагрузки Windows с помощью диспетчера задач и служебных программ настройки системы.
Это высвободит больше системных ресурсов для настольного программного обеспечения на панели задач и ускорит работу Windows. Вы можете проверить эту статью для получения дополнительных советов, которые освободят системные ресурсы в Windows 10.
Если у вас есть какие-либо другие вопросы или предложения, не стесняйтесь оставлять их в разделе комментариев ниже.
Преодолевая границы Windows: процессы и потоки
Это четвертая статья из серии «Преодолевая границы Windows», в рамках которой я рассказываю об ограничениях, существующих для фундаментальных ресурсов в Windows. На сей раз, я собираюсь обсудить с вами ограничение на максимальное количество потоков и процессов, поддерживаемое Windows. Здесь я кратко опишу различие между потоком и процессом, ограничение потока опроса (от англ. survey thread), после чего мы поговорим об ограничениях, связанных с процессами. В первую очередь я решил рассказать об ограничениях потоков, так как каждый активный процесс имеет, по крайней мере, один поток (процесс, который завершился, но ссылка на который хранится в обработчике, предоставленном другим процессом, не имеет ни одного потока), так что ограничения процессов напрямую зависят от основных ограничений, связанных с потоками.
В отличие от некоторых вариантов UNIX, большинство ресурсов Windows не имеют фиксированного ограничения, заложенного в операционную систему на этапе сборки, а скорее получают ограничения на основании имеющихся в распоряжении ОС базовых ресурсов, о которых я рассказывал ранее. Процессы и потоки, например, требуют для себя физической памяти, виртуальной памяти и памяти пула, так что число процессов и потоков, которые могут быть созданы на данной системе Windows, в конечном счете, определяется одним из этих ресурсов, в зависимости от того, каким образом эти процессы или потоки были созданы и какое из ограничений базовых ресурсов будет достигнуто первым. Поэтому я рекомендую вам, чтобы вы прочитали мои предыдущие статьи, если вы до сих пор этого не сделали, потому что далее я буду обращаться к таким понятиям, как зарезервированная память, выделенная память и системное ограничение памяти, о которых я говорил в предыдущих своих статьях:
Процессы и потоки
Процесс Windows по своей сути является контейнером, в котором хранится код команд из исполняемого файла. Он представляет собой объект процесса ядра и Windows использует этот объект процесса и связанные с ним структуры данных для хранения и сопровождения информации об исполняемом коде приложения. Например, процесс имеет виртуальное адресное пространство, в котором хранятся его частные и общие данные и в которое отображаются исполняемый образ и связанные с ним библиотеки DLL. Windows с помощью инструментов диагностики записывает информацию об использовании процессом ресурсов для обеспечения учета и выполнения запросов и регистрирует ссылки процесса на объекты операционной системы в таблице дескриптора процесса. Процессы работают с контекстом безопасности, именуемом маркером, который идентифицирует учетную запись пользователя, группы учетной записи и привилегии, назначенные процессу.
Процесс включает в себя один или более потоков, которые фактически выполняют код в процессе (технически, выполняются не процессы, а потоки) и представлены в системе в виде объектов потоков ядра. Есть несколько причин, почему приложения создают потоки в дополнение к их исходному начальному потоку: 1) процессы, обладающие пользовательским интерфейсом, обычно создают потоки для того, чтобы выполнять свою работу и при этом сохранять отзывчивость основного потока к командам пользователя, связанными с вводом данных и управлением окнами; 2) приложения, которые хотят использовать несколько процессоров для масштабирования производительности или же которые хотят продолжать работать, в то время как потоки останавливают свою работу, ожидая синхронизации операций ввода/вывода, создают потоки, чтобы получить дополнительную выгоду от многопоточной работы.
Ограничения потоков
Помимо основной информации о потоке, включая данные о состоянии регистров ЦП, присвоенный потоку приоритет и информацию об использовании потоком ресурсов, у каждого потока есть выделенная ему часть адресного пространства процесса, называемая стеком, которую поток может использовать как рабочую память по ходу исполнения кода программы, для передачи параметров функций, хранения локальных переменных и адресов результатов работы функций. Таким образом, чтобы избежать нерациональной траты виртуальной памяти системы, первоначально распределяется только часть стека, или же часть ее передается потоку, а остаток просто резервируется. Поскольку стеки в памяти растут по нисходящей, система размещает так называемые «сторожевые» страницы (от англ. guard pages) памяти вне выделенной части стека, которые обеспечивают автоматическое выделение дополнительной памяти (называемой расширением стека), когда она потребуется. На следующей иллюстрации показано, как выделенная область стека углубляется и как сторожевые страницы перемещаются по мере расширения стека в 32-битном адресном пространстве:
Поскольку каждый поток потребляет часть адресного пространства процесса, процессы имеют базовое ограничение на количество потоков, которое они могут создать, равное размеру их адресного пространства, поделенного на размер стека потока.
Еще раз, так как часть адресного пространства уже использовалась под код и начальную динамическую память, не все 2Гб были доступны для стеков потоков, так что общее количество созданных потоков не смогло достигнуть теоретического предела в 2048 потоков.
Я попробовал запустить Testlimit с дополнительной опцией, предоставляющей приложению расширенное адресное пространство, надеясь, что если уж ему дадут больше 2Гб адресного пространства (например, в 32-битных системах это достигается путем запуска приложения с опцией /3GB или /USERVA для Boot.ini, или же эквивалентной опцией BCD на Vista и позднее increaseuserva), оно будет его использовать. 32-битным процессам выделяется 4Гб адресного пространства, когда они запускаются на 64-битной Windows, так сколько же потоков сможет создать 32-битный Testlimit, запущенный на 64-битной Windows? Если основываться на том, что мы уже обсудили, ответ должен быть 4096 (4Гб разделенные на 1Мб), однако на практике это число значительно меньше. Вот 32-битный Testlimit, запущенный на 64-битной Windows XP:
Причина этого несоответствия кроется в том факте, что когда вы запускаете 32-битное приложение на 64-битной Windows, оно фактические является 64-битным процессом, которое выполняет 64-битный код от имени 32-битных потоков, и потому в памяти для каждого потока резервируются области под 64-битные и 32-битные стеки потоков. Для 64-битного стека резервируется 256Кб (исключения составляют ОС, вышедшие до Vista, в которых исходный размер стека 64-битных потоков составляет 1Мб). Поскольку каждый 32-битный поток начинает свое существование в 64-битном режиме и размер стека, который ему выделяется при старте, превышает размер страницы, в большинстве случаев вы увидите, что под 64-битный стек потока выделяется как минимум 16Кб. Вот пример 64-битных и 32-битных стеков 32-битного потока (32-битный стек помечен как «Wow64»):
32-битный Testlimit смог создать в 64-битной Windows 3204 потока, что объясняется тем, что каждый поток использует 1Мб + 256Кб адресного пространство под стек (повторюсь, исключением являются версии Windows до Vista, где используется 1Мб+ 1Мб). Однако, я получил другой результат, запустив 32-битный Testlimit на 64-битной Windows 7:
Различия между результатами на Windows XP и Windows 7 вызвано более беспорядочной природой схемы распределения адресного пространства в Windows Vista, Address Space Layout Randomization (ASLR), которая приводит к некоторой фрагментации. Рандомизация загрузки DLL, стека потока и размещения динамической памяти, помогает улучшить защиту от вредоносного ПО. Как вы можете увидеть на следующем скриншоте программы VMMap, в тестовой системе есть еще 357Мб доступного адресного пространства, но наибольший свободный блок имеет размер 128Кб, что меньше чем 1Мб, необходимый для 32-битного стека:
Здесь следует отметить, что произошла другая ошибка, из чего следует, что в данной ситуации причиной является не адресное пространство. Фактически, 64Кб-стеки должны обеспечить приблизительно 32 000 потоков (2Гб/64Кб = 32768). Так какое же ограничение проявилось в данном случае? Если посмотреть на возможных кандидатов, включая выделенную память и пул, то никаких подсказок в нахождении ответа на этот вопрос они не дают, поскольку все эти значения ниже их пределов:
Ответ мы можем найти в дополнительной информации о памяти в отладчике ядра, который укажет нам искомое ограничение, связанное с доступной резидентной памятью, весь объем которой был исчерпан:
Базовый стек ядра занимает 12Кб в 32-битной Windows и 24Кб в 64-битной Windows. 14225 потоков требуют для себя приблизительно 170Мб резидентной памяти, что точно соответствует объему свободной памяти на этой системе с выключенным Testlimit:
Как только достигается предел доступной системной памяти, многие базовые операции начинают завершаться с ошибкой. Например, вот ошибка, которую я получил, дважды кликнув на ярлыке Internet Explorer, расположенном на рабочем столе:
Причиной, по которой ранее я употреблял термин «базовый» стек ядра, является то, что поток, который работает с графикой и функциями управления окнами, получает «большой» стек, когда он исполняет первый вызов, размер которого равен (или больше) 20Кб на 32-битной Windows и 48Кб на 64-битной Windows. Потоки Testlimit не вызывают ни одного подобного API, так что они имеют базовые стеки ядра.
Ограничения процессов
Число процессов, поддерживаемых Windows, очевидно, должно быть меньше, чем число потоков, потому как каждый процесс имеет один поток и сам по себе процесс приводит к дополнительному расходу ресурсов. 32-битный Testlimit, запущенный на системе с 64-битной Windows XP и 2Гб системной памяти создает около 8400 процессов:
Если посмотреть на результат работы отладчика ядра, то становится понятно, что в данном случае достигается ограничение резидентной доступной памяти:
Если бы процесс использовал резидентную доступную память для размещения только лишь стека потока привилегированного режима, Testlimit смог бы создать намного больше, чем 8400 потоков на системе с 2Гб. Количество резидентной доступной памяти на этой системе без запущенного Testlimit равно 1,9Гб:
Путем деления объема резидентной памяти, используемой Testlimit (1,9Гб), на число созданных им процессов получаем, что на каждый процесс отводится 230Кб резидентной памяти. Так как 64-битный стек ядра занимает 24 Кб, мы получаем, что без вести пропали примерно 206Кб для каждого процесса. Где же остальная часть используемой резидентной памяти? Когда процесс создан, Windows резервирует достаточный объем физической памяти, чтобы обеспечить минимальный рабочий набор страниц (от англ. working set). Это делается для того, чтобы гарантировать процессу, что любой ситуации в его распоряжении будет достаточное количество физической памяти для сохранения такого объема данных, который необходим для обеспечения минимального рабочего набора страниц. По умолчанию размер рабочего набора страниц зачастую составляет 200Кб, что можно легко проверить, добавив в окне Process Explorer столбец Minimum Working Set:
На скриншоте снизу вы можете увидеть, что отладчик ядра сообщает не только о том, что был достигнут предел выделенной системной памяти, но и о том, что, после достижения этого ограничения, имели место тысячи ошибок распределения памяти, как виртуальной, так и памяти, выделенной под выгружаемый пул (предел выделенной системной памяти фактически был достигнут несколько раз, так как, когда случалась ошибка, связанная с нехваткой объема файла подкачки, этот самый объем увеличивался, отодвигая это ограничение):
Начальный объем выделенной памяти под стек потока, описанный ранее, оказывает незначительное влияние на остальные запросы на предоставление памяти, требуемой для структур данных адресного пространства процесса, записей таблицы страниц, таблицы дескрипторов, объектов процесса и потока, и собственных данных, которые процесс создает во время своей инициализации.
Сколько процессов и потоков будет достаточно?
Таким образом, ответы на вопросы «сколько потоков поддерживает Windows?» и «сколько процессов вы можете одновременно запустить на Windows?» взаимосвязаны. Помимо нюансов методов, по которым потоки определяют размер их стека и процессы определяют их минимальный рабочий набор страниц, двумя главными факторами, определяющим ответы на эти вопросы для каждой конкретной системы, являются объем физической памяти и ограничение выделенной системной памяти. В любом случае, если приложение создает достаточное количество потоков или процессов, чтобы приблизиться к этим пределам, то его разработчику следует пересмотреть проект этого приложения, поскольку всегда существуют различные способы достигнуть того же результата с разумным числом процессов. Например, основной целью при масштабировании приложения является стремление сохранить число выполняющихся потоков равным числу ЦП, и один из способов добиться этого состоит в переходе от использования синхронных операции ввода/вывода к асинхронным с использованием портов завершения, что должно помочь сохранить соответствие числа запущенных потоков с числом ЦП.
За что отвечает параметр “Число процессоров” в msconfig?
Очень часто в различных статьях и видео по “ускорению” работы компьютера можно встретить совет с включением параметра “Число процессоров” и присвоения ему значения, которое равно количеству ядер установленного процессора. Якобы это позволит операционной системе использовать ресурсы процессора на полную мощность.
В данной статье мы расскажем вам истинное назначение этого параметра в конфигурационном окне msconfig, а также примеры ситуаций, когда включение данной опции действительно может быть полезным.
Все ядра в Windows задействованы по умолчанию
Переключение вида отображения
Окно будет поделено на количество частей равное количеству ядер (потоков) в вашем процессоре. И для каждого из них будет рисоваться график загруженности. Это значит, что в данный момент они задействованы для выполнения тех или иных задач.
Отображение нагрузки на ядра
Для чего же тогда нужна настройка “Число процессоров”?
Она нужна для ограничения использования ядер (потоков) вашего процессора. Причин на это может быть много. Например, у вас есть старая программа, которая не рассчитана на работу в многопоточной среде из-за чего не хочет запускаться.
В этом случае вы ограничиваете число потоков до нужного значения при помощи данной настройки, перезагружаетесь и получаете работоспособное приложение. Также такая возможность может пригодится тем, кто пишет программы под конкретное число ядер и хочет проверить их работоспособность.
Вывод
Число процессоров в msconfig никоим образом не увеличивает скорость работы компьютера и не разблокирует все ядра процессора. В операционной системе Windows они все сразу задействованы по умолчанию. Единственным назначением данной настройки является принудительное отключение ядер (потоков) для какой – то конкретной задачи и цели.