Какие Причины “Фатальные ошибки внутреннего соединения”
Я использую его в практическом смысле, когда мы передаем большие двоичные объекты (изображения) через веб-сервисы. Таким образом, когда я тестирую веб-сервис C# с помощью сценария Python, двоичный объект может быть воссоздан с небольшим волшебством.
[В Python]
import base64
imageAsBytes = base64.b64decode( dataFromWS )
3 ответа
После нескольких месяцев игнорирования этой проблемы, она начала достигать критической массы, поскольку трафик постепенно увеличивался. При большой нагрузке, включая некоторые сканеры, все сходило с ума, и эти ошибки непрерывно выливались.
Путем проб и ошибок мы в конечном итоге отследили несколько запросов SqlCommand или LINQ, SqlConnection которых не был закрыт сразу после использования. Вместо этого из-за небрежного программирования, возникшего из-за неправильного понимания соединений LINQ, объекты DataContext удалялись (и соединения закрывались) только в конце запроса, а не сразу.
После того, как мы реорганизовали эти методы, чтобы немедленно закрыть соединение с помощью C # "using" блок (освобождая этот пул для следующего запроса), мы больше не получали ошибок. Пока мы все еще не Не зная, почему пул соединений так запутался, мы смогли устранить все ошибки этого типа. Эта проблема была решена вместе с другой аналогичной ошибкой, которую я опубликовал, и обнаружен здесь: Почему моя SqlCommand возвращает строку, когда она должна быть int?
Проверьте папку журнала вашего сервера (\ program files \ Microsoft SQL Server \ MSSQL.1 \ MSSQL \ LOG или аналогичный) для файлов с именами SqlDump * .mdmp и SqlDump * .txt. Если вы все же найдете, вам придется обратиться в службу поддержки.
Похоже, соединение с базой данных прерывается или истекает время ожидания.
Недавно у нас были похожие проблемы при переходе на IIS 6 из IIS 5 при подключении к SQL 2000. Наша проблема была решена путем увеличения количества доступны эфемерные порты.
Посмотрите на использование эфемерных портов сервером IIS. Макс. Номер по умолчанию. доступных портов обычно составляет 4000. Вы можете рассмотреть возможность увеличения этого числа, если сайты на вашем сервере особенно загружены или ваше приложение выполняет много обращений к базе данных.
Вы можете сначала отслеживать их, чтобы увидеть, не превышается ли максимальный предел.
Найдите в базе знаний Microsoft «MaxUserPort» и «TcpTimedWaitDelay» и внесите необходимые изменения в реестр. Перед внесением изменений убедитесь, что вы создали резервную копию реестра или сервера моментальных снимков. Чтобы изменения вступили в силу, потребуется перезагрузка.
Вы должны дважды проверить вашу базу данных и соединение набора записей закрывается после использования. Если не закрывать, этот диапазон портов будет израсходован без надобности.
В любом случае проверьте эффективность хранимых процедур, так как они могут занимать больше времени, чем нужно.
«Если вы быстро открываете и закрываете 4000 сокетов менее чем за четыре минуты, вы достигнете максимального значения по умолчанию для клиентских анонимных портов, и новые попытки подключения к сокету завершатся ошибкой, пока не истечет время ожидания существующего набора сокетов TIME_WAIT. " - из http://support.microsoft.com/kb/328476