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

Откуда:
Сообщений: 539
приветствую

вопрос больше к DBA

есть некий "тяжелый" запрос который согласно оценке завершиться дней через 30...)

там чудо-курсор делающий merge в таблицу 20гб данных + 45гб индексов
переписать ничего нельзя

собсна, блокировок нет, паралельно ничего не выполняется, фрагментации нет, статистика обновлена, план выполнения ок.

Microsoft SQL Server 2017 (RTM-GDR) (KB4293803) - 14.0.2002.14 (X64)   Jul 21 2018 07:47:45   
Copyright (C) 2017 Microsoft Corporation Enterprise Edition: Core-based Licensing (64-bit) on Windows Server 2016 Standard 10.0 <X64> (Build 14393: ) (Hypervisor)

32гб ram
16 cores

целевая БД хранится на диске HP LOGICAL VOLUME SCSI

Maximum server memory 16295MB

подскажите какие показатели/счетчики сервера стоит глянуть ?
8 май 19, 14:53    [21881135]     Ответить | Цитировать Сообщить модератору
 Re: анализ производительности сервера  [new]
komrad
Member

Откуда: Msk -> Utrecht
Сообщений: 4929
_human,

в курсоре там позаписная обработка что ли?

ну посмотрите общие ОС типа цпу, памяти, очереди к дискам,
в сиквеле динамику PLE, к примеру , latency , динамику чекпойтов , кол-во батчей в секунду
в errorlog гляньте на предмет delayed IO

вот у товарища Глена Берри неплохая подборка диагностических скриптов
https://www.sqlskills.com/blogs/glenn/category/dmv-queries/
8 май 19, 15:46    [21881253]     Ответить | Цитировать Сообщить модератору
 Re: анализ производительности сервера  [new]
_human
Member

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

komrad
в курсоре там позаписная обработка что ли?

кусками размером от 20-50'000

Queue length в основном до 2-5-и когда пишет в 1-н файл БД, но бывает и до 20-50-и когда читает/пишет в 2-а
о самом storage device инфы нет
8 май 19, 21:27    [21881503]     Ответить | Цитировать Сообщить модератору
 Re: анализ производительности сервера  [new]
alexeyvg
Member

Откуда: Moscow
Сообщений: 28867
_human
подскажите какие показатели/счетчики сервера стоит глянуть ?
Ну вот, Queue length большая, дисковая система является узким местом.
А вообще, если "переписать ничего нельзя", следует обращаться к производителю, вряд ли выполнение процедуры за 30 дней - это нормально.
8 май 19, 21:30    [21881505]     Ответить | Цитировать Сообщить модератору
 Re: анализ производительности сервера  [new]
_human
Member

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

сейчас создаются индексы активная запись в файл БД и лог.
очередь до 2000 Response time прыгает 500-600 ms

насколько эти показатели вписываются в нормальные показатели ?
есть подозрение что оптимизированный код не даст прироста в производительности
8 май 19, 22:03    [21881520]     Ответить | Цитировать Сообщить модератору
 Re: анализ производительности сервера  [new]
Критик
Member

Откуда: Москва / Калуга
Сообщений: 31978
Блог
_human,

Если оптимизированный код уберет ваши узкие места, то почему бы и нет?
8 май 19, 22:53    [21881545]     Ответить | Цитировать Сообщить модератору
 Re: анализ производительности сервера  [new]
komrad
Member

Откуда: Msk -> Utrecht
Сообщений: 4929
_human
komrad,

komrad
в курсоре там позаписная обработка что ли?

кусками размером от 20-50'000

Queue length в основном до 2-5-и когда пишет в 1-н файл БД, но бывает и до 20-50-и когда читает/пишет в 2-а
о самом storage device инфы нет


+ посмотрите какие waits у вас набегают в процессе работы запроса/сессии
https://www.mssqltips.com/sqlservertip/4078/getting-per-session-wait-statistics-in-sql-server-2016/
8 май 19, 23:06    [21881553]     Ответить | Цитировать Сообщить модератору
 Re: анализ производительности сервера  [new]
alexeyvg
Member

