Добрый день.

  Веду разработку в файловом режиме, работаю в базе один. Заметил, что 1С работает медленно. Это хорошо чувствуется в формах списках. Если есть левое соединение, то уже думает. Сразу скажу, что запросы в списках нормальные.
  В рабочей базе клиент-сервер кривой запрос отрабатывается 12 сек, в моей базе 250.
  С одной стороны это хорошо) Я прям хорошо чувствую все не оптимальные моменты, но с другой стороны инертность базы сильно замедляет работу.
Фоновых зданий нет, вес базы - 1 Гб, как бы не вижу причин для таких  тормозов

Версия платформы: 8.3.10.2252. Режим совместимости с 8.3.6

конфа какая? ERP там пытаешься в файле ворочить?

Конфа легкая - Вторчермет, если слышали такую. Очень легкая, меньше БСП

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

база на сетевом ресурсе?

(4) Да нет, у моего коллеги в другой организации такая же беда с УНФ.
  В файлом режиме тормозит, в рабочей клиент-сервер все хорошо

(5) База лежит у меня локально

2(7) На винте с 5400 оборотов? В ОС Убунта? С 2 Гигами пармяти?

Будто включили режим слоу мо)

(6) Ну у меня вот файловые УПП\ДО\ERP и описаных тормозов я не чувствую...

(8) Win 10, 4Гб, i3 3.7
Жесткий не знаю

Демо УТ 11.2 ворочается нормально

(12) Ну значит дело не в железе\платформе, что-то у вас там в Вторчермете интересного...

2(11) Короче. Про винду и файлы. Винда не кэширует файлы, если доступ к ним происходит по сети. Но у тебя не этот случай, потому идем дальше.

Локальные файлы винда кэширует. То есть если файл  базы 1 Гб, всего 4 Гб памяти, то у файловой базы есть все шансы целиком оказаться в памяти. То есть должно работать быстро.

Медленно может работать в двух случаях - у тебя уже все занято из 4 Гб, и тогда винде приходится какието части свопить на диск, в файл подкачки. Работа с диском, особенно если он не ССД - по определению самая медленная.

Ну и еще возможен вариант, когда у тебя база несмотря на то что лежит локально, подключена все-таки через сетевой путь типа \\МойКомп\Рессурс\папкаБазы тогда к файлу все равно идет доступ через NetBUE забыл аббревиатуру, а значит он не помещается в быстрый кэш в память.

(14) Памяти занято 50 %, скачет туда сюда. Но на 10-ке я часто вижу, что процессов толком нет, а занята половина. Если просуммировать отдельные процессы, то не будет 50 %.
База подключена через обычный путь:
C:\Users\Admin\Documents\База для разработки

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

ВЫБРАТЬ ПЕРВЫЕ 50
    ДокЗаявкаКлиента.Дата,
    ДокЗаявкаКлиента.Номер,
    ДокЗаявкаКлиента.Клиент,
    ДокЗаявкаКлиента.Вес,
    ДокЗаявкаКлиента.Объем,
    ДокЗаявкаКлиента.Стоимость,
    ДокЗаявкаКлиента.СпособПогрузки,
    ДокЗаявкаКлиента.ДатаПогрузкиДляОтбора КАК ДатаПогрузки,
    ДокЗаявкаКлиента.ДатаРазгрузкиДляОтбора КАК ДатаРазгрузки,
    ДокЗаявкаКлиента.ТребованиеКТС,
    ДокЗаявкаКлиента.НазваниеГруза,
    ДокЗаявкаКлиента.ПредоставитьДо,
    ДокЗаявкаКлиента.ПунктОтправленияПредставление КАК ПунктОтправления,
    ДокЗаявкаКлиента.ПунктНазначенияПредставление КАК ПунктНазначения,
    ДокЗаявкаКлиента.Автор,
    ДокЗаявкаКлиента.Клиент.ОсновнойМенеджерПокупателя КАК ОтветственныйМенеджер,
    ДокЗаявкаКлиента.ВторойЛогист,
    ДокЗаявкаКлиента.Ссылка,
    ДокЗаявкаКлиента.Комментарий,
    ДокЗаявкаКлиента.СтоимостьДляПеревозчика,
    ДокЗаявкаКлиента.ТипТС,
    ЕСТЬNULL(уатЗаказГрузоотправителя.Ссылка, ЗНАЧЕНИЕ(Документ.уатЗаказГрузоотправителя.ПустаяСсылка)) КАК Заказ,
    ЕСТЬNULL(СтатусЗаявкиКлиентаСрезПоследних.Статус, ЗНАЧЕНИЕ(Перечисление.СтатусыПредварительнойЗаявки.ПустаяСсылка)) КАК Статус,
    уатЗаказГрузоотправителя.Ответственный КАК ОтветственныйЛогист
