SQL, отказывающийся от соединения при загрузке

Я запускаю тест нагрузки в своей системе. На определенном уровне нагрузки я начинаю получать SQL-ошибки в моем журнале:

System.Data.SqlClient.SqlException (0x80131904): При установлении соединения с SQL Server возникла связанная с сетью или конкретная ошибка экземпляра. Сервер не найден или не был доступен. Проверьте правильность имени экземпляра и настройте SQL Server для удаленного подключения. (поставщик: Именованные каналы Prprovidererror: 40 – Не удалось выполнить взаимодействие с SQL Server) —> System.ComponentModel.Win32Exception (0x80004005): сетевой путь не найден

Запустив монитор производительности на соответствующем SQL-сервере, я обнаружил следующее:

  • Уровень процессора редко превышает 50%. (На предыдущей итерации я увидел, что она максимизируется на 100%, поэтому я увеличил спецификации виртуальной машины, что помогло проблеме повысить уровень нагрузки.)
  • Количество пользовательских подключений достигло тени более 8000. Сервер Sql имеет настройку по умолчанию, равную 32 767 максимальным соединениям.
  • Строка подключения определяет максимальный размер пула 1000 подключений к каждой базе данных, а на сервере 100 баз данных. Тест нагрузки распределяется случайным образом между 100 базами данных, поэтому должно быть достаточно ровное распределение, что означает около 80 подключений на базу данных. Нигде рядом с пределом 1k.

Какие еще факторы могут привести к тому, что Sql Server перестанет быть в состоянии принимать соединения?

UPDATE: дополнительная информация: я использую Entity Framework Core (EF7) для моих соединений с БД, если это помогает.

«Network Path Not Found» не похож на ошибку, связанную с емкостью SQL Server. Как бывший «IT Guy», я подозреваю, что брандмауэр отбрасывает ваши пакеты. Если это происходит во время стресс-теста, брандмауэр может интерпретировать многочисленные запросы как атаку отказа в обслуживании и использовать какое-то предопределенное правило для удаления соединений за указанный период времени.

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

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

Можете ли вы предоставить код, доступ к базе данных? Вы вызываете метод dispose () или закрываете соединение?

Кроме того, вы посмотрели, может ли datacaching данных облегчить загрузку db? 2-5-секундный datacache может значительно сократить количество запросов к базе данных.

Вы используете ограничение на listen() TCP listen() для прослушивающего порта SQL-Server. Когда это произойдет, платформы Windows (но не * nix-платформы) выдадут «отказ в подключении» для последующих входящих соединений.

Я не парень SQL-Server, но обязательно должен быть параметр, в котором вы можете увеличить его прослушивание.

В качестве альтернативы вам следует искать лучший или более пул соединений на клиенте.

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

Решение: мы уменьшили количество отключенных потоков, используя шаблон, показанный в этом ответе .

  • SQL-сервер ADO.NET по протоколу TCP / IP с низкой пропускной способностью дает какие-либо советы / опыт?
  • Я не могу изменить порт сервера SQL Server (1433)
  • Не удалось подключиться к SQL Server 2000 через TCP / IP на localhost
  • Существующее соединение было принудительно закрыто удаленным хостом
  • Удаленный доступ к базе данных MSSQL с помощью Plesk
  • Давайте будем гением компьютера.