Откуда: Moscow
Сообщений: 28867
_human
сейчас создаются индексы активная запись в файл БД и лог.
очередь до 2000 Response time прыгает 500-600 ms

насколько эти показатели вписываются в нормальные показатели ?
Во время построения инедксов нормально, как я думаю.
_human
есть подозрение что оптимизированный код не даст прироста в производительности
Может даст, может нет, это только вы можете сказать.
8 май 19, 23:28    [21881556]     Ответить | Цитировать Сообщить модератору
 Re: анализ производительности сервера  [new]
_human
Member

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

+
wait_type                                                    waiting_tasks_count  wait_time_ms         max_wait_time_ms     signal_wait_time_ms  Session_Id waiting_tasks_count  wait_time_ms         max_wait_time_ms     signal_wait_time_ms
------------------------------------------------------------ -------------------- -------------------- -------------------- -------------------- ---------- -------------------- -------------------- -------------------- --------------------
LATCH_SH 17714 1336614 3324 970 71 768 130 2 17
LATCH_EX 3730573 344192728 300004 194307 71 152675 687383 1601 17677
PAGELATCH_SH 295733 89074 2714 10603 71 12 0 0 0
PAGELATCH_UP 89236 211720 2888 8288 71 81 125 80 2
PAGELATCH_EX 4039328 884120 2058 72383 71 15 12 3 0
PAGEIOLATCH_SH 116028512 5991946107 18040 2641455 71 10602 104953 1333 285
PAGEIOLATCH_UP 134334 3065584 3405 2333 71 241 596 48 2
PAGEIOLATCH_EX 15137563 329117509 19750 103281 71 10858 107384 3023 61
IO_COMPLETION 934598 7070464 11484 6666 71 18037 2871 36 86
SLEEP_TASK 18765157 1710218631 5012 937069 71 42688 167 3 157
SOS_SCHEDULER_YIELD 107674682 9554099 2554 9471123 71 40163 986 12 963
WRITELOG 9275027 15184197 5180 244702 71 14844 4350 168 348
CMEMTHREAD 614546 17930 140 15491 71 92367 2425 5 2083
CXPACKET 14297055755 20840031441 6083053 636572583 71 5302812446 6508795061 458150 262636023
EXECSYNC 61554 93352564 6083056 2198 71 978 103 0 16
CXROWSET_SYNC 1077 92 1 20 71 61 4 0 1
PREEMPTIVE_OS_FILEOPS 22973 116140 6164 0 71 79 47 1 0
PREEMPTIVE_OS_FLUSHFILEBUFFERS 3085 3906 3143 0 71 79 4 0 0
PREEMPTIVE_OS_GETDISKFREESPACE 3159 459 8 0 71 79 10 0 0
PREEMPTIVE_OS_WRITEFILEGATHER 1147 98667 10851 0 71 79 81 2 0
WRITE_COMPLETION 2042 537 128 7 71 79 8 0 0
MEMORY_ALLOCATION_EXT 5544760572 4480403 1665 0 71 2466094 2385 3 0
RESERVED_MEMORY_ALLOCATION_EXT 43561376 68251 1054 0 71 720670 490 2 0
SESSION_WAIT_STATS_CHILDREN 207365 123843 41 19378 71 82172 36559 41 5393

(24 rows affected)



alexeyvg,

единственное наколенное решение это ручками переместить весь этот обьем ручками - партиционирование, благо версия позволяет
10 май 19, 11:30    [21882066]     Ответить | Цитировать Сообщить модератору
 Re: анализ производительности сервера  [new]
PizzaPizza
Member

Откуда:
Сообщений: 271
_human
есть подозрение что оптимизированный код не даст прироста в производительности


Действительно. Если 60 Гб да на 30 дней... Значится 2 Гб в день... 83 мб в час... 1 мб в минуту...

_human
32гб ram
16 cores


У вас там сервер картошку не чистит параллельно с перекурами?
10 май 19, 21:05    [21882254]     Ответить | Цитировать Сообщить модератору
 Re: анализ производительности сервера  [new]
komrad
Member

Откуда: Msk -> Utrecht
Сообщений: 4929
_human
komrad,

