ReSQL.ru
     
powered by simpleCommunicator - 2.0.50     © 2025 Programmizd 02
Мобильная версия    Контакт    Правила    FAQ    Помощь
Доб. в избранное | Игнор. тему | Прикреп. тему | Пометить прочит. / непрочит. | Фильтр
Форумы / Microsoft SQL Server [игнор отключен] [закрыт для гостей] / Скачет время выполнения
14 сообщений из 14, страница 1 из 1
Скачет время выполнения
    #40094609
Фотография Megabyte
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Megabyte
Участник
Коллеги, сегодня появилась странная проблема со стабильным процессом.
Проца, которая в цикле обрабатывает пачку записей из одной таблицы(внури на каждую запись вызывается другая проца).

Автор процы не я. Работает стабильно уже более года.

Время выполнения то почти мгновенно, то зависает с типом ожидания SOS_SCHEDULER_YIELD на куске кода, в котором вроде бы ничего необычного. При этом пока не срубить процесс, так и будет висеть. Хотя после сброса может опять же выполниться мгновенно.

Проблемный кусок кода, на котором висит ожидание SOS_SCHEDULER_YIELD:
Код: sql
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
declare @tech_tran_pares table 
  (
   FirstLeg	int,
   LastLeg int
  )
; with AAA AS (
select tr.LEG_ID, cl.DST_IP, cl.CREATED, cl.ENDED, cl.DST_ID
from #Transfers tr
join dbo.CALL_LEGS cl (nolock)
  on cl.SESSION_ID = tr.SESSION_ID
 and cl.LEG_ID = tr.LEG_ID
              )
insert into @tech_tran_pares
select FirstLeg = a1.LEG_ID, 
       LastLeg = a2.LEG_ID
from AAA a1
join AAA a2
  on a1.LEG_ID < a2.LEG_ID
 and a1.DST_ID = a2.DST_ID
 and a1.DST_IP != a2.DST_ID
 and datediff(second, a1.ENDED, a2.CREATED) between 0 and 1


CALL_LEGS - большая таблица. На всякий обновил статистику.
#Transfers - времянка. Записей там от 1 до 4 может быть.

Код процы изучил по шагам, никакого куска кода, который внезапно стал работать дольше, не заметил. Но на всякий по большинству таблиц обновил статистику.

Я в курсе, что SOS_SCHEDULER_YIELD - это означает ожидание процессорного времени.
Сервер БД на виртуалке. Со слов админа на виртуалке повышенного потребления ЦПУ не наблюдается. Сама вирт. машина с MS SQL тоже не кушает сильно много.

Вопрос: тип ожидания SOS_SCHEDULER_YIELD - это всегда только ожидание процессорного времени?

У меня закончились идеи, что еще посмотреть и куда копать, тем более проблема плавающая? Буду рад любым идеям.
---
Проходя мимо разложенных граблей, ты теряешь драгоценный опыт. (с)
...
Рейтинг: 0 / 0
01.09.2021, 20:51
| Ответить | Цитировать | Написать  
Скачет время выполнения
    #40094611
flexgen
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
flexgen
Участник
Megabyte,

Я бы предположил что:
  • за год количество данных в таблицах сильно увеличилось
  • индексов, подходящих для запросов, нет
  • статистика по таблицам и индексам не собирается
...
Рейтинг: 0 / 0
01.09.2021, 20:55
| Ответить | Цитировать | Написать  
Скачет время выполнения
    #40094612
Фотография Megabyte
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Megabyte
Участник
flexgen
Megabyte,

Я бы предположил что:
  • за год количество данных в таблицах сильно увеличилось
  • индексов, подходящих для запросов, нет
  • статистика по таблицам и индексам не собирается
Все это есть: за индексами слежу, статистика по большим таблицам обновляется. Да и при появлении проблемы прошелся и руками обновил по всем участвующим таблицам, о чем написал в посте выше.
Кол-во данных если бы влияло, то запрос тормозил всегда, а тут иногда.
...
Рейтинг: 0 / 0
01.09.2021, 21:03
| Ответить | Цитировать | Написать  
Скачет время выполнения
    #40094614
flexgen
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
flexgen
Участник
Megabyte
flexgen
Megabyte,