ИЗ
    Документ.ЗаявкаКлиента КАК ДокЗаявкаКлиента
        ЛЕВОЕ СОЕДИНЕНИЕ Документ.уатЗаказГрузоотправителя КАК уатЗаказГрузоотправителя
        ПО (ДокЗаявкаКлиента.Ссылка = (ВЫРАЗИТЬ(уатЗаказГрузоотправителя.ДокументОснование КАК Документ.ЗаявкаКлиента)))
        ЛЕВОЕ СОЕДИНЕНИЕ РегистрСведений.СтатусЗаявкиКлиента.СрезПоследних КАК СтатусЗаявкиКлиентаСрезПоследних
        ПО (СтатусЗаявкиКлиентаСрезПоследних.ЗаявкаКлиента = ДокЗаявкаКлиента.Ссылка)

(13) Здесь что-то на низком уровне

(15) Нужно память с учетом кэша смотреть
например
https://www.dropbox.com/s/w5gnies1dwtkg2w/Screenshot%202017-06-09%2010.09.21.png?dl=0
память использована на 75%, но остальное занято кэшем. Конечно кэш можно выгрузить, но это займет время.

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

Посмотри еще есть ли индекс по уатЗаказГрузоотправителя.ДокументОснование
и
СтатусЗаявкиКлиентаСрезПоследних.ЗаявкаКлиента

(17) Пробовал, без соединений тоже не особо хорошо, но лучше.

Попробую SQL Express

локально

ФизическаяТаблица
  Левое Соединение с ФизическаяТаблица
  ПО НеиндексированыеПоля
  Левое Соединение с ВиртуальнаяТаблица
  По НеиндексированыеПоля

"Сразу скажу, что запросы в списках нормальные"

Я тебя понял...

(22) Данный запрос без индексирования работает быстро, база не 200 Гб

(22) Понты не уместны

Индексирование здесь также не дает прироста

(15) И как это вообще работает?...
А если на основании одной заявки создали несколько документов уатЗаказГрузоотправителя? Платформа падать должна из-за неуникального ключа в списке?

(22) Как ты собрался этот запрос индексировать?

(26) На это есть запреты

(6) Разработку очень желательно вести в том же варианте в котором работает и боевая.

(18) Спасибо за содействие, думаю тут проблема кроется на низком уровне в файловом режиме. Переведу на клиент-сервер

(29) Я прекрасно понимаю, что желательно, что нет. По существу есть что сказать или  просто нужно что-то написать?

(27) (24) (23)
Во первых, рабочая база на SQL, а оптимизатор запросов SQL сервера гораздо умнее тебя, смирись. Файловая СУБД так не умеет.
Во вторых, выбери то что ты джойнишь в отдельные ВТ и там проидексируй, потом джойни эти ВТ к основному запросу.
В тертьих, даже на ИТС написано что не надо джойнить виртуальный таблицы к чему угодно без предварительной выборки в ВТ, т.к на стороне SQL сервера оно разворачивает во вложенный запрос и в итоге у тебя джойн к вложенному запросу что убивает производительность.
В четвёртых в БСП 2.4 есть консоль запросов которая отображает план запроса, можешь её качнуть и посмотреть что конкретно в твоём запросе не так.
В пятых, ты вот тут ДокЗаявкаКлиента.Клиент.ОсновнойМенеджерПокупателя - ещё и неявный джойн бахнул

