Вход | Регистрация


1С:Предприятие ::

Метки: 

Как записать 1000 документов за 1 сек.

Я
   shaman_kz
 
28.12.17 - 19:22
Возникла потребность проведения большого объема данных.

При проведении система не загружена. Тесты по железу сети показывают 10-15%.

Почему документы не записываются в 1 сек.
 
  Рекламное место пустует
   nordbox
 
1 - 28.12.17 - 19:30
о как, я а то балда думал что Записать и Провести это разные весчи )))))
   nordbox
 
2 - 28.12.17 - 19:36
(0) с тобой все нормально? ))) Стаж: 13 лет 16 дней
   rs_trade
 
3 - 28.12.17 - 19:53
отключить итоги на время проведения
   mingw
 
4 - 28.12.17 - 20:09
Вот интересно. Слово транзакция много программистов знает?
А понимает что это?
   ПросТак
 
5 - 28.12.17 - 20:18
(2) зарегился во времена 7.7 и ушел в спячку)
   lubitelxml
 
6 - 28.12.17 - 20:56
(5) я регился в 2004, ушел в спячку на пару лет - удалили акк ))
   МимохожийОднако
 
7 - 28.12.17 - 21:13
(0) Ждёшь новогоднего чуда? ))
   Лефмихалыч
 
8 - 28.12.17 - 21:15
(0) надо позвать 1сника, дать ему денег за то, чтобы он разобрался, объяснил происходящее и предложил варианты решения.
Ну, или - подождать. Тупо.
   shaman_kz
 
9 - 28.12.17 - 21:33
Транзакции не помогут. Либо через фоновые задания разделять на потоки либо запускать дополнительные сеансы.
   shaman_kz
 
10 - 28.12.17 - 21:34
Задача стоит нагрузить систему одним сеансом.
 
  Рекламное место пустует
   shaman_kz
 
11 - 28.12.17 - 21:35
система клиент серверная. железо и сеть не загружены.
   shaman_kz
 
12 - 28.12.17 - 21:36
при оптимизации кода прирост небольшой есть, но задача не код до бесконечности оптимизировать а загрузить железо хотя бы на 50-60%
   H A D G E H O G s
 
13 - 28.12.17 - 21:39
(12) Вариант Н

н - никак.

p.s. Железо у вас загружено максимально.
   shaman_kz
 
14 - 28.12.17 - 21:43
(13) Все тесты показывать что не загружено. Тесты специализованые админские. Тестит спец контора.
   shaman_kz
 
15 - 28.12.17 - 21:44
При регламентных работах все загружено. При проведении нет.
   mikecool
 
16 - 28.12.17 - 21:45
(14) слово Ежова - последнее. точка.
   shaman_kz
 
17 - 28.12.17 - 22:08
100% не последнее. Вариантов куча.
   shaman_kz
 
18 - 28.12.17 - 22:10
Оптимизаторов звать не охота, дорого стоят. Может тут какой вариант высветится.
   Fragster
 
