Назад | Перейти на главную страницу

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

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

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

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

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

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

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

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

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

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

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

Принтеры были проблемой. Причина и способ устранения подробно описаны в:
Размер куста реестра «HKEY_USERS.DEFAULT» постоянно увеличивается на сервере под управлением Windows Server 2008 R2 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, но я готов поспорить, что это проблема памяти из-за количества пользователей и процессов. Я бы рассмотрел исчерпание памяти невыгружаемого пула как вероятную причину. Кроме того, количество процедур составляет почти 800, что довольно много. MS, вероятно, посоветует вам уменьшить количество процессов, что можно сделать только за счет уменьшения пользовательской нагрузки.

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

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

Запустите Windows Performance Monitor для наблюдения за различными счетчиками:

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

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

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

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

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

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

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

Скачать здесь

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

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

Максимальное значение счетчика perfmon нередко было переключением контекста, оно приводило к остановке сервера, в то время как другие счетчики, такие как 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.

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

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

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

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

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

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

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

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