Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Microsoft SQL Server Новый топик    Ответить
Топик располагается на нескольких страницах: Ctrl  назад   1 [2] 3   вперед  Ctrl      все
 Re: Тормозить SQL сервер. Не могу разобраться почему.  [new]
CrazyDr1v3r
Guest
TaPaK
из-за двери: Удел 1с-ников открыть QUERY STORE и жмакать FORCE PLAN на запросах ну может ещё RESOURCE GOVERNOR, хотя и не уверен


Ага, в 2008-м сиквеле ))))
27 июл 17, 13:39    [20679664]     Ответить | Цитировать Сообщить модератору
 Re: Тормозить SQL сервер. Не могу разобраться почему.  [new]
invm
Member

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

Когда "тормозит", не очень много толку смотреть кумулятивную статистику ожиданий.
Смотрите в момент "тормозов", что есть в sys.dm_exec_requests для сессий со статусами running, runnable и suspended.
27 июл 17, 14:45    [20679906]     Ответить | Цитировать Сообщить модератору
 Re: Тормозить SQL сервер. Не могу разобраться почему.  [new]
nata44845
Member

Откуда: Красноярск
Сообщений: 355
invm,

Там тормозит какой-то общий момент.
Когда тормозит звонят админу "все плохо"
Админ идет ко мне, посмотри

Я не гинеколог по ораклу больше, но посмотреть могу
27 июл 17, 17:58    [20680728]     Ответить | Цитировать Сообщить модератору
 Re: Тормозить SQL сервер. Не могу разобраться почему.  [new]
Дедушка
Member

Откуда: Город трёх революций
Сообщений: 5111
nata44845
Админ идет ко мне, посмотри

Я не гинеколог по ораклу больше, но посмотреть могу
т.е. вы не знаете ни сиквела, ни 1Ски и при этом пытаетесь лечить больного методом тыка?
почему не рассматриваете вариант позвать батюшку окропить сервак святой водицей?
28 июл 17, 12:56    [20682380]     Ответить | Цитировать Сообщить модератору
 Re: Тормозить SQL сервер. Не могу разобраться почему.  [new]
nata44845
Member

Откуда: Красноярск
Сообщений: 355
Один за сутки так

WaitTypeWait_SResource_SSignal_SWaitCountPercentageAvgWait_SAvgRes_SAvgSig_S
ASYNC_NETWORK_IO943.45827.03116.42859985729.120.00010.00010.0000
PREEMPTIVE_OS_WAITFORSINGLEOBJECT824.49824.490.00510049125.450.00020.00020.0000
SOS_SCHEDULER_YIELD405.6711.96393.711465128812.520.00000.00000.0000
LCK_M_S218.17218.160.022216.730.98720.98710.0001
PAGEIOLATCH_SH193.83192.651.186612575.980.00030.00030.0000
ASYNC_IO_COMPLETION160.31160.260.058824.950.18180.18170.0001
PAGEIOLATCH_EX92.8792.350.524722252.870.00020.00020.0000
LCK_M_IX63.7163.710.0091.977.07877.07870.0000
BACKUPBUFFER51.5749.192.382042581.590.00030.00020.0000
BACKUPIO51.3750.281.101652391.590.00030.00030.0000
CXPACKET44.7942.792.0187321.380.00510.00490.0002
WRITELOG30.6124.795.821464300.940.00020.00020.0000


А вот на втором CMEMTHREAD зашкаливает
Посмотрела одну базу, дефрагментация некоторых индексов 99%

SELECT 
       DatbaseName = DB_NAME(),
       TableName = OBJECT_NAME(s.[object_id]),
       IndexName = i.name,
       i.type_desc,
       [Fragmentation %] = ROUND(avg_fragmentation_in_percent,2),
       page_count,
       partition_number,
       'alter index [' + i.name + '] on [' + sh.name + '].['+ OBJECT_NAME(s.[object_id]) + '] REBUILD' + case
                                                                                                           when p.data_space_id is not null then ' PARTITION = '+convert(varchar(100),partition_number)
                                                                                                           else ''
                                                                                                         end --+ ' with(maxdop = 4,  SORT_IN_TEMPDB = on)' 
                                                                                                         [sql]
  FROM sys.dm_db_index_physical_stats(db_id(),null, null, null, null) s
  INNER JOIN sys.indexes as i ON s.[object_id] = i.[object_id] AND
                                 s.index_id = i.index_id
  left join sys.partition_schemes as p on i.data_space_id = p.data_space_id
  left join sys.objects o on  s.[object_id] = o.[object_id]
  left join sys.schemas as sh on sh.[schema_id] = o.[schema_id]
  WHERE s.database_id = DB_ID() AND
        i.name IS NOT NULL AND
        OBJECTPROPERTY(s.[object_id], 'IsMsShipped') = 0 and
        page_count > 100 and
        avg_fragmentation_in_percent > 10
  ORDER BY 4, page_count


