Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Microsoft SQL Server Новый топик    Ответить
 timeout  [new]
Alexander Us
Member

Откуда:
Сообщений: 1133
При высокой нагрузке клиетсие приложения спорадически пошут в лог "timeout,... .Net SqlClient Data Provider" .
Даже при запросам к маленьким таблицам.
К сожалению ни в трэйсе ни в логе сервера не могу найти причин.

В какую сторону копать?
select count(*) from sys.dm_exec_sessions  --> 1500
select @@version --> Microsoft SQL Server 2005 - 9.00.5000.00 (X64)   Dec 10 2010 10:38:40   Copyright (c) 1988-2005 Microsoft Corporation  Enterprise Edition (64-bit) on Windows NT 5.2 (Build 3790: Service Pack 2) 
28 ноя 14, 17:14    [16921021]     Ответить | Цитировать Сообщить модератору
 Re: timeout  [new]
Glory
Member

Откуда:
Сообщений: 104760
Alexander Us
В какую сторону копать?

В сторону увеличения таймаута ожидания в ваших приложениях.
И в сторону оптимизации времени выполения запросов, которые эти приложения отсылают серверу
28 ноя 14, 17:17    [16921044]     Ответить | Цитировать Сообщить модератору
 Re: timeout  [new]
Alexander Us
Member

Откуда:
Сообщений: 1133
Glory,

туда я уже копал: если бы запросы отваливалить по таймауту как обычно, это было бы видно в трейсе(тип=duration).

оптимизация в данном случае тоже не причём: (спорадически!) обламываются запросы к таблице в 100 строк и это не чидно в трейсе, только в логе приложения.
28 ноя 14, 17:22    [16921092]     Ответить | Цитировать Сообщить модератору
 Re: timeout  [new]
Alexander Us
Member

Откуда:
Сообщений: 1133
Glory,

я имею ввиду, может после N коннекшинов наступают какие то эффекты?
28 ноя 14, 17:24    [16921109]     Ответить | Цитировать Сообщить модератору
 Re: timeout  [new]
Гавриленко Сергей Алексеевич
Member

Откуда: Moscow
Сообщений: 37068
Alexander Us
оптимизация в данном случае тоже не причём: (спорадически!) обламываются запросы к таблице в 100 строк и это не чидно в трейсе, только в логе приложения.
Я могу заблокировать таблицу с 0 записей так, что ее никто за два года прочитать не может.
28 ноя 14, 17:25    [16921112]     Ответить | Цитировать Сообщить модератору
 Re: timeout  [new]
Glory
Member

Откуда:
Сообщений: 104760
Alexander Us
туда я уже копал: если бы запросы отваливалить по таймауту как обычно, это было бы видно в трейсе(тип=duration).

Клиентский таймаут не может генерировать события не сервере. Потому что он клиентский

Alexander Us
оптимизация в данном случае тоже не причём: (спорадически!) обламываются запросы к таблице в 100 строк и это не чидно в трейсе, только в логе приложения.

Ага. Это баг сервера. Ему не нравятся ваши прекрасные производительные запросы. И он в бессильной злобе рвет соединения, заствыляя клиентское приложение генерировать непонятное сообщение о таймауте.
28 ноя 14, 17:27    [16921120]     Ответить | Цитировать Сообщить модератору
 Re: timeout  [new]
Alexander Us
Member

Откуда:
Сообщений: 1133
Гавриленко Сергей Алексеевич
Я могу заблокировать таблицу с 0 записей так, что ее никто за два года прочитать не может.


И это не будет видно в трэйсе?
Ктоме того, при вознокновении блокировок у меня настроено оповещение в случае если она длится более N секунд.


==============================
Проверка блокировок:
WITH [Blocking]
AS 
(
   SELECT w.[session_id]
   ,s.[original_login_name]
   ,s.[login_name]
   ,w.[wait_duration_ms]
   ,w.[wait_type]
   ,r.[status]
   ,r.[wait_resource]
   ,w.[resource_description]
   ,s.[program_name]
   ,w.[blocking_session_id]
   ,s.[host_name]
   ,r.[command]
   ,r.[percent_complete]
   ,r.[cpu_time]
   ,r.[total_elapsed_time]
   ,r.[reads]
   ,r.[writes]
   ,r.[logical_reads]
   ,r.[row_count]
   ,q.[text]
   ,q.[dbid]
   ,p.[query_plan]
   ,r.[plan_handle]
 FROM 
             [sys].[dm_os_waiting_tasks] w
 INNER JOIN  [sys].[dm_exec_sessions] s ON w.[session_id] = s.[session_id]
 INNER JOIN  [sys].[dm_exec_requests] r ON s.[session_id] = r.[session_id]
 CROSS APPLY [sys].[dm_exec_sql_text](r.[plan_handle]) q
 CROSS APPLY [sys].[dm_exec_query_plan](r.[plan_handle]) p
 WHERE 1=1
 and w.[session_id] > 50
 and w.[wait_type] NOT IN ('DBMIRROR_DBM_EVENT','ASYNC_NETWORK_IO')
)

