11.4.10. Счетчики для анализа производительности сетевой подсистемы

Анализ загрузки сети, Всего байт/сек (Bytes total/sec), применение Сетевого монитора (Network Monitor)

Последняя физическая подсистема сервера, мониторинг которой имеет смысл производить, — сетевая подсистема. Как правило, пользователи подключаются к SQL Server по сети.

Обычно какие-то проблемы с производительностью работы сети, вызванные именно работой SQL Server, возникают редко. Как правило, сеть намного активнее загружается другими приложениями (например, приложениями на основе настольных баз данных — FoxPro, Access, Clipper, Paradox и т. п.).

На предприятиях часто встречаются ситуации, когда за работу сети отвечает один человек (или подразделение), а за работу приложения, использующего SQL Server, — другой. И договориться им часто бывает сложно. Рассмотрим возможности мониторинга загруженности сети с точки зрения администратора SQL Server.

Проблемы с производительностью работы сети могут встретиться в двух вариантах. Первый вариант — не хватает производительности конкретного сетевого адаптера, установленного на сервере. Чтобы проверить это, можно воспользоваться счетчиком Всего байт/сек (Bytes total/sec) для объекта Сетевой интерфейс (Network Interface) (выбрав нужный сетевой интерфейс из списка). Значение этого счетчика предлагается сравнивать с паспортным значением для данного сетевого интерфейса. Если сетевой интерфейс действительно работает на пределе своих возможностей, то его можно заменить на специальный серверный мультипортовый адаптер.

Намного чаще возникает другая ситуация — когда проблема не в сетевом интерфейсе, а в общем уровне загрузки сети. В этом случае работа клиентов с SQL Server может серьезно замедлиться. Могут происходить тайм-ауты при установке соединений, разрывы уже установленных соединений и т. п. Как отследить общий уровень загрузки сети и в случае необходимости представить доказательства сетевому администратору?

В Системном мониторе подходящего объекта нет. Он был в Windows NT 4.0 (и назывался Сетевой сегмент (Network Segment)), но в Windows 2000 и 2003 его убрали (мотивируя это заботой о безопасности). Поэтому придется использовать другие способы. Средства оценки производительности сети встроены в большинство снифферов (одни из самых мощных — в Net Observer), в том числе в сниффер от Microsoft, который называется Сетевой монитор (Network Monitor). Правда, использовать для анализа загрузки сети ту версию Сетевого монитора, которая поставляется с Windows 2000 и 2003 (ее можно установить, выбрав в списке необязательных компонентов операционной системы), бесполезно. Этот сниффер видит только трафик, который передается с этого компьютера, на этот компьютер, широковещательный трафик и трафик групповой рассылки. Если трафик генерируется другими компьютерами, то стандартная версия Сетевого монитора просто его не увидит и, соответственно, не отобразит при анализе уровня загрузки. Поэтому нужно использовать версию Сетевого монитора, которая поставляется с Systems Management Server.

После установки запуска Сетевого монитора вам нужно выбрать сетевой адаптер, который будет использоваться для перехвата пакетов в сети. Затем нужно будет в меню Захват (Capture) выбрать команду Старт (Start), чтобы начать захват данных. Информация о загрузке сети (% загрузки сети) будет представлена как в графическом, так и в цифровом виде (в правой части экрана).

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

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

q      использовать приложение с Web-интерфейсом;

q      использовать терминальный доступ при помощи Microsoft Terminal Services или Citrix MetaFrame.

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

q      терминальные решения требуют минимального трафика в сети и обычно нормально работают даже по модемным коммутируемым соединениям;

q      в случае разрыва соединения пользователь может заново подключиться к своему сеансу и продолжить работу с того же места;

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

q      на клиентском компьютере может быть установлена практически любая операционная система (при использовании Citrix MetaFrame, в том числе и DOS, и Unix). Требования к системным ресурсам компьютера также минимальны;

q      трафик Citrix MetaFrame и Microsoft Terminal Server автоматически шифруется (в отличие от трафика работы обычных клиентов с SQL Server, которые подключаются, например, по OLE DB или ODBC);

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

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

Другие варианты повышения производительности сетевой подсистемы при работе с SQL Server обычно включают в себя использование свитчей вместо хабов, обновление сетевой инфраструктуры (с 10 Мбит до 100, с 100 Мбит — до 1 Гбит и т. п.), а также выделение клиентов вместе с SQL Server в отдельный сегмент сети.

Получить учебные материалы по этому курсу