Лимит выделенной памяти iis wsus
Пол года wsus исправно работал обновлял компы в домене, но что то пошло не так помогите разобраться.
Пул приложений "WsusPool" автоматически отключен из-за серии отказов в процессах, обслуживающих его.
Консоли администрирования WSUS не удается подключиться к серверу WSUS через удаленный API.
Процесс, обслуживающий пул приложений "WsusPool", превысил лимиты времени для завершения работы. Идентификатор процесса "24440".
Рабочий процесс "24440", обслуживающий пул приложений "WsusPool", не смог остановить канал прослушивателя для протокола "http" в отведенный интервал времени. Поле данных содержит номер ошибки.
Рабочий процесс, обслуживающий пул приложений "WsusPool", запросил очистку, поскольку достигнуто ограничение собственной памяти.
Процесс, обслуживающий пул приложений "WsusPool", превысил лимиты времени для завершения работы. Идентификатор процесса "23960".
Рабочий процесс "23960", обслуживающий пул приложений "WsusPool", не смог остановить канал прослушивателя для протокола "http" в отведенный интервал времени. Поле данных содержит номер ошибки.
---------------------------------------------------------------------------------------------------------------------------------------------------
Проверьте, запущены ли на сервере служба Update Services, IIS и SQL. Если проблему не удается устранить, попробуйте перезапустить IIS, SQL и службу Update Services.
Непредусмотренная ошибка консоли администрирования WSUS. Данная ошибка может быть временной, попробуйте перезапустить консоль администрирования. Если ошибку не удается устранить,
попробуйте удалить сохраненные параметры, удалив файл с именем "wsus" по адресу %appdata%\Microsoft\MMC\.
System.IO.IOException — Сбой установки соединения из-за неожиданного формата пакета.
Stack Trace:
в Microsoft.UpdateServices.Administration.AdminProxy.CreateUpdateServer(Object[] args)
в Microsoft.UpdateServices.UI.SnapIn.Scope.ServerSummaryScopeNode.GetUpdateServer(PersistedServerSettings settings)
в Microsoft.UpdateServices.UI.SnapIn.Scope.ServerSummaryScopeNode.ConnectToServer()
в Microsoft.UpdateServices.UI.SnapIn.Scope.ServerSummaryScopeNode.get_ServerTools()
Настройка Internet Information Server
Чтобы прибавить процессу память, запустите оснастку IIS и откройте Advanced settings:
Установите в качестве лимита 0.
Очистка базы
В консоли WSUS можно запустить «Server Cleanup Wizard». Главный секрет в том, что запускать его надо регулярно, не реже одного раза в месяц.
Одобрили свежую пачку обновлений — очистите сервер. Если этого не делать, мастер прекращает нормально работать. После запуска он висит несколько часов, после чего консоль падает с ошибкой.
Для начала можно попробовать запускать каждый пункт по отдельности, сверху вниз:
Если это не помогает, надо выполнить очистку напрямую в базе. Для этого необходимо подключиться к экземпляру SQL Server инструментом Management Studio. Management Studio стала отдельным продуктом. Его можно скачать по этой ссылке.
Если вы используете Windows Internal Database, необходимо поставить Management Studio на сервер с WSUS. Для подключения к экземпляру используется строка:
Для очистки базы выполните 4 волшебные команды:
Для команды spCompressUpdate используется «обёртка»:
Такая же обертка для spDeleteUpdate:
Во время работы «обёрток» клиенты прекращают получать обновления. Вы можете в любой момент прервать выполнение скрипта без потери прогресса. Для того, чтобы продолжить процесс, не забудьте удалить временную таблицу:
В мастере очистки 5 команд, мы вполнили 4 из них. Команду «Delete computers not contacting server» следует выполнить из мастера.
Переиндексация базы
Для переиндексации базы используйте следующий скрипт:
Настройка TempDB
As a general rule, if the number of logical processors is less than or equal to 8, use the same number of data files as logical processors. If the number of logical processors is greater than 8, use 8 data files and then if contention continues, increase the number of data files by multiples of 4 (up to the number of logical processors) until the contention is reduced to acceptable levels or make changes to the workload/code.
Эту рекомендацию не следует игнорировать. Я останавливаюсь на четырех файлах. Начальный размер файлов должен быть одинаковым. После этого ожидания, как правило, исчезают.
Введение
Приходилось ли вам когда-нибудь самим настраивать производственные веб-сервера (production servers) под управлением ОС Windows Server 2008 R2/IIS 7.5 и выше? Для системных администраторов, имеющих большой опыт работы с IIS, скорее всего, это тривиальная задача, но вот для веб-разработчиков, которым по различным причинам порой приходится самим участвовать в настройке «боевых» серверов, данная информация может оказаться весьма полезной.
Предыстория
1. Параметры конфигурации IIS
Схема конфигурационных файлов для IIS 7.x и выше выглядит так:
Рис. 1. Схема конфигурационных файлов
- для 32-битной — %WINDIR%\System32\inetsrv\config\
- для 64-битной — %WINDIR%\SysWOW64\inetsrv\config\
При конфигурации IIS можно выделить два основных параметра, влияющих на доступность приложения и его производительность.
1. Параметр appConcurrentRequestLimit — максимальное количество одновременных запросов в приложении. Увеличение числа одновременных запросов IIS расширит доступные ресурсы веб-сервера для обслуживания запросов. Значение по умолчанию — 5000.
Наиболее быстро изменить параметр appConcurrentRequestLimit можно утилитой appcmd.exe через командную строку. Сделать это можно как глобально для всех сайтов IIS через файл ApplicationHost.config, так и для отдельного сайта (приложения).
Выполняем команду, затем открываем в IIS раздел «Configuration Editor» для корневого каталога и проверяем новое значение установленного параметра appConcurrentRequestLimit. Причём здесь же можно вручную изменить это значение.
Рис. 2. Установка параметра appConcurrentRequestLimit
Для установки данного параметра наиболее часто используется формула:
usersCount * 1.5>, где usersCount — количество одновременно работающих пользователей.
Выполняем команду, затем открываем в IIS раздел «Application Pools», выбираем в списке пул «DefaultAppPool », заходим в меню «Advanced Settings» и проверяем.
Рис. 3. Установка параметра queueLength
В диспетчере IIS выберите узел сервера в дереве, затем нажмите на иконку «Worker Processes»:
Рис. 4. Меню Worker Processes в диспетчере IIS
В появившемся списке вы можете видеть загрузку всех запущенных в текущий момент пулов.
Рис. 5. Просмотр работающих пулов через Worker Processes
При нажатии “View Current Request” появляется таблица со списком адресов обрабатываемых страниц и другими полезными параметрами. Для обновления списка можно нажимать F5 на экране. Таким образом, вы сможете найти «подвисшие» запросы:
Рис. 6. Список текущих запросов в пуле
Для просмотра показателей производительности, конечно, лучше использовать счётчики Performance Monitor, но они не покажут вам, как Requests Monitor, URL-адреса текущих запросов.
Работа пулов приложений в интегрированном режиме имеет несколько преимуществ по сравнению с работой в классическом режиме. Рекомедуется запускать пулы приложений в integrated mode.
Для оптимальной работы веб-приложений по умолчанию включен режим автоконфигурации настроек пула. В этом случае, cвойство autoConfig равно "true" для секции processModel> в файле machine.config, а другие ключевые параметры не заданы вообще.
- maxConnection
- maxWorkerThreads / minWorkerThreads
- maxIoThreads / minIoThreads
- minFreeThreads
- minLocalRequestFreeThreads
Таким образом, на сервере с 4-х ядерным процессором максимальное кол-во одновременных подключений к конечному IP-адресу равно 48=12*4 (по умолчанию).
Важно: Схема для адреса параметра maxconnection должна быть такой:
Увеличение maxconnection позволяет делать больше одновременных вызовов к удаленным сервисам. Этот атрибут не влияет на локальные вызовы веб-служб! Необходимо понимать, что недостаточно только обойти ограничение на количество одновременных подключений к сервису. Так как увеличение числа одновременных вызовов приводит к увеличению использования потоков CLR, которые используются для создания удаленных и обработки обратных вызовов.
Аттрибуты, заданные в секции processModel>:
1. Параметр maxWorkerThreads — указывает максимальное количество рабочих потоков для каждого процессора в пуле потоков среды CLR. Значение по умолчанию — 20. Максимальное значение — 100.
2. Параметр maxIoThreads — указывает максимальное количество потоков ввода/вывода для каждого процессора в пуле потоков среды CLR. Значение по умолчанию — 20. Максимальное значение — 100.
3. Параметр minWorkerThreads — указывает минимальное количество рабочих потоков для каждого процессора, которые могут быть предоставлены немедленно для обслуживания удаленного запроса. Значение по умолчанию — 1.
4. Параметр minIoThreads — указывает минимальное количество потоков ввода/вывода для каждого процессора, которые могут быть предоставлены немедленно для обработки обратного вызова. Значение по умолчанию — 1.
Обратите внимание, параметры maxWorkerThreads, minWorkerThreads, maxIoThreads, minIoThreads неявно умножаются на число процессоров, а параметры minFreeThreads и minLocalRequestFreeThreads — нет.
Обратите внимание: на весь пул приложения, то есть на каждый рабочий процесс w3wp.exe, обслуживающий пул, имеется один пул потоков CLR ThreadPool. Для всех доменов приложений (сайтов), настроенных на один пул, используется общий набор потоков. Следовательно, для требовательных к ресурсам приложений лучше использовать отдельные пулы.
3. Рекомендации по оптимизации базовой конфигурации
Прежде всего, необходимо точно определить количество процессоров на веб-сервере. Как вариант, можно посмотреть TaskManager -> вкладка «Performance». Если процессор поддерживает режим HyperThreadingTechnology (HTT), значит половина ядер логические (Logical processors), а не физические (Cores). Например, при включенном режиме HTT процессор с 4-мя физическими ядрами будет работать как 8 логических ядер:
Рис. 8. Окно загрузки процессоров в TaskManager
Также можно попробовать воспользоваться следующими командами в командной строке:
Если веб-страница на backend-части делает несколько сетевых вызовов для каждого запроса, то MSDN рекомендует использовать следующие настройки конфигурации:
- maxWorkerThreads = 100 | minWorkerThreads = maxWorkerThreads / 2 = 50
- maxIoThreads = 100
- maxConnection = 12 * N
- minFreeThreads = 88 * N
- minLocalRequestFreeThreads = 76 * N, где N — количество процессоров.
Изменения в секцию processModel> разрешено вносить только в файле machine.config из-за установленного там же атрибута allowDefinition при добавлении секции processModel.
Чтобы иметь возможность устанавливать значения секции processModel для каждого приложения в отдельности через web.config, необходимо установить свойство allowDefinition .
Важно: после внесения изменений требуется обновить Application pools.
Помните, что увеличивать данные параметры нужно только в случае необходимости при наличии достаточного количества ресурсов ЦП.
Возможно, что после проверки счётчиков вам придётся внести корректировки в конфигурацию вашей системы.
Дополнительно
Если вы используете IIS8 — не будет лишним обратить внимание на «Полноценное регулирование нагрузки CPU (CPU Throttling)».
Заключение
Для сайтов, которые не совершают частые сетевые запросы на стороне сервера, стандартных настроек пула должно хватать (processModel/autoConfig=“true”). При этом IIS выставит ограничение в 20 рабочих потоков и 12 удаленных соединений на ядро. При превышении этих значений запросы начнут становиться в очередь и производительность веб-приложения упадёт.
Приглашаю всех поделиться вашим опытом настройки и оптимизации работы производственных веб-серверов на платформе Windows Server.
06.12.2017
itpro
System Center Configuration Manager, Windows Server 2008
комментариев 6
У одного из заказчиков столкнулся с интересной проблемой установки обновлений на клиентах с Windows 7. Обновления распространяются посредством сервера WSUS, интегрированного в среду System Center Configuration Manager. На SCCM сервере используется Windows Server 2008 R2, версия WSUS соответственно — WSUS 3.0 SP2. Должны обновляется клиентские ПК с Windows 7 SP (порядка 2000 компьютеров).
Клиентские компьютеры не могут получить обновления с Software Update Point, в журналах при этом фиксируется ошибка 0x80244022.
На клиентской стороне журнал WUAhandler.log содержит ошибки:
OnSearchComplete - Failed to end search job. Error = 0x80244022.
В журнале службы Windows Update WindowsUpdate.log тоже множество ошибок вида:
На стороне сервера при этом в логе WSUSCtrl.log есть ошибка:
Failures reported during periodic health check by the WSUS Server SPB-MAN1. Will retry check in 1 minutes
Примечание. Более быстро детальное описание ошибки можно получить по ее коду из статьи со списком всех ошибок Windows Update.
Открыв консоль управления IIS Manager, я увидел что пул, отвечающий за работу WSUS (WsusPool) находится в отключенном состоянии.
A worker process serving application pool ‘WsusPool’ has requested a recycle because it reached its private bytes memory limit
По умолчанию в системе лимит используемой памяти для пула WsusPool
ограничен 1,8 Гб. При превышении этого значения (а это может запросто случится при большом количестве клиентов WSUS, особенно при первом сканировании), пул сбрасывается. Чтобы понять сколько памяти использует ваш пул WSUS, достаточно посмотреть за процессом w3wp.exe. При превышении лимита 1,8 Гб, процесс перезапускается. Таким образом для решения проблемы нужно увеличить объем выделяемой памяти.
Примечание. Проблема отчасти напоминает рассмотренный ранее кейс с ошибкой 0x8024401 при получения обновлений c в Windows 10.
Сделать это можно из консоли IIS Manager, выбрав Application Pools -> ПКМ WsusPoll -> Recycling, увеличив значение в поле Private memory usage (in KB).
Насколько увеличить, решайте сами, рекомендую начать с 3-4 Гб. В моем случае для 2000+ клиентов WSUS, оказалось достаточно 6 Гб памяти.
Размер выделяемой памяти также можно изменить и из раздела расширенных настроек пула (Advanced Settings), увеличив значение в поле Private memory usage (KB).
Осталось перезапустить пул через кнопки Start/Stop или Recycle.
После чего процесс w3wp.exe перестал потреблять более 3 Гб RAM. А на следующий день на компьютерах стали закачиваться обновления.
Совет. При большом количестве клиентов WSUS, получающих обновления с SCCM Software Update Point (особенно получающих обновления впервые), в расширенных настройках пула можно увеличить следующие параметры:
Кроме того, рекомендуется установить на WSUS 3.0 SP2 под Windows Server 2008 R2 следующие обновления:
На WSUS 4.0 на Windows Server 2012 R2 такие:
- KB2919442
- KB2919355
- KB3095113
- KB3159706
Предыдущая статья Следующая статья
Скрипты для полного удаления любых версий MS Office
Как преобразовать WQL запрос SCCM в SQL отчет
Огромное спасибо! Как с коллегами только не пробовали его разворачивать — WSUS ломался после первого сканирования.
Спасибо большое. Помогло увеличение лимита на память.
Windows Server 2019
07.11.2016
itpro
Windows Server 2012
Комментариев пока нет
Важной функцией любого веб-сервера является возможность ограничения использования процессорных ресурсов CPU определенным сайтом, в противном случае один сайт может монополизировать ресурсы CPU, что может быть неприемлемо, особенно для серверов веб-хостинга, разделяемых ресурсы между несколькими клиентами с разными сайтами. В IIS (Internet Information Services) 7.0 и более ранних версиях, присутствовала возможность мониторинга использования CPU веб приложениями и отключения на несколько минут пула приложений, превысившего заданный лимит. Полноценная возможность управления потреблением ресурсов CPU, доступных каждому пулу приложений, появилась только в IIS 8.0 (Windows Server 2012 и выше). Эта возможность называется CPU Throttling и позволяет вместо временной остановки чрезмерного агрессивного к процессору пула приложений, задать максимальное количество ресурсов CPU, доступных каждому пулу IIS.
В этой статье мы покажем, как ограничить использование CPU пулами приложений в IIS 8 (и выше) на примере веб-сервера на базе Windows Server 2012.
Откройте консоль Internet Information Services (IIS) Manager (%systemroot%\system32\inetsrv\iis.msc), разверните в дереве ваш сервер и выберите раздел Application Pools. Настройки CPU Throttling в IIS находятся в разделе параметров каждого пула.
Совет. Чтобы для каждого сайта, запущенного на IIS, можно было задать собственные лимиты CPU, нужно для каждого сайта создать собственные App Pool.
- Если нужно включить ограничения для конкретного пула, выберите его в списке и перейдите в раздел настроек Advanced Settings.
- Если нужно задать настройки лимитов по-умолчанию для всех пулов, нужно выбрать секцию Set Application Pool Defaults.
В окне настроек Advanced Settings нас интересуют параметры, задаваемые в секции CPU:
- Limit – максимальный % процессорного времени, который может использовать пул приложений. При превышении этого значения, выполняется действие, указанное в поле Limit. В IIS 8 процент задается в тысячных долях (1/ 1000 процента ). К примеру, чтобы ограничить потребление CPU в 20%, в поле Limit нужно указать 20000. В IIS 8.5 значение указывается в обычных процентах. Отключить лимит использования можно, задав 0
- Limit Action – действие, которое выполняется с пулом при превышении лимита использования CPU
- Limit Interval (minutes) – периодичность проверки и сброса результатов загрузки при приостановке рабочего процесса. Этот параметр не используется для CPU Throttling, и используется для совместимости с предыдущими версиями IIS.
Совет. Эти настройки применяются только к пользователю, из-под которого запущен пул. По умолчанию каждый пул запускается из-под своей учетной записи, таким образом, нагрузка каждого пула регулируется индивидуально. Если же вы используете выделенную учетку для запуска нескольких пулов, то настройки для них будут идентичными.
В поле Limit Action можно выбрать одно из следующих действий, которое будет выполнено при превышении заданного лимита.
- NoAction – никаких действий не выполняется, а в журнал записывается событие о превышении CPU
- KillW3wp (Kill worker processes) — рабочий процесс пула, превысившего лимит приостанавливается на время, указанное в поле Limit Interval. В журнал добавляется соответствующая запись.
- Throttle – жесткое ограничение доступных ресурсов CPUзначением, заданным в поле Limit. Значение поля Limit в этом случае игнорируется, а в журнал пишется событие.
- ThrottleUnderLimit – ограничения работают только при высокой загрузке сервера. При наличии свободных ресурсов CPU, пул может превысить заданный лимит.
Настроить CPU Throttling можно и из командной строки с помощью утилиты appcmd. Например, чтобы для пула DefaultAppPool установить ограничение в 30% использования CPU, нужно выполнить команду:
%systemroot%\system32\inetsrv\appcmd set apppool DefaultAppPool /cpu.limit:30000 /cpu.action:Throttle
Включить ограничение для всех пулов IIS можно так:
%systemroot%\system32\inetsrv\appcmd set config -section:system.applicationHost/applicationPools /applicationPoolDefaults.cpu.limit:10000 /cpu.action:Throttle /commit:apphost
Также нужно отметить, что регулирование нагрузки применяется не только к основному процессу, но и ко всем дочерним, если таковые имеются.
Таким образом, в IIS 8 появилась возможность гибкого регулирования загрузки сервера запущенными веб-приложениями. Но нужно понимать, что CPU Throttling используется только для ограничения максимальной загрузки CPU, но не для резервирования процессорных мощностей для веб-приложения.
Читайте также: