Сервер терминалов 2008 R2: «Недостаточно системных ресурсов для завершения запрошенного сервиса»

Я работаю с нездоровым терминальным сервером Windows 2008 R2, настроенным в среде vSphere. В настоящее время он имеет 4 виртуальных ЦП и 32 ГБ оперативной памяти. Нет чрезмерных обязательств.

Число одновременных пользователей на этом сервере резко возросло за последние месяцы (~ 70) и, возможно, превышает рекомендованный уровень. Из-за приложений, используемых пользователями в этой системе, разделение этого на несколько серверов будет проблемой вне рамок этого вопроса.

Однако в определенные моменты в течение недели (а теперь и почти ежедневно) вход в систему новых пользователей приводит к следующим ошибкам: Событие с кодом 1500

Windows не может войти в систему, потому что ваш профиль не может быть загружен. Убедитесь, что вы подключены к сети и что ваша сеть работает правильно.

ДЕТАЛИ. Недостаточно системных ресурсов для завершения запрошенной услуги.

Это остается до тех пор, пока некоторые пользователи не выйдут из системы, сеансы не будут отключены вручную или система не будет полностью перезагружена.

Я хотел бы знать:

• На какой ресурс ссылается это сообщение об ошибке? Что на самом деле ограничено?
• Существует ли настройка или настройка на уровне ОС, которая может помочь с этим?
• Пользователи довольны производительностью, за исключением увеличения частоты появления этого сообщения об ошибке. Здесь есть что-то еще?
• Существует ли абсолютное ограничение на количество пользователей, которое может обслуживать терминальный сервер? Я вижу 150+ пользователей, описанных в некоторых руководствах по настройке терминальных серверов.

Это было решено.

Я начал изучать реестр, потому что увеличение ресурсов ЦП и ОЗУ на виртуальной машине не решило проблему.

Я указал на инструмент dureg от Microsoft, чтобы оценить размер реестра. Просматривая через regedit, я столкнулся с проблемами при открытии клавиш HKEY_USERS\.Default\PRINTERS. Используя dureg, я начал исследовать эту иерархию.

Принтеры были проблемой. Причина и исправление подробно описаны в:
Размер куста реестра HKEY_USERS.DEFAULT постоянно увеличивается на сервере под управлением Windows Server 2008 R2 с пакетом обновления 1 (SP1)

Исправление: http://support.microsoft.com/kb/2871131

Это, очевидно, останавливает рост, но ключи и реестр должны быть сжаты, чтобы освободить место.

Сжатие раздутого реестра: http://support.microsoft.com/kb/2498915

1)  Boot from a WinPE disk.
2)  Open regedit while booted in WinPe, load the bloated hive under HLKM. (e.g. HKLM\Bloated)
3)  Once the bloated hive has been loaded, export the loaded hive as a "Registry Hive" file with a unique name.
4) Unload the bloated hive from regedit.
5) Rename the hives so that you will boot with the compressed hive.
e.g.
c:\windows\system32\config\ren software software.old
c:\windows\system32\config\ren compressedhive software

Хм, несколько шагов ... довольно сложно сделать удаленно в рабочие часы. Я попытался связаться с моим постоянным экспертом Microsoft, чтобы завершить, но он был занят поиском какой-нибудь проблемы SCCM или SCVMM где-то . Читая некоторые форумы, связанные с Citrix, я обратил внимание на инструмент, который может выполнить вышеизложенное с меньшим количеством шагов ...

Поэтому я сделал снимок виртуальной машины, затем скачал и запустил бесплатное программное обеспечение для сжатия реестра (Tweaking.com) ; несмотря на подавляющий звук коллективных стонов системных инженеров Microsoft повсюду ...

обратите внимание на 1,4 ГБ, сохраненные в конфигурации по умолчанию ...

ПОЖАЛУЙСТА ПЕРЕЗАГРУЗИТЕ!

После перезагрузки все было хорошо. Количество пользователей достигло 86 без каких-либо побочных эффектов и ошибок, связанных с профилем. Я наблюдал за кустом реестра принтера, и он держался стабильно.

В Windows Server 2003 эта ошибка была результатом исчерпания памяти ядра. Поскольку вы имеете дело с Windows Server 2008 R2, я не уверен, насколько тесно связана причина проблемы с причиной в W2K3, но я бы поспорил, что это проблема памяти из-за количества пользователей и процессов. Я хотел бы взглянуть на исчерпание памяти Nonpaged Pool в качестве вероятной причины. Кроме того, количество процессов составляет почти 800, что довольно много. MS, вероятно, скажет вам уменьшить количество процессов, что может быть сделано только путем уменьшения пользовательской нагрузки.

В этой статье содержится полезная информация об использовании памяти в Windows и о том, как вы можете просмотреть лимит невыгружаемого пула, чтобы выяснить, является ли это причиной проблемы:

https://blogs.technet.com/b/markrussinovich/archive/2009/03/26/3211216.aspx

Запустите монитор производительности Windows, чтобы отслеживать различные счетчики:

• Переключатели контекста
• Записи таблицы страниц
• Элементы GDI
• рукоятки
• … (Все, что вы можете найти)

И посмотрите, если один из этих пиков, когда вы получаете неудачный вход в систему.

Кроме того: что-то вызывает высокую загрузку ЦП ядра в вашей системе - вы должны исследовать это, чтобы увидеть, приводит ли это к связанной проблеме.

Здесь может помочь служба очистки кустов профилей пользователей , поскольку она «помогает гарантировать, что пользовательские сеансы полностью завершаются при выходе пользователя из системы».

