Вход | Регистрация
 
1С:Предприятие :: 1С:Предприятие 7.7 и ранее

v7: Долго отрабатывает Спр.Записать() при большом количестве новых элементов..

v7: Долго отрабатывает Спр.Записать() при большом количестве новых элементов..
Я
   Дегенератор идей
 
16.11.21 - 15:36
Конфигурация на базе типовой ТИС..
При загрузке из экселя большого количества новых элементов начинает тормозить.
Структура: Справочник "Номенклатура" и два подчинённых справочника "Цены" и "ЕдиницыИзмерения"
При загрузке используются транзакции, которые фиксируются после каждой 1000 элементов.
После 5000 начинает заметно тормозить и скорость падает.
Замер показывает следующее:

212    Спр.Записать();            75    228.873823    98.98 //Номенклатура, записываем новый элемент
220    СпрЕ.Записать();    76    0.028009    0.01  //Единицы, записываемый новый элемент
223    Спр.Записать()            76    0.015034    0.01  //Номенклатура, обновляем единицы измерения
233    СпрЦ.Записать();    76    0.174291    0.08  //Цены, записываем новый элемент с периодическими реквизитам

Почему так получается и что с этим сделать?
   dubolom
 
1 - 16.11.21 - 15:54
Не пробовал Эксель сначала в ТЗ грузить, а оттуда уже - в справочник?
Мне кажется, долго открытый COM-объект Экселя может ресурсы жрать.
   Дегенератор идей
 
2 - 16.11.21 - 15:58
(1) до замера производительности были у меня такие мысли..
но ресурсов вроде не сильно тратится: 3% ЦП и 450м оперативки, причем память не увеличивается.
   Эльниньо
 
3 - 16.11.21 - 16:12
Делай по 100 элементов
   Дегенератор идей
 
4 - 16.11.21 - 16:16
(3) ага.. уже
пока падения скорости обработки не заметно
   Андрей_Андреич
 
5 - 16.11.21 - 16:19
(3) В транзакции по 100-500 элементов
   Дегенератор идей
 
6 - 16.11.21 - 16:22
по 100 элементов в транзакции обрабатывается от 2 до 10 секунд..

гы.. после 11 тысяч скорость упала в 10 раз
   Дегенератор идей
 
7 - 16.11.21 - 16:28
10000 2
     10100 2
     10200 2
     10300 1
     10400 2
     10500 1
     10600 2
     10700 2
     10800 1
     10900 1
     11000 1
     11100 41
     11200 20
     11300 37
     11400 54
     11500 72
     11600 68
     11700 43
     11800 60
   Злопчинский
 
8 - 16.11.21 - 17:45
может у тебя где-то транзакция не закрывается вовремя?
   Злопчинский
 
9 - 16.11.21 - 17:46
основное время жрется чтением из Экселя если поячеечно читается.
Вруби замер производительности и смотри на колов операций и продолжительность. Тогда можно предметно говорить.
   Дегенератор идей
 
10 - 16.11.21 - 23:03
я тоже думал что эксель..
но по замерам показывает что запись нового элемента в справочник
кста.. никакого ускорения не было при транзакции в 100 элементов. просто я в предыдущие разы уже создал 11 тысяч элементов и обработка их просто обновляла, поэтому запись шла быстрее.
а после 11 тысяч начались новые элементы и скорость упала в 10 раз

(9) в (7) пункте количество отработанных элементов и прошедшее время в секундах

кста.. при транзакции по 500 после 13500 элеменнтов 1с вылетела с ошибкой CODEBASE  ERROR Error -70 Reading File SC84.CDX


ну и время в последней обработке росло по экспоненте.. последние 500 элементов 13к секунд, предыдущие 500 - 5к секунд, предыдущие - 700 секунд..

(9) замер производительности в (0).. в экселе читаю построчно если элемент найден обновляю флаг и реквизит подчиненного справочника,
если не найден то создаю новый элемент  справочника" номенклатура", записываю, создаю новые элементы в подчиненных справочниках "единицы" и "цены" и снова записываю элемент "номенклатура"
из замера видно что если записывать новый элемент занимает очень много времени, а если потом его просто записать, то быстро.. строки замера 212 и 223
   Дегенератор идей
 
11 - 16.11.21 - 23:06
если не ошибаюсь.. я этой обработкой уже грузил много тысяч элементов, но было это лет 10 назад
и вроде как не было у меня таких проблем.
   H A D G E H O G s
 
12 - 16.11.21 - 23:21
Семерка уже сырая...
   Злопчинский
 
13 - 16.11.21 - 23:48
(10) ну если совсем плохо будет - скидывай базу мне, я на своем компе попробую прогнать.
и да, запись жрет достаточно много времени. я на обмене КИС-WMS сначала находил эклмент и тупо создавал новый/записывал. А потм переделал на кучу проверко чтобы понять - надо ли обновление делать существующих. и хотя проверко дохрена - все стало летать нааамного быстрее, секунд 10-15 против минут
   Злопчинский
 
14 - 16.11.21 - 23:49
а вот ошибка -17 - это нехорошо, не нравится мне это...
   hogik
 
15 - 17.11.21 - 02:44
(0)
Посмотрите 30 сообщение в теме: https://forum.infostart.ru/forum9/topic36308/
"максимальный приемлемый размер ключа для "движка" "1С 7.7" равен 117 байтам"(с)
   Bigbro
 
16 - 17.11.21 - 07:25
если база на скуле стоит посмотреть как там фрагментирован лог файл и какими порциями прирастает mdf и ldf
а то бывает там по 1 мб приращение ставят а потом удивляются почему все колом встает на объемных загрузках.
   Дегенератор идей
 
17 - 17.11.21 - 08:07
(13) спс..
есть тупое решение. тупо разбить загрузку на несколько.

