У клиента ERP + Бит финанс 2.4.10.75/3.2.25.4, конфигурация практически не правилась (косметические правки - добавлены пара регистров сведений и регламентные задания)
столкнулись со следующей ситуацией: каждый расчет себестоимости идет чуть дольше предыдущего и вот наконец последний расчет стал вываливаться с ошибкой о нехватке места tempdb.
Посоветовал админу увеличить объем диска под tempdb. Место существенно увеличили, но это не помогло. Последние успешные расчеты с/с занимали по 10-12 часов (в зависимости от нагрузки на сервер), проблемное закрытие, по словам админа, начинает отжирать место где-то через 10 часов после запуска и падает через 13-14 часов. Аналогичная ситуация произошла в прошлом месяце, помогли реиндексация и пересчет итогов.
Что подскажет коллективный разум? Куда копнуть? Количество документов по месяцам в среднем плюс-минус одно и то же.

существенно - это сколько в ГБ?

(1) 250 Gb -> 1.7 Tb

TOP 5 запросов на запись в tempdb, plansql в ТЖ и молиться, чтобы это не было 100500 мелких запросиков.

Можно и без plansql, но если знаешь конфигу и на глазок можешь соотнести SQL и 1С

Посмотри чем занят СКЛ в момент отжора.
Недавно было нечто похожее. СрезПоследних регистра цен и соединение с курсами валют начало сильно жрать темп. пришлось вначале получать срез последних, потом стыковать курсы валют. Т.е. работало быстро, даже копию поднимали, а потом записей 500 добавилось и запрос вместо 3 секунд выполняться начал минут 10, при этом жрал темп и проц.

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

Может использование итогов отключено?

(0)протокол расчета себестоимости посмотри + настройки закрытия, могли число итераций сменить

(8) дык штатно РСВ их отключает =)

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

(10) смотри в последнем закрытом месяце