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

Откуда: Москва
Сообщений: 4927
Я столкнулся с упрямством DBA которые увидили в SQL Sentry мол как бы большие значения SLEEP_BPOOL_FLUSH. К сожалению, у меня нету никакой достоверной информации от DBA по поводу того какие именно SQL statement являются причиной бед связанных с IO, и мне хотелось бы самому проанализиваровать какие SQL это делают. Как можно узнать время разных блокировок конкретного @@SPID (или текущего @@SPID)? Я бы тогда записал это в свои логи.




Вот по этой ссылке я нашел запросик как посмотреть статистику по блокировкам:
Troubleshooting Performance Problems in SQL Server 2005
select top 30 * 
from sys.dm_os_wait_stats 
--where wait_type in ('SLEEP_BPOOL_FLUSH','PAGEIOLATCH_SH') 
order by wait_time_ms desc


WAITFOR 99889038 39024802473 300010 22684947
LAZYWRITER_SLEEP 8105382 15479468773 794570133 816935
CLR_SEMAPHORE 200844 3295370279 28860 99471
SP_SERVER_DIAGNOSTICS_SLEEP 1589362 2840531530 300303 2840531530
CLR_AUTO_EVENT 2768615 2839688732 38826124 146168
OLEDB 15630370 1769745496 1799991 0
MSQL_DQ 1055393 1735546009 1799994 0
XE_TIMER_EVENT 320891 1420735183 13198 1420734903
HADR_FILESTREAM_IOMGR_IOCOMPLETION 2764108 1420734761 32377 791241
DIRTY_PAGE_POLL 13013106 1420682119 2200 64288
XE_DISPATCHER_WAIT 45547 1420680773 65347 0
SQLTRACE_INCREMENTAL_FLUSH_SLEEP 354311 1420189715 4353 3017
LOGMGR_QUEUE 35544701 1419510476 2247 865275
REQUEST_FOR_DEADLOCK_SEARCH 283590 1419397519 5254 1419397519
BROKER_EVENTHANDLER 1191 1412711184 59425248 720
FT_IFTS_SCHEDULER_IDLE_WAIT 23480 1409007035 60514 9354
CHECKPOINT_QUEUE 634863 1391420284 2100205 421582
ONDEMAND_TASK_QUEUE 83 1384006277 602978583 306
DISPATCHER_QUEUE_SEMAPHORE 515396 883465862 693084337 144019
SLEEP_TASK 219086862 735882470 32673 3436883
BROKER_TO_FLUSH 689661 710302410 29155 249988
SOS_SCHEDULER_YIELD 612255159 227132451 54746 226735639
BROKER_TASK_STOP 42665 216336554 10186 27806
CLR_MANUAL_EVENT 4216940 189770546 47443 1943578
LCK_M_IX 348254 118175015 380554 125016
PAGEIOLATCH_SH 8995414 83712103 28581 5983664
BROKER_RECEIVE_WAITFOR 455 77212593 599923 134
PAGELATCH_EX 596864900 69565701 31916 66478762
WRITELOG 21098262 67447148 31998 6341414
TRACEWRITE 126978 37549923 2178 21698
..
SLEEP_BPOOL_FLUSH 14114078 10338431 30091 1727042

Microsoft SQL Server 2012 (SP1) - 11.0.3368.0 (X64) May 22 2013 17:10:44 Copyright (c) Microsoft Corporation Enterprise Edition: Core-based Licensing (64-bit) on Windows NT 6.1 <X64> (Build 7601: Service Pack 1)
18 июл 13, 05:01    [14581198]     Ответить | Цитировать Сообщить модератору
 Re: Большие значения SLEEP_BPOOL_FLUSH  [new]
Гость333
Member

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

Я, конечно, ни разу не DBA, но...
BOL
SLEEP_BPOOL_FLUSH
Occurs when a checkpoint is throttling the issuance of new I/Os in order to avoid flooding the disk subsystem.

Разве это не означает, что этот тип ожидания напрямую не связан ни с какими SPID'ами, и для решения проблемы надо пошевелить параметр recovery interval (что является компетенцией DBA)? Вопрос не риторический.

BusyMan
Как можно узнать время разных блокировок конкретного @@SPID (или текущего @@SPID)?

http://www.sqlskills.com/blogs/paul/capturing-wait-stats-for-a-single-operation/
18 июл 13, 10:44    [14582045]     Ответить | Цитировать Сообщить модератору
 Re: Большие значения SLEEP_BPOOL_FLUSH  [new]
Критик
Member

Откуда: Москва / Калуга
Сообщений: 35376
Блог
как вариант - проблемы в дисковой подсистеме
18 июл 13, 11:53    [14582593]     Ответить | Цитировать Сообщить модератору
 Re: Большие значения SLEEP_BPOOL_FLUSH  [new]
Критик
Member

Откуда: Москва / Калуга
Сообщений: 35376
Блог
проблемные запросы можно определить так

-- запросы с высокими издержками на ввод-вывод
SELECT TOP 50
       [Average IO] = (total_logical_reads + total_logical_writes) / qs.execution_count,
       [Total IO] = (total_logical_reads + total_logical_writes),
       [Execution count] = qs.execution_count,
       [Individual Query] = SUBSTRING (qt.text,qs.statement_start_offset/2, (CASE
                                                                               WHEN qs.statement_end_offset = -1 THEN LEN(CONVERT(NVARCHAR(MAX), qt.text)) * 2 
                                                                               ELSE qs.statement_end_offset
                                                                             END - qs.statement_start_offset)/2),
       [Parent Query] = qt.text,
       [DatabaseName] = DB_NAME(qt.dbid)
  FROM sys.dm_exec_query_stats qs
  CROSS APPLY sys.dm_exec_sql_text(qs.sql_handle) as qt
  ORDER BY [Average IO] DESC


-- нагрузку на подсистему ввода-вывода
select top 50
    (total_logical_reads/execution_count) as avg_logical_reads,
    (total_logical_writes/execution_count) as avg_logical_writes,
    (total_physical_reads/execution_count) as avg_phys_reads,
     Execution_count, 
    statement_start_offset as stmt_start_offset, 
    plan_handle,
    qt.text
  from sys.dm_exec_query_stats  qs
  CROSS APPLY sys.dm_exec_sql_text(qs.sql_handle) as qt
  order by  (total_logical_reads + total_logical_writes) Desc
18 июл 13, 11:56    [14582623]     Ответить | Цитировать Сообщить модератору
 Re: Большие значения SLEEP_BPOOL_FLUSH  [new]
Mind
Member

Откуда: Лучший город на Земле
Сообщений: 2322
BusyMan
Я столкнулся с упрямством DBA которые увидили в SQL Sentry мол как бы большие значения SLEEP_BPOOL_FLUSH.

Я бы усомнился в квалификации таких DBA, потому как:
http://www.sqlskills.com/blogs/paul/wait-statistics-or-please-tell-me-where-it-hurts/
This is normal to see and indicates that checkpoint is throttling itself to avoid overloading the IO subsystem. I would add this to the list of waits to filter out and re-run the wait stats query.
19 июл 13, 00:21    [14586952]     Ответить | Цитировать Сообщить модератору
Все форумы / Microsoft SQL Server Ответить