19 - 28.12.17 - 22:21
разделить на неблокирующие очереди и поручить кратный прирост (примерный эффект можно оценить с помощью http://catalog.mista.ru/public/173394/ )
   MrStomak
 
20 - 28.12.17 - 23:17
(10) Ты уж определись - либо одним сеансом, либо максимально загрузить железо. Как ты хочешь, чтобы 1с выполняла последовательный код проведения документов одного сеанса сразу на всех ядрах?
   vde69
 
21 - 28.12.17 - 23:19
в типовых практически не возможно добится сабжа...

в самописках это вполне реально...
   MrStomak
 
22 - 28.12.17 - 23:27
(21) Проведение документа за 0.001с вполне реально? Это в каких самописках такое? На голой платформе с базой из 1 документа с датой и номером и без движений - и то медленнее будет
   Aleksey
 
23 - 28.12.17 - 23:31
(22) у меня модель проведения в 7.7 отрабатывает за такое время. Другое дело дальше идут накладные расходы на запись самого документа.
   Aleksey
 
24 - 28.12.17 - 23:34
Кстати ТС, а с чего ты взял что железо не загружено? При условии что 1С - однопоточное приложение, ты ожидал загрузки всех ядер?
   MrStomak
 
25 - 28.12.17 - 23:41
(23)
Запись документа и запись движений - это уже нормальные такие расходы. Модуль проведения тут не причем.

Затестил для примера - в пустой базе без всего с 1 документом без реквизитов, без ТЧ, без движений в файловой базе на ssd с ядром 4.5 Ггц время проведения 1000 документов (точнее 1 документа 1000 раз) - 690 мс, т.е. 0.00069.
Можно даже не мечтать в продакшене с существующей логикой проведения приблизиться к 0.001.
   Aleksey
 
26 - 29.12.17 - 00:02
(25) на моем 2600к (3,4ГГц) - 790 мс
   Tateossian
 
27 - 29.12.17 - 00:50
(0) Если документы независимы, можно разбить на 8-10 сеансов и провести, но, думаю, отвалится на блокировках система.

(4) При больших объемах транзакции - зло. Скорость постепенно падает в геометрической прогрессии, лог разрастается так же, в геометрической. При 100 документах в транзакции в УПП лог вырастал до 8 Гб с 2 за несколько минут.
   Tateossian
 
28 - 29.12.17 - 00:55
(27) Дополню: можно попробовать параметр /Z. Если конфа не в режиме совместимости, можно сдвинуть максимально вперед минимальную границу рассчитанных итогов (если известна минимальная дата проведения документов), или, если нет при проведении запросов к остаткам/оборотам - отключить использование итогов.
   H A D G E H O G s
 
29 - 29.12.17 - 01:05
(27) Я сталкивался с обратным
При фиксации транзакции по каждому чиху - SQL начинал грузить SSD на 100% и все упиралось в него (SSD). При заключении чихов в большую транзакцию - SSD жил околонулевой нагрузкой и все заметно ускорялось, упираясь в производительность процессора сервером 1С.
   Tateossian
 
30 - 29.12.17 - 01:46
(29) Тут все не очень очевидно: это идет работа буфера MSSQL. Он не сразу пишет на диск, а предварительно пушит в буфер. Видимо, при завершении транзакции запись из буфера идет на диск: в первом случае активно работает диск, во втором - оперативная память. Тут надо анализировать показатели PAGEIOLATCH и BUFFER MANAGER.
   Tateossian
 
31 - 29.12.17 - 01:50
(29) Есть относительно "безопасный" способ оптимизации вот именно этого вопроса: если есть RAM диск (а в 2018 такой диск грех не иметь), можно туда вынести все TEMPDB и логи (при условии, что база находится в простой или разностной модели восстановления).
   Feanor
 
32 - 29.12.17 - 08:59
(31) "разностная модель восстановления" - что за зверь? О.о
   Владимир1С
 
33 - 29.12.17 - 09:14
(0) Нужны подробности: Проведение уже существующих доков, или создание и проведение новых. Что это за сеанс: ручной для запуска обработки или СерверныйРоботПроведения(для устранения конкурентного доступа к регистрам оборотов-остатков-сведений).  Если это проведение существующих доков, возможно прочитать остатки на начало дня, поднять все необходимые данные в таблицу значений, в ней всё пересчитать за день, и из ТЗ просто последовательно записывать в документы подокументные порции информации.
Подробности задачи в студию, тогда можно будет предложить более конкретные способы решения. Можно?
 
  Рекламное место пустует
   rs_trade
 
34 - 29.12.17 - 09:18
(29) при фиксации транзакции идет запись в журнал это как минимум.


Кстати, если отключить синхронный коммит, скорость должна значительно прибавится.
   shamashs
 
35 - 29.12.17 - 10:02
(0) Озвучте задачу, которая перед вами стоит, как часто у вас будут пачки по 1000 документов, чего хотите добится в итоге
   Segate
 
36 - 29.12.17 - 10:03
(14)
в (13) дело говорят. если скорость именно такая, значит где-то железо загружено максимально.
Специальные "админские тесты" судя по всему не включали в себя анализ ожиданий на блокировках, анализ очереди загруженности диска, очередь к ядрам, использование нума каналов. Если все это было оценено и вы так и не выяснили, где же затык, то скорее всего в коде стоит Обработчик ожидания. Это единственный вариант.
   vde69
 
37 - 29.12.17 - 10:09
(22) автор имеет в виду 1документ = 1 секунда
   D_E_S_131
 
38 - 29.12.17 - 10:15
Ну записать документы в несколько потоков это еще куда ни шло, но проводить-то все равно придется последовательно.
   spiller26
 
39 - 29.12.17 - 10:20
(0) Проведение документов во многом зависит:
1. от количества движений документа, возможны пересчеты, проверки и т.д.
2. транзакции
3. железо
4. объем базы

Короче много факторов
   Вафель
 
40 - 29.12.17 - 10:21
(0) Скорее всего 1 ядро загружено на 100%, а тк их много, то кажется что загрузки никакой нет
   Бубр
 
41 - 29.12.17 - 10:23
предновогодняя ветка.  чтобы у всех  документы  в новом году у всех  так быстро  проводились! :)
   hhhh
 
42 - 29.12.17 - 10:28
(38) проводить тоже параллельно можно. Кроме БП конечно. Там 90% проведения - это регистр бухгалтерии, особо не распараллелишь.
   D_E_S_131
 