По скрипту не могу понять правильный или нет (сперто) , есть базы, где фрагментация в 70% за пару дней уходит, что вызывает у меня сомнения

Добавляем ежедневный мейнтанс по индексации и статистике
28 июл 17, 12:56    [20682381]     Ответить | Цитировать Сообщить модератору
 Re: Тормозить SQL сервер. Не могу разобраться почему.  [new]
invm
Member

Откуда: Москва
Сообщений: 9349
nata44845
Там тормозит какой-то общий момент.
...
Я не гинеколог по ораклу больше, но посмотреть могу
Т.е. вы по ораклу, но как искать "общие моменты" в MSSQL очень хорошо знаете?
Остается только пожелать удачи в поисках...
28 июл 17, 13:14    [20682476]     Ответить | Цитировать Сообщить модератору
 Re: Тормозить SQL сервер. Не могу разобраться почему.  [new]
nata44845
Member

Откуда: Красноярск
Сообщений: 355
invm,

Я не вижу особых отличий, есть список задержек, есть причины

CMEMTHREAD 0x207 Это waittype указывает, что идентификатор SPID ожидает доступа к объекту памяти поточно ориентированными. Сериализации гарантирует, что в то время как пользователи, выделение и освобождение памяти из объектов памяти, другие SPID, которые пытаются выполнить ту же задачу придется ждать и CMEMTHREAD waittype имеет значение при ожидании SPID.

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


Вот, возможно действительно дело в параметризации
28 июл 17, 13:31    [20682574]     Ответить | Цитировать Сообщить модератору
 Re: Тормозить SQL сервер. Не могу разобраться почему.  [new]
nata44845
Member

Откуда: Красноярск
Сообщений: 355
Ну что пока могу сказать, на втором сервере проставила на всех БД принудительную параметризацию
Перегрузили

Статистика ожиданий за 2 часа

WaitTypeWait_SResource_SSignal_SWaitCountPercentageAvgWait_SAvgRes_SAvgSig_S
WRITELOG93.6885.328.364226332.350.00220.00200.0002
OLEDB80.8780.870.007759427.930.00100.00100.0000
CMEMTHREAD38.2635.922.34619113.210.00620.00580.0004
ASYNC_NETWORK_IO27.9720.887.093727469.660.00010.00010.0000
PREEMPTIVE_OS_WAITFORSINGLEOBJECT20.7920.790.002295187.180.00010.00010.0000
PAGEIOLATCH_SH11.3711.110.26339493.930.00030.00030.0000
PAGEIOLATCH_EX3.813.730.08120091.310.00030.00030.0000



На первом сервере за трое суток так, причем сначала в статистике CXPACKET не было, но все равно вылазит, да и ладно

WaitTypeWait_SResource_SSignal_SWaitCountPercentageAvgWait_SAvgRes_SAvgSig_S
CXPACKET32033.4819885.9712147.511602920939.420.00200.00120.0008
OLEDB23399.7923399.790.0074046159828.790.00000.00000.0000
BACKUPBUFFER3226.053163.6062.4543761153.970.00070.00070.0000
ASYNC_IO_COMPLETION3188.373187.950.4150943.920.62590.62580.0001
WRITELOG2686.132272.54413.60129852253.310.00020.00020.0000
ASYNC_NETWORK_IO2567.312251.87315.45261867113.160.00010.00010.0000
BACKUPIO2369.302326.9542.3529000412.920.00080.00080.0000
PREEMPTIVE_OS_WAITFORSINGLEOBJECT2273.212273.210.00174287892.800.00010.00010.0000
PAGEIOLATCH_SH1725.801713.2612.5464564222.120.00030.00030.0000
PAGEIOLATCH_EX1702.131668.3233.81184274402.090.00010.00010.0000
SOS_SCHEDULER_YIELD1652.9231.851621.06441131302.030.00000.00000.0000
BACKUPTHREAD1113.101112.810.29242441.370.04590.04590.0000
31 июл 17, 09:44    [20686914]     Ответить | Цитировать Сообщить модератору
 Re: Тормозить SQL сервер. Не могу разобраться почему.  [new]
