Что вызывает этот SqlException: Ошибка транспортного уровня произошла при получении результатов с сервера

Question

Вот полная ошибка: SqlException: A transport-level error has occurred when receiving results from the server. (provider: Shared Memory Provider, error: 1 - I/O Error detected in read/write operation)

Я начал видеть это сообщение перерывами на несколько модульных тестов в моем приложении (имеется более 1100 единиц & системных тестов). Я использую тестовый бегун в ReSharper 4.1.

Еще одна вещь: моя машина для разработки - виртуальная машина VMWare.

Answer 1

Я столкнулся с этим множеством лун назад. В конце концов, вы исчерпали доступные порты.

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

Если это так, проверьте количество доступных портов для SQL Server.

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

Если пул включен, вам необходимо профилировать все порты SQL Server и убедиться, что у вас есть достаточно и расширить их, если необходимо.

Когда я столкнулся с этой ошибкой, пул соединений был отключен, и это вызвало эту проблему, когда на сайт была добавлена ​​приличная нагрузка. Мы не видели его в разработке, потому что нагрузка составляла 2 или 3 человека максимум, но как только число выросло более чем на 10 человек, мы все время видели эту ошибку. Мы включили пул, и он исправил это.

Answer 2

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

Answer 3

Я видел это много, когда сеть была напугана, или сетевой адаптер был на пути. Проверьте сетевой стек.

Answer 4

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

Answer 5

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

Answer 6

Мы видели эту ошибку несколько раз и пробовали разные разрешения с переменным успехом. Одна общая основная тема заключалась в том, что система, дающая ошибку, была низкой в ​​памяти. Это особенно актуально, если сервер, на котором размещен сервер Sql, запускает ЛЮБОЙ другой процесс, отличный от ОС. По умолчанию SQL Server будет захватывать любую память, чтобы он мог, а затем оставил мало для других процессов/драйверов. Это может привести к неустойчивому поведению и прерывистым сообщениям. Хорошей практикой является настройка вашего SQL Server для максимальной памяти, которая оставляет некоторый запас, есть ли другие процессы, которые могут понадобиться. Пример: Visual Studio на dev-машине, на которой выполняется копия выпуска разработчиков SQL Server на одном компьютере.