+ SELECT OS.* ,
S.Session_Id ,
S.waiting_tasks_count ,
S.wait_time_ms ,
S.max_wait_time_ms ,
S.signal_wait_time_ms
FROM sys.dm_os_wait_stats OS
INNER JOIN sys.dm_exec_session_wait_stats S ON OS.wait_type = S.wait_type
WHERE S.session_id = 71
wait_type                                                    waiting_tasks_count  wait_time_ms         max_wait_time_ms     signal_wait_time_ms  Session_Id waiting_tasks_count  wait_time_ms         max_wait_time_ms     signal_wait_time_ms
------------------------------------------------------------ -------------------- -------------------- -------------------- -------------------- ---------- -------------------- -------------------- -------------------- --------------------
LATCH_SH 17714 1336614 3324 970 71 768 130 2 17
LATCH_EX 3730573 344192728 300004 194307 71 152675 687383 1601 17677
PAGELATCH_SH 295733 89074 2714 10603 71 12 0 0 0
PAGELATCH_UP 89236 211720 2888 8288 71 81 125 80 2
PAGELATCH_EX 4039328 884120 2058 72383 71 15 12 3 0
PAGEIOLATCH_SH 116028512 5991946107 18040 2641455 71 10602 104953 1333 285
PAGEIOLATCH_UP 134334 3065584 3405 2333 71 241 596 48 2
PAGEIOLATCH_EX 15137563 329117509 19750 103281 71 10858 107384 3023 61
IO_COMPLETION 934598 7070464 11484 6666 71 18037 2871 36 86
SLEEP_TASK 18765157 1710218631 5012 937069 71 42688 167 3 157
SOS_SCHEDULER_YIELD 107674682 9554099 2554 9471123 71 40163 986 12 963
WRITELOG 9275027 15184197 5180 244702 71 14844 4350 168 348
CMEMTHREAD 614546 17930 140 15491 71 92367 2425 5 2083
CXPACKET 14297055755 20840031441 6083053 636572583 71 5302812446 6508795061 458150 262636023
EXECSYNC 61554 93352564 6083056 2198 71 978 103 0 16
CXROWSET_SYNC 1077 92 1 20 71 61 4 0 1
PREEMPTIVE_OS_FILEOPS 22973 116140 6164 0 71 79 47 1 0
PREEMPTIVE_OS_FLUSHFILEBUFFERS 3085 3906 3143 0 71 79 4 0 0
PREEMPTIVE_OS_GETDISKFREESPACE 3159 459 8 0 71 79 10 0 0
PREEMPTIVE_OS_WRITEFILEGATHER 1147 98667 10851 0 71 79 81 2 0
WRITE_COMPLETION 2042 537 128 7 71 79 8 0 0
MEMORY_ALLOCATION_EXT 5544760572 4480403 1665 0 71 2466094 2385 3 0
RESERVED_MEMORY_ALLOCATION_EXT 43561376 68251 1054 0 71 720670 490 2 0
SESSION_WAIT_STATS_CHILDREN 207365 123843 41 19378 71 82172 36559 41 5393

(24 rows affected)





судя по данным, у вас сессия сканирует что-то большое (таблица/индекс), которое находится полностью в буфере
к подобному может приводить неоптимальный план запроса (nested loops vs hash/merge joins) из-за устаревшей статистики, например
13 май 19, 12:01    [21883195]     Ответить | Цитировать Сообщить модератору
 Re: анализ производительности сервера  [new]
_human
Member

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

Так и есть,
Только там статистика актуальная
А код кривой
13 май 19, 14:19    [21883380]     Ответить | Цитировать Сообщить модератору
 Re: анализ производительности сервера  [new]
komrad
Member

Откуда: Msk -> Utrecht
Сообщений: 4929
_human
komrad,

Так и есть,
Только там статистика актуальная
А код кривой

попробуйте ради интереса тот же самый запрос выполнить с хинтом
option (maxdop 1, recompile)

шанс невелик, но может и быстрее сработать
13 май 19, 14:43    [21883425]     Ответить | Цитировать Сообщить модератору
 Re: анализ производительности сервера  [new]