44 - 29.12.17 - 10:47
(42) ТС конечно же не указал, что это за документы такие, но если это связано с "Расходом", то параллельно вряд ли получится - нужно же остаток актуальный знать.
   Fish
 
45 - 29.12.17 - 10:50
(37) В топике написано, что 1000 документов за 1 секунду, т.е. на один документ 0,001 сек. :)
   mistеr
 
46 - 29.12.17 - 10:53
ТС же сказал прямым текстом: жалко денег на оптимизацию кривой системы. А так он все понимает. Он пришел сюда не за советами, это просто крик души.
   mistеr
 
47 - 29.12.17 - 10:55
(45) Это как посчитать. Если распараллелить на 1000 потоков, да без накладных расходов, то как раз выйдет 1 документ за секунду. :)
   rs_trade
 
48 - 29.12.17 - 10:59
(47) только потоки дольше будут создаваться.

за 1 сек вообще никак не сделать.
   мистер игрек
 
49 - 29.12.17 - 11:01
(0) Ты с Казахстана?
 
  Рекламное место пустует
   1Сергей
 
50 - 29.12.17 - 11:03
(47) 1000 видов документов, 1000 серверов и нет ничего невозможного :)
   Flover
 
51 - 29.12.17 - 11:04
(0) Как глобальный вариант:

Проводить порциями сразу скажем в 12-ти базах интервалами в месяц.

Через Обмен сливать в 13-ю общую базу движения с кажой базы.
Т.е. некий аналог "Биг Дата" построить.
   Fragster
 
52 - 29.12.17 - 11:33
да ладно вам, вот http://fragster.ru/perfomanceTest/result.php?guid=a151f734-e48f-11e7-8062-50e549ef447d - в один поток 1600 документов с движениями по одному регистру.
   rs_trade
 
53 - 29.12.17 - 11:41
(52) версия сикела не указана. а это важно.
   Fragster
 
54 - 29.12.17 - 12:24
(53) да там вообще первые 15 страниц http://fragster.ru/perfomanceTest/results.php?sort=sum1&direction=desc имеют скорость больше 1000 в секунду... повторюсь, речь про документ с одним набором записей и без всяких контролей
   4St
 
55 - 29.12.17 - 13:53
Был доклад на тусовке Инфостарта в 2015 году:
https://event.infostart.ru/2015/speakers/index.php?ELEMENT_ID=378326
Вкратце - SQL в режиме In-Memory, 2000 документов в секунду.
   Elf_80_lvl
 
56 - 29.12.17 - 13:58
А ведь когда то само название 1С означало, что можно сформировать любой отчет за 1 секунду. Жаль что об этой идее быстро забыли....
   nordbox
 
57 - 29.12.17 - 14:11
(56) а ты вот скажи, какая нафиг половая разница между отчетом за 1 сек или за 10 сек ? )))
   Вафель
 
58 - 29.12.17 - 14:18
(57) есть разница
   H A D G E H O G s
 
59 - 29.12.17 - 14:19
(57) Отчет в 10 секунд забьет кэш SQL и сервера 1С тупыми данными. Отчет в 1 секунду - нет
   Вафель
 
60 - 29.12.17 - 14:19
ты еще скажи что нет разницы если документ будет открываться 10с вместо 1с
   organizm
 
61 - 29.12.17 - 14:29
а как можно ускорить запись огромного движения регистра  ?
   Новиков
 
62 - 29.12.17 - 15:37
(0) Возьми в руки трейсер, напиши свой код на 1С по записи твоих тыщи доков. Поймай по трассе его. Потом откати базу, где нет этих тыщей доков. И просто запусти в на скуле как выполнение запроса твоего текстового. Посмотри - он отработает на 1 сек? Если да - тогда, наверное, можно - если ты научишься генерить как платформа такие портянки и как-то быстро прокидывать его на выполнение через дмо, адо или как желает музыка в твоей голове. Если нет - значит нет.

Но если ты не полконник мусье Мазохи, то надо искать какое-то другое решение, вплоть до скидывания тысячи записей в какую-то простую таблицу и потом в фоне генерация и запись нужных доков.
   Вафель
 
63 - 29.12.17 - 15:41
(62) один документ - это 100500 запросов на скуль
   Новиков
 
64 - 29.12.17 - 15:43
(63) тебе жалко?
   Вафель
 
65 - 29.12.17 - 15:44
(64) Просто ты предлагаешь потом запустить этот запрос.
Но это не реально
   Новиков
 
66 - 29.12.17 - 15:49
(65) Если бы это не было не реально - тогда не было бы прямой генерации доков на скуле. Ну - ее никто бы никогда не сделал, т.к. это тупо не реально. Однако? Ты что-нибудь слышал когда-нибудь про обмены, которые написаны не на конвертахе, а на прямых запросах к скулю?
   ИТ директор
 
