Немного далеко, но в лаборатории некоторое время назад мы столкнулись с ситуацией, когда SQL Server казался не отвечающим, не потому, что мы взломали процессор или что-то, что мы могли отследить в SQL Server, он казался работоспособным для всех тестов. но соединения не удалось при некоторой нагрузке.
Проблема, как оказалось, была связана с объемом трафика на сервере, что означало, что мы запускаем встроенную защиту от Syn Syntack Flood в Windows. Досадно, что когда вы нажимаете эту кнопку, на сервере Windows или в SQL нет зарегистрированного сообщения - вы видите только те символы, которые не могут быть установлены - это происходит потому, что Windows замедляет прием сообщений и создает очередь. С точки зрения соединения сервер, кажется, не отвечает, когда должен (он даже не подтверждает прибытие сообщения)
http://msdn.microsoft.com/en-us/library/ee377084(v=bts.10).aspx
Прокрутите вниз до SynAttackProtect, и вы увидите, что по умолчанию в Windows Server 2003 SP1 и выше было включать эту функцию по умолчанию. Это эффективный механизм защиты DDOS, и отсутствие запуска, которое он вызывает, делает невероятно трудным обнаружить, когда ваш сервер делает это.
Потребовалось 3 дня в лаборатории MS, чтобы выяснить это.
Вы упомянули 100 подключений, у нас было приложение, которое постоянно подключалось, выполняло запросы и затем отключалось, оно не поддерживало открытые подключения. Это означало, что у нас было несколько потоков на каждом подключении к машине, 10 компьютеров, несколько потоков на машину, и было сочтено, что было последовательно установлено / разорвано достаточно различных подключений для запуска защиты.
Трудно сказать, находитесь ли вы на этом уровне (поскольку он не является четко определенным пороговым значением для MS).