![]() |
![]() |
![]() |
|
Тормоза при выполнение запроса в транзакции | ☑ | ||
---|---|---|---|---|
0
Drufa
28.06.11
✎
13:48
|
Есть непонятный глюк
При выполнении запроса в транзакции время выполнения 0,5 сек При выполнении запроса в без транзакции время выполнения 0,003 сек НачатьТранзакцию(); Запрос = Новый Запрос; Запрос.Текст = "ВЫБРАТЬ споСпецУсловияСрезПоследних.* ИЗ РегистрСведений.споСпецУсловия.СрезПоследних(Условие) КАК споСпецУсловияСрезПоследних"; Выборка = Запрос.Выполнить().Выбрать(); ЗафиксироватьТранзакцию(); Народ объясните почему это происходит и как с этим бороться? |
|||
1
Рэйв
28.06.11
✎
13:49
|
(0)А зачем чтение данных пихать в транзакцию?
|
|||
2
Drufa
28.06.11
✎
13:51
|
Чтение происходи в обработке проведения то все плохо.
Если вынести этот запрос в консоль то все хорошо. А это как пример. |
|||
3
Рэйв
28.06.11
✎
13:52
|
(2)Обработка проведения -сама по себе транзакция.Убери и не мучайся.
|
|||
4
Drufa
28.06.11
✎
13:54
|
У меня в обработке проведения есть код
Запрос = Новый Запрос; Запрос.Текст = "ВЫБРАТЬ споСпецУсловияСрезПоследних.* ИЗ РегистрСведений.споСпецУсловия.СрезПоследних(Условие) КАК споСпецУсловияСрезПоследних"; Выборка = Запрос.Выполнить().Выбрать(); Он выполняется 0,5 сек Если этот код выполнить обработкой тогда 0,003 сек Если в обработке добавить транзакцию то тоже будет 0,5 сек. |
|||
5
apokrit
28.06.11
✎
13:56
|
(0)
При выполнении вне транзакции - запрос выполняется в READ UNCOMMITTED. Т.е. никакие блокировки не накладываются. При выполнении в транзакции - запрос выполняется (в зависимости от режим управления блокировками и для автоматического от типа данных) в READ COMMITTED, REPEATABLE READ или SERIALIZABLE - т.е. на все считываемые данные накладываются S блокировки. Наложение блокировок само по себе занимает ресурсы, ну и самое главное они могут конфликтовать с другими блокировками. Т.е. ожидать завершения других транзакций перед наложением. |
|||
6
rs_trade
28.06.11
✎
13:56
|
Смысл оборачивания в транзакцию можешь пояснить?
|
|||
7
rs_trade
28.06.11
✎
13:58
|
(5) в READ UNCOMMITTED насколько я помню только списки читают.
|
|||
8
unregistered
28.06.11
✎
13:59
|
(6) Эксперимент. Изначально код был в обработке проведения, которая выполняется в транзакции.
|
|||
9
Maxus43
28.06.11
✎
14:01
|
в типовых во всех чтение данных запросами в обработке проведения, и никто не жалуется
|
|||
10
Axel2009
28.06.11
✎
14:05
|
(0) открывай профайлер и смотри.
|
|||
11
Drufa
28.06.11
✎
14:07
|
В сабже это упрощенный пример.
В реальной базе этот запрос выполняется в обработке проведения которая сама по себе транзакция Если этот код выполнить в не обработки проведения то все быстро. Во всей базе стоят управляемые блокировки В момент выполнения кода запись в регистр не происходит. Если этот запрос выполнить в T-SQL на сервере БД то этот запрос выолняется быстро что в транзакции что без. |
|||
12
Axel2009
28.06.11
✎
14:08
|
(11) значит сервер 1с вешает блокировки (управляемые) после выполнения запроса.
|
|||
13
rs_trade
28.06.11
✎
14:10
|
(11) какой то бессмысленный набор фраз. уж простите
|
|||
14
Dem1urg
28.06.11
✎
14:13
|
(11) Во всей ли? На уровне самой конфигурации какой режим блокировки?
|
|||
15
Drufa
28.06.11
✎
14:14
|
При выполнении на QueryAnalizer
SQL:BatchCompleted BEGIN TRAN "0" SQL:BatchCompleted exec sp_executesql N'SELECT #V8TblAli1_Q_000_T_001._Fld23302RRef AS f_1..... "2" SQL:BatchCompleted Commit TRAN "0" В кавычках это задержка При выполнении из 1C обработки из сабж задержка 537 |
|||
16
Drufa
28.06.11
✎
14:14
|
(14) Управляемый
|
|||
17
neomarat
28.06.11
✎
14:20
|
Вы хотите понять почему платформа работает именно так?
Ответ: потому что ее так написали. Единственный путь - отправит на хотлайн, тут вам врят ли помогут |
|||
18
Drufa
28.06.11
✎
14:22
|
(17) В идеале хотелось бы понять почему так.
Но еще больше бы хотелось узнать как это вылечить. Если перегрузить сервер SQL то эта проблема отпадет на какое то время. |
|||
19
rs_trade
28.06.11
✎
14:24
|
(18) как это вылечить уже пояснили. не делать так. все равно это бессмысленно. так зачем выяснять почему? возможно какие то издержки сервера 1С на управления транзакциями.
|
|||
20
neomarat
28.06.11
✎
14:24
|
(18) SQL или сервер предприятия?
|
|||
21
Drufa
28.06.11
✎
14:31
|
(20) SQL
|
|||
22
Axel2009
28.06.11
✎
14:33
|
(21) тогда запустить технологический журнал и его считать. может там что путное покажется
|
|||
23
Drufa
28.06.11
✎
14:42
|
(19) Нельзя не делать так.
Подготовка данных в обработке проведения неизбежна значит не избежны запросы в транзакции. Постоянно дергать SQL тоже не выход. |
|||
24
Всеяд
28.06.11
✎
15:55
|
*Мне интересна эта тема*
|
|||
25
МуМу
28.06.11
✎
18:27
|
Сравни посимвольно запросы на уровне MSSQL.Только очень внимательно а лучше сравнением двух файлов. Посмотри разницу(если она есть).
В трассе MSSQL запрос сколько выполняется(duration) в одном и в другом случае? (не в отладчике а именно в трассе) Ситуация возникает постоянно? Ситуация моделируется? Я уверен что дело соверешенно в другом. |
|||
26
Drufa
28.06.11
✎
19:03
|
(25) Эмуляция ситуации
В 1С запускаю обработку в сабже. Задержка(duration) выполнения в трассе 537 Беру из трассы запрос (один к одному) и выполняю его в Query Analizer Задержка(duration) выполнения в трассе 3 |
|||
27
Axel2009
29.06.11
✎
09:10
|
(26) может QA в одной сети с скулем, а 1с сервер в разных?
|
|||
28
Axel2009
29.06.11
✎
09:11
|
(26)+ *на одном компе и на разных
|
|||
29
rs_trade
29.06.11
✎
09:20
|
(26) из твоих замеров ясно что когда через сервер 1С, тогда дольше. значит дело в сервере 1С. Если через сервер без транзакции, быстрее, значит издержки сервера на транзакцию.
|
|||
30
rs_trade
29.06.11
✎
09:22
|
(26) технологический журнал смотрел? можно из него что нить по твоему вопросу получить?
|
|||
31
Reaper_1c
29.06.11
✎
09:25
|
Естессно, автор условий в запросе не накладывает, отбирает практически весь регистр. А в транзакции - так еще и блокирует всю таблицу к чертовой бабушке. Пущай условия в параметры виртуальной таблицы запилит - все и разрешится.
|
|||
32
rs_trade
29.06.11
✎
09:30
|
(31) я так понял что строка Условие их содержит
|
|||
33
Reaper_1c
29.06.11
✎
10:29
|
(32) А я нет. Я там вижу только явное указание периода.
|
|||
34
rs_trade
29.06.11
✎
10:44
|
(33) может автор что то упростил при копипасте. так дело не в этом. автор гоняет один и тот же запрос в транзакции и без. пофигу на отборы.
|
|||
35
Drufa
29.06.11
✎
10:59
|
(27) Да Сервер 1С на другом сервере чем Скуль
Выполнение запроса по адо из 1С дает результат с задержкой "3" (29) Очень странная вещь. Только запросы от 1С в транзакции скуль выполняет медленно. (30) Журнал не смотрел. (31) РегистрСведений.споСпецУсловия.СрезПоследних( УСЛОВИЕ ) Набор дает 0-3 записей. |
|||
36
Axel2009
29.06.11
✎
11:13
|
(35) запусти QA на том же компе что и сервер1с стоит. и сравни выполнение. ресурсы что необходимы на транспорт данных тоже отражаются в duration..
|
|||
37
Drufa
29.06.11
✎
11:18
|
(36) Запускал эфект тот же
Есть подозрение что глючат процессы 1С сервера (rphost) База 300 пользователей на 1С сервере 4 процесса каждый из которых достиг предела по памяти около 2гб. Сегодня перенесли 1С сервер на новый и включили 15 процессов. Пока веду наблюжение. Попутно есть вопросы как бороться с ростом отжираемой памяти процессом? И как расширить количество IP потров для создания большего числа процессов. |
|||
38
МуМу
29.06.11
✎
11:41
|
Чего то не сходится. Если результат разный именно в трассах то сервер приложений не причем. Точнее он может влиять, например если у него канал забит или плохой.В этом случае большой получаемый рекордсет может получаться значительно больше. Вообщем много может быть вариантов - лучше позвони я тебе расскажу подробней чего нужно сделать.
|
Форум | Правила | Описание | Объявления | Секции | Поиск | Книга знаний | Вики-миста |