Имя: Пароль:
1C
1С v8
производительность 1с
,
0 МОРЖ
 
30.01.13
14:20
Есть такая проблема. Пускаешь обработку и чем дольше она выполняется тем медленнее она это делает. Моя обработка грузит документы из хмл. Но вопрос не в сути обработки. Этот симптом встречается очень часто.
Есть предположение что перегружаемая оперативка в процессе выполнения не высвобождается.
Вопрос 1: какие идеи есть о причинах снижения производительности?
Вопрос 2: есть ли идеи, предложения, как с этим бороться?
1 Fragster
 
гуру
30.01.13
14:21
использовать ЧтениеXML
2 Fragster
 
гуру
30.01.13
14:21
оно не тупит и память не жрет
3 Fragster
 
гуру
30.01.13
14:22
тупить может конкатенция в цикле, если итераций много - из-за того, что пересоздается строка в памяти каждый раз, при этом памяти каждый раз чуть больше нужно...
4 Fragster
 
гуру
30.01.13
14:22
а вообще надо код смотреть
5 Maxus43
 
30.01.13
14:22
да и смотря что конкретно делает. например проведение документов, да ещё обёрнутое в транзакцию всё - есно тупить будет
6 Fragster
 
гуру
30.01.13
14:23
кстати, (5) прав, если все в транзакции происходит...
7 МОРЖ
 
30.01.13
15:06
Там не транзакция у меня а попытка. Как я недавно понял попытка все таки не транзакция. Документы у меня не перепроводятся, а перезаписываются. В общем-то операция тоже транзакционная.
8 МОРЖ
 
30.01.13
15:07
Пользуюсь ЧтениемХМЛ, про проблемы с другим типом данных слышал, не мой случай.
9 Fragster
 
гуру
30.01.13
15:07
(7) имеется ввиду одна транзакция на 100500 документов, а не запись по отдельности
10 МОРЖ
 
30.01.13
15:09
Да и вообще, если групо говоря 1 документ проводится секунду, это не значит что 10 000 документов будет провозиться 10 000 секунд, а может и до 15 000 затянуться. Вот. С чем это связано может быть? (9) тоже не мой вариант)
11 fisher
 
30.01.13
15:11
(7) Самое смешное, что попытка реализована в 1С как неявная транзакция. Так что если у тебя внутри попытки супер-цикл с записью в БД, то...
12 ДенисЧ
 
30.01.13
15:11
(10) 1с - глючная и кривая система. Она рабоатет так, как хочет.  И не подчиняется законам обычной логики.
13 Fragster
 
гуру
30.01.13
15:12
(11) да ладно? опробуй писать документы в цикле внутри попытки... все, кроме того, на чем упадет - запишется
14 Fragster
 
гуру
30.01.13
15:12
(10) выводишь в окно сообщений что-то?
15 Fragster
 
гуру
30.01.13
15:13
кстати, база - файловая?
16 Fragster
 
гуру
30.01.13
15:13
на файловой замечал изредка такое, например при реструктуризации - когда скорость счетчика замедляется...
17 fisher
 
30.01.13
15:14
(13) Хм? Странно. А я помню откуда-то объяснение, что исключение ведет к откату внешней транзакции именно потому, что попытка дескать тоже как транзакция реализована...
18 МОРЖ
 
30.01.13
15:15
(14) намек понял, но нет, информацию не вывожу. база MSSQL
а про попытку удивил))) при случае проверю)))
19 МОРЖ
 
30.01.13
15:16
(17)
Знаю точно что вложенных транзакций в 1с нет а вложенные попытки есть)
20 Fragster
 
гуру
30.01.13
15:17
(18) т.е. кода не будет?
21 Fragster
 
гуру
30.01.13
15:17
который замедляется
22 dva1c
 
30.01.13
15:18
(19) Любопытно было бы посмотреть.
23 fisher
 
30.01.13
15:24
(19) Не то чтобы совсем нет. В терминологии СУБД это называется "псевдовложенные" транзакции.
24 МОРЖ
 
30.01.13
15:40
Поверьте на слово - бессмысленно. Заполняю документ из хмл и перезаписывается) делает это в нескольких тысячах строк. Ну и если честно там таких костылей понатыкано, что стыдно показывать)

Бог с ним с кодом. Любая обработка, какая бы не была, без любых транзакций сожрет много оперативы. Когда оператива подходит к концу - тормозит все и всегда в 1с. А тут еще скуль имеет свойство когда есть свободная оперативка, съедать ее, на всякий случай) в итоге однотипная перезапись документов превращается в мучение если их много.
25 Fragster
 
гуру
30.01.13
15:48
(24) у меня обработки не жрут оперативы...
26 Fragster
 
гуру
30.01.13
15:48
может быть у тебя есть циклические ссылки, посредством коих утекает память...
27 dmrjan
 
30.01.13
15:55
Я тоже подумал на циклические ссылки. Была уже подобная тема, когда в родитель номенклатуры ссылался сам на себя.
28 H A D G E H O G s
 
30.01.13
15:59
(3) 93.451234% что причина в этом.
29 Fragster
 
гуру
30.01.13
16:03
(27) я немного другие циклические ссылки имею ввиду
30 Fragster
 
гуру
30.01.13
16:03
(28) без кода все равно ничего не понять
31 dva1c
 
30.01.13
16:05
(30) Автор не расколется, о чем писалось в (24).
32 Fragster
 
гуру
30.01.13
16:06
а в случае (26) - еще и без вдумчивого его курения, что лень. нужно методом последовательной детализации выяснить, какая функция конкретно замедляется и прикидывать причины...
33 dva1c
 
30.01.13
16:06
(32) +100
34 МОРЖ
 
30.01.13
16:40
(32) ты обсолютно прав! ближайшее время этим и буду заниматься
ты заговорил про конкатенацию. С этим можно бороться? она актуальна только со строками?
35 Fragster
 
гуру
30.01.13
16:42
(34) для строк просто происходит непрерывное увеличение необходимой памяти, из-за чего каждый раз растет фрагментация. для чисел и дат - не так актуально.
36 Fragster
 
гуру
30.01.13
16:46
js = Новый COMОбъект("MSScriptControl.ScriptControl");
js.Language = "javascript";
Стр = "";
Для Сч = 1 по 10 Цикл
   Отметка = js.Eval("(new Date()).valueOf()")/1000;
   Для Сч2 = 1 по 10000 Цикл
       Стр = Стр + "1";
   КонецЦикла;
   Отметка2 = js.Eval("(new Date()).valueOf()")/1000;
   Сообщить("" + Сч + " " + (Отметка2-Отметка));
   Отметка = Отметка2;
КонецЦикла;
37 Fragster
 
гуру
30.01.13
16:47
1 0,078
2 0,156
3 0,406
4 0,625
5 0,515
6 1,656
7 1,891
8 1,235
9 1,844
10 1,562
38 МОРЖ
 
30.01.13
16:53
Возьму на заметку)
Углублюсь в анализ производительности! Спасибо большое за ответы!