Очень похоже, а что они проверяют? По времени сходиться?
Если рассматривать работу тасков, то у нас же получается, что обращение может быть уже закрыто, а такс будет висеть и дожидаться своей очереди.
Например, проверка сроков исполнения, казалось бы, простая задача, но только если не плодить таски! Т.к система работает, скажем, по графику 9-18. Срок выставляем на 18-00 скажем по 1000 элементам, (кто-то, не разбираясь, сдвинул срок на одно и тоже время.) выходит апп сервер в 9 утра по мимо своей работы будет исполнять таски. Что может вызывать жуткие тормоза. И нагрузку на сервер.
Григорий Ненашев пишет:
Очень похоже, а что они проверяют? По времени сходиться?
Если рассматривать работу тасков, то у нас же получается, что обращение может быть уже закрыто, а такс будет висеть и дожидаться своей очереди.
Например, проверка сроков исполнения, казалось бы, простая задача, но только если не плодить таски! Т.к система работает, скажем, по графику 9-18. Срок выставляем на 18-00 скажем по 1000 элементам, (кто-то, не разбираясь, сдвинул срок на одно и тоже время.) выходит апп сервер в 9 утра по мимо своей работы будет исполнять таски. Что может вызывать жуткие тормоза. И нагрузку на сервер.
Чисто теоретически, это могло быть, но сегодня я проверил что могло бы вызвать всплеск отложенных заданий, но так и не нашёл ничего (смотрел по правилам, где есть отложенные задания. Соответственно искал заявки, подпадающие под эти правила). Да и разве при срабатывании отложенных заданий, создаётся отдельное подключение к SQL?
Все таки параметр Threadpool size 60, на мой взгляд, много… у меня 16 при условии, что в online доходит до 360-380 человек. И кол.сессий порог 18.
При этом 4 сервера держат пользователей и 2 сервера отвечают за почту.
Баланс пользователей один к одному.
Если не возможно определить логически, тогда нужно изучать профайлер. Других путей нет. Раз это скуль повисает, нужно искать строчку, после которой возникает зависание. Судя по проблеме их, может быть несколько….
Григорий Ненашев пишет:
Все таки параметр Threadpool size 60, на мой взгляд, много… у меня 16 при условии, что в online доходит до 360-380 человек. И кол.сессий порог 18.
При этом 4 сервера держат пользователей и 2 сервера отвечают за почту.
Баланс пользователей один к одному.
Если не возможно определить логически, тогда нужно изучать профайлер. Других путей нет. Раз это скуль повисает, нужно искать строчку, после которой возникает зависание. Судя по проблеме их, может быть несколько….
Threadpool size уменьшил, посмотрим, что это даст. У меня 2 отдельных апплика для web-пользователей, соответственно, 8 под клиент.
Покопался в журнале транзакций, может ли эта ошибка вызывать сбой?
NO STATS:([sdctdb].[dbo].[IFC_ATTACHMENTCLASSIFICATIONS].[aca_rcd_oid], [sdctdb].[dbo].[IFC_GENERICRELATIONGROUPS].[grg_rcd_oid])
К сожалению, профайлер не вариант - уж слишком сильно систему грузит.
Григорий Ненашев пишет:
Кстати, а в момент зависонов, что происходит в данном столбце?
Процессы разные там во время падений. Вчера, к примеру, завис во время синхронизации с Citrix, перенесли синхронизацию на другое время, чтобы понять может ли быть проблема в этом. Однако, есть в этом сомнения, так как при прочих равных условиях (кроме количества подключений), тестовый сервер при запуске синхронизации не упал.
Григорий Ненашев пишет:
Но ведь на тестовом стенде нет такой нагрузки.. верно?
Я не думаю, что тестовый стенд живет на том же сервере где и боевая база…
Ну это да, нагрузки такой там нет.
Попробую сегодня вечером записать данные из ITSM_EMAILSC в отдельную таблицу и сотру данные за предыдущие года. Может действительно дело всё-таки в ней.