Добро пожаловать в форум, Guest >> Войти | Регистрация | Поиск | Правила | | В избранное | Подписаться | ||
Все форумы / Microsoft SQL Server |
![]() ![]() |
Топик располагается на нескольких страницах: ←Ctrl назад 1 [2] 3 вперед Ctrl→ все |
hichnik_andrei Member Откуда: Сообщений: 29 |
Да |
||||||||
12 дек 19, 22:03 [22039186] Ответить | Цитировать Сообщить модератору |
hichnik_andrei Member Откуда: Сообщений: 29 |
Как-нибудь точнее можно? |
||||
12 дек 19, 22:05 [22039188] Ответить | Цитировать Сообщить модератору |
alexeyvg Member Откуда: Moscow Сообщений: 31783 |
Если вы его делаете для файлов базы, то это замедляет работу базы из за сильной фрагментации. Если вы его делаете для файлов лога, то это замедляет работу базы из за необходимости увеличивать лог после уменьшения. Особенно печально, если для файла установлено маленькое автоувеличение, например, 1 мб - тогда этом может вызывать заметное замедление. Идеально - установить достаточные размеры файлов базы, и шринк не делать. |
||||||||
12 дек 19, 22:08 [22039190] Ответить | Цитировать Сообщить модератору |
felix_ff Member Откуда: Moscow Сообщений: 1698 |
hichnik_andrei, ну шринк конечно зло, но это не объясняет поведения почему после рестарта как ТС говорит проблема исчезает. покажите на всякий случай select /*[name],*/ [is_auto_shrink_on], [is_auto_update_stats_on], [is_auto_update_stats_async_on], [is_parameterization_forced], [log_reuse_wait_desc] from sys.databases; вам бы диагностику проводить именно тогда когда вы на сервере реально наблюдаете проблемы производительности. Сообщение было отредактировано: 12 дек 19, 22:10 |
12 дек 19, 22:09 [22039191] Ответить | Цитировать Сообщить модератору |
hichnik_andrei Member Откуда: Сообщений: 29 |
alexeyvg, Да шаг 1Мб, сколько лучше сделать? К сообщению приложен файл. Размер - 27Kb |
12 дек 19, 22:14 [22039193] Ответить | Цитировать Сообщить модератору |
Владислав Колосов Member Откуда: Сообщений: 8350 |
Можно включить оценку унаследованную кратности (legacy cardinality estimation) для базы и понаблюдать. Если поможет - то так и оставить. |
12 дек 19, 22:18 [22039197] Ответить | Цитировать Сообщить модератору |
hichnik_andrei Member Откуда: Сообщений: 29 |
[quot felix_ff#22039191]hichnik_andrei, покажите на всякий случай select /*[name],*/ [is_auto_shrink_on], [is_auto_update_stats_on], [is_auto_update_stats_async_on], [is_parameterization_forced], [log_reuse_wait_desc] from sys.databases; К сообщению приложен файл. Размер - 45Kb |
12 дек 19, 22:19 [22039198] Ответить | Цитировать Сообщить модератору |
felix_ff Member Откуда: Moscow Сообщений: 1698 |
hichnik_andrei, давайте уж в догонку тогда подробности глянем: select [counter_name], [instance_name], [cntr_value] from sys.dm_os_performance_counters where [object_name] = 'SQLServer:Locks' and [counter_name] in ('Lock Requests/sec', 'Lock Timeouts/sec', 'Number of Deadlocks/sec', 'Lock Waits/sec') union select [counter_name], [instance_name], [cntr_value] from sys.dm_os_performance_counters where [object_name] = 'SQLServer:Databases' and [counter_name] in ('Log Flush Waits/sec', 'Log Flush Wait Time') union select [counter_name], [instance_name], [cntr_value] from sys.dm_os_performance_counters where [object_name] = 'SQLServer:Wait Statistics' order by [counter_name], [instance_name], [cntr_value] desc |
12 дек 19, 22:21 [22039199] Ответить | Цитировать Сообщить модератору |
hichnik_andrei Member Откуда: Сообщений: 29 |
felix_ff, пару мин и сброшу, бэкап по расписанию делается |
12 дек 19, 22:26 [22039201] Ответить | Цитировать Сообщить модератору |
hichnik_andrei Member Откуда: Сообщений: 29 |
Сообщение было отредактировано: 13 дек 19, 01:36 |
||||||
12 дек 19, 22:36 [22039205] Ответить | Цитировать Сообщить модератору |
felix_ff Member Откуда: Moscow Сообщений: 1698 |
hichnik_andrei, вы если в текущий (прямо сейчас) момент проблемы с производительностью наблюдаете то используйте или процедуру sp_WhoIsActive она информативнее или прям запрос выполните: select [session_id], [exec_context_id], [blocking_session_id], [blocking_exec_context_id], [wait_duration_ms], [wait_type], [resource_description] from sys.dm_os_waiting_tasks where [blocking_session_id] is not null or [wait_duration_ms] > 10000 если возвращаются строки с каким либо достаточно долгим wait_type надо предметно разбираться что и кого сессии ждут. |
12 дек 19, 22:36 [22039206] Ответить | Цитировать Сообщить модератору |
felix_ff Member Откуда: Moscow Сообщений: 1698 |
hichnik_andrei, картинка для китайцев. вы сами можете разобрать что там нарисованно? :) |
12 дек 19, 22:37 [22039208] Ответить | Цитировать Сообщить модератору |
hichnik_andrei Member Откуда: Сообщений: 29 |
felix_ff, редактировал уже))) К сообщению приложен файл. Размер - 105Kb |
12 дек 19, 22:39 [22039210] Ответить | Цитировать Сообщить модератору |
hichnik_andrei Member Откуда: Сообщений: 29 |
felix_ff, К сообщению приложен файл. Размер - 128Kb |
12 дек 19, 22:40 [22039211] Ответить | Цитировать Сообщить модератору |
hichnik_andrei Member Откуда: Сообщений: 29 |
felix_ff, К сообщению приложен файл. Размер - 146Kb |
12 дек 19, 22:40 [22039212] Ответить | Цитировать Сообщить модератору |
Yasha123 Member Откуда: Сообщений: 1955 |
статистику соберите хотя бы за сутки, т.е. не рестарьте сервер каждый час. но даже за короткий период у вас на первом месте LCK_M_IX. значит, или на страницы, или на таблицы целиком ждут IХ. это означает, что кто-то апдэйтит тучу строк за 1 стэйтмент, раз там уже чей-то Х |
||||||||
12 дек 19, 23:44 [22039252] Ответить | Цитировать Сообщить модератору |
alexeyvg Member Откуда: Moscow Сообщений: 31783 |
|
||||
12 дек 19, 23:45 [22039253] Ответить | Цитировать Сообщить модератору |
alexeyvg Member Откуда: Moscow Сообщений: 31783 |
hichnik_andrei, Счётчики (и вообще результаты запросов) лучше копировать из SSMS, и выкладывать в таблице CSV=t и в спойлере:
|
|
12 дек 19, 23:53 [22039255] Ответить | Цитировать Сообщить модератору |
komrad Member Откуда: Сообщений: 5516 |
не помешает поставить хотя бы второй сервис-пак https://sqlserverbuilds.blogspot.com/#sql2016x |
||||
13 дек 19, 00:38 [22039270] Ответить | Цитировать Сообщить модератору |
felix_ff Member Откуда: Moscow Сообщений: 1698 |
у него там их всего 40 штук и общее время ожидания было 26 секунд на все IX. по первому скрину я бы сказал что система особо ничего и не ждет. А вот по счетчикам можно предположить следующее: в топах запросов блокировок два типа: Metadata и Object на metadata причем приходится порядка 38% процентов запросов на блокировки. на базе включен auto_update_statistics, предположительно в бд преобладает в основном Ad-Hoc нагрузка что дает такую значительную разницу в типах блокировок на метаданные. (вообще метаданных хренова туча может лочиться но чаще всего лично мне встречался stats) на втором месте object и только после него Key следовательно достаточно часто запросы идут с локом всей кучи/кластера. RID блокировок мало Key много, в целом по базе преобладают кластеризованные таблицы. таймауты в основном по блокировкам ключей правда может там вообще nowait типы я с счетчиком промазал немного. итого имхо: по видимому у вас в бд возникают достаточно часто сканирующие запросы при этом скорее всего это ad-hoc. Вам необходимо посмотреть степень преобладающей нагрузки на базу: with x as ( select pool_id, cacheobjtype, objtype, size_in_bytes, refcounts, usecounts, sum([size_in_bytes]) over (partition by pool_id, cacheobjtype, objtype order by 1/0) * 100 / sum([size_in_bytes]) over () as [percentage] from sys.dm_exec_cached_plans ) select pool_id, cacheobjtype, objtype, sum(size_in_bytes) as [bytes], sum(refcounts) as refs, count(1) as cnt, sum(usecounts) as [uses], max(percentage) as [percentage] from x group by pool_id, cacheobjtype, objtype если процентно преобладает Adhoc посмотрите в сторону sp_configure 'optimize for ad hoc workloads' если 0 можно поставить в 1 необходимо предметно смотреть почему так часто вызываеются блокировки объектов вместо ключей => недостающие/неоптимальные индексы на таблицах если ad-hod нагрузка значительно преобладает над Proc, и вы знаете что на бд много пишушей нагрузки то auto_update_stats на базе можно или перевести в асинхронную модель или отключить и вешать отдельный джоб на обновление статистики. Сообщение было отредактировано: 13 дек 19, 01:39 |
||||||||
13 дек 19, 01:34 [22039290] Ответить | Цитировать Сообщить модератору |
alexeyvg Member Откуда: Moscow Сообщений: 31783 |
|
||||
13 дек 19, 09:52 [22039388] Ответить | Цитировать Сообщить модератору |
Yasha123 Member Откуда: Сообщений: 1955 |
на моем нынешнем месте работы картинка была ровно такая. но не потому, что сервер "ничего не ждал", а потому, что перегружали по неск. раз в день, когда висело вообще все. а висели все, т.к. все лезут в основную таблицу, а в ней мой нынешний начальничег апдэйтил миллионы строк одним стэйтментом. так что там был escalation до таблицы через несколько секунд его деятельности. ну и в связи с тем, что все блокировалось, они свои более мелкие апдэйты нескольких таблиц завернули в транзакции, типа если уж отвалится, то чтобы все целиком. и таймауты навешали. и вот это все держало локи до конца таймаута, т.к. основная таблица была все равно недоступна. ---- пускай хотя бы за день соберет статистику, а первое место в ней все равно настораживает
вот именно. причем индексы могут даже и быть, но если способные граждане миллионы разом апдэйтят, никакие индексы не спасут |
||||||||
13 дек 19, 10:45 [22039442] Ответить | Цитировать Сообщить модератору |
hichnik_andrei Member Откуда: Сообщений: 29 |
Сегодня опять сервер начал тормозить, а потом выдал ошибку 1с К сообщению приложен файл. Размер - 7Kb |
13 дек 19, 15:57 [22039890] Ответить | Цитировать Сообщить модератору |
Yasha123 Member Откуда: Сообщений: 1955 |
но это же 1С не хватило памяти, а не серверу. а вы еще и недовольны, что сервер мало отъел. |
13 дек 19, 16:03 [22039904] Ответить | Цитировать Сообщить модератору |
Sergey Sizov Member Откуда: Сообщений: 1564 |
hichnik_andrei, ну вот и причина тормозов. Только к sql это не имеет ни малейшего отношения. Ибо это проблемы сервера 1с. |
13 дек 19, 16:03 [22039906] Ответить | Цитировать Сообщить модератору |
Топик располагается на нескольких страницах: ←Ctrl назад 1 [2] 3 вперед Ctrl→ все |
Все форумы / Microsoft SQL Server | ![]() |