SELECT 
      b.[session_id] AS [WaitingSessionID]
      ,b.[blocking_session_id] AS [BlockingSessionID]                     
      ,b.[login_name] AS [WaitingUserSessionLogin]
      ,s1.[login_name] AS [BlockingUserSessionLogin]
      ,b.[original_login_name] AS [WaitingUserConnectionLogin] 
      ,s1.[original_login_name] AS [BlockingSessionConnectionLogin]
      ,cast(b.[wait_duration_ms] / 1000.0 as decimal(14,2)) AS [WaitDuration_Sec]
      ,b.[wait_type] AS [WaitType]
      ,t.[request_mode] AS [WaitRequestMode]
      ,UPPER(b.[status]) AS [WaitingProcessStatus]
      ,UPPER(s1.[status]) AS [BlockingSessionStatus]
      ,b.[wait_resource] AS [WaitResource]
      ,t.[resource_type] AS [WaitResourceType]
      ,t.[resource_database_id] AS [WaitResourceDatabaseID]
      ,DB_NAME(t.[resource_database_id]) AS [WaitResourceDatabaseName]
      ,b.[resource_description] AS [WaitResourceDescription]
      ,b.[program_name] AS [WaitingSessionProgramName]
      ,s1.[program_name] AS [BlockingSessionProgramName]
      ,b.[host_name] AS [WaitingHost]
      ,s1.[host_name] AS [BlockingHost]
      ,b.[command] AS [WaitingCommandType]
      ,b.[text] AS [WaitingCommandText]
      ,(SELECT  [text] FROM  sys.dm_exec_requests r CROSS APPLY sys.dm_exec_sql_text(sql_handle) where r.session_id = b.[blocking_session_id]) as BlockingCommanText
      ,b.[row_count] AS [WaitingCommandRowCount]
      ,b.[percent_complete] AS [WaitingCommandPercentComplete]
      ,b.[cpu_time] AS [WaitingCommandCPUTime]
      ,b.[total_elapsed_time] AS [WaitingCommandTotalElapsedTime]
      ,b.[reads] AS [WaitingCommandReads]
      ,b.[writes] AS [WaitingCommandWrites]
      ,b.[logical_reads] AS [WaitingCommandLogicalReads]
      ,b.[query_plan] AS [WaitingCommandQueryPlan]
      ,b.[plan_handle] AS [WaitingCommandPlanHandle]
      
 
FROM
            [Blocking] b
INNER JOIN [sys].[dm_exec_sessions] s1 ON b.[blocking_session_id] = s1.[session_id]
INNER JOIN [sys].[dm_tran_locks] t     ON t.[request_session_id] = b.[session_id]
WHERE t.[request_status] = 'WAIT'
28 ноя 14, 17:33    [16921146]     Ответить | Цитировать Сообщить модератору
 Re: timeout  [new]
Alexander Us
Member

Откуда:
Сообщений: 1133
Glory
Alexander Us
туда я уже копал: если бы запросы отваливалить по таймауту как обычно, это было бы видно в трейсе(тип=duration).

Клиентский таймаут не может генерировать события не сервере. Потому что он клиентский

Alexander Us
оптимизация в данном случае тоже не причём: (спорадически!) обламываются запросы к таблице в 100 строк и это не чидно в трейсе, только в логе приложения.

Ага. Это баг сервера. Ему не нравятся ваши прекрасные производительные запросы. И он в бессильной злобе рвет соединения, заствыляя клиентское приложение генерировать непонятное сообщение о таймауте.



"ваши прекрасные производительные запросы" - это Вы сами сказали :)
"в бессильной злобе рвет соединения" - в таком случае он должен и плеваться, а это было бы заметно в трэйсе.
28 ноя 14, 17:47    [16921230]     Ответить | Цитировать Сообщить модератору
 Re: timeout  [new]
invm
Member

Откуда: Москва
Сообщений: 9405
Alexander Us
туда я уже копал: если бы запросы отваливалить по таймауту как обычно, это было бы видно в трейсе(тип=duration).
Чтобы timeout было видно в трейсе, нужно отлавливать событие Attention из категории Errors and Warnings.
28 ноя 14, 17:48    [16921234]     Ответить | Цитировать Сообщить модератору
 Re: timeout  [new]
Alexander Us
Member

Откуда:
Сообщений: 1133
invm,

Спасибо большое.
Настроил, ловлю.
28 ноя 14, 18:02    [16921309]     Ответить | Цитировать Сообщить модератору
Все форумы / Microsoft SQL Server Ответить