Я бы предположил что:
  • за год количество данных в таблицах сильно увеличилось
  • индексов, подходящих для запросов, нет
  • статистика по таблицам и индексам не собирается
Все это есть: за индексами слежу, статистика по большим таблицам обновляется. Да и при появлении проблемы прошелся и руками обновил по всем участвующим таблицам, о чем написал в посте выше.
Кол-во данных если бы влияло, то запрос тормозил всегда, а тут иногда.


Наличие ожидания SOS_SCHEDULER_YIELD говорит о проблемах с CPU
авторThe SQL Server SOS_SCHEDULER_YIELD is a fairly common wait type and it could indicate one of two things:

SQL Server CPU scheduler is utilized properly and is working efficiently

There is a pressure on CPU
Вот здесь довольно подробно описано это ожидание.
...
Рейтинг: 0 / 0
01.09.2021, 21:11
| Ответить | Цитировать | Написать  
Скачет время выполнения
    #40094616
Фотография Megabyte
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Megabyte
Участник
flexgen
Megabyte
пропущено...

Все это есть: за индексами слежу, статистика по большим таблицам обновляется. Да и при появлении проблемы прошелся и руками обновил по всем участвующим таблицам, о чем написал в посте выше.
Кол-во данных если бы влияло, то запрос тормозил всегда, а тут иногда.


Наличие ожидания SOS_SCHEDULER_YIELD говорит о проблемах с CPU
авторThe SQL Server SOS_SCHEDULER_YIELD is a fairly common wait type and it could indicate one of two things:

SQL Server CPU scheduler is utilized properly and is working efficiently

There is a pressure on CPU

Вот здесь довольно подробно описано это ожидание.
Эх, да справку я смотрел не раз. :)

Но я вот только что разобрался. Первый раз такое на моей практике)
Хотя эта статья навела на верную мысль.
авторКогда поток, жертвует себя другому потоку, это создаёт данный вид ожиданий.

У меня установлено ограничение на max кол-во потоков через формулу, найденную где-то в гугле.
С 14.08 в sysprocesses обнаружил кучу незавершенных процессов от одного сервиса(в статусеs leeping). По ходу уперся как-то в лимит потоков\процессов. Прибил эти процессы, все стало выполняться быстро.
...
Рейтинг: 0 / 0
01.09.2021, 21:26
| Ответить | Цитировать | Написать  
Скачет время выполнения
    #40094618
Фотография Megabyte
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Megabyte
Участник
Megabyte
flexgen
пропущено...


Наличие ожидания SOS_SCHEDULER_YIELD говорит о проблемах с CPU
пропущено...

Вот здесь довольно подробно описано это ожидание.

Эх, да справку я смотрел не раз. :)

Но я вот только что разобрался. Первый раз такое на моей практике)
Хотя эта статья навела на верную мысль.
авторКогда поток, жертвует себя другому потоку, это создаёт данный вид ожиданий.


У меня установлено ограничение на max кол-во потоков через формулу, найденную где-то в гугле.
С 14.08 в sysprocesses обнаружил кучу незавершенных процессов от одного сервиса(в статусеs leeping). По ходу уперся как-то в лимит потоков\процессов. Прибил эти процессы, все стало выполняться быстро.
Поторопился с выводами. Несколько минут все было нормально и снова проблемы...
...
Рейтинг: 0 / 0
01.09.2021, 21:30
| Ответить | Цитировать | Написать  
Скачет время выполнения
    #40094636
Владислав Колосов
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Владислав Колосов
Участник
Megabyte,

ищите, кто процессор отбирает, если это виртуалка, то ваши дела плохи, не найдёте виновных ;-)
...
Рейтинг: 0 / 0
01.09.2021, 22:30
| Ответить | Цитировать | Написать  
Скачет время выполнения
    #40094639
Фотография Megabyte
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Megabyte
Участник
Владислав Колосов
Megabyte,

ищите, кто процессор отбирает, если это виртуалка, то ваши дела плохи, не найдёте виновных ;-)

Да я грешил на это. Договорились ребутнуть ночью службу MS SQL. Посмотрим, что как.
...
Рейтинг: 0 / 0
01.09.2021, 22:42
| Ответить | Цитировать | Написать  
Скачет время выполнения
    #40094663