Итак, из того, что я читал о планировании емкости RDS в Server 2008 R2, вы можете просто использовать свой плохой терминальный сервер на ресурсах, недостаточных для количества пользователей, которые его используют. В частности, я заметил, что у вас 80 пользователей на 4 vCPUS, и MS рекомендует 1 ядро ​​на 15 пользователей.

Из блога technet, озаглавленного « Определение размеров RDS и руководство по планированию мощностей» :

We always felt the need of Hardware capacity guidance and sizing information for Terminal Services or Remote Desktop services for Server 2008 R2, Whenever I am engaged in any architectural guidance discussion for RDS deployment i always get a question what needs to be taken into consideration while deciding the hardware configuration and to do capacity planning.

Here are some bullet points which I recommend to my partners and customers to consider:

• 2 ГБ памяти (RAM) - это оптимальный предел для каждого ядра ЦП. Например, если у вас 4 ГБ ОЗУ, для оптимальной производительности необходимо использовать двухъядерный процессор.
• Двухъядерный процессор работает лучше, чем одноядерный процессор.
• Рекомендуемая пропускная способность для локальной сети 30 пользователей и глобальной сети 20 пользователей. Пропускная способность (b) = 100 мегабит в секунду (Мбит / с) с задержкой (l) менее 5 миллисекунд.
• На терминальном сервере 64 МБ на пользователя - это требование идеальной памяти (ОЗУ) для GP. Используйте только + 2 ГБ для ОС, например (100 пользователей * 64) + 2000 = 8,4 ГБ, т.е. 8 ГБ ОЗУ.
• Большее количество используемых приложений (например, Office, CAD Apps и т. Д.) Потребует увеличения объема памяти на пользователя для расчета более 64 МБ базовой памяти на пользователя.
• 15 сеансов TS на ядро ​​ЦП является оптимальным пределом производительности сервера терминалов.
• Сеть не должна иметь более 5 скачков, а задержка должна быть менее 100 мс.
• 64 кбит / с - идеальная пропускная способность на сеанс пользователя. (256 цветов, коммутируемая сеть, только кэширование растровых изображений)
• Производительность ЦП ухудшается, если% времени процессора на ядро ​​постоянно превышает 65%.
• Производительность серверов терминалов удваивается, когда он работает на X64 HW и ОС.

In addition to that, Microsoft has just released a whitepaper on Capacity Planning in Windows Server 2008 R2.

Загрузите это здесь

У меня очень мало времени, поэтому я просто сделаю схематичный ответ и, надеюсь, уточню его позже.

Когда я делал заклинания в командах Citrix, я вспоминал, как мы пытались использовать 15-20 пользователей на сервер, но на них работали тяжелые приложения. В наши дни в x64 мы загружаем больше пользователей, но 70+ звучат как много.

Максимальное использование счетчика перфмонов было нередко переключением контекста, оно бы перекрывало сервер, в то время как другие счетчики, такие как RAM, CPU и т. Д., Выглядели хорошо. Возможно, это может быть причиной (сервер не может выделить ресурсы до истечения времени ожидания из-за чрезмерного переключения контекста). Вот два способа контролировать переключение контекста :

The System\Context Switches/sec counter in 
System Monitor reports systemwide context 
switches.

The Thread(_Total)\Context Switches/sec  
counter reports the total number of context 
switches generated per second by all threads.

Также вы можете найти что-то полезное в руководстве по планированию мощностей, вы найдете ссылку на него в этой записи блога .

Когда я смогу потратить время на этот ответ, я сделаю это, я просто добавлю сюда, предостерегая от всех временных измерений в виртуальной машине vSphere.

Из-за того, как vCPU был абстрагирован от физических процессоров, vCPU не имеет ни малейшего представления, какое это время (одна виртуальная секунда может быть больше или меньше одной реальной (или, по крайней мере, физической) секунды. Как следствие, все время основано Счетчики perfmon (процессорное время, переключение контекста / сек и т. д.) неточны (иногда даже очень сильно), даже если они могут служить очень грубыми индикаторами.

Чтобы убедиться в этом, сравните любой встроенный счетчик ЦП в виртуальной машине с его аналогом на хосте vSphere для этой виртуальной машины. По этой причине VMware публикует некоторые счетчики для процессора (и памяти, которая также неточна с точки зрения гостя) с помощью инструментов VMware в два объекта perfmon VMguest.

Таким образом, правильные значения, основанные на времени, становятся доступными из гостевой системы, но только если посмотреть на счетчики опубликованных объектов VMware.

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

Как только у меня будет время, я отредактирую ссылки на технические документы и т. Д., В которых подробно остановлюсь на этом, и на точных встречных путях \ именах. Естественно, все это тоже можно гуглить.

Я бы предложил реализовать WSRM (диспетчер системных ресурсов Windows). Когда на одном хосте работает множество приложений, подключений и сервисов, система не знает, что всем нужно хорошо играть вместе. Windows Server естественным образом пытается использовать все свои ресурсы, чтобы завершить все время, пока не узнает ... войти в WSRM.

Внедряя WSRM, вы можете устанавливать ограничения ресурсов для всех видов вариаций, чтобы обеспечить равномерное игровое поле для всех работающих или подключенных пользователей. Судя по вашим заметкам, это не похоже на проблему ESX / vSphere, а на слишком большое количество подключенных пользователей, которые постоянно борются за все. Вам нужно будет протестировать WSRM, чтобы найти удачный способ балансировки ресурсов среди всего, но также не повлиять на уровни производительности, к которым все привыкли.

Обзор WSRM: http://technet.microsoft.com/en-us/library/cc732553.aspx