Как определить оптимальное количество соединений, которые могут быть открыты на моей БД SQL Server 2000? - PullRequest
Новая
       7

Как определить оптимальное количество соединений, которые могут быть открыты на моей БД SQL Server 2000?

2 голосов
/ 03 ноября 2008

Какое оптимальное количество соединений может быть открыто в БД SQL Server 2000. Я знаю, что в предыдущей компании, в которой я работал, на машине с 64-процессорной версией Oracle 8i, 8-процессорной, мы выяснили, что 8 * 12 = 96 соединений кажутся хорошим числом. Есть ли такой калькулятор для SQL Server 2000. БД работает на 2-процессорной (гипер-поточной 4) машине. Есть много транзакций, которые работают с БД. Причина, по которой я спрашиваю, состоит в том, что у нас есть приложение, которое обычно оставляет около 100 открытых соединений, даже если оно ничего не делает, и мне трудно объяснить, что это может быть причиной наших проблем с производительностью. Может быть, SQL Server не имеет такого ограничения ... Может ли кто-нибудь из вас высказать некоторые мудрости по этому поводу? Очень ценю это. Спасибо,

Я должен добавить, что это Standard Edition.

Ответы [ 4 ]

1 голос
/ 04 ноября 2008

Если вы не знаете, является ли это узким местом вашей производительности, вы должны попытаться определить это, не пытаясь ограничить соединения или что-то в этом роде.

Если нет, вам следует:

  1. Используйте SQL Profiler для поиска длительных запросов.
  2. Мониторинг загрузки ЦП вашего сервера БД, использования памяти / файла подкачки и использования сети
  3. Найдите один из ваших самых длительных запросов (см. № 1 выше) и напишите очень скудное тестовое приложение, которое может генерировать этот запрос на вашем сервере БД во время пиковой нагрузки и записывать некоторое время ответа.

Если # 1 и # 2 ничего не раскрывают, а # 3 показывает, что ваш db-сервер имеет медленное время отклика во время загрузки, то вы знаете, что у вас есть проблема, такая как «слишком много соединений». Но если вы еще не сделали № 3, то, по-видимому, это целесообразно сделать, так как гадость с ограничениями соединения и тому подобным образом создаст искусственные узкие места и не поможет вам полностью понять причину вашей проблемы, IMO.

0 голосов
/ 04 ноября 2008

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

Так же как и ответ от sliderhouserules, в качестве быстрого исправления я бы предложил отключить гиперпоточность, а не ограничивать ваши соединения. link1 , link2 (примечание: этот парень работал над кодом MS SQL 2005)

Каждое соединение занимает тривиальный объем памяти. Общая блокировка БД предназначена только для стабильности.

0 голосов
/ 04 ноября 2008

Если приложение долго работает и находится на том же сервере, если приложение оставляет открытые дескрипторы БД, которые создали блокировку, это действительно ухудшает производительность. Вы можете проверить что-то вроде select * из sys.dm_tran_locks или sp_lock, чтобы дать вам представление.

0 голосов
/ 03 ноября 2008

Этот пост в блоге на MSDN указывает на то, что ограничений нет - по крайней мере, в редакциях Express: http://blogs.msdn.com/euanga/archive/2006/03/09/545576.aspx

И это указывает, что это может быть 256, для облегченных изданий - http://blogs.msdn.com/stevelasker/archive/2006/04/10/SqlEverywhereInfo.aspx

Это также показывает без ограничений: http://channel9.msdn.com/forums/TechOff/169030-The-difference-between-SQL-Server-2005-Express-and-Developer-Edition/?CommentID=299642

сложение - из комментария, http://msdn.microsoft.com/en-us/library/aa196730(SQL.80).aspx указывает, что максимальное значение равно 32767, в то время как «идеальный» отсутствует

...