AHDP,

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

DmitriyZНавскидку пути оптимизации: резать мега-документ на более мелкие, использовать управляемые блокировки, поиграться с индексами (должен быть оптимальный вариант). Судя по обсуждению резервы оптимизации по коду есть немалые :)
резать может... но ушли от этого. сейчас идея вынести табличные части в регистры, при записи основного документа будут дёргаться мало.
индексами игрались. как раз вот вроде баланс между скоростью записи и чтения.
пасиб за то, что уделили внимание )

HoBTIDнаутилусHoBTID,

выше я писал размер базы
116107,73МБ

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

AHDPЕсли у вас очередь к темпдб, то лучше увеличить память. Прирост получите в десятки раз. Пытаясь оптимизировать дисковую подсистему получите улучшение в десятки процентов, за схожую сумму.
понимаете... мы в любом случае упрёмся в ограничение по памяти. либо финансовое.. либо просто по объёму.
в системе два документа - один в количестве даёт прирост 9%, а второй (о котором речь выше) - до 40% (сейчас, зимой будет чуть меньше).
т.е. памяти мы неограниченно добавить не сможем и темпдб будет в любом случае.

AHDPЭто кто же придумал, для получения правильного рассчёта перепроводить документ по нескульку раз!?!?!?!?! Тут не запросы, а архитектора обрабатывать напильником нужно!!! Пользователю-то сообщили сколько раз документ перепровести нужно? Или он для надёжности его до конца формирования отчётности перепроводит с завидным упорством?
нет конечно ) имелось ввиду "всередине" данные записывались по несколько раз. производились расчёты промежуточных данных.


AHDPИ поясните, как это Вы себе представляете

наутилус[quot DmitriyZ]сейчас идея вынести табличные части в регистры, при записи основного документа будут дёргаться мало.
есть данные, которые связаны с документом. и пишутся эти данные в табличные части. есть мысль, что если вынести связанные данные в регистры - запись основного документа, незатрагивающая "таблицы" будет происходить быстрее

AHDPА ещё мы все умрём :(, но это не повод обращаться за спасением к Индусам. :)
Что с того, сколько он даёт приросту? Вопрос как вы с этим приростом оперируете. Неужели вы при проведении поднимаете все документы этого типа!?!?!
Просто база у вас конечно большая, но соотношение оперативка/база у вас очень хорошее. Вероятно это подозревает и ваш финик, требуя от вас обоснований.
последнее обновление железа было три года назад. за это время количество юзверей и документов выросло в разы

AHDP"всередине" - это как? Лень было нарисовать кнопку "Сохранить"?
зачем вы тгавите? (с) =))) я вам передал дословно почему нельзя отказаться от временных запросов. тип было без этого, но было ещё хуже. зело тяжёлый по логике документ сохраняется.

AHDPМожет я что и упустил в тенденциях развития 1С, но мне казалось, что в документ вносятся "первичные данные", в регистр, порождаемые этими данными движения. В любом случае, структура хранения данных дложна отвечать потребностям их обработки, а уж потом занесения в базу.
это "производный документ" от первичных данных. он тяжело рассчитываемый. проблему эту и сами видим, и будем исправлять, но пока вот так.

AHDPПока видится необходимость в оперативке (если вы не ошиблись с адресом очереди). Можно попытаться обойтись докупкой винтов для разнесения темпдб, потом они всё равно пригодятся. И крепко думать над архитектурой базы данных... Уж больно легко вы готовы перенести данные из ТЧ в регистр.
вот винты точно. память хорошо, но винты критичней.
про архитектуру думаем. переделываем. =/ проблема есть ещё в том, что эти процессы "живые" и не статичные. появляются новые задачи, и первоначальный сарай для хранения дров оброс уже такими мансардами и подземными паркингами, что ужосъ. =(

unnamed54321А если по шагам пройтись в отладчике, и найти тот кусок кода, который долго выполняется? И уже конкретно над ним поэкспериментировать? Раз уж конфигурация самописная..
по-отдельности каждый шаг недолог. но их много. а 1С держит транзакцией данные в сиквеле от начала записи и до окончания её (транзакции).

AHDP,

=( я вам больше скажу. его просто нет. архитектора =(

AHDP,

спасибо, за участие. постараюсь не забыть доложить о результатах изменений и что помогло (если поможет)