если я правильно понимаю.. у меня при загрузке тупо растёт индексный файл: от 16 метров до 2 гигов при записи новых элементов.

учитывая тот факт, что десять лет назад у меня таких проблем не было на идентичной базе, то пока проблему я вижу из-за двух местах: ОС или длинные реквизиты.
есть возможность проверить и то, и то..
   ДенисЧ
 
18 - 17.11.21 - 08:08
Если растёт индекс - значит, индексные выражения большие...
Нигде строк длинных проиндексированных нет?
   Андрей_Андреич
 
19 - 17.11.21 - 08:13
(18) Наименование всегда индексируется и у номенклатуры всяко не 10 длина наименования
   ДенисЧ
 
20 - 17.11.21 - 08:14
(19) У других-то не растёт?
   Bigbro
 
21 - 17.11.21 - 08:16
не заметил про cdx файл.
тогда надо смотреть фрагментацию индексов в первую очередь, размер файлов и количество записей в них.
   АгентБезопаснойНацио
 
22 - 17.11.21 - 08:32
Если растет индекс, значит, неэффективно перестраивается дерево. Значит, большой разнобой в наименованиях. Значит, сортируй предварительно (в екзеле, или выгрузив предварительно в ТЗ) по наименованию.
ну, или сделать прямые создание и запись. Но для разовой задачи это лениво.
Можно не писать наименования, писать только равное ему "ПолноеНаименование", а после загрузки "снаружи" перезаполнить, и штатно переиндексироваться.
Можно посмотреть, какой именно индекс занимает больше места в файле - но я название той утилиты уже не помню. Можно заголовок cdx разобрать, конечно  - но тоже лениво для разовой задачи.
   ADirks
 
23 - 17.11.21 - 09:09
(10) sc84 - это номенклатура в ТиС?
там есть такой прикол - индекс на поле НеВключатьВпрайс
при большом количестве вставок у DBF-движка крышу от этого сносит, и выражается как раз в таком вот росте индексного файла.
   Злопчинский
 
24 - 17.11.21 - 09:19
(23) а почему именно на это поле? у меня аналогичных флажков несколько, "ассортиент", "выгружать наружу"...
   Злопчинский
 
25 - 17.11.21 - 09:20
(17) много реквизитов с сортировкой и отбором. и часто увеличивают наименование свыше 50 символов
   ADirks
 
26 - 17.11.21 - 10:33
(24) я так понимаю, что на любое поле с флажком такая реакция. Но нужно чтобы номенклатур были десятки тысяч.
мне один раз попадалась такая база с номенклатурой автозапчастей - для добавления поля в справочник пришлось выключать отбор, а после обновления снова включать.
   Дегенератор идей
 
27 - 17.11.21 - 10:41
итого..
достал базу из архива. три штуки.
1. уменьшил наименование со 100 до 50
2. изменил обработку. новый элемент решил попробовать сразу записать с пустым наименованием и реквизитами
3. ничего не менял. но запустил на своем компе вместо сервера. только реиндексировал

в базе наименование строка 100, артикул строка 25 сортировка и отбор, НеВключатьВпрайс число 1 сортировка и отбор

1 вариант загрузил 45к позиций в базу менее чем за 9 минут
2 и 3 вариант.. скорее всего до конца не дойдут.
   Ёпрст
 
28 - 17.11.21 - 10:42
(0)Проще прямым запросом проинсертить табличку.
В снеговике, тоже шляпа с добавлением новых элементов.
Спонадобилось тут 90 мультов создать элементов с 1 реквизитом наименование. Дык вот, штатненько, можно и неделю лепить.
А так, сам скуль справился минут за 10.
   Ёпрст
 
29 - 17.11.21 - 10:43
И это с учетом выгребания самих наименований с рс, в котором это наименование как реквизит регистра и количеством неуникальных записей 250 мультов.
   Дегенератор идей
 
30 - 17.11.21 - 10:55
ну это...
если наименование сделать длиной 80, то 45к загружает за те же 9 минут
 
 
   Ёпрст
 
31 - 17.11.21 - 10:56
(30) сыми отборы со всех реквизитов и пробуй.
   Дегенератор идей
 
32 - 17.11.21 - 11:05
(31) зачем?
в (15) правильный ответ.. если уменьшить длину наименования, то проблема исчезает
   Дегенератор идей
 
33 - 17.11.21 - 11:21
ещё один вариант решения..
запускаем обработку, после того как она создала 10к новых элементов прекращаем её по esc. реиндексируем базу(ибо индекс будет около 1 гига, после реиндексации 20 метров)
запускаем обработку снова, первые 10к у нас уже созданы и она их быстро перезапишет и начнёт тормозить уже на второй 10К. повторяем процедуру
   Злопчинский
 
34 - 17.11.21 - 12:12
(26) флажок-то - это обычный числовой реквизит. длина = 1.
есть мысль что если на флажок (допустимые значения 0/1) поставить длина=2 (учитывая ВОЗМОЖНЫЙ ЗНАК (или поиграться с признаком "неотрицательный" - то ситуация станет лучше)
   Эльниньо
 
35 - 30.11.21 - 13:44
(12) Восьмёрка ещё сырая, семёрка уже перезрела. Как жыдь?
   ADirks
 
36 - 30.11.21 - 13:57
(35) Можно пилить. Можно трясти. Ещё можно сидеть на берегу реки (говорят, если достаточно долго сидеть, то мимо обязательно проплывёт труп твоего врага).
   Злопчинский
 
37 - 30.11.21 - 14:59
(36) труп - это EDT..?


Список тем форума
 
ВНИМАНИЕ! Если вы потеряли окно ввода сообщения, нажмите Ctrl-F5 или Ctrl-R или кнопку "Обновить" в браузере.