aleks222
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
aleks222
Участник
Megabyte
Коллеги, сегодня появилась странная проблема со стабильным процессом.
Проца, которая в цикле обрабатывает пачку записей из одной таблицы(внури на каждую запись вызывается другая проца).

Автор процы не я. Работает стабильно уже более года.

Время выполнения то почти мгновенно, то зависает с типом ожидания SOS_SCHEDULER_YIELD на куске кода, в котором вроде бы ничего необычного. При этом пока не срубить процесс, так и будет висеть. Хотя после сброса может опять же выполниться мгновенно.

Проблемный кусок кода, на котором висит ожидание SOS_SCHEDULER_YIELD:
Код: sql
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
declare @tech_tran_pares table 
  (
   FirstLeg	int,
   LastLeg int
  )
; with AAA AS (
select tr.LEG_ID, cl.DST_IP, cl.CREATED, cl.ENDED, cl.DST_ID
from #Transfers tr
join dbo.CALL_LEGS cl (nolock)
  on cl.SESSION_ID = tr.SESSION_ID
 and cl.LEG_ID = tr.LEG_ID
              )
insert into @tech_tran_pares
select FirstLeg = a1.LEG_ID, 
       LastLeg = a2.LEG_ID
from AAA a1
join AAA a2
  on a1.LEG_ID < a2.LEG_ID
 and a1.DST_ID = a2.DST_ID
 and a1.DST_IP != a2.DST_ID
 and datediff(second, a1.ENDED, a2.CREATED) between 0 and 1


CALL_LEGS - большая таблица. На всякий обновил статистику.
#Transfers - времянка. Записей там от 1 до 4 может быть.

Код процы изучил по шагам, никакого куска кода, который внезапно стал работать дольше, не заметил. Но на всякий по большинству таблиц обновил статистику.

Я в курсе, что SOS_SCHEDULER_YIELD - это означает ожидание процессорного времени.
Сервер БД на виртуалке. Со слов админа на виртуалке повышенного потребления ЦПУ не наблюдается. Сама вирт. машина с MS SQL тоже не кушает сильно много.

Вопрос: тип ожидания SOS_SCHEDULER_YIELD - это всегда только ожидание процессорного времени?

У меня закончились идеи, что еще посмотреть и куда копать, тем более проблема плавающая? Буду рад любым идеям.
---
Проходя мимо разложенных граблей, ты теряешь драгоценный опыт. (с)


Копать в сторону бездарно написанного запроса.
"CALL_LEGS - большая таблица.", а у вас, как минимум, один лишний join.
Если оптимизатор ошибется с планом - отгребаете то, что отгребаете.

ЗЫ. Запросы вставки в @table_VAR не параллелятся - поэтому внешне CPU не кушается. Нагружен только один поток под завязку.
...
Рейтинг: 0 / 0
02.09.2021, 05:52
| Ответить | Цитировать | Написать  
Скачет время выполнения
    #40094669
