Всем доброго дня. Знаю, что часто 1С-ники любят разобраться в вопросе досконально. Очень рассчитываю на хороший совет. Есть бухгалтерский документ, содержащий 230 тыс проводок. При попытке записать все проводки разом, я получаю "нехватку памяти" (SQL серверная база, SQL 2008, Сервер 1С 32 разрядный). Потому сейчас добавляю наборами по 1000 записей (прямо в регистр, без чтения). Но уж очень долго это длится (несколько часов), причем 76% времени - запись в регистр. Был вариант отключения итогов с последующим включением - но включение итогов длится тоже долго (около 3х часов). Может, кто-то поделится своим опытом по оптимизации похожей ситуации?

Поменяйте подсистему жестких дисков

(1) 5й рейд на SSD

И записывать можно по 20 тыщ

писать порциями в транззакции начать/зафиксировать

(2) 10-ку ж лучше бы

делай (4), порции не по 1000, а тыщ по 5-10 делай

(4)
Если док - там и так уже транзакция

(4) А это поможет чем-то по скорости?

(3),(5) Понял, попробую. А вообще, в принципе, так и должно быть, что медленная запись идет такая? Ну, полчаса - еще туда-сюда. Но 2 и более часа!

(7) была похожая ситуа - 800 000 в один РН и 800 000 в другой в предалах одного регистратора - вроде помогло...

но в итоге вендоры поменяли алгоритм чтобы было меньше движений

А по 1 тыще как записываешь - в разных транзакциях или как ?

кстати да... это всё уже в транзакции проведения

(8) РБ вещь не быстрая

Если в одной - там сервер накапливает информацию для возможности отката - не гуд

(10) пишу в одной - "все или ничего"

(11) пусть попробует. хуже не станет

(15) вопрос с изменением таблицы итогов - она пересчитывается при фиксации транзакции, или при добавлении набора записей?
Я так понимаю, что самое медленное тут - именно пересчет итогов

(14)
Ну так разбей по 20 тыщ - и записывай в одной транзакции.
Пометки ставь - что записано. Потом в следующей порции, все можно в регламентном на сервере

(16) при фиксации

Ок, спасибо за идею. Попробую писать в маленьких транзакциях по 20 тыс записей.

Переходите на 8.2, просто в 8.3.4 они "оптимизировали" механизм записи регистров бухгалтерии и из-за этого тормозит сильно запись

(20) а это и есть 8.2 :)

(21) Ну тогда попробуй 8.3.4 :)

(20) + просто поскольку запись в обработке проведения - то и так и сяк это на сервере идет.

(16)
Ну у Вас же скорее всего документ реальным временем -вряд ли он год назад - поэтом тут не пересчет итогов а именно запись. Мы боролись усилением дисковой подсистемы.

Ну пересчет можно ускорить если порции выбирать по "ключевым" измерениям входящим в индекс, а не просто как попало

например по одной организации

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

(24) у меня тоже "роятся" идеи оптимизировать как-то таблицу, которая пишется. Но оптимизировать порции не вижу смысла, а целая таблица занимает > 3 Гб в оперативке. тоже ворочается еле-еле.

(24)+ Документ проводится как раз в 90% случаев "задним числом" - в прошлом месяце.

>просто поскольку запись в обработке проведения - то и так и сяк это на сервере идет.

у "пациентов" на упп падал клиент... документ успешно записывался только на 64 серваке, клиент отъедал 3,5 гб.

(29) + соответственно на компе буха с 32бит все падало, документ проводили на сервере через RDP

может попробовать итоги сдвинуть до документа, заблокировать весь регистр бухгалтерии доолнительно

(29) Я, чтобы уберечься от нехватки памяти, захожу клиентом на сам сервер (где и Сервер 1С, и SQL) - и запускаю оттуда. Там 32 Гб оперативки, с памятью все нормально хотя бы. Но, вероятно, придется искать возможность ставить 64x сервер.

(30) + сервер 1с был 32...

самое смешное - франь (он же вендор решения) сразу начал бубнить пациентам что надо срочно купить сервер 1с на 64

(31) документ-то проведется быстро, но итоги потом будут считаться вечность :(

(33) я вот тоже сомневаюсь, что это решит ситуацию. Потратить деньги легко. Но с меня же трясти будут результат.

(32) ты читаешь плохо... если написано через анус сервер не спасет...

(35) поставь эмуль протиестируй, и прими решение

(36) Я понимаю еще скорость чтения - она может зависеть от оптимальности запроса и т.п. Но скорость записи-то готовой таблицы.. как она может зависеть от "криворукости"?

(37) эмуль не работает с 64

(39) оппа....

(39) "хороший" работает

(34) итоги передвигать по ночам

А там журнал транзакций и прочее надеюсь по разным дискам в рейде ?

какой процесс падает? клиент или rphost?

(44) rphost

(43) нет, все на одном диске. ОС отдельно стоит, а все касательно баз - на одном.

(42) а днем как оборотку смотреть?

(49),(41) пожалуй, не стоит эту тему тут развивать :)

(42) не отключение итогов, а период рассчитанных итогов

(49) Я тут, конечно, не спец. Но мне кажется, что первый же проведенный документ сдвинет эти итоги обратно.

а сама винда на сервере какая? 64?

можно попробовать еще процессов наплодить рабочих, чтобы все "в одну лунку не совали"

(46)
Настрой по рекомендациям
http://infostart.ru/public/65955/

(51) Винда 64, процессов я "наплодил" 4. Сейчас посмотрю, что будет при записи транзакциями по 20 тыс записей. Может, и результат будет нормальный

Там 452 плюса

(52) Спасибо тебе, добрый человек. Попробую настроить - у меня немного иначе сейчас выставлено.