заведение в тупик sql и таймаут почти постоянно
Свяжите может сделать простое циклическое выравнивание нагрузки на своем собственном, но не проверит время отклика сервера. Чтобы сделать это, необходимо будет выбрать некоторое измерение производительности (например, задержка) и затем или переписать зональный файл или использовать rrset-order команда для сообщения этого, который порядок поставить записи в.
Так или иначе выравнивание нагрузки DNS далеко от идеального решения, специально для высокого TTL. То, что будет обычно происходить, - то, что сервер DNS большого ISP кэширует Ваш ответ и затем большинство клиентов от того, что ISP поражает первый IP в том ответе. Для предотвращения этого, можно установить TTL 0 для отключения кэширования, но затем сервер DNS будет коваться...
Для получения дополнительной информации о выравнивании нагрузки DNS со связывают, взглянули на http://www.zytrax.com/books/dns/ch9/rr.html (это не полностью актуально, будучи записанным для 9.3.0, свяжите, в 9.7.0 теперь, но должен дать Вам общее представление о том, как можно сделать это, использование связывает),
Это скорее вопрос разработки. Вы можете проконсультироваться со своими разработчиками, чтобы определить, какой уровень изоляции транзакций используется.
Уровень изоляции Microsoft SQL Server по умолчанию - зафиксирован при чтении. Разработчик должен знать и устанавливать соответствующий уровень для транзакции. Обычно рекомендуется использовать минимально возможный уровень изоляции и избегать использования уровней изоляции Repeatable Read и Serializable, если это возможно.
Если они используют более строгий уровень изоляции, чем по умолчанию, такой как Repeatable Read или Serializable, тогда приложение будет более предрасположено к проблемам с блокировкой. Если они используют более строгий уровень изоляции, чем по умолчанию, и не знают об этом, это еще хуже.
Передовая технология доступа к данным Microsoft, Entity Framework по умолчанию использует уровень изоляции Serializable. Это не очень хорошо задокументировано или раскрыто. Если приложение использует Entity Framework и разработчик не знает об этом факте, разработчик может захотеть проверить структуру базы данных, чтобы определить, могут ли они установить уровень изоляции транзакции на Read Committed.
Дополнительная информация:
УСТАНОВИТЬ УРОВЕНЬ ИЗОЛЯЦИИ ТРАНЗАКЦИЙ (Transact-SQL)
http://msdn.microsoft.com/en-us/library/ms173763.aspx
Транзакции и соединения в Entity Framework 4.0
http://blogs.u2u.be/diederik/post/2010/06/29/Transactions-and-Connections-in-Entity-Framework-40.aspx
Я не люблю пиво, но вам следует серьезно взглянуть на профилировщик SQL Server - это ценный инструмент для анализа вашей рабочей нагрузки, в том числе некоторые инструменты, помогающие выявить причины тупиковых ситуаций.
На эту тему написано множество статей, эта достаточно обширна. Официальная документация на MSDN также содержит некоторую информацию, хотя и не так хорошо написана.
Удалось ли вам хотя бы записать запросы, вызывающие проблемы? По моему опыту, очень мало запросов отвечает за подавляющее большинство проблем.
Судя по сообщениям об ошибках, вы используете SQL Server. Если вы используете 2005 или лучше, включите Trace Flag 1222 DBCC TRACEON (1222, -1) , он должен дать вам некоторую информацию о запросах. Дрянная схема может вызвать проблемы, но я никогда не видел, чтобы дрянная схема напрямую вызывала взаимоблокировки. Обычно есть обходной путь. Медленный запрос намного лучше, чем запрос, вызывающий постоянные взаимоблокировки.
Извлеките некоторые из запросов, которые мешают, и мы могли бы предложить некоторые изменения в них.
Если у вас есть правильные индексы, нет хорошего способа решить эту проблему без исправления схемы базы данных и / или запросы: в частности, тестирование с помощью SNAPSHOT ISOLATION и READ COMMITTED SNAPSHOT . Это не быстрые решения.
Если вы не против превратить нового зверя обратно в медленную свинину, вы можете отключить параллелизм . Неизвестно, насколько это поможет.
В конечном итоге частые тупиковые ситуации являются результатом неадекватного проектирования базы данных, и нет никакого способа обойти это.