Имя: Пароль:
1C
 
Тормоза при выполнение запроса в транзакции
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
Чего то не сходится. Если результат разный именно в трассах то сервер приложений не причем. Точнее он может влиять, например если у него канал забит или плохой.В этом случае большой получаемый рекордсет может получаться значительно больше. Вообщем много может быть вариантов - лучше позвони я тебе расскажу подробней чего нужно сделать.