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

Проблемы с производительностью удаленного рабочего стола в Windows 2008

Мы запускаем приложение как удаленное приложение с использованием удаленного рабочего стола на сервере Windows Server 2008, и мы получаем ситуации, когда (после того, как у нас вошло около 40 человек) сервер может зависнуть на несколько секунд (например, 20 секунд). ).

Не похоже, что проблема вызвана нехваткой процессора или памяти. Приложение довольно тяжелое на диске, но мы изменили диски с Raided SATA на более быстрый SSD-диск, и никаких улучшений не произошло.

Приложение представляет собой 32-разрядное приложение, работающее в 64-разрядной среде и 8 ГБ ОЗУ.

Приложение отлично работало по протоколу RDP в Windows Server 2000 (до 100 пользователей) (хотя оно начало замедляться из-за нехватки памяти на сервере)

Если посмотреть на различные мониторы, то во время зависаний наблюдается пик использования процессора и сети, хотя это, похоже, больше связано с тем, что сервер переводит дыхание после размораживания.

Мы думаем, что это может быть как-то связано с выгрузкой / загрузкой Hives при входе пользователей в систему, но это предположение.

У меня такие вопросы ... - Как мне узнать, что могло вызвать эту ошибку? - Кто-нибудь еще сталкивался с подобной проблемой - И как вы ее исправили?

Спасибо.

По моему опыту, зависание может быть вызвано одним из следующих факторов:

  • Большая длина дисковой очереди (т.е. больше операций ввода-вывода, чем может обработать жесткий диск)
  • Неисправные драйвера и прошивки
  • Очень большой объем сетевого трафика
  • Высокая загрузка памяти или процессора

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

Я видел это и задал связанный вопрос (Как-вы-диагностируете-сервер-временное зависание).

Взгляните на следующую статью. http://support.microsoft.com/kb/934330, это может помочь, но я до сих пор точно не знаю, что происходит.

Раньше я запускал большие терминальные серверы на границе своей среды, чтобы контролировать доступ людей, использующих нашу систему. У нас была эта проблема с тех пор, как я использовал Терминальный сервер Windows 2000. Я обнаружил, что проблема заключается в том, что когда люди заходят в систему и выходят из нее, сервер "замораживается" для всех участников. "Заморозка" будет ухудшаться по мере того, как сервером будет пользоваться все больше людей.

Я всегда обвинял Novell client 32 в накладных расходах и в конечном итоге использовал старый комплект нулевого администрирования, чтобы исключить функциональные возможности из сеансов входа пользователей в систему, пока они не будут работать как можно более экономно.

Позже у меня был терминальный сервер, использующий 2003, а не Novell, и были те же проблемы. Я обнаружил, что проблема заключается в перемещаемых профилях. "Заморозка" произойдет, когда он попытается загрузить профиль нового пользователя по сети ... Теперь это происходит, когда мы синхронизируем автономные файлы с домашних дисков.

Как это исправить?

  • Ограничьте "красивые" возможности окон.
  • Используйте больше кеша на этих типах серверов.
  • Держите сервер дефрагментированным, хотя на SSD это не всегда рекомендуется
  • Держите сервер исправленным
  • Ограничить антивирусную активность
  • Не позволяйте пользователям хранить файлы локально на сервере

Проверьте, есть ли у вас что-то работающее, которое одновременно выполняет большое количество обращений к диску. Только на прошлой неделе возникла проблема с MySQL 5.0, которая полностью уничтожила терминальный сервер 2008 года без видимой причины, поставил там MSSQL, и он сработал.

(Я не тролль M $, и лично я этого не делал, это делал мой суп. Я просто слышал, как он бился головой о стену в течение нескольких дней, а позже он сказал мне, что вот как он «починил» это )

Ваши клиенты работают на Vista? У меня была аналогичная проблема с очень производительными компьютерами Windows Server 2003 и 2008, которые практически не нагружали их (в то время я был единственным, кто их использовал).

Оказывается, в стеке TCP / IP Vista есть некоторые оптимизации окна приема, которые на самом деле приводят к снижению производительности некоторых маршрутизаторов для таких приложений, как RDP.

Вот несколько статей, объясняющих эту проблему:

Подводя итог, попробуйте следующее:

netsh interface tcp set global autotuninglevel=disabled

Если это не ваша проблема, вы можете отменить это, используя следующее:

netsh interface tcp set global autotuninglevel=normal