Мы заметили проблему, при которой сеансы удаленного рабочего стола на сервере зависают, когда сервер имеет высокую загрузку процессора.
Окружающая среда:
- VMWare ESX 4.0u1.
- Гостевая ОС - Windows Server 2008 R2 (это зависающий сервер).
- В гостевой ОС есть MS SQL Server 2008 R2 (10.50.4000) и внутренние приложения, работающие как службы Windows.
- Клиент удаленного рабочего стола обычно находится на ноутбуке с Windows 7.
Подключение RDP к серверу работает нормально. Когда сервер загружается, происходит следующее:
- Существующий сеанс RDP перестает отвечать и кажется зависает - по крайней мере, экран не обновляется. Если диспетчер задач запущен, он становится статичным, так как вы больше не видите, что он обновляет статистику каждые несколько секунд. Вы можете нажать на кнопку или что-то еще, и визуальный ответ будет задержан на несколько минут.
- Консольный сеанс через инструмент администрирования vmware будет зависать точно так же. (Так что в основном это влияет на графический интерфейс / интерактивность).
- Попытка подключиться через RDP в этом состоянии займет очень много времени и часто будет просто отображать черный экран, который никогда не переходит в фактический графический интерфейс.
- Остальные сервисы продолжают отвечать! Если к веб-приложению, работающему на сервере, получить доступ из браузера на другой машине, оно будет реагировать довольно быстро и, по-видимому, почти не зависит от высокой нагрузки. Монитор удаленных процессов, который обращается к «зависающему» серверу с помощью WMI, также продолжает работать.
Нагрузка в этом сценарии обычно состоит из того, что процесс A выполняет последовательное (без потоков) сочетание вычислений и вызовов процесса B.При получении такого вызова процесс B обычно выполняет вызов базы данных, за которым следуют некоторые вычисления, а затем возвращает результат процессу. А.
В удаленном диспетчере процессов мы можем подтвердить, что процессы A, B и SQL Server вместе занимают 100% ЦП, но из-за последовательных вызовов между процессами на самом деле никогда не должно быть более одного процесса, готового к запуску в любой момент. во время. Эти процессы являются службами Windows и никак не взаимодействуют с графическим интерфейсом пользователя.
Это похоже на то, что Windows полностью лишает GUI-компонент циклов ЦП, когда другие процессы вызывают нагрузку.
Я провел несколько экспериментов, чтобы проверить - например, если я запустил три копии цикла занятости на своем ноутбуке, каждая из них будет занимать 33% ЦП, итоговое значение будет указано как 100%, но графический интерфейс Windows в целом по-прежнему будет полностью реагировать.
Что заставляет графический интерфейс сервера так зависать под нагрузкой и что можно сделать, чтобы этого не произошло?
VM имеет 6 ГБ ОЗУ, SQL Server ограничен 2 ГБ ОЗУ, другие задействованные службы обычно меньше 200 МБ каждая. Так что это не похоже на истощение памяти.
Службы работают с приоритетом "Нормальный", но я также снизил их до "Ниже нормального" без каких-либо реальных изменений в поведении.
Обновление 1
В попытке сузить проблему я пробовал это:
- На сервере с нормальным приоритетом запустите индивидуальный процесс, который представляет собой просто цикл занятости. Как и предполагалось, это максимизирует ЦП на 100%. В течение этого времени система по-прежнему отлично реагирует на интерактивного пользователя.
- Выполните запрос с интенсивным использованием ЦП и данных к серверу SQL (
select * from dbo.Table where Name like '%flarp%' повторяется 6 раз в одном пакете команд). В таблице 1,6 миллиона записей. Никакой другой процесс не требует значительных ресурсов ЦП. Когда запрос выполняется, графический интерфейс полностью зависает, пока пакет запроса не будет завершен. Я устанавливаю приоритет SQL Server на НИЗКИЙ и повторяю. По-прежнему зависает графический интерфейс. - Попробуйте оба варианта одновременно. Сначала я запустил цикл ЦП (с нормальным приоритетом), и он занимает 100%. Когда вскоре после этого я запускаю SQL-запрос (в SQL Server с НИЗКИМ приоритетом), графический интерфейс полностью зависает. Удаленный диспетчер процессов указывает, что SQL Server, несмотря на низкий приоритет, получает 100% ЦП, в то время как цикл ЦП (с нормальным приоритетом) находится на уровне 0%, пока запрос не будет завершен. Таким образом, несмотря на то, что сервер sql имеет более низкий приоритет, он полностью истощает цикл чистого процессора.