Перенесли УПП 1.3.49.1 с фаловой версии на сервер. Теперь документы в среднем с нескольких секунд стали проводиться до минуты.
Сервер: http://snap.ashampoo.com/wfBjG83G
Отладка показала, что 56% времени тратятся на процедуру записи движений   регистра(1-ая строка) и 32% на проверку существующих записей регистра (процедура так и называется):
http://snap.ashampoo.com/wSrGYikF.
В файловом варианте на том же документе данные показатели в сотни раз меньше.
Догадываюсь, что причина кроется в настройках самой базы в MSSQLServer 2014(не в настройках сервера - так как остальные базы, в том числе и УПП работают на нем нормально).
http://snap.ashampoo.com/Ja6HGReD
http://snap.ashampoo.com/QhwdGapI
http://snap.ashampoo.com/2nL23RWV
Подскажите, в чем может быть причина?

а че памяти на серваке мало? 10 гигов

+ да и проц слабоват

тест Гилева запусти, покажи сколько "попугаев"

(0)[ Теперь документы в среднем с нескольких секунд стали проводиться до минуты. ]
так и должно быть

(0) удивил. ты первый у кого 1с и sql 2014 заработал

(5) второй =)

(0) Поставьте памяти хотя бы 16гб, сделайте повторный замер.

(3) Что за тест Гилева?

На втором сервере (sql 2008r2) с этой базой такие же проблемы.

Укажи параметры сервера 1с и настройку рабочих процессов

(10) 8.3.3.721
в 8,3 рабочие процессы автоматом конфигурируются

(11)а разрядность?

х32.. но это не критично, так как на этом же сервере есть еще пара тестовых баз УПП 1.3.24.2 и УТ 10.1, в которых такой проблемы нет..
Размеры баз соизмеримы.. в районе 15ГБ
проблема только в одной базе УПП 1.3.49.1

База нетиповая, но модифицирована незначительно - добавлен один РН и два РС. Проведение тормозит на документах, которые не имеют отношения к этим регистрам.
Тест Гилева:
http://snap.ashampoo.com/0RRyxsLE

К (14) описался - измененная

(0) Похоже, это не сервер, а обычный комп.
Дисковая система какая?

(16)+ Там еще и виртулка. "Сервер-инвалид"

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

(14) Впечатляет.

Выше прочитать трудно? что аналогичная по размеру БД УПП на нем же работает отлично..

случайно rls одновременно с переносом не включили?

Если с другими базами всё ок, то - в профайлере сравнить одинаковые операции на "быстрой" и "медленной" базе.

(21) Ограничение на уровне записей отключено.

(22) Надо попробовать

Попробовали в общем  - сняли трассировки с "Нормально" УПП и с "тормозной". Взяли обработку проведения документа РеализацияТУ. В первом файле трассировки получилось 2500 с лишним строк, во втором - 1600 с лишним. Как это анализировать?
По трассировкам "тормозной" базы мастер настройки бд предложил создать 1 индекс с 7% приростом производительности. По "нормальной" - ничего не предложил.
Вчера, когда создавали базы на сервере, запускали создание всех индексов. Создались не все?

Подумываю обратиться в 1С, чтоб помогли с этой базой. Только, вот, не знаю, как это делается. Просветите?

(25) Сначала отладчиком сделай замер производительности и найди точно строку, на которой самая большая разница.
Ну и точка останова + ловим в профайлере запрос.

(27) Ок! Спасибо! Завтра попробуем

а в типовой УПП уже переделали двойную запись всех наборов в процессе проведения?

Сделали трассировку самой "тяжелой" строки - записи в регистр "РасчетыПоРеализацииВУсловныхЕдиницахОрганизации" в обеих базах. Результат: в "тормозной" - 32 строки, в "нормальной" - 81 строка. Заметили ещё такую особенность - в "нормальной" базе использовались временные таблицы в tempdb, а в "тормозной" всё делалось в самой базе. Строки трассировок сильно отличаются в обеих базах, поэтому по ним затрудняемся сделать какие-то выводы. Может дело в том, что версии УПП разные?
Какие моменты в трассировках ещё можно сравнить?

"Может дело в том, что версии УПП разные?" - да.

вопрос первый. расчет итогов включен в тормозной базе?  кроме того самые "тяжелые" операции для 1С-ки это чтение и запись. помогает процентов на 15 увеличить скорость тонкая настройка серверов по данным параметрам. про размеры оперативной памяти на сервере такие комменты: играет роль 1)количество запрашиваемых записей и количество юзеров. если в документах очень большие табл. части рекомендую сразу (на вырост, что называется) вставлять обработчики пакетной записи по 1000 строк, например. 2) при документах с большими табл. частями имеет смысл ставить на сервак такой объем памяти, чтобы, в идеале, закэшировать всю базу целиком.
обычно самые тяжелые для упп любой версии (кроме ерп 2.0) это партии товаров на складах, затраты и незавершенное производство. в них больше всего аналитики.... по этому ориентироваться можно еще на количество записей в этих регистрах.

На файовой всегда быстрей работает. СКУЛь не для быстроты