В базе очень по медленно выполняются любые запросы к таблицам остатков. Минимум 2 секунды в пустой базе.

Бьюсь над их ускорением запросов. На данный момент итоге не пересчитаны. Индексы еще не проверял

Сколько у Вас выполняется такой запрос ?
ВЫБРАТЬ
    ТоварыНаСкладахОстатки.Склад,
    ТоварыНаСкладахОстатки.Номенклатура,
    ТоварыНаСкладахОстатки.Качество,
    ТоварыНаСкладахОстатки.ХарактеристикаНоменклатуры,
    ТоварыНаСкладахОстатки.СерияНоменклатуры,
    ТоварыНаСкладахОстатки.КоличествоОстаток
ИЗ
    РегистрНакопления.ТоварыНаСкладах.Остатки КАК ТоварыНаСкладахОстатки

А что за конфа?
Если это Ка2 или ЕРП это супер быстро.
А если это розница или бухия то надо смотреть.

Хотя в бухии нет такого регистра вроде.

Файловая или клиент-серверная? Неплохо бы проиндексировать таблицы

(0) >Минимум 2 секунды в пустой базе.
а все остальное летает?
так не бывает

(1) УПП. В таблице остатках примерно 150 т. записей

(3) серверная
(4) остальное более-менее оптимизировано. Сейчас главный тормоз - выполнение контролей при проведении документов.
Получается замкнутый круг. Запрос к остаткам долго выполняется ->документ проводится долго->большое время на блокировку->медленно выполняется запрос

(4) под словом пустая база подразумевается, что данные есть, но ни кто не работает

(6) запрос к остаткам должен выполняться с отборами в параметрах виртуальной таблицы

(7) оригинально

(8) +много
(0) если есть RLS, то выполняй в привилегированном режиме

(7) если для тебя это пустая база то я балдею...
ни дам ни одного конкретного ответа т.к. не понятно на 1 сервере у тебя всё или разные сервера 1С и СУБД. Замер прям на сервере или на клиенте.
150К записей... и тебе все они нужны? Маня что-ли? Про отборы (8) написано по существу. как и про РЛС (см под админом).
PS граница расчёта остатков по регистру актуальна?

Дак 150 это не много вообще пара десятков перемещений + поступления продажи на пару складов.

"На данный момент итоге не пересчитаны. Индексы еще не проверял" даже не знаю как ругнутся.

(6) Так отключи контроль и все будет летать.

(0) Постгрес что ли?

Перехватывай текст sql-запроса и пробуй его запустить в режиме анализа плана выполнения. Смотри какая операция выполняется долго. И далее по обстоятельствам..

(8) верно. Рабочее запросы выполняются с отборами, но все равно долго.
У меня логика такая - смогу понять причину долго выполнения запроса без условий (чтобы их влияние убрать), то основные запросы смогу оптимизировать
(11) Сервер и СУБД разные. Замер выполняю через консоль запросов
(12) Если я правильно помню логику работы остатков. То берется остаток на ближайший месяц и к нему динамически добавляется вычисляемый остаток на данный момент. Возможно сильно ошибаюсь. В каком разделе ИТС почитать как на самом деле работают остатки?
(14) SQL
(15) спасибо, попробую

(16) в консоли некорректно замерять, она расшифровку тащит тупым способом.

ТоварыНаСкладахОстатки.Качество,
    ТоварыНаСкладахОстатки.ХарактеристикаНоменклатуры,
    ТоварыНаСкладахОстатки.СерияНоменклатуры

а вот весь этот цирк точно нужен?

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

Вариант, что сервер такой же старый как и конфигурация реален?

(16) в каком месте время окончания выполнения запроса в консоли фиксируется? а то мб после выгрузки в таблицу на форме. как минимум подтягиваются представления для ссылок. ну и прочее

(0) итоги посчитай

(16) В консоле запросов время считать можно по разному.
1. Время выполнения самого запроса.
2. Время вывода в ТЗ.

Часто на больших объемах данных, время вывода в ТЗ может быть больше, чем время выполнения самого запроса.

Какое время считаете?

(16) ну может к 100му посту соберешься и выложишь запрос, который надо оптимизировать

(22) Так то он в (0) его выложил )))

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

И да, РН оборотов или остатков, а?

(23) а что бывают запросы к виртуальной таблице без указания скобок (даже еcли в них пусто)?

(17) да, почти все измерения используются в работе. Порезать их не получится
(18) да, это тестовый старый сервер. Но я на нем один
(21) чистое время выполнения запроса
(24) регистр остатков. Все остатки получаются долго.

Подниму еще 3-х летнюю тему

Я перепровожу РТиУ и расходный ордер.

РТиУ.Записать(РежимЗаписи.Проведение);
РО.Записать(РежимЗаписи.Проведение);

Если при перепроведении РО ошибка, то РТиУ должна откатиться. Это можно сделать как-то без начатьТранзакцию

Что блокируется при вызове НачатьТранзакцию?
Что блокируется при вызове НачатьТранзакцию?

(26) Может мало памяти? Данные из кэша вываливаются?

Можно из без начать транзакцию, но тогда самостоятельно писать механизм и следить за его валидностью.

(26) что с памятью, очередью на чтение диска, загруженностью процессора - смотреть перфмоном.
Итоги рассчитаны на какой период? Запрос на какую дату формируешь?
Может всё таки реальный текст запроса дашь посмотреть?

(25) Да, всегда работало

(29) забавно.... проверил, работает

запрос в sql - профайлер покажи

(30) Это текущие итоги будут.
(0) Возможно в таблице текущих итогов полно нулевых записей, я бы просто пересчитал текущие итоги.
150К итоговых записей это вообще ниочем, должно очень быстро получать

Подскажите, при такой конструкции будет блокировка у РегистрСведений.ИдентификаторыОбъектов или НачатьТранзакцию повлияет на запись всех документов, справочников и т.д ?
        
НачатьТранзакцию();
        
        БлокировкаДанных = Новый БлокировкаДанных;
        ЭлементБлокировки = БлокировкаДанных.Добавить("РегистрСведений.ИдентификаторыОбъектов");
        ЭлементБлокировки.Режим = РежимБлокировкиДанных.Исключительный;
        ЭлементБлокировки.УстановитьЗначение("Идентификатор", Object.ID);
        БлокировкаДанных.Заблокировать();

(0) состав измерений и отборы покажи

А также на какую дату получаются остатки

Остатки без даты это выборка из физической таблицы на время выборки влияют блокировки. Если выборка на меньшую дату, то тогда остатки минус движения до даты и так же блокировки могут влиять. Твой запрос это полная выборка таблицы. Выборка зависит от фрагментации таблицы, очереди к диску, объёму свободной памяти в кэше. Если данные передаются через сеть, то и от загруженности сети.

(16) Так как есть отборы, пересоздай индексы, можешь средствами sql, есть специальная команда по-моему, для одной таблицы, для проверки ( исключит дефрагментацию индексов ), так же собери статистику - из-за неё парсер может выдать неоптимальный запрос.

Столько советов, а автор даже статистику запроса на sql-сервере не посмотрел..

(33) какая разница если у тебя в монорежиме абзац

(32) 2.пересчитать итоги предлагал ему, но похоже он не слышит