Период ожидания, прошедший до получения соединения от пула

Question

Наш сайт работает отлично в течение 90% дня, а затем в часы пик, когда трафик примерно в два раза тяжелее обычного, все замедляется до ползания. Время загрузки страницы, которое обычно составляет 1 секунду, занимает 30 секунд. Проверяя наши журналы ошибок, похоже, что это может быть проблема пула соединений. У нас есть 3 веб-сервера, подключенные к 1 sql server db. Сервер SQL летает до 25% на всех ядрах.

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

Я уверен, что мы просто используем любые настройки по умолчанию, которые MS прилагает для работы с нашим пулом приложений. Что я могу сделать, чтобы проверить, является ли проблема с пулом приложений? Каковы негативы увеличения размера пула приложений до 1000 (и как это сделать?).

Спасибо!

Answer 1

Это может быть связано с неправильным расположением соединений sql (возвращается в пул). Убедитесь, что вы звоните SqlConnection.Dispose.

Answer 2

Это может быть потому, что пул подключений SQL будет исчерпан (это отличается от пула приложений.) Вы можете проверить, что с помощью increasing the pool size через строку соединения:

Integrated Security=SSPI;Initial Catalog=northwind;Max Pool Size=100; 

Но более вероятно, ваша база данных может Не отставайте от потока входящих запросов. Это приводит к тому, что соединения ждут завершения запроса. Добавление большего количества подключений поможет избежать запросов на пакет, но не против устойчивого трафика.

Вот некоторые предложения, чтобы улучшить производительность SQL Server при устойчивой высокой нагрузке:

• Throw аппаратных средств на проблему (особенно RAM на SQL Server)
• Приложить SQL Server Profiler для сервера, получить след одного периода высокой нагрузки, и следить за его РЕКОМЕНДУЕМЫМ индексирует
• из журнала трассировки, проверьте длительные запросы, а также улучшить их вместе с T-SQL разработчиком

Удачи, эти вещи могут быть довольно сложными!

Answer 3

В моем опыте есть 3 основных типа времени ожидания вы можете получить из SQL Server:

1) InvalidOperationException - Неудача для клиента, чтобы получить объединенном соединение с собственного бассейна до таймаута, указанного в команде строка (по умолчанию 15 секунд). Пул клиента максимальный, и все объединенные соединения используются и остаются в использовании до истечения таймаута.

2) SQLException - Время ожидания соединения. Пул соединений клиента создает новое соединение с базой данных, но база данных не отвечает до таймаута, указанного в командной строке (по умолчанию 15 секунд).

3) SQLException - Время ожидания команды. Было получено соединение, но время выполнения инструкции SQL для выполнения команды превысило тайм-аут, указанный в свойстве CommandTimeout команды (по умолчанию 30 секунд)


В ваших обстоятельствах сервера, выполняющего нормально до загрузки, добавляются звуки, подобные случаю # 1. Я обнаружил, что таймауты приходят очень быстро - обычно 2 секунды.

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

Вы можете увеличить максимальные настройки темы с этим Transact-SQL:

sp_configure 'max worker threads', 8192 
go 
Reconfigure 

Затем перезапустите SQL Service.

Кстати, вы можете видеть, сколько потоков в настоящее время выделено SQL Server с помощью этой команды:

select sum(current_workers_count) from sys.dm_os_schedulers 

Этот параметр резьбы делает огромную разницу в том, как SQL Server выполняет при многих соединений. SQL Server становится очень невосприимчивым, когда заканчивается поток.

Answer 4

Когда я получил эту ошибку:

The timeout period elapsed prior to obtaining a connection from the pool. This may have occurred because all pooled connections were in use and max pool size was reached

Это было связано с тем, что я использовал метод SqlCommand.ExecuteQuery() вместо SqlCommand.ExecuteNonQuery().

Например: Мой оригинал хранится вызов procdure выглядеть примерно так:

using (SqlCommand cmd = new SqlCommand()) 
{ 
    cmd.CommandType = System.Data.CommandType.StoredProcedure; 
    cmd.CommandText = "InsertSproc"; 
    cmd.Parameters.AddWithValue("@Value", myValue); 
    cmd.Parameters.AddWithValue("@LoggedDate", myDate); 
    DatabaseManager.instance.ExecuteQuery(cmd); 
} 

Код выше является то, что бросил исключение. Однако изменение вызова использовать ExecuteNonQuery() исправлена ​​проблема:

using (SqlCommand cmd = new SqlCommand()) 
{ 
    cmd.CommandType = System.Data.CommandType.StoredProcedure; 
    cmd.CommandText = "InsertSproc"; 
    cmd.Parameters.AddWithValue("@Value", myValue); 
    cmd.Parameters.AddWithValue("@LoggedDate", myDate); 
    DatabaseManager.instance.ExecuteNonQuery(cmd); 
} 

Answer 5

Я имел этот вопрос с Powershell и спиной к спине запросов (Invoke-Sqlcmd следует другим Invoke-Sqlcmd). Оба запроса включали изменения данных. Решено путем добавления -connectiontimeout 1 к вызову параметра.

Пример:

invoke-sqlcmd "insert into testdb..tab1 (cname) select 'x'" -connectiontimeout 1 
invoke-sqlcmd "update testdb..tab1 set ctr=ctr+1 where cname='aaa'" 

Длина тайм-аута может изменяться в зависимости от количества затронутых строк.