aleks222
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
aleks222
Участник
Код: sql
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
with tr as ( select * from #Transfers )
    ,  a  as ( select * from  dbo.CALL_LEGS (nolock) )
insert into @tech_tran_pares
select FirstLeg = a1.LEG_ID, 
       LastLeg = a2.LEG_ID
from tr
        inner join a as a1 on a1.SESSION_ID = tr.SESSION_ID and a1.LEG_ID = tr.LEG_ID
        inner join a as a2 on a2.SESSION_ID = tr.SESSION_ID 
                                      and a1.DST_ID = a2.DST_ID
                                      and a1.LEG_ID < a2.LEG_ID
                                      and a2.CREATED <= dateadd( second, 1,  a1.ENDED ) 
                                      and a1.DST_IP != a2.DST_ID
;
...
Рейтинг: 0 / 0
02.09.2021, 06:38
| Ответить | Цитировать | Написать  
Скачет время выполнения
    #40094683
Фотография Megabyte
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Megabyte
Участник
aleks222


Копать в сторону бездарно написанного запроса.
"CALL_LEGS - большая таблица.", а у вас, как минимум, один лишний join.
Если оптимизатор ошибется с планом - отгребаете то, что отгребаете.

ЗЫ. Запросы вставки в @table_VAR не параллелятся - поэтому внешне CPU не кушается. Нагружен только один поток под завязку.

Код: sql
1.
2.
3.
4.
5.
select tr.LEG_ID, cl.DST_IP, cl.CREATED, cl.ENDED, cl.DST_ID
from #Transfers tr
join dbo.CALL_LEGS cl (nolock)
  on cl.SESSION_ID = tr.SESSION_ID
 and cl.LEG_ID = tr.LEG_ID


Этот подзапрос работает, само собой, по индексу у dbo.CALL_LEGS(индекс по SESSION_ID, LEG_ID в include).
...
Рейтинг: 0 / 0
02.09.2021, 09:14
| Ответить | Цитировать | Написать  
Скачет время выполнения
    #40094687
aleks222
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
aleks222
Участник
Megabyte
aleks222


Копать в сторону бездарно написанного запроса.
"CALL_LEGS - большая таблица.", а у вас, как минимум, один лишний join.
Если оптимизатор ошибется с планом - отгребаете то, что отгребаете.

ЗЫ. Запросы вставки в @table_VAR не параллелятся - поэтому внешне CPU не кушается. Нагружен только один поток под завязку.

Код: sql
1.
2.
3.
4.
5.
select tr.LEG_ID, cl.DST_IP, cl.CREATED, cl.ENDED, cl.DST_ID
from #Transfers tr
join dbo.CALL_LEGS cl (nolock)
  on cl.SESSION_ID = tr.SESSION_ID
 and cl.LEG_ID = tr.LEG_ID


Этот подзапрос работает, само собой, по индексу у dbo.CALL_LEGS(индекс по SESSION_ID, LEG_ID в include).


Ты могешь продолжать верить в чудеса.
Только это контрпродуктивно.

ЗЫ. Если можно не писать соединение в запросе - его надо не писать.
...
Рейтинг: 0 / 0
02.09.2021, 09:20
| Ответить | Цитировать | Написать  
Скачет время выполнения
    #40094691
Фотография Megabyte
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Megabyte
Участник
aleks222
Megabyte
пропущено...

Код: sql
1.
2.
3.
4.
5.
select tr.LEG_ID, cl.DST_IP, cl.CREATED, cl.ENDED, cl.DST_ID
from #Transfers tr
join dbo.CALL_LEGS cl (nolock)
  on cl.SESSION_ID = tr.SESSION_ID
 and cl.LEG_ID = tr.LEG_ID


Этот подзапрос работает, само собой, по индексу у dbo.CALL_LEGS(индекс по SESSION_ID, LEG_ID в include).


Ты могешь продолжать верить в чудеса.
Только это контрпродуктивно.

ЗЫ. Если можно не писать соединение в запросе - его надо не писать.

Я переписал по-своему запрос, заменил табличное представление на временную таблицу. Теперь при зависании указывает на другой кусок запроса. Спасибо, конечно, за идею с запросом.
...
Рейтинг: 0 / 0
02.09.2021, 09:38
| Ответить | Цитировать | Написать  
Скачет время выполнения
    #40094734
Фотография Megabyte
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Megabyte
Участник
В общем, все стало нормально после переписывания куска запроса. Один раз только уже запущенный процесс якобы подвис на другом коде. Сбросил и уже 1.5 все работает штатно. По ходу все же таки с планом подзапроса были проблемы.
Всем спасибо за подсказки.
...
Рейтинг: 0 / 0
02.09.2021, 10:56
| Ответить | Цитировать | Написать  
14 сообщений из 14, страница 1 из 1
Форумы / Microsoft SQL Server [игнор отключен] [закрыт для гостей] / Скачет время выполнения
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Найденые пользователи ...
Разблокировать пользователей ...
Читали тему (0):
Читали форум (0):
Пользователи онлайн (0):
Польз. соглашение
NoSQL.ru       Новости, Чат       Фотоальбом: Участники, Встречи
Закрыть
start [/forum/topic.php?fid=46&fpage=15&tid=1684348]:
 0ms
get settings:
 8ms
get forum list:
 13ms
check forum access:
 3ms
check topic access:
 3ms
track hit:
 40ms
get topic data:
 10ms
get forum data:
 2ms
get page messages:
 46ms
get tp. blocked users:
 1ms
others: 247ms
total:  373ms
созд. / загр.: 373ms
x
x
Закрыть


Просмотр
0 / 0
Close
Debug Console [Select Text]