_human
Member

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


komrad
выполнить с хинтом

1-е что попробовал :D

30+ дней
там веб дев sql код написал..
case closed
13 май 19, 15:27    [21883501]     Ответить | Цитировать Сообщить модератору
 Re: анализ производительности сервера  [new]
invm
Member

Откуда: Москва
Сообщений: 8712
komrad
которое находится полностью в буфере
Наоборот.
13 май 19, 15:38    [21883514]     Ответить | Цитировать Сообщить модератору
 Re: анализ производительности сервера  [new]
komrad
Member

Откуда: Msk -> Utrecht
Сообщений: 4929
invm
komrad
которое находится полностью в буфере
Наоборот.

почему?
13 май 19, 15:43    [21883519]     Ответить | Цитировать Сообщить модератору
 Re: анализ производительности сервера  [new]
invm
Member

Откуда: Москва
Сообщений: 8712
komrad
почему?
Там полно PAGEIOLATCH_* и IO_COMPLETION. Гораздо больше, чем PAGELATCH_
13 май 19, 15:47    [21883524]     Ответить | Цитировать Сообщить модератору
 Re: анализ производительности сервера  [new]
komrad
Member

Откуда: Msk -> Utrecht
Сообщений: 4929
invm
komrad
почему?
Там полно PAGEIOLATCH_* и IO_COMPLETION. Гораздо больше, чем PAGELATCH_

не совсем так
в выборке джойн серверных (бежевое слева) ожиданий и сессионных (зеленое справа)
в зеленой части выделяется преимущественно только CXPACKET

К сообщению приложен файл. Размер - 45Kb
13 май 19, 15:51    [21883530]     Ответить | Цитировать Сообщить модератору
 Re: анализ производительности сервера  [new]
TaPaK
Member

Откуда: Kiev
Сообщений: 6420
komrad,

а CXPACKET это типа чтение из буфера что ли?
13 май 19, 16:02    [21883539]     Ответить | Цитировать Сообщить модератору
 Re: анализ производительности сервера  [new]
invm
Member

Откуда: Москва
Сообщений: 8712
komrad
в зеленой части выделяется преимущественно только CXPACKET
CXPACKET свидетельствует о параллелизме в запросе, а не о том, что данные читаются из BP.
И такое ожидание вообще генерируется всегда при праллельном плане.
13 май 19, 16:09    [21883547]     Ответить | Цитировать Сообщить модератору
 Re: анализ производительности сервера  [new]
komrad
Member

Откуда: Msk -> Utrecht
Сообщений: 4929
invm,

остальные _сессионные_ ожидания очень малы, поэтому я и написал, что данные судя по всему в кэше
или я неправ?
13 май 19, 16:17    [21883554]     Ответить | Цитировать Сообщить модератору
 Re: анализ производительности сервера  [new]
invm
Member

Откуда: Москва
Сообщений: 8712
komrad,

Посмотрите, например, сессионные для PAGEIOLATCH_SH.
13 май 19, 16:56    [21883576]     Ответить | Цитировать Сообщить модератору
 Re: анализ производительности сервера  [new]
komrad
Member

Откуда: Msk -> Utrecht
Сообщений: 4929
invm
komrad,

Посмотрите, например, сессионные для PAGEIOLATCH_SH.

это которые 10 тысяч?
они же копеечные

тогда уж LATCH_EX, которых в 7 раз больше
13 май 19, 17:07    [21883592]     Ответить | Цитировать Сообщить модератору
 Re: анализ производительности сервера  [new]
TaPaK
Member

Откуда: Kiev
Сообщений: 6420
гадание без запроса, такое себе развлечение, там какой-нить кривой мерж и стоять может совесем не на ожиданиях а на блокировках и тп
13 май 19, 17:10    [21883595]     Ответить | Цитировать Сообщить модератору
 Re: анализ производительности сервера  [new]
TaPaK
Member

Откуда: Kiev
Сообщений: 6420
хотя то что нагенеривает 1С лучше и не смотреть
13 май 19, 17:13    [21883598]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: [1] 2   вперед  Ctrl      все
Все форумы / Microsoft SQL Server Ответить