Возникла потребность проведения большого объема данных.

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

Почему документы не записываются в 1 сек.

о как, я а то балда думал что Записать и Провести это разные весчи )))))

(0) с тобой все нормально? ))) Стаж: 13 лет 16 дней

отключить итоги на время проведения

Вот интересно. Слово транзакция много программистов знает?
А понимает что это?

(2) зарегился во времена 7.7 и ушел в спячку)

(5) я регился в 2004, ушел в спячку на пару лет - удалили акк ))

(0) Ждёшь новогоднего чуда? ))

(0) надо позвать 1сника, дать ему денег за то, чтобы он разобрался, объяснил происходящее и предложил варианты решения.
Ну, или - подождать. Тупо.

Транзакции не помогут. Либо через фоновые задания разделять на потоки либо запускать дополнительные сеансы.

Задача стоит нагрузить систему одним сеансом.

система клиент серверная. железо и сеть не загружены.

при оптимизации кода прирост небольшой есть, но задача не код до бесконечности оптимизировать а загрузить железо хотя бы на 50-60%

(12) Вариант Н

н - никак.

p.s. Железо у вас загружено максимально.

(13) Все тесты показывать что не загружено. Тесты специализованые админские. Тестит спец контора.

При регламентных работах все загружено. При проведении нет.

(14) слово Ежова - последнее. точка.

100% не последнее. Вариантов куча.

Оптимизаторов звать не охота, дорого стоят. Может тут какой вариант высветится.

разделить на неблокирующие очереди и поручить кратный прирост (примерный эффект можно оценить с помощью http://catalog.mista.ru/public/173394/ )

(10) Ты уж определись - либо одним сеансом, либо максимально загрузить железо. Как ты хочешь, чтобы 1с выполняла последовательный код проведения документов одного сеанса сразу на всех ядрах?

в типовых практически не возможно добится сабжа...

в самописках это вполне реально...

(21) Проведение документа за 0.001с вполне реально? Это в каких самописках такое? На голой платформе с базой из 1 документа с датой и номером и без движений - и то медленнее будет

(22) у меня модель проведения в 7.7 отрабатывает за такое время. Другое дело дальше идут накладные расходы на запись самого документа.

Кстати ТС, а с чего ты взял что железо не загружено? При условии что 1С - однопоточное приложение, ты ожидал загрузки всех ядер?

(23)
Запись документа и запись движений - это уже нормальные такие расходы. Модуль проведения тут не причем.

Затестил для примера - в пустой базе без всего с 1 документом без реквизитов, без ТЧ, без движений в файловой базе на ssd с ядром 4.5 Ггц время проведения 1000 документов (точнее 1 документа 1000 раз) - 690 мс, т.е. 0.00069.
Можно даже не мечтать в продакшене с существующей логикой проведения приблизиться к 0.001.

(25) на моем 2600к (3,4ГГц) - 790 мс

(0) Если документы независимы, можно разбить на 8-10 сеансов и провести, но, думаю, отвалится на блокировках система.

(4) При больших объемах транзакции - зло. Скорость постепенно падает в геометрической прогрессии, лог разрастается так же, в геометрической. При 100 документах в транзакции в УПП лог вырастал до 8 Гб с 2 за несколько минут.

(27) Дополню: можно попробовать параметр /Z. Если конфа не в режиме совместимости, можно сдвинуть максимально вперед минимальную границу рассчитанных итогов (если известна минимальная дата проведения документов), или, если нет при проведении запросов к остаткам/оборотам - отключить использование итогов.

(27) Я сталкивался с обратным
При фиксации транзакции по каждому чиху - SQL начинал грузить SSD на 100% и все упиралось в него (SSD). При заключении чихов в большую транзакцию - SSD жил околонулевой нагрузкой и все заметно ускорялось, упираясь в производительность процессора сервером 1С.

(29) Тут все не очень очевидно: это идет работа буфера MSSQL. Он не сразу пишет на диск, а предварительно пушит в буфер. Видимо, при завершении транзакции запись из буфера идет на диск: в первом случае активно работает диск, во втором - оперативная память. Тут надо анализировать показатели PAGEIOLATCH и BUFFER MANAGER.

(29) Есть относительно "безопасный" способ оптимизации вот именно этого вопроса: если есть RAM диск (а в 2018 такой диск грех не иметь), можно туда вынести все TEMPDB и логи (при условии, что база находится в простой или разностной модели восстановления).

(31) "разностная модель восстановления" - что за зверь? О.о

(0) Нужны подробности: Проведение уже существующих доков, или создание и проведение новых. Что это за сеанс: ручной для запуска обработки или СерверныйРоботПроведения(для устранения конкурентного доступа к регистрам оборотов-остатков-сведений).  Если это проведение существующих доков, возможно прочитать остатки на начало дня, поднять все необходимые данные в таблицу значений, в ней всё пересчитать за день, и из ТЗ просто последовательно записывать в документы подокументные порции информации.
Подробности задачи в студию, тогда можно будет предложить более конкретные способы решения. Можно?

(29) при фиксации транзакции идет запись в журнал это как минимум.


Кстати, если отключить синхронный коммит, скорость должна значительно прибавится.

(0) Озвучте задачу, которая перед вами стоит, как часто у вас будут пачки по 1000 документов, чего хотите добится в итоге

(14)
в (13) дело говорят. если скорость именно такая, значит где-то железо загружено максимально.
Специальные "админские тесты" судя по всему не включали в себя анализ ожиданий на блокировках, анализ очереди загруженности диска, очередь к ядрам, использование нума каналов. Если все это было оценено и вы так и не выяснили, где же затык, то скорее всего в коде стоит Обработчик ожидания. Это единственный вариант.

(22) автор имеет в виду 1документ = 1 секунда

Ну записать документы в несколько потоков это еще куда ни шло, но проводить-то все равно придется последовательно.

(0) Проведение документов во многом зависит:
1. от количества движений документа, возможны пересчеты, проверки и т.д.
2. транзакции
3. железо
4. объем базы

Короче много факторов

(0) Скорее всего 1 ядро загружено на 100%, а тк их много, то кажется что загрузки никакой нет

предновогодняя ветка.  чтобы у всех  документы  в новом году у всех  так быстро  проводились! :)

