Терминальный сервер R2 2008 года: “Недостаточные системные ресурсы существуют для завершения требуемого сервиса”
необходимо смочь больше всего наполнить в теории согласно этой статье MS: http://msdn.microsoft.com/en-us/library/ms189595.aspx; но я вообразил бы, не отвечает ли сервер, что поэтому когда-либо Вы все еще могли бы столкнуться с проблемами. Необходимо смочь, по крайней мере, выполнить команды диагностики (DMV's) и диагностировать то, что привязывает сервер.
Это было решено.
Я начал исследовать реестр, поскольку увеличение ресурсов ЦП и ОЗУ на виртуальной машине не решило проблему.
Мне было указано на инструмент Microsoft dureg для оценки размера реестра. При просмотре через 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 без каких-либо побочных эффектов и ошибок, связанных с профилем. Я наблюдал за кустом реестра принтеров, и он остается стабильным.
обратите внимание на 1,4 ГБ, сохраненные в конфигурации по умолчанию ...
ПОЖАЛУЙСТА, ПЕРЕЗАГРУЗИТЕ!
После перезагрузки все было хорошо. Количество пользователей достигло 86 без каких-либо побочных эффектов и ошибок, связанных с профилем. Я наблюдал за кустом реестра принтеров, и он остается стабильным.
обратите внимание на 1,4 ГБ, сохраненные в конфигурации по умолчанию ...
ПОЖАЛУЙСТА, ПЕРЕЗАГРУЗИТЕ!
После перезагрузки все было хорошо. Количество пользователей достигло 86 без каких-либо побочных эффектов и ошибок, связанных с профилем. Я наблюдал за кустом реестра принтеров, и он остается стабильным.
Start up Windows Performance Monitor to monitor the various counters:
- Context Switches
- Page Table Entries
- GDI elements
- Handles
- … (whatever you can find)
And see if one of these peaks when you get a failed login.
Also: something is causing high kernel CPU% on your system - you should investigate that to see if it leads you to a related problem.
The User Profile Hive Cleanup service may help out here as it "helps to ensure user sessions are completely terminated when a user logs off".
Что ж, судя по тому, что я читал о планировании емкости RDS в Server 2008 R2, вы, возможно, просто используете свой плохой терминальный сервер на недостаточных ресурсах для того числа пользователей, которые его используют. В частности, я заметил, что у вас 80 пользователей на 4 vCPUS, и MS рекомендует 1 ядро на 15 пользователей.
Из блога Technet под названием Руководство по определению размеров и емкости RDS :
Мы всегда считали необходимость руководства по мощности оборудования и информации о размерах для служб терминалов или служб удаленных рабочих столов для Server 2008 R2, всякий раз, когда я участвую в обсуждении каких-либо архитектурных рекомендаций по развертыванию RDS, я всегда получаю вопрос, что необходимо учитывать при принятии решения о конфигурации оборудования и сделать планирование мощности.
Вот несколько пунктов, которые я рекомендую рассмотреть своим партнерам и клиентам:
- 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 HW и ОС.
В дополнение к этому, Microsoft только что выпустила технический документ по планированию емкости в Windows Server 2008 R2.
В Windows Server 2003 эта ошибка была результатом исчерпания памяти ядра. Поскольку вы имеете дело с Windows Server 2008 R2, я не уверен, насколько тесно связана причина проблемы с причиной в W2K3, но я готов поспорить, что это проблема памяти из-за количества пользователей и процессов. Я бы рассмотрел исчерпание памяти невыгружаемого пула как вероятную причину. Кроме того, количество процедур составляет почти 800, что довольно много. MS, вероятно, посоветует вам уменьшить количество процессов, что можно сделать только за счет уменьшения пользовательской нагрузки.
В этой статье есть полезная информация об использовании памяти в Windows и о том, как вы можете просмотреть лимит невыгружаемого пула, чтобы убедиться, что это причина проблемы:
https://blogs.technet.com/b/markrussinovich/archive/2009/03/26/3211216. aspx
Я бы предложил внедрить WSRM (диспетчер системных ресурсов Windows). Когда на одном хосте работает множество приложений, подключений, сервисов, система не знает, что всем нужно хорошо играть вместе. Windows Server, естественно, пытается использовать все свои ресурсы для выполнения всего в любое время, если он не уведомлен ... введите WSRM.
Реализуя WSRM, вы можете установить ограничения ресурсов всевозможными вариантами, чтобы убедиться, что игровое поле для всего, что работает или подключенных пользователей. Судя по вашим заметкам, это не похоже на проблему ESX / vSphere, а скорее на слишком много подключенных пользователей, которые постоянно соревнуются за все. Вам придется протестировать WSRM, чтобы найти золотую середину для балансировки ресурсов между всем, но при этом не влиять на уровни производительности, к которым все привыкли.
Обзор WSRM: http://technet.microsoft.com/en-us/library/cc732553.aspx
У меня очень мало времени, поэтому я просто сделаю отрывочный ответ и, надеюсь, уточню его позже.
Когда я делал заклинания в командах 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.
Также вы можете найти что-нибудь полезное в руководстве по планированию емкости, вы найдете ссылку на него в этой записи блога .
] Когда я смогу потратить время на этот ответ, я
Таким образом, правильные значения, основанные на времени, становятся доступными из гостевого perfmon, но только если посмотреть на счетчики опубликованных объектов VMware.
Я просто подумал, что эта базовая информация немного актуальна, так как ответы пока сосредоточены на измерения на основе времени из виртуальной машины vSphere, что в некоторых случаях является решающим обстоятельством для правильного анализа. Это также, конечно, напрямую относится к теме этого конкретного (незавершенного) ответа и его комментариев. Это может быть кому-то полезно.
Как только у меня появится время, я отредактирую ссылки на официальные документы и т. Д., В которых подробно рассматривается это, а также точные пути \ имена счетчиков. Естественно, все это тоже доступно в Google.
Я просто подумал, что эта базовая информация немного актуальна, поскольку ответы до сих пор сосредоточены на измерениях на основе времени из виртуальной машины vSphere, что в некоторых случаях является решающим обстоятельством для правильного анализа. Это также, конечно, напрямую относится к теме этого конкретного (незаконченного) ответа и его комментариев. Это может быть кому-то полезно.
Как только у меня появится время, я отредактирую ссылки на официальные документы и т. Д., В которых подробно рассматривается это, а также точные пути \ имена счетчиков. Естественно, все это тоже доступно в Google.
Я просто подумал, что эта основная информация немного актуальна, поскольку ответы на данный момент сосредоточены на измерениях на основе времени с виртуальной машины vSphere, что в некоторых случаях является решающим обстоятельством для правильного анализа. Это также, конечно, напрямую относится к теме этого конкретного (незавершенного) ответа и его комментариев. Это может быть кому-то полезно.
Как только у меня появится время, я отредактирую ссылки на официальные документы и т. Д., В которых подробно рассматривается это, а также точные пути \ имена счетчиков. Естественно, все это тоже доступно в Google.
Как только у меня будет время, я отредактирую ссылки на официальные документы и т. Д., В которых подробно рассматривается это, и точные пути \ имена счетчиков. Естественно, все это тоже доступно в Google.
Как только у меня появится время, я отредактирую ссылки на официальные документы и т. Д., В которых подробно рассматривается это, а также точные пути \ имена счетчиков. Естественно, все это тоже доступно в Google.