Бегом матчасть курить, понты тут не уместны...

(32) Всё это очень интересно, но только не имеет никакого отношения к проблеме автора. У него база в режиме совместимости 8.3.6. То есть БСП 2.4 - забыть, временные таблицы в запросах для динамических списков - забыть.

Единственное что может ускорить этот запрос динамического списка - это включение хранение итогов для РС СтатусЗаявкиКлиента. Так как один фиг обращение идет к текущему срезу регистра.

А так еще потенциально узкое место я указал в (26). И никакие запреты это узкое место не уберут. Это косяк в логике.

(33) Я не предлагаю ему БСП 2.4 накатывать, консоль автономна.

(0)
1) Может тупо антивирь (даже встроенный в винду)?
2) Может все же кеш не работает. (Допустим C:\Users\Admin\Documents\ - расшарена)

(0) А если друг за другом повторить один и тот же запрос, второй раз быстрее намного или без разницы?

(11) >> Win 10, 4Гб, обычный HDD
Одно это уже обязано тормозить, даже без всякой 1с.
А вести разработку 1с на таком железе ну это извращение.

(34) Ну ещё можно индексировать поля соединения документа и регистра, таки 1С даёт возможно для 1 реквизита указать то что он индексируется. Но это хрень конечно, для того что бы решить задачу у меня тормозит база для разработки...

Еще не удивлюсь если это окажется не десктоп, а ноутбук  и процессор i3 3.7  работающий на низкой честоте из-за перегрева.

Win 10 нужно 1,5-2гб памяти для себя.
пару-тройку гигабайт для 1с,
еще пару гигабайт если запущены другие задачи, например браузер.
Ну и под кэш желательно чтобы оставалось 2-4Гб оперативки.

Тогда оно как-то работает.
А как это все уместить в 4гб? Только используя файл подкачки, и начисто отказавшись от кэширования.

(39) >> можно индексировать поля соединения документа и регистра

Ты хоть посмотри по каким полям он соединяет. К бабке ходить не надо, чтобы понять, что поле Ссылка в ДокЗаявкаКлиента - индексируемое (иначе быть не может) и ЗаявкаКлиента в РС СтатусЗаявкиКлиента тоже индексируемое (ибо стопудово ведущее и вообще это следует из логики самого этого регистра).

(42) ДокументОснование - Стопудово не индексируется, "ЗаявкаКлиента в РС СтатусЗаявкиКлиента тоже индексируемое (ибо стопудово ведущее и вообще это следует из логики самого этого регистра)." - Ты этот регистр видел? Я нет, может там это вообще 5ое измерение не ведущее, разговор не про коробку, это какая то нетленка от левой франи...

(32) Во первых, рабочая база на SQL, а оптимизатор запросов SQL сервера гораздо умнее тебя, смирись.

  Это я понимаю

Во вторых, выбери то что ты джойнишь в отдельные ВТ и там проидексируй, потом джойни эти ВТ к основному запросу.
В тертьих, даже на ИТС написано что не надо джойнить виртуальный таблицы к чему угодно без предварительной выборки в ВТ, т.к на стороне SQL сервера оно разворачивает во вложенный запрос и в итоге у тебя джойн к вложенному запросу что убивает производительность.

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

В четвёртых в БСП 2.4 есть консоль запросов которая отображает план запроса, можешь её качнуть и посмотреть что конкретно в твоём запросе не так.

   В курсе, но у меня обычное приложение.
  
В пятых, ты вот тут ДокЗаявкаКлиента.Клиент.ОсновнойМенеджерПокупателя - ещё и неявный джойн бахнул

  Тоже в курсе, запрос не мой, это обращение не критично.
Можно и до столба дое...тся