(38) проводить тоже параллельно можно. Кроме БП конечно. Там 90% проведения - это регистр бухгалтерии, особо не распараллелишь.

(42) ТС конечно же не указал, что это за документы такие, но если это связано с "Расходом", то параллельно вряд ли получится - нужно же остаток актуальный знать.

(37) В топике написано, что 1000 документов за 1 секунду, т.е. на один документ 0,001 сек. :)

ТС же сказал прямым текстом: жалко денег на оптимизацию кривой системы. А так он все понимает. Он пришел сюда не за советами, это просто крик души.

(45) Это как посчитать. Если распараллелить на 1000 потоков, да без накладных расходов, то как раз выйдет 1 документ за секунду. :)

(47) только потоки дольше будут создаваться.

за 1 сек вообще никак не сделать.

(0) Ты с Казахстана?

(47) 1000 видов документов, 1000 серверов и нет ничего невозможного :)

(0) Как глобальный вариант:

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

Через Обмен сливать в 13-ю общую базу движения с кажой базы.
Т.е. некий аналог "Биг Дата" построить.

да ладно вам, вот http://fragster.ru/perfomanceTest/result.php?guid=a151f734-e48f-11e7-8062-50e549ef447d - в один поток 1600 документов с движениями по одному регистру.

(52) версия сикела не указана. а это важно.

(53) да там вообще первые 15 страниц http://fragster.ru/perfomanceTest/results.php?sort=sum1&direction=desc имеют скорость больше 1000 в секунду... повторюсь, речь про документ с одним набором записей и без всяких контролей

Был доклад на тусовке Инфостарта в 2015 году:
https://event.infostart.ru/2015/speakers/index.php?ELEMENT_ID=378326
Вкратце - SQL в режиме In-Memory, 2000 документов в секунду.

А ведь когда то само название 1С означало, что можно сформировать любой отчет за 1 секунду. Жаль что об этой идее быстро забыли....

(56) а ты вот скажи, какая нафиг половая разница между отчетом за 1 сек или за 10 сек ? )))

(57) есть разница

(57) Отчет в 10 секунд забьет кэш SQL и сервера 1С тупыми данными. Отчет в 1 секунду - нет

ты еще скажи что нет разницы если документ будет открываться 10с вместо 1с

а как можно ускорить запись огромного движения регистра  ?

