Настройка производительности терминального сервера

 Реальный, пошаговый подход,чтобы максимально продуктивно использовать Citrix MetaFrame, New Moon Canaveral или Mocrosoft Terminal Services.

Terminal Server Performance Tuning, Copyright © 2003 by Brian Madden.

Назначение этой статьи

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

Эта статья написана для терминальных служб Windows 2000 и Windows Server 2003. Описанные в ней методы применяются вне зависимости от того, используете ли вы Citrix MetaFrame, Tarantella / New Moon Canaveral iQ или только Terminal Services.

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

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

Автор:

Брайен Мадден
http://www.brianmadden.com
август, 2003

    От автора
    Я консультант и писатель. Со мной консультировались сотни компаний, обращаясь за помощью в решении проблем с производительностью их терминальных серверов. Эта практика дала мне в этой области много опыта. В этом документе описан подход, который я предпринимаю всякий раз, когда меня просят, чтобы я обратился к проблемам производительности терминального сервера.

    Об Авторе
    Внештатный автор и консультант Брайен Мадден написал множество популярных книг о вычислениях на базе тонкого клиента. Его книга Citrix MetaFrame XP: Advanced Technical Design Guide уже переживает шестое издание. Его самая последняя книга (в соавторстве с Роном Оглесби), Terminal Services for Microsoft Windows Server 2003, будет опубликована в январе 2004. Кроме того, Брайен консультирует клиентов во всем мире. Подробная информация и портфель его работ доступны на сайте www.brianmadden.com.

    О Спонсоре
    Компания RTO Software, основанная в 2000г., является идером на рынке в новой категории инструментальных средств управления производительностью, которые автоматически, непрерывно и автономно улучшают производительность, универсальность и управляемость приложений на базе Windows, серверов и рабочих столов.
    Наш первый продукт, TScale, обеспечивает недорогой способ улучшить производительность, емкость и управляемость серверов Citrix MetaFrame или Microsoft Terminal Services, выполняющих Windows NT и/или Windows 2000/2003. RTO Software также предлагает консультативные услуги предприятиям и программным фирмам, которые хотят улучшить производительность и универсальность их приложений в терминальной среде. Продукты RTO широко используются в разнообразных отраслях промышленности, включая финансовое управление, производство, здравоохранение, телекоммуникации и правительство.
    Для получения дополнительной информации или для получения бесплатной оценочной версии оценки TScale, посетите сайт RTO Software www.rtosoft.com или позвоните +1-678-455-5506.

    Информация о версии
    Этот документ версии 1.0, опубликованный в августе 2003.

    Что такое производительность?

    Хотя это странный вопрос, но он важен для создания границ того, чего вы можете ожидать, читая эту статью. Говоря простыми словами, "производительность" - это получение ожидаемых результатов на основании установленного набора вводных данных.

    Терминальные серверы работают хорошо тогда, когда они сответствуют вашим ожиданиям. Неважно, поддерживаете ли вы 10, 100 или 1000 пользователей на сервере. Гораздо важнее знание того, что вы можете надежно поддерживать 10, 100 или 1000 пользователей на сервере.

    Все проблемы производительности Терминального сервера на самом деле можно разбить на две категории:

    • Вы хотите, чтобы что-то происходило быстрее.
    • Вы хотите чего-то в большем количестве.

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

    Подумайте о скорости различных действий на ваших терминальных серверах. Вы хотите, чтобы диалоговые окна выскакивали через одну десятую секунды вместо половины секунды? Вы хотите уменьшить время входа в систему с тридцати секунд до десяти?

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

    Подход к вашей проблеме производительности

    Прежде, чем вы начнете расследовать проблему производительности, важно понять, что каждый терминальный сервер имеет свой предел. Этот предел изменяется от компании к компании, но основывается на приложениях, параметрах пользователя, аппаратных средствах, сети и бесчисленного количества других факторов. Есть множество "точно настроенных" сред, в которых на сервере можно разместить лишь 25 пользователей. Но наряду с этим есть и среды с 350 пользователями на сервере.

    Как только вы примете тот факт, что вы никогда не сможете поддерживать 750 пользователей на двухпроцессорном сервере, следующий шаг должен состоять в определении вашей проблемы. Это важный шаг, который может быть довольно сложен. В конце концов, что является реальной проблемой в вашей среде? Если у вас есть сервер, который медленно работает со 100 пользователями, то, может быть, он просто плохо настроен? Или это свидетельствует, что на нем слишком много пользователей? С точки зрения производительности, это два различных взгляда на одну и ту же проблему.

    Учитывая, что все проблемы производительности терминального сервера заключаются в желаниях"больше" или "быстрее", вашей специфической проблемой производительности, вероятно, будет одно из следующих:

    • Слишком медленные входы в систему
    • Слишком медленная общая среда.
    • Вы хотите поддерживать на вашем сервере больше пользователей .
    • Сервер беспорядочно зависает, выбрасывает, приостанавливается, замораживается и/или становится медленным.

    Вы можете сталкиваться с некоторыми из этих проблем (или со всеми), и весьма часто они связаны друг с другом. По этой причине я рекомендую, чтобы вы прочитали эту статью целиком перед созданием вашего плана решения проблемы производительности. Давайте начинем с расследования медленных подключений.

    Поиск и решение проблем, связанных с медленным входом в систему

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

    Что представляет собой "медленный вход"? Это зависит от вашей среды. Вход на терминальный сервер и создание нового сеанса никогда не будут столь же быстрыми, как соединение с ранее разъединенным сеансом. В некоторых компаниях процесс входа в систему занимает несколько секунд, а в других - несколько минут. Бывает, что процесс входа в систему занимает даже 20-30 минут. Эту ситуацию мы и будем здесь расследовать.

    Понимание процесса входа в систему терминального сервера

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

    Когда пользователь входит на терминальному сервер, происходит следующая последовательность событий :

    1. Пользователь нажимает кнопку подключения.
    2. В среде Terminal Server 2003 сервер направляют пользователя на сервер, который держит разъединенный сеанс пользователя.
    3. Сервер ведет переговоры с клиентом и запрашивает у того уровень шифрования и возможности виртуальных каналов.
    4. Пользователь аутентифицируется в домене и проверяются его права доступа к подключению.
    5. Проверяются лицензии. Сначала проверяется лицензия доступа клиента к серверу, а затем лицензия доступа клиента к терминальному серверу.
    6. Терминальный сервер загружает профиль пользователя.
    • Сначала он входит в контакт с сервером регистрации (контроллером домена), чтобы проверить, есть ли для пользователя перемещаемый профиль.
    • Если есть, сервер выясняет, существует ли локальный профиль.
    • Если есть локальный профиль, то сервер проверяет, какой из них новее.
    • Если более новой является удаленная копия перемещаемого профиля, сервер копирует перемещаемый профиль с удаленного сервера.
    1. Терминальный сервер применяет любые GPO, которые были сконфигурированы.
    • Cервер вновь соединяется с сервером регистрации, чтобы проверить любые GPO для пользователя.
    • Если есть политики, сервер загружает их
    • Затем он применяет эти политики
    • Терминальный сервер проверяет фильтрацию GPO, рекурсию, и т.д.
    • Затем он обрабатывает каждое расширение GPO, например, переназначение папки, политики безпасности, дисковые квоты и т.д
    1. Терминальный сервер запускает любые приложения, которые определены в политиках.
    2. Сервер запускает содержимое значений раздела реестра "Run" .
    3. Сервер выполняет пользовательские сценарии входа в систему.
    4. Сервер запускает все программы, находящиеся в папке Startup ("Автозагрузка") меню Start.

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

    Теперь, когда вы увидели то, что происходит (или может произойти) при каждом входе пользователя, вы можете запустить трассировку этого процесса, чтобы увидеть, где может находиться задержка. Здравый смысл подсказывает, что нужно начать с простых шагов и продвигаться к более сложным. Вот подход, который я предпочитаю:

    1. Изолируйте проблему
    2. Проверьте перемещаемые профили.
    3. Проверьте все, что выполняется или загружается при входе пользователя.
    4. Проверьте любые другие действия, которые происходят при входе пользователя.
    5. Сделайте трассировку процесса входа в систему, включив отладку.

    Шаг 1. Изолируйте Проблему

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

    • Вход в систему медленный для отдельных пользователей или для всех?
    • Если вы используете Citrix MetaFrame, то вход через ICA столь же медленный, как вход через RDP?
    • Что происходит, если пользователь с медленным входом попробует войти через консоль сервера?
    • Медленный вход всегда или в определенное время дня?
    • Пользователи испытывают медленные входы в систему каждый раз, или это присходит случайно?
    • Есть ли что-то еще, что испытывают пользователи с медленным входом? (Они все находятся в одной доменной группе или OU? Они все находятся в одном здании? Они все имеют одинаковый тип клиентского устройства? Они все бухгалтеры?)

    Ответы на эти вопросы помогут сузить рамки вашего расследования. Например, если вы нашли, что медленный вход случается только при подключении через ICA, а не через RDP, то вы сможете сосредоточиться на процессе запуска сеанса ICA.

    Как только вы изолировали признаки проблемы, вы можете перейти к Шагу 2 вместе с информацией, которая вам необходима для интеллектуальной диагностики.

    Шаг 2. Проверьте перемещаемый профиль

    Хотя проверка перемещаемых профилей логически не выглядит лучшим местом для начала, перемещаемые профили виноваты в 95% всех проблем медленного входа на терминальном сервере. Надлежащее использование и проектирование профилей в терминальной среде находится за рамками этого документа. (См. в конце этой статьи раздел "Ресурсы"). Если вы не используете перемещаемые профили, перейдите сразу к Шагу 3.

    Если Вы используете перемещаемые профили, то выясните, насколько велики профили ваших пользователей. Теоретически, Windows 2000 и 2003 не должны позволять главным копиям профилей ваших пользователей включать в себя элементы, напрасно расходующие место - например, временные файлы Internet. Однако, на практике перемещаемые профили могут содержать мусор любого рода, включая временные файлы, кэш Internet, файлы регистрации аварийного отказа и сотни файлов, начинающихся "~".

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

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

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

    Шаг 3. Идентифицируйте все, что запускается при входе пользователя

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

    Проверьте сценарий входа
    Помните, что пользователи могут получить сценарии входа в систему из разных источников. Помимо сценария, применяемого как часть параметров настройки учетной записи пользователя, вы также можете иметь сценарии, применяемые как часть GPO. Наконец, не забудьте про существование файла usrlogon.cmd (даже в Windows Server 2003) - возможно, некоторые процессы запускаются из него.

    Проверьте системный реестр
    Есть несколько мест в системном реестра, которые могут запускать процессы при входе пользователя. На ваших терминальных серверах, проверьте следующие ключи реестра:

    Ключ: HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon\
    Значение: AppSetup
    Данные: Разделенный запятыми список выполнимых программ, которые запускаются при запуске сеанса.

    Для большинства серверов этот список будет содержать UsrLogon.cmd. (Не забудьте проверить UsrLogon.cmd, чтобы увидеть, что он добавляет к процессу входа). Для серверов Citrix MetaFrame это значение системного реестра будет также включать cmstart.exe.Это программа, которая конфигурирует среду Citrix после входа, включая отображение диска и переназначение принтера.

    Ключ: HKCU\Software\Microsoft\Windows\CurrentVersion\Run
    Значение: Имя запускаемой программы.
    Данные: Путь к запускаемой программе.

    Эти два ключа "Run" часто используются поставщиками программного обеспечения для запуска программ, не давая пользователю возможности это отменить. Из-за этого в системном трее появляется куча раздражающих значков. Каждый из этих ключей может содержать несколько программ. Убедитесь, что вы знаете, что каждая из них собой представляет.

    Проверьте папку автозагрузки
    Много людей не задумываются о проверке стандартных папок Windows "Автозагрузка" (Startup) в меню "Пуск" (Start) - как папка индивидуального пользователя, так и папка для всех пользователей (All users). Однако, вы даже представить себе не можете, сколько пользователей загружают всякий хлам, который устанавливается и автоматически запускается через эти папки.
    С технической точки зрения, содержимое папок Starup запускается после входа, так как сначала должна загрузиться оболочка Windows. Однако, эти приложения все равно могут значительно увеличить ощущаемое время входа для ваших пользователей.

    Разборка с программами, которые запускаются при входе

    Теперь, когда вы имеете список того, что запускается при входе пользователя, что вы должны сделать? Сначала выясните, для чего это все нужно и не является ли одна из программ источником медленного входа. Поскольку мы имеем дело с терминальным сервером, это просто сделать. Войдите под администратором и запустите Task Manager или Performance Monitor. Затем войдите под пользователем и наблюдайте имена процессов, выполняющиеся для этого пользователя.

    Что вы должны сделать, если вы обнаружили нечто, что выполняется слишком долго? Удалите это. Однако, если программа необходима, все еще есть некоторые уловки, которые вы можете использовать. Лучшее всего позволить программе работать в ее собственном окне. В сущности, вы можете превратить любую программу в фоновый процесс.

    Например, приложение cmstart.exe от Citrix, как известно, долго запускается, особенно если пользователи имеют много принтеров и разрешено отображение принтера. Так как программа cmstart.exe вызывается каждый раз при входе пользователя через ключ реестра "AppSetup", который мы ранее обсуждали, сеанс пользователя не может начаться до тех пор, пока не завершится cmstart.exe. Чтобы справиться с этим, удалите cmstart.exe из ключа реестра "AppSetup" и добавьте в сценарий входа пользователя. Если вы добавите его в сценарий usrlogon.cmd (который по иронии судьбы тоже запускается из ключа реестра "AppSetup"), он будет запускаться для каждого пользователя, который регистрируется на сервере.

    Вместо того, чтобы добавлять строку к сценарию входа, который просто выглядит как "cmstart", добавьте следующую строку:

     start /c cmstart.exe

    Команда "start" запустит этот процесс в его собственном командном окне, позволяя системе идти дальше, не ожидая завершения. Опция "/c" инструктирует автоматически закрыть окно после завершения команды.

    Вы можете использовать start /c для запуска любого приложения из сценария входа, будучи уверенным, что приложение не замедлит ваш процесс входа в систему. Если вы решаете это сделать, то должны выполнить с командной строки start /? и cmd /? , так как обе команды имеют несколько дополнительных опций, которые могут быть полезны при использовании в сценариях входа.

    Важно понять, что метод start /c не ускорит выполнение программ, но позволит им работать в фоновом режиме, чтобы ваши пользователи могли быстрее начать работу.

    Шаг 4. Идентифицируйте другие действия, которые происходят во время входа

    Если вы не можете идентифицировать программу, которая замедляет вход, то вы должны составить список всего остального, что происходит во время входа.

    Для этого проверьте конфигурацию всех ваших программ. Посмотрите, что происходит с виртуальными каналами тонкого клиента (RDP и ICA). Вы используете отображение диска? А как на счет отображения принтера или переназначении портов? Все эти опции должны инициализировать себя при запуске сеанса. В то время как некоторые из этих опций являются частью cmstart.exe, другие более присущи системе и не могут быть обмануты путем запуска их другим способом (отличным от их полного отключения).

    Вы, вероятно, задаетесь вопросом, насколько это может действительно затрагивать производительность системы. Учитывайте следующие факты: отключение оценки часового пояса клиента при запуске позволило одной компании увеличить загрузку их серверов с 65 до 110 пользователей на сервер. Другая компания смогла увеличить с 35 до 62 число пользователей на сервере просто отключив автоматическое отображение принтеров. (Отображение принтера занимает значительное время при входе, поскольку новые принтеры обнаруживаются и устанавливаются службой спулера. Отключите эту особенность или включите опцию, которая позволяет пользователям подключаться не дожидаясь принтеров, и наблюдайте, как сокращается время входа).

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

    При рассмотрении действий, которые имеют место во время входа в систему, не забудьте о нетерминальном сервере и приложениях, отличных от Citrix. Например, известно, что антивирусное программное обеспечение часто замедляет процесс входа на сервер Citrix, поскольку проверяет каждый файл профиля пользователя во время его загрузки. Перенос антивирусного программного обеспечения с сервера терминалов на ваш главный файловый сервер профилей потенциально позволит существенно уменьшить время входа.

    Шаг 5. Сделайте трассировку журнала отладчика для пользовательского процесса входа

    Если после этих трех шагов вы не определили причину медленного входа, пришло время испачкать руки. В Windows 2000 и Windows Server 2003, приложение по имени userenv.dll отвечает за создание полной операционной среды во время входа. Оно включает загрузку профиля пользователя и применение групповых политик.

    К счастью, вы можете включить диагностику всех действий, которые осуществляет файл userenv.dll. Эти файлы трассировки чрезвычайно детализированы, описывая с точностью до миллисекунд то, что делал сервер. Например, вы не только можете сделать трассировку высокоуровневого процесса входа, описанного выше, но можете также видеть, как userenv.dll проверяет список файлов профиля, проверяет дисковое пространство, проверяет ntuser.dat, загружает ntuser.dat в HKCU и заменяет системные переменные в пути фактическими значениями.

    Рассматривая этот журнальный файл , вы сможете увидеть, не застрял ли где-нибудь некоторый файл перемещаемого профиля, если процесс копирования файла занимает слишком много времени, или не держат ли сервер DNS или WINS. Вы также можете отслеживать применение GPO, чтобы видеть, не занимает ли это чрезмерное время (или у вас слишком много политик, которые замедляют процесс).

    Этот журнал поможет вам точно определить причину медленного входа, о которой вы даже не подозревали. Например, одна компания испытывала медленные входы из-за контроллера домена. Персонал отдела автоматизации сосредоточил свое внимание на пути между терминальным сервером и файловым сервером, на котором хранились основные копии профилей пользователей. Но просмотрев журнал userenv.dll, они обнаружили, что контроллер домена был настолько занят, что ему требовалось 30-45 секунд для ответа на запрос от терминального сервера о месторасположении перемещаемого профиля пользователя. Аппаратное обновление за 3000$ контроллера домена сэкономило для этой компании 45 секунд на каждом пользовательском входе на 20 терминальных серверах.

    Вы можете включить отладку userenv.dll, добавив следующий параметр в реестр на терминальном сервере:

    Ключ: HKLM\Software\Microsoft\Windows NT\CurrentVersion\Winlogon
    Значение: UserEnvDebugLevel
    Тип: REG_DWORD
    Data: 10002 (Hex)

    Значение 10002 включит подробную регистрацию в файл. После установки значения перезагрузите ваш сервер и проверьте файл userenv.log в каталоге %SystemRoot%\Debug\UserMode\. Не забудьте потом выключить отладку, т.к. каждый пользовательский вход может легко добавить 100 КБ к размеру этого журнала.

    Давайте взглянем на небольшой фрагмент файла userenv.log. Этот пример сильно урезан и показывает лишь несколько случайных строк, чтобы дать вам представление о типе информации, которая доступна в этом журнале. (Полный файл журнала процесса входа одного пользователя занял бы 15 печатных страниц.)

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

       09:25:30:606 UnloadUserProfile: Entering, hProfile = <0x850>
       09:25:30:606 UnloadUserProfile: In console winlogon process
       09:25:30:616 UnloadUserProfileP: Entering, hProfile = <0x850>
       09:25:30:616 CSyncManager::EnterLock <S-1-5-21-2364083253-1420309831-852573094-500>
       09:25:30:616 CSyncManager::EnterLock: No existing entry found
       09:25:30:616 CSyncManager::EnterLock: New entry created
       09:25:30:616 CHashTable::HashAdd: S-1-5-21-2364083253-1420309831-852573094-500 added in bucket 19
       09:25:30:616 UnloadUserProfileP: Wait succeeded. In critical section.
       09:25:30:872 MyRegUnLoadKey: Returning 1.
       09:25:30:872 UnloadUserProfileP: Succesfully unloaded profile is local, not setting preference key
       09:27:39:975 CreateLocalProfileImage: One way or another we haven't got an existing local profile, try and create one
       09:27:39:975 CreateSecureDirectory: Entering with <C:\Documents and Settings\brian>
       09:27:40:052 CreateSecureDirectory: Created the directory <C:\Documents and Settings\brian>
       09:27:40:052 ComputeLocalProfileName: generated the profile directory <C:\Documents and
       09:27:42:068 CopyProfileDirectoryEx: Leaving with a return value of 1
       09:27:42:106 MyRegLoadKey: Returning 00000000
       09:27:42:106 IssueDefaultProfile: Leaving successfully
       09:27:42:115 RestoreUserProfile: Successfully setup the local default.
       09:27:42:115 SetupNewHive: Entering
       09:27:42:115 SetDefaultUserHiveSecurity: Entering
       09:27:42:335 SecureUserKey: Entering
       09:27:42:335 SecureUserKey: Leaving with a return value of 1
       09:27:42:335 SecureUserKey: Entering
       09:27:42:345 SecureUserKey: Leaving with a return value of 1
       09:27:49:719 ProcessGPOs: -----------------------
       09:27:49:719 ProcessGPOs: Processing extension Microsoft Disk Quota
       09:27:49:719 CompareGPOLists: The lists are the same.
       09:27:49:719 ProcessGPOs: Extension Microsoft Disk Quota skipped with flags    0x6.
       09:27:49:719 ProcessGPOs: -----------------------
       09:27:49:719 ProcessGPOs: Processing extension QoS Packet Scheduler
       09:27:49:719 CompareGPOLists: The lists are the same.
       09:27:49:719 ProcessGPOs: Extension QoS Packet Scheduler skipped with flags    0x6.
       09:27:49:719 ProcessGPOs: -----------------------
       09:27:49:729 ProcessGPOs: Processing extension Scripts
       09:27:49:729 CompareGPOLists: The lists are the same.
       09:27:49:729 ProcessGPOs: Extension Scripts skipped because both deleted and changed GPO lists are empty.
       09:27:49:862 ProcessGPOs: User Group Policy has been applied.
       09:27:49:862 ProcessGPOs: Leaving with 1.
       09:27:49:872 ApplyGroupPolicy: Leaving successfully.
       09:27:51:763 IsSyncForegroundPolicyRefresh: Synchronous, Reason: policy set to SYNC
       09:27:52:700 LibMain: Process Name: C:\WINDOWS\system32\userinit.exe
       09:27:53:139 GPOThread: Next refresh will happen in 109 minutes
       09:27:57:926 LibMain: Process Name: C:\WINDOWS\system32\ie4uinit.exe
       09:28:40:507 LibMain: Process Name: C:\WINDOWS\system32\msiexec.exe
       09:28:47:967 LibMain: Process Name: C:\WINDOWS\system32\userinit.exe 

    Этих инструментов должо быть достаточно для расследования медленного входа в систему. Имейте в виду, что процесс входа в систему всегда занимает некоторое время, в действительности 15-20 секунд, и вероятнее всего такую скорость вы получите. Однако, если ваши текущие пользователи ждут минуту или две, есть способы ускорения процесса.

    Поддержка большего числа пользователей на вашем сервере

    Почти каждый хочет знать, как поддерживать больше пользователей на своих терминальных серверах. Хотя это благородное желание, важно помнить первые параграфы этой статьи, где мы обсуждали ограничения аппаратных средств сервера.

    Чтобы вместить на сервер больше пользователей, вам необходимо определить узкое место. Узкое место существует всегда. Вы только хотите знать, можно ли его выявить и исправить. Затем вы можете искать следующее узкое место. В конечном счете вы столкнетесь с таким узким местом, с которым не сможете справиться, но к счастью, к этому моменту вы уже сможете поддерживать значительно больше пользователей, чем в начале.

    Даже большие серверы класса datacenter имеют практические пределы числа пользователей, которых они могут поддерживать, особенно если они выполняют 32-разрядные версии Windows. Современные самые большие 32-разрядные системы могут поддерживать приблизительно до 500 одновременных пользователей, хотя большинство серверов настроено на поддержку от 50 до 150 пользователей.

    Чтобы определять, могут ли ваши серверы поддерживать больше пользователей, мы разберем сервер на его технические компоненты и проанализируем методы, требуемые для оценки и оптимизации каждого из них. Давайте начнем с рассмотрения версии программного обеспечения Windows, которое выполняется на вашем терминальном сервере.

    Выбор версий вашего программного обеспечения

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

    Версия Windows

    При прочих равных условиях, Microsoft Windows Server 2003 поддерживает на 25-80% больше пользователей, чем Windows 2000 Server. (Эта цифра основана на исследованиях Gartner, Hewlett-Packard, Unisys, Microsoft и на моем опыте). В это трудно поверить, и многие являются скептиками пока не увидят это собственными глазами, но доказано, что вы можете поддерживать намного больше пользователей на сервере Windows 2003, чем на сервере Windows 2000 с идентичными аппаратными средствами.

    Единственная сноска к этому правилу заключается в том, что Windows 2003 поддерживает больше пользователей, чем Windows 2000 только тогда, когда серверы не сдерживаются аппаратным ограничением. Другими словами, если серверу не хватает памяти или мощности, то Windows 2003 и Windows 2000 будут работать одинаково. Однако, если вы имеете большой сервер, выполняющий Windows 2000 (скажем, четыре процессора и 4GB памяти), модернизация до Windows Server 2003 даст вам возможность поддерживать на этом сервере больше пользователей. Это факт.

    Причин для этого две. Первый факт состоит в том, что Windows 2003 вцелом намного лучше работает, чем Windows 2000, не только Terminal Services. Второй факт (несколько менее уместный, но тоже интересный) состоит в том, что вам не требуется настраивать Windows 2003 в том объеме, как в Windows 2000. Windows 2003 включает все настройки терминального сервера, которые были "открыты" спустя три года эксплуатации Windows 2000.

    Версия Citrix MetaFrame

    Citrix MetaFrame XP Feature Release 3 работает существенно быстрее, чем предыдущие версии. В свою очередь, это позволяет вам обслуживать на единичном сервере больше пользователей. Недавно опубликованная статья ActiveAnswers (от HP/Compaq ) утверждает, что некоторые задачи при использовании Feature Release 3 могут выполняться на 12% быстрее, чем в Feature Release 2. В Feature Release 3 включено множество улучшений производительности MetaFrame XP и все они могут составить большую прибавку к пользовательской загрузке. Зачем тратить усилия для ручного впихивания большего числа пользователей сервере, когда простое обновление программного обеспечения может это сделать для вас?

    Память

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

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

    • Вы должны понять, как работает память в среде терминального сервера.
    • Вы должны выяснить, достаточно ли памяти для того, что вы хотите сделать.
    • Если система, как вам кажется, через какое-то время становится медленнее, вы должны проверить утечку памяти.

    Реальная оценка памяти

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

    Объем памяти, требуемый для пользователя, зависит от приложений, которые они используют, и операционной системы вашего сервера. Для базовой системы обычно принимают около 128 МБ .

    Для профессиональных пользователей, которые используют Outlook, IE, Word и Excel и кто часто переключается туда-сюда между ними, хорошей оценкой будет приблизительно по 15 МБ памяти для каждого пользователя на серверах Windows 2000 и по 10 МБ на серверах Windows 2003. Для пользователей, которые используют единственное приложение для ввода данных, вы можете рассчитывать приблизительно по 7 МБ для Windows 2000 и по 5 МБ для Windows 2003. Если ваши терминальные серверы поддерживают сложные бизнес-приложения на базе клиент-сервер, то заранее сложно предсказать, сколько потребуется памяти. Это может быть 20, 30 и даже 50 МБ для каждого пользователя, в зависимости от приложения.

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

    Как используется память в среде терминального сервера

    Каждый пользователь, который выполняет приложение на терминальном сервере, будет использовать память для этого приложения так же, как если бы он выполнял его на обычной рабочей станции. Если заглянуть в диспетчер задач, то вы увидите, что Microsoft Word для работы требует около 10 МБ памяти. Каждый пользователь Word будет нуждаться в 10 МБ, означая, что 20 одновременных пользователей будут требовать 200 МБ.

    Конечно, необходим некоторый запас, необходимый для запуска самого сеанса - это приблизительно 4 МБ. Поэтому для того, чтобы 20 пользователей смогли работать в Word, необходимо 280 МБ памяти.

    К этому вы должны добавить память, требуемую для основной операционной системе, что составляет около 128 МБ. Если вы сложите все вместе, то обнаружите, что для 20 пользователей теоретически потребуется 408 МБ памяти на терминальном сервере.

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

    • Приложения требуют переменных объемов памяти. Даже при том, что менеджер задач показал, что Microsoft Word потребляет 10 МБ памяти, потребление памяти сильно меняется в зависимости от документов, которые в нем открыты. Загрузите и откройте насыщенный графикой 300-страничный документ, и увидите, что Word будет потреблять намного больше 10 МБ. Другая вещь, которую нельзя упустить - это файлы поддержки, типа DLL, которые иногда потребляют больше всего памяти.
       
    • Windows обрабатывает множественные экземпляры одной и той же выполнимой программы особым способом. Если бы все 20 пользователей использовали Word по 10 МБ каждый, то вы бы предположили, что используется 200 МБ памяти, правильно? На самом деле Windows поступает умнее. Поскольку все 20 пользователей используют одну и ту же копию winword.exe, система полагает, что не должна физически загружать один и тот же двоичный образ в память 20 раз. Вместо этого она загружает выполнимую программу только один раз и "направляет" другие сеансы на этот первый экземпляр. Это делается с оглядкой. Компоненты, управляющие сеансом каждого пользователя думают, что они имеют полную копию выполнимой программы, загруженной локально в собственное пространство памяти, тогда как на самом деле они имеют указатель на другое пространство памяти. Если один сеанс должен изменить в памяти копию выполнимой программы, сервер прозрачно (и быстро) создает уникальную копию выполнимой программы для этого сеанса.

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

    Даже после понимания всего это, осталось еще немного, что мы должны охватить до того, как вы получите точное понимание реального использования памяти вашего сервера. Большинство людей использует Task Manager для получения информации о том, имеет ли сервер достаточно физической памяти (Вкладка Performance | Physical Memory (K) | Available). Проблема состоит в том, что число, сообщаемое менеджером задач, немного вводит в заблуждение. Хотя оно действительно правильно показывает объем свободной физической памяти, оно не показывает, почему эта память свободна. Например, если Task Manager показывает, что вы почти исчерпали всю память, то вы можете подумать, что вам необходимо больше памяти, тогда как на самом деле ее добавление вообще не поможет. Чтобы понять почему, вы должны разобраться с тем, как Windows управляет распределением памяти.

    В операционной системе Windows, индивидуальный процесс запрашивает память у системы блоками. Каждый блок (chunk) называют "страницей", она размером 4 КБ. Любые страницы памяти, которые Windows предоставляет процессу, называют "выделенной памятью" (committed memory). Выделенная процессу память представляет полный объем памяти, который дала ему система, и эта выделенная память может находиться в физической памяти или перенесена на диск (или частично там и там).

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

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

    Однако, когда общее использование физической памяти увеличивается (порядка 80%), Windows начинает нервничать. Она начинает проверять все процессы, чтобы проверить, какие из рабочих множеств активно используются. Если процесс не использует все его рабочее множество, система сбросит часть его на диск. Это позволит системе освободить некоторый объем физической памяти для других процессов. Важно обратить внимание, что это естественный процесс и в действительности не влияет на производительность, поскольку на диск сбрасываются лишь неиспользуемые части рабочего множества процесса.

    Помните, что система не запускает высвобождение неиспользуемой памяти рабочего множества до тех пор, пока общее использование памяти не достигнет 80%. Это означает, что в системах с большим объемом памяти Windows не будет использовать подкачку неиспользованной памяти рабочего множества. (Зачем беспокоиться, если у вас много памяти, правда?)

    Побочным эффектом этого является то, что когда памяти в избытке, определение объема памяти, который система использует в даный момент времени (путем просмотра рабочего множества), покажет число, которое намного выше, чем должно быть. Это может привести вас к мысли, что ваш сервер нуждается в большем количестве памяти, чем имеет.

    Давайте еще раз просуммируем сказанное, так как это очень важно. Выделенная память для процесса - это объем памяти, которая выделена ему операционной системой Windows, а рабочее множество - это подмножество выделенной памяти, которое находится в физической оперативной памяти. Если процесс активно не использует все свое рабочее множество, то система может убрать часть рабочего множества, чтобы лучше использовать физическую оперативную память для чего-нибудь еще. Это не влияет на общую производительность системы, так как процесс все равно не использует эту память.

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

    Как определить, достаточно ли физической памяти?

    Использовать Performance Monitor для слежения за фактическим использованием памяти непросто. Теперь, когда вы поняли (или прочли, так или иначе), как процессы Windows используют память, давайте использовать реальную аналогию, чтобы вы смогли начать оценивать сложность проблем, которые должны проследить. В этой аналогии используйте следующую таблицу:

     

    Сервер Windows Аналогия
    Физическая память Здание вашего офиса
    Файл подкачки Архив офисных документов
    Процесс или программа Сотрудник
    Раздел памяти, используемый процессом Документ
    Операционная система Ваш начальник

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

    Если вы принимаете несколько новых коллег, они займут часть вашего офисного пространства. Чтобы облегчить это, ваш начальник может приказать: "Разберись с документами и отнеси те, которые не трогал пять лет, в архив". Это освободит место в офисе для новых сотрудников.

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

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

    Предположим, вас пригласили в качестве бизнес-аналитика для участия в решении проблемы с документами этой компании - что бы вы предложили? Очевидно, что они нуждаются в большем пространстве или меньшем количестве сотрудников, но что лучше? Как вы можете проследить производительность по отношении к количеству документов, находящихся в офисе и архиве? Трудно создать жесткие критерии для этого. В конце концов, кто может решить, что приемлемо, а что - нет?

    Вот почему трудно использовать Performance Monitor для отслеживания реального использования памяти на терминальном сервере.

     

    Лучший способ использовать Performance Monitor в этом случае состоит в том, чтобы следить за тенденциями. Вы должны наблюдать несколько счетчиков сразу, чтобы видеть, как они соотносятся друг с другом, когда ваша система начинает себя плохо вести. Вот счетчики, которые вы должны проследить:

    Process I Working Set I _Total
    Счетчик Working Set - это фактически свойство процесса, а не системной памяти. Поэтому вы должны выбрать объект процесса. Вы будете видеть каждый работающий процесс, но выбор "_Total" даст вам общий итог в байтах всех рабочих множеств всех процессов в системе. Когда вы проверяете его, помните, что он не включает основную память, поэтому вы будете должны добавить еще 128 МБ или около того.

    Memory I Pages Input/ Sec
    Этот счетчик сообщает вам частоту обращения процесса к той части памяти, которая не была в его рабочем множестве, означая, что система должна была взять ее из файла подкачки. По нашей аналогии, это аналогично получению документа из архива.

    Memory I Pages Output/ Sec

    Этот счетчик противоположен счетчику 'Pages Input/Sec'. Он сообщает, сколько раз в секунду система решила урезать рабочее множество процесса, записывая часть памяти на диск , чтобы освободить физическую память для другого процесса.

    Memory I Available Bytes
    Этот счетчик отслеживает количество свободных байтов в физической памяти. Свободные байты готовы к использованию другим процессом. Когда памяти в изобилии, эти свободные байты используются беспечно, поэтому вы не можете проследить этот счетчик сам по себе для определения требования к памяти.

    Terminal Services I Active Sessions
    Вы должны также следить за числом пользовательских сеансов, которые вы имеете на системе, чтобы иметь ориентир для того, что происходит.

    Так что же вы ищете на самом деле? Начните с добавления в систему нескольких пользователей. Первое, на что вы обратите внимание, это то, что рабочее множество будет быстро расти. (Помните, что система не беспокоится об управлении им, пока не станет ощущаться нехватка памяти). Вы также обратите внимание, что счетчик Available Bytes сначала резко упадет вниз, поскольку система позволяет рабочим множествам процессов пребывать в памяти. В этом месте вы увидите некоторую активность счетчиков Memory Pages во время входа пользователей, но об этом не стоит беспокоиться. (Пиковые значения могут доходить до 200, но общий уровень будет довольно низкий).

    Продолжая добавлять пользователей, вы в конечном счете обратите внимание, что счетчик рабочего множества начинает понижаться. Это происходит, когда истощается физическая память и система начинает урезание неиспользуемых частей рабочих множеств процессов. Счетчик Pages Output/Sec начинает пикообразно расти вверх (даже до нескольких тысяч в секунду), поскольку система начинает записывать страницы на диск. При продолжении добавления пользователей резкие скачки Pages Output/Sec уменьшаются, хотя общая тенденция состоит в общем повышении Pages Output/Sec. Это ожидаемо, и производительность вашей системы из-за этого не пострадает. (Пока не покупайте больше памяти только из-за этого!)

    По мере добавления пользователей, рабочее множество продолжит уменьшаться, а оба счетчика страниц памяти продолжат устойчиво повышаться. Счетчик Available Bytes приближается к нулю.

    Что это означает? Как вы можете знать, сколько пользователей вы сможете добавить, и поможет ли вам добавление памяти? Если ваш сервер не показывает описанные тенденции, то у вас много памяти. Критический счетчик, который необходимо наблюдать, это Pages Output/Sec. Помните, что он какое-то время остается на низком уровне, а затем начинает пикообразно расти. Резкие всплески постепенно становятся все меньше и меньше, пока счетчик не повысит свой общий уровень. Место между всплесками - это сладкое место для терминального сервера. Если ваш счетчик никак не начинает существенно повышаться после всплеска, то у вас достаточно памяти, и ваше пользовательское ядро ограничено чем-то другим. Если счетчик Pages Output/Sec начинает устойчиво подниматься после всплеска, то вы можете извлечь выгоду из большего количества памяти (или других методов настройки, выделенных позже в этой статье).

    Обнаружение утечек памяти

    Другая проблема, относящаяся к памяти и которая может негативно влиять на производительность терминального сервера - это утечка памяти. Утечка памяти забирает из системы вполне пригодную память. Большинство утечек прогрессируют и отбирают с течением времени все больше и больше памяти. В зависимости от утечки это может происходить медленно, со скоростью несколько килобайт в час, а может и быстро - несколько мегабайт в минуту. Во всех случаях утечки памяти происходят из-за проблем с каким-то приложением или драйвером, и, как правило, лечатся применением заплат (предполагая, что продавец приложения достаточно компетентен их создать).

    Утечку памяти можно сравнить с раком, медленно разрушающим систему. Если ее не сдерживать, она будет замедлять систему до тех пор, пока она полностью не зависнет. Утечки памяти могут также вызвать проблемы с подключениями клиентов, чрезмерное использование процессора, засорение диска. Иногда вы можете идентифицировать виновное приложение и уничтожить его вручную. В остальных случаях единственным выходом является перезагрузка системы.

    Хорошей новостью об утечках памяти являтся то, что они в наши дни они встречаются очень редко, обычно в доморощенных приложениях. Когда-то они постоянно возникали в Windows NT, но теперь с этим покончено. Если вы когда-нибудь столкнетесь с консультантом, утверждающим, что все проблемы производительности терминального сервера происходят из-за утечек памяти, то будете знать, что это человек старой школы, который не менял свои навыки поиска неисправностей последние пять лет.

    Идентификация утечки памяти обычно довольно проста.(труднее определить что ее вызывает). Для этого используйте Performance Monitor. Технически говоря, утечка памяти происходит когда система выделяет процессу памяти больше, чем процесс возвращает в пул. Утечку памяти может вызвать любой тип процесса. Вы можете заметить утечку памяти, контролируя параметры Paged Pool Bytes (Memory | Pool Paged Bytes) and Page File Usage (Paging File | %Usage | _Total) . Если вы видите, что один из этих счетчиков (или оба) постоянно растет, даже если вы не добавляете в систему дополнительных пользователей, то вероятно имеете утечку памяти. У вас также может быть утечка, если вы видите скачкообразный рост (опять же, не добавляя новых пользователей), так как утечки памяти могут происходить в процессах, которые не всегда выполняются.

    Итак, обнаружение утечки памяти не представляет сложностей. Куда сложнее определить, какой именно процесс ее вызывает. Вы можете использовать Performance Monitor, чтобы проследить объем памяти, потребляемый каждым процессом (Process | Private Bytes | выберите процесс). Конечно, на терминальных серверах выполняются сотни процессов, поэтому такой способ не подходит. К сожалению, более простого способа нет. Вы можете поместить в график сразу все процессы, выбрав радиокнопку "all instances" в окне "Add Counters". Иногда это хорошо работает, особенно на неактивных серверах. Сотни строк расположены на графике горизонтально, поэтому любое увеличение сразу становится заметным. Когда вы это заметили, включите подсветку (Ctrl+H) и просмотрите ваш список процессов, пока не найдете тот, который устойчиво увеличивает счетчик.

    Что делать, если вы не можете изолировать утечку памяти с помощью Performance Monitor? В этом случае утечка памяти вероятнее всего вызвана чем-то, работающим в привилегированном режиме. Утечки памяти привилегированного режима обычно требуют обращения в службу поддержки Microsoft. Там предложат вам запустить утилиту poolmon.exe, находящуюся на CD-ROM Windows в папке "support", которая контролирует пул памяти привилегированного режима и выводит содержимое в командное окно.

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

    Использование файла подкачки

    Файл подкачки Windows - интересная штука. Общее неправильное представление состоит в том, что этот файл якобы является простым расширением физической памяти. Многие думают, что если купить много физической памяти, то можно не беспокоиться о файле подкачки. В среде терминального сервера все это далеко от истины. Действительно, файл подкачки используется тем больше, чем меньше физической памяти. Но Windows использует файл подкачки также для других целей.

    Из предыдущих разделов вы можете вспомнить, что Windows достаточно умна, чтобы загружать в память только одну копию исполняемой программы, когда несколько процессов используют одно и то же приложение. Технически это называется "copy-on-write optimization" (оптимизация копирования при записи), т.к. Windows создаст в памяти дополнительную копию части приложения только тогда, когда процесс попытается в нее записать.

    В среде Windows, запись в каждую выполнимую программу и DLL делается по мере использования. (Это не подразумевает запись в файлы EXE или DLL, расположенные на диске. Это просто означает, что как только они загружены в память, их версии в памяти могут изменяться).

    Поэтому в память загружается единичный DLL, а система позволяет нескольким процессам совместно его использовать. Однако, как только процесс пробует записать в часть этого DLL, система делает быструю его копию и позволяет процесса писать в копию, а не в оригинал. Кроме того, система также резервирует часть этого DLL в файле подкачки. Это означает, что в памяти существует три копии одного и того же DLL - оригинал, копия для другого процесса, и резервная копия в файле подкачки. Те же явления происходят для каждой программы, которая совместно используется несколькими процессами (или пользователями), включая файлы EXE и DLL. В правильных средах Windows, резервирование раздела выполнимой программы в файле подкачки не представляет проблемы. Однако представьте себе, как это неэффективно в среде Терминального сервера!

    Представьте терминальный сервер с 30 пользователями, которые все используют толстое приложение, например, JD Edwards One World. Это приложение является стандартным приложением в архитектуре клиент-сервер, и при запуске программного обеспечения клиента JD Edwards в пространство памяти сеанса каждого пользователя загружается исполняемая программа и несколько DLL. Однако, Windows загружает единственную копию программы в физическую память только в самом начале.

    Поскольку все 30 пользователей используют одно приложение, оптимизация копирования при записи Windows создаст в памяти 29 копий больших частей каждой программы JD Edwards. (Одна для первого пользователя и 29 копий для остальных 29 пользователей.) Это означает, что Windows также разместит дополнительные 29 копий оригинальных программ в файл подкачки перед тем, как копии будут сделаны. Это означает, что 30 пользователей JDE фактически заставят загрузиться в память 59 копий единственной выполнимой программы. Теперь умножьте это на число всяких EXE и DLL, которые загружает JD Edwards.

    К сожалению, такое встречается часто. Толстые приложения клиент-сервер в действительности никогда не разрабатывались для терминального сервера. Приложения, подобные JDE OneWorld, Cerner, Lotus Notes, Siebel, PeopleSoft, SAP и другие при своем запуске загружают массивную клиентскую среду. (Она обычно включает ядро EXE плюс несколько DLL).

    Понимание такого поведения начинает давать вам идею относительно важности файла подкачки на терминальном сервере - независимо от того, сколько у вас физической. Чтобы немного смягчить ситуацию, вы можете сделать следующее:

    • Вы можете изменить способ, которым Windows использует файл подкачки.
    • Вы можете сделать файл подкачки быстрее.

    Изменение способа использования файла подкачки

    Оптимизация копирования при записи является частью основных компонентов управления памятью Windows, и вы не можете просто ее выключить. Однако, вы можете использовать программы третьих производителей, чтобы изменить способ, которым Windows использует эти функциональные возможности. Для этого можно использовать программу TScale от RTO Software.

    TScale наблюдает, как приложения используют свои рабочие множества и как множественные образцы приложения затрагиваются оптимизацией копирования при записи. Он регистрирует потенциальную оптимизацию в файл карты оптимизации на жестком диске сервера. Затем, когда пользователь в следующий раз запускает приложение, сервер читает карту оптимизации.

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

    TScale блестяще работает с большими клиент-серверными приложениями. Фактически (и немного иронически), единственные приложения, которые TScale не сильно оптимизирует (позволяя на 10% больше пользователей вместо обычных 30%) - это приложения Microsoft - например, Office, Visio и Project. (Как будто люди, пишущие эти приложения в Редмонде, знают кое-что об особенностях Windows, о которых никто другой не знает).

    30-дневную испытательную версию вы можете скачать с сайта www.rtosoft.com. Таким образом вы можете лично убедиться, насколько полезна эта программа в вашей среде.

    Убыстрение файла подкачки

    Даже после применения TScale или оптимизации файла подкачки Expedian, он все равно будет использоваться в среде терминального сервера. Поэтому вы должны обеспечить, чтобы ваш файл подкачки был доступен настолько, насколько возможно.

    Часто используемый файл подкачки чрезмерно напрягает дисковый ввод-вывод. Поэтому прочитайте в разделе "Использование диска" информацию о том, как определить, является ли дисковый ввод/вывод узким местом в вашей среде. Если вы решили, что ваш файл подкачки является узким местом и хотели бы сделать его быстрее, то есть несколько вещей, которые вы можете сделать:

    • Поместите файл подкачки на отдельный диск на отдельном канале SCSI.
    • Отформатируйте раздел диска с файлом подкачки в FAT, поскольку FAT быстрее, чем NTFS.
    • Купите один из дисков Flash RAM. (Они напоминают обычные жесткие диски за исключением того, что они твердотельные. Они имеют Flash RAM вместо дисков и шпинделей. Они очень быстрые, но очень дорогие, их цена доходит до нескольких тысяч долларов за несколько гигабайт).

    Ни одно из этих решений не окажет существенного влияния, и вы должны попробовать их только после применения программной оптимизации файла подкачки с помощью TScale или Expedian.

    Задание размера файла подкачки

    Последний аспект файла подкачки, который может влиять на возможное число поддерживаемых пользователей - это размер файла подкачки. Если ваш файл подкачки превысит допустимый размер, вы не сможете вместить больше пользователей на свой сервер. "Официальная" рекомендация для размера файла подкачки для терминального сервера - 1,5 от объема физической памяти. Однако, не обязательно строго следовать этой рекомендации. При определении размера вашего файла подкачки, смотрите на типы и число приложений, которые используют пользователи. Также учитывайте объем полной системной памяти. Если вы имеете сервер с 512 МБ, то файл подкачки 1.5x будет адекватным. Однако, если у вас 8GB памяти, то вы можете использовать файл меньшего размера. Попробуйте для начала файл подкачки размером 4GB, а затем при необходимости увеличьте его размер.

    Вы можете проверить процент использования файла подкачки с помощью следующего счетчика Performance Monitor:
    Paging File I % Usage I _Total

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

    Использование процессора

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

    • Разберитесь с тем, как терминальные серверы используют процессоры и как вы можете проследить за этим использованием.
    • Предпримите шаги для уменьшения воздействия на процессор со стороны приложений.
    • Если ваш сервер работает на процессорах Intel Xeon, разберитесь, как разрешение или запрещение Hyperthreading затронет производительность.

    Отслеживание использования процессора

    Отслеживание использования процессора легко желается в Performance Monitor. Добавьте в график два следующих два счетчика:

    Processor I % Processor Time I _Total
    Этот счетчик показывает, насколько заняты процессоры. Если он приближается к 100%, то вам нужно что-то делать. Однако, если процессор слишком занят, это не предполагает автоматически, что вам необходима дополнительная процессорная мощность. Процессор может быть занят из-за нехватки памяти и тратит время на запись и чтение из файла подкачки.

    System I Processor Queue Length
    Если вы обратили внимание на высокое использование процессора, то можете еще проследить счетчик длины очереди процессора. Этот счетчик показывает, сколько запросов зарезервировано в процессе ожидания процессора, который нужно освободить для их обслуживания. Прослеживая этот показатель, вы можете видеть, очень занят процессор или слишком занят (есть разница). Очень занятый процессор может показать 100%-е использование, но отступает как только поступает другой запрос. Вы можете это увидеть, потому что длина очереди процессора будет почти нулевая. Процессор, который слишком занят, тоже может показывать 100%-е использование, но поскольку он слишком занят, он не может обслужить дополнительные запросы, приводя к заполнению очереди процессора.

    Вы никогда не должны использовать Task Manager для понимания использования процессора в вашей системе. Он предназначен только для общей оценки.

    Уменьшение воздействия приложений на процессор

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

    Многие приложения имеют "особенности", которые включены по умолчанию и наносят ущерб производительности терминальных серверов. Отключение фоновой проверки правописания в Microsoft Word позволит Вам удвоить число пользователей на сервере. Хотя проверка правописания не оказывает существенного воздействия на однопользовательскую систему, сто пользователей с постоянной фоновой проверкой правописания оказывают мучительное воздействие на терминальный сервер.

    Хорошая новость состоит в том, что теперь вы знаете, что может вызвать ненужное использование процессора. Плохая новость состоит в том, что эти проблемы невозможно обнаружить с помощью Performance Monitor. (С 120 пользователями на сервере, как бы вы узнали, что отключение фоновой проверки правописания может снизить среднее использование каждого пользователя с 0.82 % до 0.46 %?)

    Другой пример - отключение персонализации в настройках Internet Explorer. Это значительно увеличит скорость его загрузки и позволит поддерживать больше пользователей.

    Фактически вам необходимо вручную выполоть сорняки в каждом из ваших приложений и отключить все изящные "особенности", которые потенциально могут потреблять ресурсы. Некоторые считают, что этого делать не следует. Делать или не делаеть - зависит от того, что вы хотите от ваших серверов. Вы хотите поддерживать больше пользователей или хотите иметь тени под курсором мыши? Решать вам.

    Если ваши пользователи могут жить с 256 цветами вместо 24-битного цвета, то вы можете поддерживать на ваших серверах на 10% больше пользователей. Помните, что каждая опция, которую вы отключаете, сама по себе не будет оказывать существенного воздействия, но умножение ее эффекта на несколько сотен пользователей может легко дать весьма ощутимые результаты.

    На использование процессора также оказывает влияние способ использования приложений. Если вы установили терминальный сервер, на котором используется только Microsoft Word, то вы сможете поддерживать гораздо больше машинисток со скоростью печати 20 слов в минуту, чем машинисток со скоростью печати 65 слов в минуту.

    Анализируя использование приложений, не забудьте про приложения, работающие на сервере в фоновом режиме. Хороший пример таких приложений - антивирусное программное обеспечение. Нужно или не нужно запускать антивирусное ПО на ваших терминальных серверах выходит за рамки этого документа. Однако учтите, что антивирусы, которые предлагают "оперативную" защиту файловой системы, сильно ограничат число пользователей, которое вы можете поддерживать на сервере. Опять же, вы не сможете это проследить с помощью Performance Monitor. Если вы можете изобрести альтернативный антивирусный план (например, антивирусная защита по периметру и на уровне файлового сервера), вы сможете добавить на ваши терминальные серверы на 20-50 больше пользователей.

    Технология Hyperthreading на процессорах Intel Xeon

    Если ваши терминальные серверы работают на процессорах Intel Xeon, то вы имеете возможность включить Hyperthreading (в BIOS). Hyperthreading - это патентованная технология Intel, которая заставляет один процессор выглядеть для операционной системы в виде двух процессоров (а два процессора - в виде четырех и т.д). Процессоры Xeon имеют два конвейера данных, входящие и выходящие из основного процессора на чипе. Сам процессор чередуется между этими двумя конвейерами. Преимущество Hyperthreading состоит в том, что при наличии двух вводов центральный процессор всегда будет что-то выполнять. Если один конвейер не совсем готов, то центральный процессор может взять код из другого конвейера. Это происходит миллиарды раз в секунду.

    Hyperthreading имеет некоторые общие недостатки. Главный недостаток (который не влияет на производительность) состоит в том, что многие приложения, лицензируемые по числу процессоров, обманываются, считая что система имеет двойное число процессоров, чем на самом деле.

    Другая потенциальная проблема с Hyperthreading (которая действительно влияет на производительность) состоит в том, что Windows не достаточно умна, чтобы знать, что вы используете Hyperthreading. Она не может определить разницу между двухпроцессорной системой с Hyperthreading и настоящей четырехпроцессорной системой. Это может привести к проблемам производительности, так как система может разбить сложный процесс для более быстрого выполнения на два из четырех процессоров. В системе с Hyperthreading это может означать, что эти оба потока пойдут на один и тот же физический процессор, в то время как другой процессор будет простаивать.

    Нужно или не нужно включать Hyperthreading в среде терминального сервера - зависит от используемой операционной системы. На время написания этой статьи, включение Hyperthreading на серверах Windows 2000 вызывает проблемы стабильности и фактически уменьшает общую производительность системы.

    Однако, согласно исследованию, проводенному Тимом Манганом, включение Hyperthreading на терминальных серверах Windows 2003 дает прирост производительности на 10-20%.

    Использование диска

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

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

    В большинстве сред, ваши терминальные серверы должны содержать только операционную систему Windows, файл подкачки и файлы ваших приложений. Пользовательские данные и данные прикладной программы лучше хранить на серверах, отличных от MetaFrame, или в сетевом хранилище данных (SAN) в вашей локальной сети, поэтому локальные диски не замедляют вещи, связанные с доступом к пользовательским файлам.

    Чтобы оценить, замедляют ли ваши жесткие диски сервер, проверьте в Performance Monitor следующие счетчики :

    Physical Disk I % Disk Time
    Этот счетчик показывает, насколько заняты жесткие диски вашего сервера. Значение 100% показало бы, что диски заняты на 100% - возможно, вам необходимы более быстрые диски, большее количество памяти или меньшее количество пользователей.

    Physical Disk I Current Disk Queue Length
    Аналогично счетчикам для процессора, если счетчик % Disk Time приближается к 100%, вы можете также проконтролировать счетчик длины очереди. Он покажет, сколько дисковых запросов находятся в ожидании из-за занятости диска. Если в вашем сервере несколько дисков (которые не используют зеракльное отражение), вы должны делать запись отдельного экземпляра этого счетчика для каждого диска, вместо единого счетчика для всех дисков. Это позволит вам определить, равномерно ли используются ваши диски, или один из них перегружен, в то время как другой простаивает.

    Узкие места, связанные с использованием диска

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

    Продавцы серверов предлагают всяческие уловки, которые вы можете применить для увеличения производительность ваших дисков. Теперь печально известный пример, что адаптеры Compaq RAID и диски поставлялись с кэшем 64 МБ, который был весь настроен как кэш чтения. Изменение конфигурации кэша (через программную утилиту) на 50% чтения и 50 % записи позволило удвоить число поддерживаемых на сервере пользователей.

    Короткое замечание: вы обратите внимание, что многие из этих решений позволят компаниям "почти удвоить" число поддерживаемых пользователей. Имейте в виду, что полный анализ производительности целиком состоит в поиске узких мест. В вашем случае осуществление одного изменения может привести лишь к 5%-му увеличению, после чего появится другое узкое место. Вам, возможно, придется проделать путь через несколько узких мест, прежде чем вы получите существенный прирост производительности.

    Если программная конфигурация сама по себе не устраняет узкое место, связанное с диском, замените ваши текущие диски на более быстрые. Помните, что когда вы имеете дело с серверами, покупайте более быстрые диски (15000 rpm против 10000 rpm), более быстрый интерфейс или оба.

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

    Использование сети

    Ограничения физических сетевых интерфейсов на терминальных серверах также могут вызвать узкое место. Что интересно, сетевую карту забивают не сеансы RDP или ICA. Скорее, блокировку вызывает связь между терминальным сервером и сетевыми файловыми серверами. Эти соединения отвечают за перемещаемые профили пользователей, домашние диски, хранилище данных IMA и все другие данные, перемещаемые с сервера и на сервер на заднем плане. Сотни пользователей на единственном сервере могут легко насытить это соединение. Как и со всеми аппаратными компонентами, если ваше сетевое соединение является узким местом, вы будете ограничены в числе поддерживаемых на сервере пользователей, независимо от того, сколько памяти или процессорной мощности вы имеете.

    Простейший способ проверить использование сети - через Performance Monitor. Конечно, вы можете также использовать Task Manager (вкладка Networking), но вы не можете оттуда ничего сохранить или получить быстрые подробности. Загрузите следующие счетчики:

    Network Interface I Bytes Total/ sec I Select your card
    Убедитесь, что выбрали по отдельному экземпляру этого счетчика для каждой сетевой карты в вашем сервере. Когда вы смотрите на результаты, имеете в виду, что сетевой интерфейс на 100 МБ/с - это 100 мегабит, а счетчик производительности отслеживает байты. Т.к. в байте содержится 8 бит, счетчик производительности покажет максимум 12.5M байт. Учитывая служебные данные, для сети 100 МБ максимум составляет около десяти мегабайт в секунду.

    Network Interface I Output Queue Length I Select you card
    Как и для других счетчиков, вы можете определить узкое место в сети, следя за длиной очереди вывода для ваших сетевых карт. Если вы видите продолжительное значение больше двух, то вам следует предпринять какие-то действия..

    Узкие места в сети

    Идентификация узких мест в сети не представляет собой сложности. Устранение их также просто - вставьте более быструю сетевую карту, включите полный дуплекс, используйте тандем из карт.

    Однако, вы можете уменьшить некоторое давление со стороны сетевого интерфейса вашего сервера, настроив общую архитектуру вашей среды терминального сервера. Например, если вы используете Citrix MetaFrame XP, то можете установить в сервер дополнительную сетевую карту, которая будет специализироваться только на связи со службой IMA по локальной сети. Или, вы можете создать локальное сетевое соединение между вашими терминальными серверами и домашними дисками ваших пользователей. Это позволит сеансам ICA или RDP пользователей проходить через один интерфейс, в то время как пользовательские данные будут проходить по другому интерфейсу.

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

    Использование памяти ядра

    В некоторых случаях производительность вашей системы может замедлиться, хотя кажется, что аппаратные ресурсы в изобилии. Что делать, когда вы достигли предела производительности, несмотря на испытание памяти, процессора, дисков и сетевого интерфейса, и определили, что ни один из этих параметров не показывает, что является узким местом?

    Выполняя сотни или даже тысячи процессов, вы упираетесь в архитектурные ограничения Windows 2000 или Windows 2003, особенно на больших серверах. Чтобы понять это, вы должны разобраться, как работает Windows.

    Как ядро использует память

    Вы когда-либо задавались вопросом, что "32" означает 32-разрядную Windows? Если вы думали, что это имеет отношение к 32-разрядным процессорам Intel, вы правы наполовину. На самом деле 32 означает, что Windows имеет 32-разрядное адресное пространство памяти, то есть может адресовать 232 байт (или 4GB) памяти, независимо от объема физической оперативной памяти, установленной в системе. Это пространство памяти 4GB разбито на две части - 2GB для процессов непривилегированного режима (пользовательские процессы) и 2GB для процессов привилегированного режима (процессы ядра).

    Каждый процесс непривилегированного режима имеет свое собственное адресное пространство 2GB. Его называют "виртуальной памятью" процесса, т.к. оно всегда доступно процессу, независимо от объема физической памяти. (Иногда под "виртуальной" памятью неверно подразумевают память, подкачиваемую на диск).

    Ядро и другие важные системные функции совместно используют другую "половину". Это означает, что все функции ядра должны совместно использовать одну область памяти 2GB.

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

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

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

    Вам необходимо найти правильное соотношение. Увеличьте одну область на 5%, и вы можете добавить еще 10 пользователей. Увеличьте на 6 %, и вы можете уменьшить это число на 20..

    Поскольку корректировка одного компонента затрагивает другой, мы начнем с рассмотрения нескольких компонентов вместе. Область памяти ядра разделена на несколько частей, из них две главные (называемые "пулами") - перемщаемый (paged pool) и неперемещаемый (nonpaged pool). Неперемещаемый пул - это раздел памяти, который не может ни при каких обстоятельствах перемещаться на диск. Перемещаемый пул - это раздел памяти, который может перемещаться на диск. (Факт хранения в перемещаемом пуле не обязательно подразумевает, что что-то будет перемещается на диск. Это лишь означает, что это либо перемещалось на диск, либо может быть перемещено на диск).

    Между этими двумя пулами находится раздел, называемый System Page Table Entries, или System PTE (таблицы системных страниц).

    Чтобы понять суть PTE (и понять, как они относятся к масштабированию терминального сервера), вы должны вспомнить только что прочитанное - что каждый процесс может использовать до 2GB памяти.

    В реальности большинство процессов не использует свои 2GB памяти. Однако поскольку каждый из них думает, что имеет полные 2GB, они ссылаются на всю их память, как будто выполняются только они. Это означает, что система должна следить за фактическим использованием памяти каждого отдельного процесса и должна "транслировать" фактическое использование памяти каждого процесса на место в физической памяти или в файле подкачки. Для этого система создает таблицу страниц памяти для каждого процесса.

    Эта таблица страниц представляет собой просто индекс, который следит за фактическими местоположениями страниц памяти процесса. Каждый вход в этой таблице прослеживает отдельную страницу памяти и называется PTE. 2GB памяти, используемые ядром, также имеют таблицу страниц. Входы в той таблице называют системными PTE.

    Какое это имеет отношение к исследованию производительности терминального сервера? Дело в том, что максимальное число системных PTE, которые может иметь сервер, устанавливается во время его загрузки. В сильно загруженных терминальных серверах вы можете исчерпать системные PTE. Вы можете использовать системный реестр, чтобы увеличить число системных PTE, но при этом покушаясь на перемещаемый пул, что может привести к исчерпанию памяти перемещаемого пула. Исчерпывание обоих плохо, и ваша цель состоит в том, чтобы настроить сервер так, чтобы оба пула исчерпывались одновременно. Это покажет, что вы максимально эффективно настроили использование памяти ядра.

    Как вы можете определить, что исчерпали PTE или память перемещаемого пула? Это зависит от того, используете ли вы Windows 2000 или Windows 2003. Стоит повторить, что в Windows 2003 вы можете обслуживать больше пользователей, чем в Windows 2000. В Windows 2003 менеджер памяти был полностью изменен (технически это обновление произошло в Windows XP). Системы Windows 2003 используют память ядра намного более эффективно, и шансы, что вы столкнетесь с ограничениями ядра, крайне малы.

    Теперь посмотрим, испытывает ли ваш терминальный сервер Windows 2000 проблемы использования памяти ядра. Помните, что эти признаки возникают на системах, которые тяжело загружены и не показывают никаких других признаков аппаратных ограничений. Если использование вашего процессора приближается к 100%, даже не пытайтесь делать никаких изменений, описанных в следующем разделе.

    Оценка проблем использования памяти ядра в Windows 2000

    Если вы находитесь в положении, когда необходимо поддерживать больше пользователей, но не можете перейти на Windows Server 2003, вы должны понять несколько вещей.

    Сначала вы должны выяснить, чего не хватает - перемещаемой памяти или системных PTE. Windows 2000 может поддерживать около 600 МБ PTE. В больших терминальных серверах почти всегда сначала исчерпываются PTE, а затем пространство перемещаемого пула.

    Чтобы действительно настраивать ваш PTE и использование перемещаемого пула, вы должны будете использовать отладчик ядра. Однако, перед этим используйте Performance Monitor, чтобы увидеть, необходимы ли любые дальнейшие шаги. Запустите сеанс Performance Monitor и добавьте следующие счетчики:

    Memory I Free System Page Table Entries
    Этот счетчик показывает число свободных системных PTE. Он не показывает биты или байты,а именно число PTE. При первой загрузке сервера это число достаточно высоко, порядка 40 000, 80 000 или 160 000. Когда это число опускается ниже 3 000, у вас начинаются неприятности.

    Memory I Paged Pool Bytes
    Этот счетчик показывает полный размер в байтах перемещаемого пула. Вы также можете добавить счетчик Taged Pool Resident Bytes, который показывает, какая часть этого пула находится в использовании. Однако, он нам не очень нужен, потому что мы знаем, что размер перемещаемого пула увеличивается по мере заполнения. Для данного испытания нам не нужно заботиться о том, насколько он заполнен. Нам надо знать, наколько он велик.

    Вы также можете проследить еще один счетчик, который отображает компонент, который мы еще не обсудили: System File Cache (Кэш системных файлов). Это область памяти, в которой хранятся открытые в настоящий момент файлы. Аналогично PTE и перемещаемому пулу, кэш системных файлов требует пространства в области памяти ядра 2GB.

    Если перемещаемый пул начинает исчерпывать пространство (когда достигает 80%, по умолчанию), система автоматически отберет часть памяти от кэша системных файлов и предоставит ее перемещаемому пулу. Это уменьшит размер кэша системных файлов. Однако, кэш является критическим и никогда не достигнет нуля. Система будет делать компромисс и будет пытаться расширить перемещаемый пул в максимально возможной степени. Вы можете смотреть использование кэша системных файлов с помощью следующего счетчика:

    Cache I Copy Read Hits %
    Этот счетчик прослеживает процент запросов к кэшу системных файлов, которые фактически найдены в кэше. Для приличной производительности это число должно оставаться между 99 и 100%. Помните, что если на вашем сервере начинает исчерпываться пространство перемещаемого пула, он "заимствует" память из кэша системных файлов. Когда это происходит, вы увидите уменьшение значений Copy Read Hits %.

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

    • Вы исчерпаете PTE.
    • Cache Hit % последовательно будет падать ниже 99 %

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

    С другой стороны, если Cache Hit % последовательно понижается ниже 99%, то вы должны увеличить размер вашего перемещаемого пула (который уменьшит число PTE).

    Если вы продолжаете добавлять пользователей, и PTE не заканчиваются и Cache Hit % не падает ниже 99 %, то вернитесь и перечитайте эту статью, потому что настройка памяти ядера к вам не относится.

    Если ваш сервер исчерпывает PTE и Cache Hit % падает ниже 99% в одно и то же время, то примите поздравления! Вы отлично настроили использование памяти ядра и достигли максимального предела числа пользователей, которое вы можете поддерживать. Возьмите число пользователей, которые были на сервере во время этих двух событий, вычтите из него два или три, и скажите своему боссу, что вы нашли архитектурный предел терминального сервера Windows 2000 в вашей среде. Если вы хотите поддерживать больше пользователей, то перейдите на Windows Server 2003 или примените один из инструментов оптимизации третьего производителя.

    Настройка использования памяти ядра в Windows 2000

    Размеры перемещаемого пула и системных PTE конфигурируются через системный реестр. Ключ для PTE:

    HKLM\System\CurrentControlSet\Control\Session Manager\Memory Management\SystemPages

    Это значение системного реестра позволяет Вам (в некоторой степени) управлять числом системных PTE, которые создаются во время загрузки Windows. Значение 0 позволяет системе создавать столько, сколько нужно, а значение 0xFFFFFFFF говорит системе, что нужно создать максимально возможное число PTE. (Однако, в Terminal Services, работающими в режиме сервера приложений, система в любом случае будет создавать столько, сколько сможет). Значение где-нибудь между этими двумя заставит систему создавать указанное число PTE, хотя система на самом деле резервирует за собой право поступать по своему усмотрению, если вы ввели экстремальное значение.

    HKLM\System\CurrentControlSet\Control\Session Manager\Memory Management\PagedPoolSize

    Значение PagedPoolSize определяет размер перемещаемого пула. Значение 0 позволит Windows автоматически выбрать оптимальный размер, а значение 0xFFFFFFFF укажет Windows максимизировать размер перемещаемого пула (ценой возможности раширить другие области, включая системные PTE). Шестнадцатеричное значение между ними дает Windows идею относительно того, какой размер пула вы хотите иметь, хотя (как с PTE) Windows резервирует за собой право игнорировать вашу установку. Если вы ограничиваете перемещаемый пул в 192 МБ или меньше (0x0C000000), Windows сможет использовать дополнительное пространство для другого (например, для системных PTE).

    Большинство систем никогда позволят перемещаемому пулу превысить около 500 МБ. Есть еще одно значение системного реестра, которое вы должны понять:

    HKLM\System\CurrentControlSet\Control\Session Manager\Memory Management\PagedPoolMax

    Значение PagedPoolMax определяет максимальный процент перемещаемого пула, который должен заполниться прежде, чем система начинает захватывать пространство кэша системных файлов. Значение по умолчанию 0 заставляет систему востребовать пространство кэша системных файлов, когда перемещаемый пул заполнен на 80%. Если вы хотите, чтобы система ждала заполнения пула до 90%, то установите здесь десятичное число 90. Если вы хотите, чтобы система захватывала память кэша при 40%-м заполнении пула, установите значение 40 (десятичное число).

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

    С более поздними сервисными пакетами (SP3 и позже), Windows 2000 Server, выполняющая терминальные службы в режиме сервера приложений, будет автоматически пытаться установить максимальное число создаваемых PTE. Если Performance Monitor показывает, что система исчерпывает системные PTE, вы можете попробовать установить значение SystemPages в 0xFFFFFFFF, но вряд ли от этого будет какой-то прок.

    С другой стороны, если Performance Monitor показывает, что вы исчерпываете пространство перемещаемого пула, то вы можете установить значение PagedPoolSize, чтобы увеличить размер пула. Для этого смотрите значения счетчиков Pool Paged Bytes и Free System PTEs как только Copy Read Hits % упадет ниже 99%.

    Если вы в этом месте видите менее 3000 свободных системных PTE, то забудьте про это - вы ничего не можете сделать (кроме перехода на Windows Server 2003). Если у вас больше 3000 свободных системных PTE, то вы можете попробовать максимизировать размер перемещаемого пула, установив значение реестра PagedPoolSize в 0xFFFFFFFF. Перезагрузите сервер и снова выполните тест, чтобы видеть, улучшилась ли ситуация.

    Риск состоит в том, что оптимальные размеры PTE и перемещаемого пула находятся где-то в посередине от максимума одного или другого. Единственный избежать его состоит в использовании отладчик ядера для определения текущего размера перемещаемого пула. Команды для отладки ядра содержатся в следующем разделе этого документа. Использование отладчика в среде Windows 2000 аналогично использованию его в Windows 2003. Единственное основное различие состоит в том, что Windows 2000 не позволяет локальную отладку. Поэтому вы должны найти ноутбук с последовательным портом и подключить его к терминальному серверу (подоробные инструкции для этого содержатся в документации к отладчику)

    Оценка проблем использования памяти ядра в Windows 2003

    Общие концепции, выделенные в предыдущем разделе о Windows 2000, также относятся к Windows 2003. (Вы должны быстро прочитать тот раздел, даже если имеете только серверы Windows 2003). Однако, есть несколько архитектурных изменений, относящихся к управлению памятью, которые сделают вашу жизнь намного проще при использовании Windows Server 2003.

    Во-первых, число системных PTE в Windows Server 2003 увеличено до максимума около 1.3GB. Это вдвое больше, чем было в Windows 2000.

    Ваш сервер Windows 2003 будет автоматически использовать максимальное число PTE в следующих случаях:

    • Вы загружаете сервер без опции /3GB. (Подробнее об этом позже)
    • Вы не установили значения ключей реестра, которые позволяют использовать эту RAM для системного кэша (поскольку будет использоваться для системных PTE)
    • Вы не установили значения ключей реестра, которые делают размер пространства сеанса или отображенного вида системы больше, чем задано по умолчанию (48 МБ).

    Кроме того, расширенное управление памятью Windows Server 2003 заставляют существенно меньше использовать перемещаемый пул.

    Если вы чувствуете нехватку PTE или перемещаемого пула на Windows Server 2003 Terminal Server, вы можете легко это проверить. Вместо того, чтобы использовать Performance Monitor, вы можете получить намного более точный снимок использования памяти ядера с помощью отладчика ядра.

    Само понятие отладчика ядра, вероятно, вызывает в воображении кошмары о хост-машинах, последовательных кабелях и прочих вещах, с которыми имеют дело разработчики и о которых вы даже не думали. К счастью, времена изменились.

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

    Первым делом вы должны загрузить Debugging Tools for Windows с сайта http://www.microsoft.com/whdc/ddk/debugging/

    Сделайте это и установите их на терминальном сервере, который вы тестируете. При установке достаточно выбрать опции по умолчанию. После этого запустите отладчик (Start | All Programs | Debugging Tools for Windows | WinDbg).

    Затем вы должны установить сеанс отладки ядра на локальным компьютере.

    1. Выберите File | Kernel Debug...
    2. Выберите вкладку "Local".
    3. Щелкните "OK".

    Теперь, прежде чем вы сможете эффективно использовать отладчик, вы должны указать ему, где находятся файлы символов. Файлы символов - это файлы с расширением .SDB, которые сообщают отладчику, как интерпретировать всю информацию, которая поступает из системы. Без файлов символов отладчик бесполезен.

    Информация о том, как получить файлы символов, находится на сайте Microsoft Debugging Tools for Windows. На время написания этой статьи существует два способа получения файлов символов для Windows Debugger.

    • Вы может загрузить файлы символов на ваш жесткий диск (или скопировать их с компакт-диска Windows Server 2003). Тогда вы настраиваете отладчик так, чтобы он знал, где их искать.
    • Вы можете использовать новый Microsoft "Symbol Server", который позволяет отладчику автоматически и динамически загружать требуемые файлы символов с веб-узла Microsoft.

    Использование сервера символов - самая простая опция, и вы должны использовать, если только ваш терминальный сервер не имеет прямого соединения с интернет. Настройка отладчика на использование сервера символов очень проста::

    1. Выберите в отладчике File | Symbol Path File.
    2. Введите в этом поле следующее:

      SRV*c:\websymbols*http://msdl.microsoft.com/download/symbols

      ("c:\websymbols" можно изменить на подходящий путь в вашей среде)
       
    3. Проверьте флажок "Reload".
    4. Щелкните "OK".

    Теперь вы готовы начать отладку. Сделайте так, чтобы ваши пользователи зарегистрировались в системе. После того, как ваша система начнет замедляться, введите в поле "lkd> " внизу отладчка следующую команду:

     ! vm 1

    Это сделает снимок виртуальной памяти ядра (2GB область памяти), что должно выглядеть подобно этому:

     lkd> !vm 1
       *** Virtual Memory Usage ***
       Physical Memory: 130908 ( 523632 Kb)
       Page File: \??\C:\pagefile.sys
          Current:    786432Kb Free Space:   767788Kb
          Minimum:    786432Kb Maximum:     1572864Kb
       Available Pages:     45979   ( 183916 Kb)
       ResAvail Pages:      93692   ( 374768 Kb)
       Locked IO Pages:        95   (    380 Kb)
       Free System PTEs:   245121   ( 980484 Kb)
       Free NP PTEs:        28495   ( 113980 Kb)
       Free Special NP:         0   (      0 Kb)
       Modified Pages:        135   (    540 Kb)
       Modified PF Pages:     134   (    536 Kb)
       NonPagedPool Usage:   2309   (   9236 Kb)
       NonPagedPool Max:    32768   ( 131072 Kb)
       PagedPool 0 Usage:    4172   (  16688 Kb)
       PagedPool 1 Usage:    1663   (   6652 Kb)
       PagedPool 2 Usage:    1609   (   6436 Kb)
       PagedPool Usage:      7444   (  29776 Kb)
       PagedPool Maximum:   43008   ( 172032 Kb)
       Shared Commit:        1150   (   4600 Kb)
       Special Pool:            0   (      0 Kb)
       Shared Process:       2939   (  11756 Kb)
       PagedPool Commit:     7444   (  29776 Kb)
       Driver Commit:        2219   (   8876 Kb)
       Committed pages:     63588   ( 254352 Kb)
       Commit limit:       320147   (1280588 Kb)

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

    • Free System PTEs
    • PagedPool Usage
    • PagedPool Maximum


    Если число PTE действительно низкое, вы должны попробовать его увеличить. Если использование перемещаемого пула достигает максимума, то вам следует его увеличить. Если не наблюдается ни того, ни другого, то добавьте еще несколько пользователей в систему и выполните команду отладчика "! vm 1" еще раз.

    Чтобы увеличить PTE, измените значение системного реестра SystemPages на 0xFFFFFFFF. Перезагрузите сервер и повторите тест. Честно говоря, это скорее всего ничего не изменит, поскольку начиная с Windows 2003 терминальный сервер пробует максимизировать число PTE. Однако, установка вручную этого значения все еще имеет смысл, посколько это сделает максимизизацию PTEs приоритетом для системы.

    Если использование перемещаемого пула находится в пределах нескольких процентов от максимума, то вы захотите увеличить максимальный размер. Однако, вы можете это сделать только если имеете много доступных системных PTE. (Не менее 3000).

    Каждый PTE имеет размер 4 КБ. Для каждого PTE, который вы можете себе позволить потерять, вы можете добавить 4 КБ к размеру вашего перемещаемого пула. Если вы имеете 10 000 свободных системных PTE, то вероятно можете позволить себе потерять 7000 (оставив 3000). Если вы имеете 14 000 свободных, то можете отдать 11 000.

    Возьмите столько PTE, сколько можете себе позволить отобрать и умножьте это число на 4. Затем прибавьте полученное число к PagedPool Maximum (максимальный размер пула), как показано в отладчике. (Убедитесь, что добавили это к крайнему правому значению). Это число будет размером вашего пула. Откройте редактор системного реестра и установите ваше значение в следующем месте:

    HKLM\System\CurrentControlSet\Control\Session Manager\Memory Management\PagedPoolSize

    Это место системного реестра хранит значение в байтах, а не в килобайтах. Поэтому умножьте ваше расчетное значение на 1024, чтобы получить число, которое вы должны здесь ввести. При вводе значения убедитесь, что вводите его в десятичном формате. Редактор системного реестра автоматически преобразует его в шестнадцатеричный формат.

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

    Понимание переключателей в BOOT.INI

    Хотя мы еще обсуждаем тему использования памяти ядра, нам следует взять небольшой перерыв и обратиться к опциям файла boot.ini, которые могут использоваться в среде терминального сервера. Если вы поищете в интернет на тему производительности терминальных серверов, то натолкнетесь на различные теории о том, как эти опции должны использоваться. Давайте разоблачим эти теории и посмотрим, как эти опции работают на самом деле.

    Есть две опции в boot.ini, с которыми вы должны быть знакомы: /3GB и /PAE.

    Опция / 3GB

    Как вы помните, 32-разрядные системы Windows могут адресовать 4GB памяти, и эта память разбита на две части по 2GB, одна для ядра и вторая для каждого процесса. Добавление опции "/3GB" в boot.ini изменяет способ, которым сервер распределяет пространство памяти 4GB. Вместо двух частей по 2GB, опция "/3GB" изменяют распределение так, что ядру достается 1GB, а каждому процессу - 3GB.

    Это полезно для требовательных к памяти приложений типа Microsoft Exchange или SQL Server. Однако, как вы знаете, терминальные серверы имеют достаточно неприятностей с ядром Windows вследствие того, что оно по умолчанию ограничено 2GB, и, как вы можете понять, ограничивая ядро до 1GB будет иметь плачевные последствия последствия в среде терминального сервера. (Более того, чтобы использовать все 3GB, приложение должно быть откомпилировано особым способом, поэтому опция "/3GB" все равно не затрагивает "обычные" приложения)

    Если ваш терминальный сервер загружается через boot.ini с опцией /3GB, немедленно удалите ее.

    Опция / PAE

    Опция PAE (Расширение физических адресов) в boot.ini используется в том случае, когда терминальные серверы имеют более 4GB физической памяти. Так как 32-разрядная операционная система Windows может адресовать только 4GB виртуальной памяти, то системы с более чем 4GB должны использовать трюки, чтобы адресовать физическую память выше 4GB. Эти трюки включатся добавлением опции "/PAE" в файл boot.ini. Если на вашем сервере более 4GB оперативной памяти, то убедитесь, что в файле boot.ini присутствует опция "/PAE". (Для использования более 4GB памяти вам необходим Windows 2000 Advanced Server или выше, или Windows 2003 Enterprise Edition или выше)

    Использование Системного реестра

    Если ваш терминальный сервер выполняется на платформе Windows 2000, то возможно, что вы не можете поддерживать больше пользователей по той причине, что исчерпали пространство в системном реестре. Реестр должен загрузить улей HKU для каждого отдельного пользователя, который выполняет сеанс на сервере. К счастью, проверка размера вашего реестра очень проста с использованием Performance Monitor. Все, что вы должны сделать - ээто загрузить следующий счетчик:

    System I % Registry Quota in Use
    Этот счетчик сообщает процент от максимального размера реестра сервера, который находится в использовании. Если этот счетчик указывает, что размер реестра приближается к его максимальному размеру, то вы можете способны поддерживать больше пользователей на сервере, настроив его так, чтобы он позволял больший реестр.

    Однако, есть потенциальные последствия этого действия. На терминальных серверах Windows 2000 файлы всего системного реестра хранятся в перемещаемом пуле ядра. Это создает двойную проблему:

    • Это означает, что максимальный размер системного реестра составляет около 160 МБ.
    • Увеличение размера системного реестра уменьшает объем перемещаемого пула, доступного для других процессов ядера, потенциально заставляя перемещаемый пул стать вашим узким местом.

    Если вы действительно должны корректировать размер системного реестра Windows 2000, вы можете сделать это через панель управления. (Control Panel | System | вкладка Advanced | кнопка "Performance Options" | кнопка "Change..." | поле "Maximum Registry Size")

    Если ваши терминальные серверы выполняются на платформе Windows Server 2003, то вам не о чем беспокоиться. Windows 2003 не хранит системный реестр в перемещаемом пуле, что означает отсуствие пределов размера реестра. Поэтому в Windows 2003 отстутствует настройка размеров реестра. Системный реестр потребляет лишь 4 МБ пространства перемещаемого пула, независимо от того, насколько большой он на самом деле.

    Устранение проблем с непостоянными всплесками, паузами и зависаниями

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

    Непостоянные проблемы обычно относятся к двум категориям:

    • Приложение или процесс на короткое время нагружает процессор на 100%, а затем возвращается в нормальное состояние. В течении этого времени сеансы пользователей обычно не откликаются.
       
    • Сервер необычно себя ведет в течение нескольких секунд. Иногда все затормаживается, даже Performance Monitor. Затем через несколько секунд (иногда 20-30 секунд) график производительности вовзращается в старое состояние. Однако, в этот период все счетчики производительности показывают нули или никаких данных.

    Лучший план решения таких проблем следующий:

    1. Поищите вашу проблему в интернете .
    2. Примените сервисные пакеты, заплаты и/или обновленные драйверы устройств.
    3. Используйте Performance Monitor для выявления аномалий.

    Шаг 1. Ищите вашу проблему в интернете

    Решения переменчивых проблем далеко не всегда интуитивно, поэтому стоит потратить десять или пятнадцать минут в Интернете, чтобы получить понимание вашей проблемы.

    Например, Windows Server 2003 выпущена в апреле 2003. В июле вышла, статья Microsoft Q821467 "Windows Server 2003 Terminal Server Stops Responding." В этой статье говорится, что проблема проявляется только на серверах Windows 2003, и что доступна от заплата Microsoft. Зачем беспокоиться о поиске решения проблемы, если кто-то уже ее решил?

    Вот список сайтов, которые я использую в поиске:

    1. Группы Google (groups.google.com). Ищите там группы новостей Microsoft. Часто полезная информация появляется там раньше, чем публикуется в базе знаний на сайте Microsoft.
       
    2. Microsoft Knowledge Base (www.microsoft.com/support).
       
    3. Список рассылки THIN (www.thethin.net). Инструмент поиска в архиве на основном узле THIN довольно неуклюжий, поэтому вы можете делать поиск в архиве через их провайдера listserv (www.freelists.org/archives/thin)
       
    4. База знаний Citrix (http://support.citrix.com/kb). Механизм поиска никогда, как мне кажется, не находит того, чего я ищу, но этот сайт необходим для поиска заплат Citrix.

    Шаг 2. Сервисные пакеты, заплаты и драйверы

    Большинство непостоянных проблем к настоящему времени уже исправлены. Сделайте быстрый поиск на сайте Microsoft Knowledge Base по ключевым словам "server stops responding", и вы найдете, что 90% решений предлагают установить последний сервисный пакет или заплату.

    Это серьезно. Например, Service Pack 2 for Windows 2000 устраняет проблему с блокировкой кэша реестра. Эта проблема обычно возникает на загруженных терминальных серверах и вызывает приостановку всей системы, если требуется запись в реестр в то время, когда Windows делает его резервную копию (она делает это периодически). Применение Service Pack 2 или более нового полностью устраняет проблему.

    Однако, вы также должны быть осторожны при обновлении промышленных серверов. Когда в августе 2003 вышел Service Pack 4 для Windows 2000, он поломал массу терминальных серверов. Проверьте веб-ресурсы, перечисленные в Шаге 1, чтобы удостовериться, что применение заплаты или сервисного пакета безопасно. Кроме того, сначала примените исправление к испытательному серверу, перед тем как применените его к промышленному серверу.

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

    Шаг 3. Запуск оснастки Performance Monitor в MMC

    Если поиск в интернет и латание сервера не устранили ваши непостоянные проблемы, вы должны продолжить расследование самостоятельно. Для этого используйте Performance Monitor. Если вы все еще имеете проблему, то должны заметить какую-нибудь активность в момент ее возникновения.

    Добавьте счетчики для ваших процессоров (Processor | % Processor Time). Лучше добавлять по одному счетчику для каждого процессора вместо "_Total", т.к. это позволит вам легче отследить, забивает ли процессор единичный процесс.

    Если ваша проблема чрезвычайно неустойчива, помните, что вы можете настроить предупреждение. Тогда вы можете сделать так, чтобы предупреждение запускало запись данных производительности в журнал. Единственная проблема состоит в том, что вы должны настроить предупреждение на частую проверку, возможно, каждые несколько секунд. Будьте внимательными, чтобы не создать ситуацию "уловки 22", когда ваши сложные схемы мониторинга, записи и предупреждения еще больше обременят сервер.

    Самая идеальная ситуация - наблюдать проблему вживую. (Вы можете настроить Performance Monitor на удаленном компьютере, чтобы следить за вашим терминальным сервером).

    Ищите приложения, которые занимают 100% процессора

    Это очевидно, но вы должны посмотреть, что на самом деле происходит во время замедления системы. Всплеск использования центрального процессора? Если так, то есть несколько различных подходов, которые вы можете предпринять. Прежде всего, пробуйте определить то, что вызывает всплеск. Загружается чей-то перемещаемый профиль? Происходит подключение сразу нескольких пользователей? В некоторых случаях вы можете столкнуться с приложением или процессом, который вызывает слишком большое использование процессора.

    Действия в случае рьяных приложений

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

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

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

    Ищите периоды, когда все обнуляется

    Надеюсь, вы поискали в интернете, пропатчили ваш сервер, обновили драйверы. Однако, если все равно ощущаете спорадические проблемы с производительностью, есть еще несколько вещей, которые можно попробовать.

    В некоторых случаях вы можете обратить внимание, что все счетчики Performance Monitor на несколько секунд исчезают и наступает пауза. Когда система оживает, Performance Monitor идет дальше, оставив в том месте, где была пауза, нули.

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

    Как с предыдущими проблемами, вы должны проанализировать все, что происходит на вашем сервере. Терминальные серверы одной компании достигали максимума при 25 пользователях, даже при том, что Performance Monitor не показывал никаких проблем. Позже было обнаружено, проблема возникала из-за того, что использовалось переназначение папки "Application Data" на диск удаленного домашнего компьютера. Из-за переназначения этой критической папки пользователя сервер замедлялся каждый раз, когда пользователь обращался к данным, находящися в этой папке (весьма частая ситуация). Пошаговое исследование производительности заставило рассматривать все, что происходило на сервере, и в конечном счете к эксперименту с отключением переназначения папок. Таким образом проблема была изолирована.

    Общая вялость и недостаток живого отклика

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

    Понимание факторов, влияющих на производительность сети

    Рассматривая производительности сети, вы должны понять разницу между "задержкой" (latency) и "полосой пропускания" (bandwith). Оба эти термина используются для описания скорости сети. Полоса пропускания означает, сколько данных могут пройти через сеть в данный промежуток времени, например, 10 мегабит в секунду или 256 килобит в секунду. Задержка означает период времени, обычно выражаемый в миллисекундах, который требуется для данных, чтобы дойти из пункта А в пункт Б. Полоса пропускания и задержка не связаны друг с другом.

    Факт, что полоса пропускания и задержка отличаются от друг друга, является важной концепцией в среде терминального сервера. (Это настолько важно, что напрашивается другая аналогия).

    Представим себе, что каждый пакет данных - это автомобиль, а сеть - дорога. Чтобы данные прошли из пункта А в пункт Б, автомобиль должен проехать с одного конца дороги в другой. В средах с высокой полосой пропускания мы имеем многоплосное шоссе, по которому могут ехать одновременно сотни автомобилей . В средах с небольшой полосой пропускания мы имеем дело с узкой проселочной дорогой, по которой одновременно могут ехать лишь несколько автомобилей. Ширина дороги аналогична полосе пропускания сети. Если задержка влияет на то, как долго требуется данным, чтобы пройти по сети, то ее можно представить как скорость автомобилей на дороге. Даже на узких дорогах (низкая полоса пропускания) могут быть водители, которые ездят быстро (низкая задержка). Наоборот, даже если вы имеете большое число автомобилей на широком шоссе (высокая полоса пропускания), водители могут ехать медленно (высокая задержка).

    Полоса пропускания и задержка независимы друг от друга, поскольку ширина дороги непосредственно не влияет на то, как быстро вы едите по ней. Однако, как вы можете предположить, полоса пропускания может влиять на задержку.

    Теперь представьте себе среду с низкой полосой пропускания, которая также имеет низкую зарежку (узкая дорога, по которой быстро ездят). Если на дороге мало машин, они могут ехать быстро без проблем. Однако, представьте, что дорога начинает заполняться автомобилями все больше и больше. Даже если водители хотят быстро ехать, они не могут, потому что дорога переполнена. В результате потребуется больше времени, чтобы добраться из одного конца дороги до другого. В некотором смысле, задержка увеличивается просто потому, что на дороге появилось больше машин.

    Есть несколько решений проблемы переполненной дороги. Вы можете:

    • Расширить дорогу.
    • Убрать часть транспортных средств.
    • Принудить водителей пересесть на меньшие транспортные средства.
    • Установить сигнализаторы траффика и устройства управления маршрутами для управления трафиком.

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

    Вернемся в реальный мир. Полоса пропускания сетевого соединения и время ожидания затрагивают траффик сеансов RDP или ICA различными способами:

    • Полоса пропускания влияет на то, сколько данных может содержать сеанс. Сеансы с высоким разрешением требуют большей полосы пропускания, чем сеансы с низким разрешением. Сеансы со звуком, печатью и отображением клиентских дисков требуют большей полосы пропускания, чем сеансы без них. Если некоторый сеанс только имеет 15Kbps доступной полосы пропускания, он все еще будет иметь приличную производительность, если соответственно настроены разрешение, разрядность цвета и другие виртуальные каналы.
       
    • Задержка является обычно более критическим параметром в среде терминального сервера. Так как задержка влияет на время, требуемое для прохождения данных между клиентом и сервером, в средах с высокой задержкой пользователи будут ощущать некомфортные паузы.

    Например, представьте среду, в которой пользователь использует Microsoft Word через удаленный сеанс RDP. Когда он нажимают клавишу на своем клиентском устройстве, код клавиши посылается через сеть на терминальный сервер. Сервер обрабатывает нажатие клавиши и готовит отобразить надлежащий символ на экране.

    Поскольку это терминальный сервер, экранная информация передается назад через сеть, после чего отображается на локальном клиентском устройстве. Чтобы символ появился на экране, данные должны пройти от клиента на сервер, а затем обратно от сервера клиенту.

    В этой ситуации, если задержка в сети составляет 10 мс, пауза составит 20 мс (потому что данные проходят по сети дважды) между нажатием клавиши и отображением символа на экране пользователя. Поскольку 20 мс - это всего 0.02 секунды, пауза не будет замечена. Однако, если бы задержка составила 200 мс, то общая пауза составила бы 400 мс, или почти половину секунды. Эта пауза уже будет заметна пользователю и, вероятно, будет недопустима.

    Простой способ оценить задержку в вашей среде состоит запуске утилиты ping. Вы можете прозвонить сервер от клиента или клиента от сервера - это не имеет значения. Например, если ваш сервер называтся "server01", вы можете с клиентской рабочей станции выполнить следующую команду :

     ping server01

    (Убедитесь, что вы запускаете ping локально, а не из сеанса RDP или ICA на сервере.). Результаты будут выглядеть приблизительно так:

       Pinging server01 [10.1.1.42] with 32 bytes of data:
       Reply from 10.1.1.42: bytes=32 time=378ms TTL=118
       Reply from 10.1.1.42: bytes=32 time=370ms TTL=118
       Reply from 10.1.1.42: bytes=32 time=360ms TTL=118
       Reply from 10.1.1.42: bytes=32 time=351ms TTL=118
       Ping statistics for 10.1.1.42:
       Packets: Sent = 4, Received = 4, Lost = 0
       Approximate round trip times in milli-seconds:
       Minimum = 351ms, Maximum = 378ms, Average = 364ms 

    Обратите внимание, что раздел "time = " каждой строки показывает приблизительную задержку. Это время, которое пингующий ожидал ответа от другой стороны. В нашем примере задержка составляет 364 мс, что возможно как при модемном соединении с полосой пропускания 28kbps, так и по выделенному каналу 512kbps. В любом случае, производительность будет не столь хороша, как в среде с меньшей задержкой.

    Решение проблем с полосой пропускания

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

    • Установите аппаратное устройство для контроля и управления приложениями и полосой пропускания. Это аналогично добавлению ГИБДД и светофоров на шоссе.
    • Посмотрите, какой трафик вы можете убрать из сети. Это аналогично уменьшению количества машин на дороге..
    • Сделайте сеансы ICA или RDP по возможности "меньше". Это аналогично убеждению водителей пересесть на небольшие машины.

    Давайте посмотрим, как можно осуществить каждое из этих трех решений.

    Аппаратные ограничители полосы пропускания
    Два самых популярных типа устройств управления полосой пропускания в терминальных средах - PacketShaper (www.packeteer.com) и Sitara QoSWorks (www.sitaranetworks.com). Оба из них являются аппаратными устройствами, которые ставятся между вашей сетью и маршрутизатором глобальной сети.

    Эти устройства позволяют анализировать и захватывать текущее использование трафика (вы можете обнаружить, что 75% вашего трафика WAN приходится на web-навигацию). Тогда вы можете дать траффику ICA или RDP более высокий приоритет над другими типами трафика. Вы даже можете конфигурировать эти устройства так, чтобы дать разные приоритеты разным адресам IP. Вы можете также гарантировать некоторое количество полосы пропускания для ICA или RDP (или любого протокола).

    Эти устройства подобны устройствам Cisco Quality of Service (QoS), за исключением того, что устройства Sitara и Packeteer являются маршрутизаторами "Уровня 7" и могут дифференцировать трфик ICA и RDP от других типов трафика.

    Удаление ненужного трафика

    Одной из самых простых вещей, которые вы можете сделать для освобождения полосы пропускания для ваших сеансов ICA или RDP, состоит в удалении нетерминального трафика. Вы копируете данные через сеть? Ваши пользователи загружают MP3? Все это отбирает полосу пропускания от ваших протоколов ICA и RDP.

    Сжатие ICA и RDP

    Удалив ненужный трафик из вашей сети, вы можете начать думать об ужимании протоколов ICA и RDP. Для этого есть несколько способов:

    1. Во-первых, отключите всякие "украшения" рабочего стола. Отключите обои, анимацию меню и темы рабочего стола.
    2. Затем отключите виртуальные каналы RDP или ICA , которые вы не используете, например, печать или отображение локальных дисков.
    3. Вы должны также сконфигурировать сеансы пользователей так, чтобы они использовали минимально требуемые параметры настройки, например, самое низкое разрешение и число цветов.
    4. Если вы еще этого не сделали, убедитесь, что на ваших терминальных серверах установлены самые последние версии сервисных пакетов и заплат. Например, SP3/FR3 для MetaFrame XP совместно с клиентами ICA версии 7 дают существенное увеличение скорости.

    Каждый из этих шагов поможет уменьшить размер и сетевое использование индивидуального пользователя

    Решение проблем с задержкой

    Если вы решили, что ваши проблемы производительности сети происходят из-за высокой задержки (latency), то также есть способы, которые могут улучшить производительность:

    Если вы используете Citrix MetaFrame, включите технологию "SpeedScreen". Эта технология использует различные виды кэширования и методы генерации символов, которые заставляют пользовательские сеансы казаться быстрее в сетях с большими задержками.

    Если у вас высокая задержка, не забудьте (как показано в нашем примере дорожного трафика), что освобождение некоторой полосы пропускания может также иметь положительный эффект.

    Заключение и завершающие мысли

    Я надеюсь, что после чтения этой статьи вы будете способны увеличить производительность ваших терминальных серверов. Имейте в виду, что настройка производительности - это всегда искусство, и никакой сервер не является совершенным. Вы просто играете в игру, двигаясь от одного узкого места к другому, и в конечном счете доходите до точки, когда чувствуете, что "все хорошо".

    Я планирую постоянно пересматривать и изменять этот документ, и вы всегда можете найти самую последнюю версию на сайте www.brianmadden.com. Не стесняйтесь посылать мне по электронной почте любые комментарии на адрес brian@brianmadden.com.

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

    • Citrix MetaFrame XP, Advanced Technical Design Guide. by Brian Madden, published November
      2002. BrianMadden.com Publishing Group, ISBN 0971151040
       
    • Terminal Services for Microsoft Windows Server 2003, Advanced Technical Design Guide, by Brian
      Madden and Ron Oglesby, due out in January 2004. BrianMadden.com Publishing Group,
      ISBN 0971151040.

    Ссылки

    Большинство методов, процессов и подходов, описанных в этой статье, основаны на моем собственном опыте и методиках консультанта. Однако, я сделал небольшое исследование некоторых слабо освещенных областей производительности терминальных серверов. При написании этой статьи, я использовал следующие материалы из Internet:

    Citrix MetaFrame XP, Advanced Technical Design Guide, Brian Madden, BrianMadden.com Publishing Group, November 2002.

    Citrix MetaFrame XP Presentation Server with Feature Release 3 on HP ProLiant Servers, HP ActiveAnswers White Paper, August 6, 2003. activeanswers.compaq.com.

    How to Configure the Paged Address Pool and System Page Table Entry Memory Areas, Microsoft Knowledge Base Article 247904.

    HOWTO: Map Adapter RAM into Process Address Space, Microsoft Knowledge Base Article 189327.

    Large Memory Support Is Available in Windows 2000 and Windows Server 2003, Microsoft Knowledge Base Article 283037.

    Microsoft Windows Server 2003 Terminal Server Capacity and Scaling, HP ActiveAnswers White Paper, April 24, 2003. activeanswers.compaq.com.

    Should you enable Hyper-Threading on Server 2003?, June 25, 2003, Tim Mangan, TMurgent Technologies, http://www.tmurgent.com/images/WP_HyperThread.pdf.

    Windows Server 2003 Driver Development Kit Documentation, Microsoft Corporation. Windows 2000 Internals, Dr Robert Capener, Weber State University.

    icarus.weber.edu/home/bob/cs3100/lectures/win2k_lectures/Win2KMemoryManagement.pdf

    Windows 2000 Terminal Services Performance Guide, UNISYS e-@ction Enterprise Application Delivery Solutions, November 2000.

    Windows NT Virtual Memory (Part II), The NT Insider, Vol 6, Issue 1, Jan-Feb 1999. http://www.osronline.com/article.cfm?id=60.

      Ресурсы

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

      BrianMadden.com
      Это мой персональный сайт, на котором много статей (вроде этой), книг, обзоров программ, обучабщих видео, новостей, интервью и пр.

      dabcc.com
      Сайт Дуга Брауна (Инженера Citrix Systems). Поскольку Дуг работает в Citrix, это первое место для (неофициальных) новостей о продуктах Citrix и заплатах.

      ServerGeek.net
      Этот сайт посвящен технологиям серверных вычислений. На сайте содержится много лакомых кусочков новостей и информации.

      TMUrgent.com
      Это сайт компании Тима Мангана. Помимо некоторых интересных инструментов и утилит, сайт Тима является одним из лучших сайтов для действительно технического глубокого исследования внутренностей Windows Terminal Services. Его сайт был источником всей информации о HyperThreading в этой статье.

      Tokeshi.com
      Этот всесторонний сайт поддержки, относящийся к серверным вычислениям. Tokeshi.com содержит тонны информации о сервисных пакетах и заплатах (от Citrix и Microsoft) и и их влияние на среду терминального сервера.

      theThin.net
      THIN Net - самый старый сайт о тонком клиенте в Интернете, на котором поддерживается бесславный список рассылки THIN listserv. Сайт содержит тонны информации для администраторов Citrix и Terminal Server, включая полезные инструменты, утилиты и шаблоны.

      TweakCitrix.com
      Этот сайт Рика Дехлинджера, системного инженера Citrix. Он известен по документу "MetaFrame XP Tuning Tips & Tricks." В этом документе описаны всяческие ухищрения, которые вы можете применить к вашим серверам MetaFrame XP.

      источник: 1th.ru

       

      Вы можете задать вопрос по статье специалисту.

      Получите квалифицированное обслуживание и качественную поддержку от наших специалистов.

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