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

TCPing сообщает о задержке 20 мс между веб-фермой и БД

У нас есть веб-ферма IIS, которая находится в DMZ и подключается к базе данных MSSQL (кластер Windows). После устранения некоторых проблем с производительностью мы обнаружили странное поведение сети.

Мы хотели проверить сетевую задержку между двумя серверами в целом, но пинг блокируется брандмауэром, поэтому мы попытались использовать версию tcping для проверки задержки специально для сервера базы данных на порту 1433. TCPing сообщает о задержке ~ 20 мс. То же TCP-соединение с моей рабочей станции на сервер БД составляет ~ 2 мс. Моя первая мысль заключалась в том, что это брандмауэр между веб-сервером и сервером БД, поэтому, чтобы подтвердить свое подозрение, я запустил еще одно TCP-соединение с другого сервера приложений, находящегося внутри сети, и он ТАКЖЕ сообщил о задержке в 20 мс. Затем я начал использовать тот же протокол TCP с других серверов. Некоторые сообщают о задержке 2 мс, некоторые - почти 20 мс.

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

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

Есть ли какая-либо конфигурация сети в Windows, которая может вызывать такое поведение? Есть ли у кого-нибудь другие предложения (другие инструменты мониторинга, другие возможные причины и т. Д.)?

Обновить Просто попытался TCP-соединение с локальным IP-адресом, а не с 127.0.0.1, но с фактическим IP-адресом машины, и я также вижу задержку (что-то вроде 15-18 мс). Я обошел несколько серверов и заметил похожее поведение. Это не кажется нормальным, есть идеи? Не все серверы демонстрируют такое поведение.

Булл, network ops некомпетентен.

2 мс - это не мало, но нормально.

20 мс - это возмутительно. Это WAN-ссылка, или перегруженная линия, или что-то в этом роде.

НИКАКАЯ ЛВС в здании не даст вам 20 мс, даже если вы подключите полдюжины маршрутизаторов.

Мне неизвестны какие-либо неисправности.

Однако блокировка ICMP может вызвать побочные эффекты - например, отброшенные TCP-пакеты. Тот, кто отключил это, должен узнать о TCP / IP перед настройкой брандмауэров. По стандартам TCP сеть нарушена из-за отсутствия ICMP (который используется, например, для определения максимального размера сегмента, который может быть безопасно транспортирован).

Дело в аппаратном обеспечении либо его недостаточно, либо оно неправильно настроено. это уровень один или два, или набор правил брандмауэра, удачи им.

Когда вы передаете SQL с сервера IIS, захватите трафик с помощью wirehark, установленного на SQL. Захватите все, а затем прорежьте его с помощью фильтра дисплея. или вы можете сделать фильтр захвата, например: TCP-порт 1433 и щелкнуть правой кнопкой мыши пакет и следовать потоку TCP ...

Попросите администраторов FW взглянуть на это: http://support.microsoft.com/kb/968872

Нужно открыть более 1433, и похоже, что они не очень хороши в этом, и в этом случае их набор правил является подозрительным, вход icmp из DMZ должен быть заблокирован. Его не следует использовать. внутри ядра, где ваша рабочая станция и SQL в порядке. Я предполагаю, что ваша сеть логически состоит из двух слоев: общедоступного, где находится ваш IIS, и основного, где находится SQL.

Под сегментом они подразумевают подсеть или vlan? Если это VLAN, то для этого есть правила .... вы можете открыть «сегмент» для TCP 1433, а не для UDP, или у вас есть vlan, хост отсутствует или отсутствует там, где должен быть, вместо этого он находится в другом.

Вы настроили ОС, чтобы она не выполняла службы браузера компьютера, WINS и тому подобное, чтобы она не пыталась идентифицировать ваш SQL с помощью netbios? Это могло замедлить работу.

Я бы открыл захват wirehark на вашем SQL-сервере и посмотрел, что вы видите. Вы можете отключить автоматическую прокрутку пакетов при захвате в реальном времени, чтобы они не пропадали мимо. Позвольте ему захватить некоторые транзакции, затем остановите его и используйте фильтр отображения, чтобы развернуть, как я думаю, tpc.port eq 1433. фильтр захвата будет следующим: порт 1433, и он получает все протоколы, предназначенные только для 1433 и от подсети, членом которой является этот компьютер.

Скорее всего, вы увидите много ретрансляций, дублирующих подтверждений и прочего подобного. Посмотрите на ARP, посмотрите, все ли в порядке, если вы видите, что трафик netbios делает то, что вам нужно, чтобы отключить его в ОС. Как и в IIS nic, у вас отключен клиент Windows или общий доступ к файлам в сетевом стеке, я совершенно забыл. Вам нужны только TCP и UDP, btwn, sql и IIS. нет NetBT, NetBios или чего-то еще. ВСЕ DNS, без WINS и т.д ... удачи в работе с сетью.

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

Конфигурация ОС может сыграть важную роль в отношении производительности - это SMB, так как он различается между версиями ОС, и конфигурации ОС могут привести, например, к тому, что Windows Server 2003 и Windows Server 2008 не будут хорошо работать вместе. Однако это не связано с задержкой в ​​сети, и это совершенно другой протокол, чем тот, который вы используете для подключения к SQL Server или, вероятно, тот, который используется TCPing.