(0) Возьми в руки трейсер, напиши свой код на 1С по записи твоих тыщи доков. Поймай по трассе его. Потом откати базу, где нет этих тыщей доков. И просто запусти в на скуле как выполнение запроса твоего текстового. Посмотри - он отработает на 1 сек? Если да - тогда, наверное, можно - если ты научишься генерить как платформа такие портянки и как-то быстро прокидывать его на выполнение через дмо, адо или как желает музыка в твоей голове. Если нет - значит нет.

Но если ты не полконник мусье Мазохи, то надо искать какое-то другое решение, вплоть до скидывания тысячи записей в какую-то простую таблицу и потом в фоне генерация и запись нужных доков.

(62) один документ - это 100500 запросов на скуль

(63) тебе жалко?

(64) Просто ты предлагаешь потом запустить этот запрос.
Но это не реально

(65) Если бы это не было не реально - тогда не было бы прямой генерации доков на скуле. Ну - ее никто бы никогда не сделал, т.к. это тупо не реально. Однако? Ты что-нибудь слышал когда-нибудь про обмены, которые написаны не на конвертахе, а на прямых запросах к скулю?

(55) Посмотрел, какой-то невнятный доклад и ответы на вопросы невнятные.
(66) я не слышал, можно ссылку?

(67) наверное рыть ИСу? :) Как думаешь? Я сам такие велосипеды писал, но сам понимаешь - это очень кастомное дерьмо. Суть кароче заключается вот в чем - делаешь нормальные вьюшки русские, чтобы можно было "аля язык запросов 1С" иметь на Т-SQL. Затем в качестве полей синхронизации по ссылке юзаешь ее гуид. И соотв. сам обмен представляет из себя поиск по каким-то полям, и если ничего не найдено - инсерт. Если найдено - апдейт. Написать это - не сложно. Но если в конвертахе просто сделать "создавай все, что не нашла", то на прямом обмене - тебе, если такое нужно, надо проанализировать последовательность таких инсертов, чтобы не попасть. И это самый гемор, когда тебе надо перетащить док в любом случае, и все ссылки в нем сначала проверить - если оные. Т.е. там кода столько под капотом, чтобы такие решения адски тяжело потом поддерживать. Прошла реструктуризация, все вьюхи завалились, у тебя все поломалось. Это первое. Но вьюхи можно пересоздать в клик. Второе - это ответ на вопросы, а почему вот этот, предположим какой-нибудь банк в р.с. контрагента, задублился? И тебе нужно протащить всю трассу в тестовую среду, чтобы разобраться - где косяк. Т.е. это не интересно все, долго, нудно. Но зато по скорости такое, что со второй конвертахой не снилось.

Поэтому чуваку протащить тыщу доков - просто запись за секунду - скорее всего можно, если у него прямой запрос (запросы) за такое время пройдут. Вопрос в том, что скорее всего, не нужно так делать и он так, даже если захочет, не сделает - нужно сильно страдать, чтоб пойти на такой шаг. Т.е. должна быть очень критичная попа-боль. Полагаю у тс не так все, я бы сказал, драматично.

Записать данные по документам в XML файл за 1 секунду и потом в фоновом задании обменом загружать их в базу 1С.

(68) 1. Обмены и проведение это какбэ разные вещи, не находишь?
2. Твои костыли не имеют никакой гарантии что ничего в базе не поломается.
3. Если нужна скорость, этот вопрос решается на уровне железа и оптимизации штатных механизмов, на крайняк открывается проект ЦКТП и 1С допиливает в узких местах платформу. И уж никак не твоими кривыми руками.

Короче всё что в этой ветке понаписали дичь дикая, а ТС тупой, жадный и ленивый.

(71) >>Обмены и проведение это какбэ разные вещи, не находишь?

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

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

>>3.на крайняк открывается проект ЦКТП и 1С допиливает в узких местах платформу. И уж никак не твоими кривыми руками.
Я не знаю, как твой ник коррелирует с твоим мозгом. Убейся об стену сам, будь мужиком :)

(73) Ты дебил? Читай сабж внематочно: "Возникла потребность проведения большого объема данных. "

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

Мой ник кореллирует с моим опытом, а твой ник кореллирует со старческим маразмом.

(74) ты точно препараты в нужной дозировке принимаешь? :)

(74) (75) парни, с новым годом! :)

(76) Спасибо, взаимно! :)