aleksrov
Member

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

Другой сервер, это другой сервер. Посмотрите сами, что это все значит: https://www.sqlskills.com/help/waits/
31 июл 17, 09:53    [20686929]     Ответить | Цитировать Сообщить модератору
 Re: Тормозить SQL сервер. Не могу разобраться почему.  [new]
nata44845
Member

Откуда: Красноярск
Сообщений: 355
aleksrov,

да я понимаю, там и баз поболе сотни будет
Смотрю в истории тоже возникала данная проблема?
31 июл 17, 10:16    [20686988]     Ответить | Цитировать Сообщить модератору
 Re: Тормозить SQL сервер. Не могу разобраться почему.  [new]
aleksrov
Member

Откуда:
Сообщений: 948
nata44845
aleksrov,

да я понимаю, там и баз поболе сотни будет
Смотрю в истории тоже возникала данная проблема?


Какая?
31 июл 17, 10:21    [20686999]     Ответить | Цитировать Сообщить модератору
 Re: Тормозить SQL сервер. Не могу разобраться почему.  [new]
nata44845
Member

Откуда: Красноярск
Сообщений: 355
aleksrov,

С параллелизмом и прочим
31 июл 17, 10:26    [20687012]     Ответить | Цитировать Сообщить модератору
 Re: Тормозить SQL сервер. Не могу разобраться почему.  [new]
aleksrov
Member

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

:) Нет, я вам пытаюсь помочь и дал ссылку чтобы вы посмотрели что каждый тип означает и дальше искали из за чего он может быть вызван. И у меня на многих серверах cxpacket на 1 месте и это не проблема, более того он 68% на главном сервере, и все ровно это не проблема конкретно для моей системы, т.к. нагрузка смешанная.
31 июл 17, 10:35    [20687044]     Ответить | Цитировать Сообщить модератору
 Re: Тормозить SQL сервер. Не могу разобраться почему.  [new]
человек_ниоткуда
Guest
nata44845
Сервер 1Сный, мейнтенс план раз в неделю по индексации и статистикам

Раз в сутки статистики минимум.
Если тормозит запрос какой - и обновление статистик по всем таблам помогает, то раз в 2 часа статы по много-меняемым таблам из этого запроса обновлять.
31 июл 17, 10:41    [20687058]     Ответить | Цитировать Сообщить модератору
 Re: Тормозить SQL сервер. Не могу разобраться почему.  [new]
Владислав Колосов
Member

Откуда:
Сообщений: 7762
2 миллисекунды синхронизации - незначительно, хуже дело обстоит с дисками - ASYNC_IO_COMPLETION. Если начнется работа с большими таблицами, т.е. пойдут физические чтения, то деградация выполнения запроса может быть существенной.
31 июл 17, 10:44    [20687073]     Ответить | Цитировать Сообщить модератору
 Re: Тормозить SQL сервер. Не могу разобраться почему.  [new]
nata44845
Member

Откуда: Красноярск
Сообщений: 355
Владислав Колосов,

Вижу, но там и количество ожиданий не существенное по сравнению с прочими.
31 июл 17, 10:48    [20687096]     Ответить | Цитировать Сообщить модератору
 Re: Тормозить SQL сервер. Не могу разобраться почему.  [new]
nata44845
Member

Откуда: Красноярск
Сообщений: 355
Владислав Колосов,

Если учесть, что это за выходные, а там в основном мейтенс плане (я его не трогала, не мое) индексация в субботу днем, статистика тоже днем, можно считать это совпадением пиков нагрузки.
В предыдущем запросе за сутки он был всего 160 секунд.
31 июл 17, 10:53    [20687124]     Ответить | Цитировать Сообщить модератору
 Re: Тормозить SQL сервер. Не могу разобраться почему.  [new]
Mind
Member

Откуда: Лучший город на Земле
Сообщений: 2322
Владислав Колосов
2 миллисекунды синхронизации - незначительно, хуже дело обстоит с дисками - ASYNC_IO_COMPLETION. Если начнется работа с большими таблицами, т.е. пойдут физические чтения, то деградация выполнения запроса может быть существенной.
Это ожидания на бэкапах, при чем тут большие таблицы?
31 июл 17, 22:44    [20689735]     Ответить | Цитировать Сообщить модератору
 Re: Тормозить SQL сервер. Не могу разобраться почему.  [new]
