Доброго всем времени суток!
Ситуация следующая:
имеется 1С8.2 УТ 10.3, крутится на SQL, база 20 гиг. При первом проведении документа (т.е. документы уже есть в базе, просто перепровожу) время проведения рандомно колеблется от 10 до 90 секунд, выявить закономерность не удалось, тут скорей всего каким-то образом влияют фазы луны и взаимное расположение планет. При повторном перепроведении этого же документа время проведения редко бывает выше 1 сек. В базе пользователей нет, ковыряю один. По 1с-ному замеру производительности затуп всегда на строке записи по регистрам Движения.Записать().
Если зайти в другой док. поступления и перепровести его - та же картина. в первый раз проводится крайне долго, во второй и последующие на порядок быстрее.
Подскажите в какую сторону копать?

В кэше пусто, а потом густо.

(1) ++.

(1) Научиться с этим жить или можно как-то побороть?

(3) Для начала посмотри в сторону производительности скуля.

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

(0) вполне возможно что скулю не хватает выделенной оперативы, или же вполне возможно что настроен еженочный перезапуск службы скуля и на момент первого проведения в оперативу он еще ничего не подкачал

(6) Кстати, да, ежедневные ребуты сервера БД - зло.

(6) тоже есть такая мысля...
на весь скуль выделено 9гиг, при этом на нем крутиться несколько продакшн баз (одна основная на 20г и несколько по 1,5 гигов) и несколько тестовых копий базы на 20г.

но тогда закономерный вопрос: как в таком случае у людей работают базы на 200-500 гиг?

(9) У базы на 200-500 Гб за десяток лет активно задействуемых таблиц - процентов десять, остальное архивные данные, к которым обращение раз в пятилетку происходит.

>> При повторном перепроведении
это еще раз нажать кнопочку "Провести"? Или все же Отменить проведение и снова провести?

Тогда вопрос:
если запилить мелкую копию продакшн, в которой будет 10 документов из рабочей и будет она весить метров 200, выделить под неё отдельный инстанс SQL так, чтобы она полностью легла в оперативу, по логике тогда док. при любом проведении должен проводиться за примерно одинаковое время.
Или я не прав?

(11)
просто повторно тисну кнопку "Провести"

повторная запись неизмененного набора ничего не делает

(7) а сервера 1С - добро

(14)
что физически происходит на субд при первом и втором нажатии "провести"?

Тут еще и настройки влияют. В частности, что именно написано в свойствах конкретного документа:
УдалениеДвижений: "Удалять автоматически при отмене проведения", "Удалять автоматически" или "Не удалять автоматически"
ЗаписьДвиженийПриПроведении: "Записывать модифицированные" или "Записывать выбранные"

Ну и вообще, в коде может быть все что угодно прописано)

(12) Не совсем, все-таки кэш тоже участвует. Но по времени уже сравнимо будет.

(16) при первом - добавление записей в таблицы , во втором - апдейт этих записей .

(19) имел ввиду при перепроведении. Когда открываешь проведенный документ, в первый раз тиснешь "Провести" - можно сходить покурить или на обед, второй раз тот же документ - меньше секунды. Открываешь другой проведенный документ - та же картина.

(17)тестил на разных доках и с разными настройками свойств дока. Например, в доке реализации дольше всего идет очистка движений, причем опять же только в при первом перепроведении, свойства в нем типовые. В доке поступления немного перепилено проведение, проводит он все движения скопом строкой Движения.Записать(), свойство дока при этом http://prntscr.com/7tau8n.
И в том и в том случае затупы именно на строках записи-удаления движений. Причем затупы только при первом нажатии "Провести" уже проведенного документа.

(20) Регламенты на sql ?

(19) нет никакого апдейта записей регистров

(22) Удаляет и снова пишет же, да?

(23) да, но 1с говорит, что тот же самый набор 2 раз не пишется

(21)каждую ночь обновляется статистика, дефрагментация индексов.
итоги в 1с актуальные

У админов имеются еще файлики мониторинга загрузки памяти, дисков, проца на серверах. Поковыряю ка я их :)

(1) (21)
Еще одно подозрение - сначала пусто потом густо в кэше плана запроса. Если админы неправильно настроили регламенты на сиквеле, то тогда те доки, которые сегодня со второго раза проводятся быстро, завтра опять в первый раз будут проводиться медленно.
Это смогу проверить только завтра

(27) с самим запросом разберитесь. Почему работает медленно.

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