67 - 29.12.17 - 16:14
(55) Посмотрел, какой-то невнятный доклад и ответы на вопросы невнятные.
(66) я не слышал, можно ссылку?
   Новиков
 
68 - 29.12.17 - 17:13
(67) наверное рыть ИСу? :) Как думаешь? Я сам такие велосипеды писал, но сам понимаешь - это очень кастомное дерьмо. Суть кароче заключается вот в чем - делаешь нормальные вьюшки русские, чтобы можно было "аля язык запросов 1С" иметь на Т-SQL. Затем в качестве полей синхронизации по ссылке юзаешь ее гуид. И соотв. сам обмен представляет из себя поиск по каким-то полям, и если ничего не найдено - инсерт. Если найдено - апдейт. Написать это - не сложно. Но если в конвертахе просто сделать "создавай все, что не нашла", то на прямом обмене - тебе, если такое нужно, надо проанализировать последовательность таких инсертов, чтобы не попасть. И это самый гемор, когда тебе надо перетащить док в любом случае, и все ссылки в нем сначала проверить - если оные. Т.е. там кода столько под капотом, чтобы такие решения адски тяжело потом поддерживать. Прошла реструктуризация, все вьюхи завалились, у тебя все поломалось. Это первое. Но вьюхи можно пересоздать в клик. Второе - это ответ на вопросы, а почему вот этот, предположим какой-нибудь банк в р.с. контрагента, задублился? И тебе нужно протащить всю трассу в тестовую среду, чтобы разобраться - где косяк. Т.е. это не интересно все, долго, нудно. Но зато по скорости такое, что со второй конвертахой не снилось.
   Новиков
 
69 - 29.12.17 - 17:16
Поэтому чуваку протащить тыщу доков - просто запись за секунду - скорее всего можно, если у него прямой запрос (запросы) за такое время пройдут. Вопрос в том, что скорее всего, не нужно так делать и он так, даже если захочет, не сделает - нужно сильно страдать, чтоб пойти на такой шаг. Т.е. должна быть очень критичная попа-боль. Полагаю у тс не так все, я бы сказал, драматично.
   MaxS
 
70 - 29.12.17 - 17:16
Записать данные по документам в XML файл за 1 секунду и потом в фоновом задании обменом загружать их в базу 1С.
   ИТ директор
 
71 - 29.12.17 - 17:20
(68) 1. Обмены и проведение это какбэ разные вещи, не находишь?
2. Твои костыли не имеют никакой гарантии что ничего в базе не поломается.
3. Если нужна скорость, этот вопрос решается на уровне железа и оптимизации штатных механизмов, на крайняк открывается проект ЦКТП и 1С допиливает в узких местах платформу. И уж никак не твоими кривыми руками.
   ИТ директор
 
72 - 29.12.17 - 17:21
Короче всё что в этой ветке понаписали дичь дикая, а ТС тупой, жадный и ленивый.
   Новиков
 
73 - 29.12.17 - 17:28
(71) >>Обмены и проведение это какбэ разные вещи, не находишь?

Ты не внимательно читаешь. Я где-то писал про проведение документа? В сабже написано: Как записать 1000 документов за 1 сек. Ну?

>>2. Твои костыли не имеют никакой гарантии что ничего в базе не поломается.
Не фантазируй, платформа при записи делает ровно тоже самое все. Ты генеришь код за нее. В части записи элементов справочника и документа - это не сложно.

>>3.на крайняк открывается проект ЦКТП и 1С допиливает в узких местах платформу. И уж никак не твоими кривыми руками.
Я не знаю, как твой ник коррелирует с твоим мозгом. Убейся об стену сам, будь мужиком :)
   ИТ директор
 
74 - 29.12.17 - 17:37
(73) Ты дебил? Читай сабж внематочно: "Возникла потребность проведения большого объема данных. "

Платформа при записи делает много чего, в т.ч. на сервере 1С.

Мой ник кореллирует с моим опытом, а твой ник кореллирует со старческим маразмом.
   Новиков
 
75 - 29.12.17 - 17:44
(74) ты точно препараты в нужной дозировке принимаешь? :)
   Дык ё
 
76 - 29.12.17 - 18:31
(74) (75) парни, с новым годом! :)
   Новиков
 
77 - 29.12.17 - 18:37
(76) Спасибо, взаимно! :)



Список тем форума
  Рекламное место пустует
ВНИМАНИЕ! Если вы потеряли окно ввода сообщения, нажмите Ctrl-F5 или Ctrl-R или кнопку "Обновить" в браузере.
Тема не обновлялась длительное время, и была помечена как архивная. Добавление сообщений невозможно.
Но вы можете создать новую ветку и вам обязательно ответят!
Каждый час на Волшебном форуме бывает более 2000 человек.
Рекламное место пустует