Mind
Member

Откуда: Лучший город на Земле
Сообщений: 2322
nata44845
На первом сервере за трое суток так, причем сначала в статистике CXPACKET не было, но все равно вылазит, да и ладно
CXPACKET очень тупое ожидание, ибо если 1 запрос будет выполнятся на 4 ядрах, при чем на 3 ядрах он выполнится за 10 секунд, а на 4-м ядре за 15, то сколько вы думаете будет засчитано в CXPACKET ожидания? 5 секунд? Ага, как же, будет - 45 секунд. Если же все распаралелится равномерно, то в ожиданиях будет 40 секунд. Ну и как вам эта информация поможет? Да никак.
31 июл 17, 22:49    [20689739]     Ответить | Цитировать Сообщить модератору
 Re: Тормозить SQL сервер. Не могу разобраться почему.  [new]
nata44845
Member

Откуда: Красноярск
Сообщений: 355
Самое нехорошее, что несмотря на все это и красивую статистику, там по утрам висит система вплоть до перезагрузки (2008 R2).
Причем красивый цп (0.2%), красивая память, и красивая работа с винтом (0.01).

RamMap показывает AWE 100 ГБ (из 200, но свободных все равно еще 50ГБ остается), перезапуск MSSQL этот AWE убирает, но проблему с тормозами не решает.

То есть перегрузили - все красиво, утром пришли - все висит.
С учетом того, что в планировщике ночью бэкапы и индексация дело в них что ли?
1 авг 17, 07:09    [20689958]     Ответить | Цитировать Сообщить модератору
 Re: Тормозить SQL сервер. Не могу разобраться почему.  [new]
nata44845
Member

Откуда: Красноярск
Сообщений: 355
ПС. Галочка AWE не стоит, проблема похожая вот, но непонятно решили или нет

http://www.forum.mista.ru/topic.php?id=591981
1 авг 17, 07:18    [20689966]     Ответить | Цитировать Сообщить модератору
 Re: Тормозить SQL сервер. Не могу разобраться почему.  [new]
aleksrov
Member

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

Каким боком тут бекап? Пол говорит, а он умный дядька, As general guidance for I/O wait types, if the wait time is higher than acceptable I/O latencies for your environment, investigate whether the I/O subsystem is overloaded or has a configuration problem. See the PAGEIOLATCH_SH wait type for more information.
Вы видимо с BACKUPIO и BACKUPTHREAD попутали. Эти два типа к примеру у нас по 2%, так как Backup пишется на сетевые ооооочень медленные носители.
И этот тип считается не так. https://www.mssqltips.com/sqlservertip/2027/a-closer-look-at-cxpacket-wait-type-in-sql-server/
1 авг 17, 07:20    [20689970]     Ответить | Цитировать Сообщить модератору
 Re: Тормозить SQL сервер. Не могу разобраться почему.  [new]
aleksrov
Member

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

Даже если галочка не стоит SQL по прежнему может использовать это api для выделения памяти когда у вас стоит locked pages in memory permissions.
И не читайте вы форумы 1с'ников. Там они такие извращения предлагают, которые даже читать противно, причем люди соглашаются. Я ни разу не встречал 1сника который хоть что-то сображал в СУБД.
1 авг 17, 07:28    [20689980]     Ответить | Цитировать Сообщить модератору
 Re: Тормозить SQL сервер. Не могу разобраться почему.  [new]
nata44845
Member

Откуда: Красноярск
Сообщений: 355
aleksrov,
А где это снять? А то я смотрю AWR растет (уже 17ГБ) и видимо за сутки нарастает до сотни.


https://www.sql.ru/forum/1205985/sql-server-pamyat
Вот такая же ерунда, там советуют ограничивать кэш базы. В параметрах базы такое не увидела.
1 авг 17, 07:57    [20690012]     Ответить | Цитировать Сообщить модератору
 Re: Тормозить SQL сервер. Не могу разобраться почему.  [new]
aleksrov
Member

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

https://sqlserverperformance.wordpress.com/2011/02/14/sql-server-and-the-lock-pages-in-memory-right-in-windows-server/

Если у вас это действительно включено и не стоит maxmemory для sql, то это конечно плохо. SQL забирает себе память, а обратно не отдает.
1 авг 17, 08:05    [20690026]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: Ctrl  назад   1 [2] 3   вперед  Ctrl      все
Все форумы / Microsoft SQL Server Ответить