Термінальний сервер R2 2008 року: "Недостатньо системних ресурсів для завершення запитуваної послуги"

Я працюю з нездоровим сервером терміналів 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 SP1 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, щоб контролювати різні лічильники:

• Контекстні комутатори
• Записи таблиці таблиць
• Елементи 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 Гб оперативної пам’яті (ОЗП) - оптимальний ліміт для кожного ядра ЦП. Наприклад, якщо у вас є 4 ГБ оперативної пам’яті, для оптимальної продуктивності повинен бути двоядерний процесор.
• 2-ядерний процесор працює краще, ніж одноядерний процесор.
• Рекомендована пропускна здатність для локальної мережі 30 користувачів та WAN 20 користувачів. Пропускна здатність (b) = 100 мегабіт в секунду (Mbps) із затримкою (l) Менше 5 мілісекунд.
• На сервері терміналів 64 Мб на користувача є вимога ідеальної пам’яті (оперативної пам’яті) для GP лише використання + 2 Гб для ОС Eg (100 користувачів * 64) + 2000 = 8,4 ГБ, тобто 8 ГБ оперативної пам’яті.
• Більше застосованих додатків (наприклад, Office, програм CAD тощо) потребуватиме більше пам’яті на кожного користувача, щоб до цього розрахунку було додано більше 64 Мб базової пам'яті на користувача.
• 15 сеансів TS на ядро ​​CPU - це оптимальний ліміт продуктивності сервера терміналів.
• У мережі не повинно бути більше 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+ звучить як багато.

Підвищення лічильника парфмонів не було рідко контекстною комутацією, воно дозволило б запустити сервер, тоді як інші лічильники, такі як оперативна пам'ять, процесор тощо, виглядали добре. Можливо, це може бути причиною (сервер не може виділити ресурси перед тимчасовим вимиканням через надмірну комутацію контексту). Ось два способи моніторингу переключення контексту :

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 не має поняття, який саме час (одна віртуальна секунда може бути більшою чи меншою, ніж одна реальна (або принаймні фізична) секунда. Як наслідок, весь час базується лічильники парфмонів (час процесора, контекстні комутатори / сек тощо) є неточними (іноді навіть дико), навіть якщо вони можуть слугувати дуже грубими показниками.

Щоб переконатись у цьому, порівняйте будь-який власний лічильник процесора, що базується на час, у ВМ із його аналогом на хості vSphere для цієї VM. З цієї причини VMware публікує декілька лічильників для процесора (і пам'яті, яка також є неточною з точки зору гостя) за допомогою інструментів VMware в два об'єкти VMguest perfmon.

Таким чином, правильні значення на основі часу стають доступними в межах гостьової перфмони, але лише якщо ви дивитесь на опубліковані VMware лічильники об'єктів.

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

Щойно я знайду час, я відредагую посилання на білі газети тощо, які детально розглядають це, та точні лічильники шляхів \ назви. Природно, це теж є гугл.

Я б запропонував впровадити WSRM (Windows System Resource Manager). Коли на одному хості працює безліч додатків, з'єднань, служб, система не знає, що всім потрібно добре грати разом. Windows Server, природно, намагається використати всі свої ресурси для завершення всього, якщо про це не відомо ... введіть WSRM.

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

Огляд WSRM: http://technet.microsoft.com/en-us/library/cc732553.aspx