Бегом матчасть курить, понты тут не уместны...
  
  Я сюда не мерятся пришел, но каждый думает, что у него больше

(38) Ну как бы много где так делают, раньше проблем не замечал

(40) Это десктоп, можешь удивиться

Парни, не нужно советовать идеальный условия для работы. Данный компьютер нормально подходит для работы, а то что подавай супер комп, плохому танцору..
   Я работал на подобном компе с базой 200 гб, больше года, все работало нормально

(45) Где?
Офисный компьютер у которого менее 8гб памяти - тормоза.
А ты 1с пытаешься крутить на 4гб.
Добавь памяти и поставь систему на SSD, базу можно оставить на HDD  и все будет работать быстрей чем на сервере.

(44)
>> В курсе, но у меня обычное приложение.
Я эту консоль в УПП 1.2 встроил, на режиме совместимости 8.2.13 Так что я думаю и ты как нибудь справишься.

>> Я сюда не мерятся пришел, но каждый думает, что у него больше
А это тут причём? Я тебе просто объяснил почему у тебя тормозит запрос.

Режим совместимости повыше не воткнуть? Конфа на поддержке?

(47) Разные базы, разные задачи - это не показатель.
8гб оперативной памяти и SSD это никак не идеальные условия работы, это необходимый минимум для работы.

(47) >> 200Гб в файловом варианте.
Чисто теоретически это конечно возможно. Но фактически...
Не верю (с).

(50) Про 8Гб оперативы поддержку, ССД не нужен если у тебя база 1Гб..

(48) Такие ресурсы мне не выделят

(51) Ну если там конфа на 200 метров, а всё остальное данные, разрабатывать принципиально можно..

(49) Повыше пока не воткнуть, так как в 8.3.8 нужно обрабатывать закрытие форм. А с 8.3.7 думаю мало что даст

(49) Поддержки нет, переписана на 80 %

(44) >> Я сюда не мерятся пришел...

Ты сам первый начал.
Тебя за язык никто не тянул, когда ты в (0) написал "что запросы в списках нормальные".
В (15) запрос нифига не нормальный для динамического списка.

(51) Я серьезно

(57) Если я уберу двойное обращение через точку, меня это не спасет. Вот правда

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

(60) В режиме совместимости я не могу использовать временные таблицы в динамическом списке

(61) Ну значит остаётся либо передывалывать архитектуру, либо отказываться от этого джойна

(62) Я согласен. Но мое шестое чувство подсказывает мне, что здесь что-то есть..

Повторюсь, убираю все соединения, работает тоже медленно, рывками как при плохом инете

(63) ну, если это ДС то это упр. форма в ОФ, они так-то работаю туговато, а у тебя небось ещё и каких условных оформлений навешано?

(63) Ну и да, вопрос на засыпку, на кой там топ 50? ДС из коробки делает ТОП 50 вроде, или что-то поменялось?

(64) Убрал все условные оформления, закоментил код формы на всякий случай

(65) Это я просто указал топ 50

(66) .. выключил 1С и отошел от компа на всякий случай...

(68) ))) Можно и так попробовать, пойду по курю)

Конфигурация работает в режиме обычное и управляемое приложение. Я думал, может сам режим может что-то давать, переключение режима не помогло

(52) SSD нужен не для базы, а для системы.
Речь же не про сервер, а про рабочую станцию.
Профиль пользователя и все темпы будут хранится либо на медленном HDD либо на бытром SSD.
Это повышает отзывчивость и производительность системы в целом.

(53) Ну это уже другой вопрос.
Я видел недавно организацию где специалист работает за ЭЛТ монитором, на LGA775 c 1гб оперативки.

(72) Проще уволиться, зп там явна не очень

Прошу прощения, явно, а не явна

(73) В том то и дело, что зарплата для данной местности там очень даже неплохая.
Бывают такие перекосы.

(61) Я тебе уже написал, что в данном случае надо у РС включить хранение итогов. Причем тут временные таблицы в запросе?