Добрый день, коллеги. Файловая база, размер около 10 Гб, переехала на новый, более мощный сервер. Ряд операций, связанных с запросами, стали тормозить. Например, такой простой запрос выполняется 50 секунд:

	ТекстЗапроса = 
	|Номенклатура = Справочник.Номенклатура.ТекущийЭлемент;
	|Группировка Номенклатура без групп;
	|Условие(Номенклатура в ВыбНоменклатура);
	|";

Кол-во номенклатуры - около 20 тыс. позиций. Выбрана группа из 5 элементов. Попробую замерить на другом сервере. В чем может быть причина?

причина может быть в том что при копировании у вас дбф файлы раздробились на 10 тысяч фрагментов и теперь их чтение занимает минуту.
или еще в чем то
10гб для файловой многовато уже.
не хотите на SQL?

(2) на SQL пробовали до меня, получалось медленнее. Придется попробовать самому.

Попробовал на другом сервере, так же долго.

Переходите на прямые запросы. Или на простые выборки. И то и другое лучше чем "черные запросы" 1с.

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

(0) Это локально или по сети? Может для начала исключить влияние сети?

(6) Судя по "база переехала на более мощный сервер", она работает в терминале. Потому что по сети на мощность сервера пофиг.

в общем нужны подробности.
начиная от размера файла с таблицей номенклатуры
количества фрагментов в ФС для этого файла
очереди диска на сервере и т.д. и т.п.
выбНоменклатура - точно не пусто?
а то он весь справочник выбирает.

(8) Это же семерка. Там всё элементарно. Размеры детские для современных серверов. Вся таблица в файловом кэше должна быть, и влияние фрагментации файлов базы можно исключить в принципе.

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

Поэтому начать надо с создания рамдиска для временных файлов, и проверить, как оно.

(9) временные файлы на рамдиск где переназначить?

(10) Опция командной строки /t

(11) аа точно. склероз. 20 лет назад рамдиски делали

(0) Вопрос в стиле:
- Доктор, у меня болит!
- Что именно болит?
- Вы же доктор, Вы мне и скажите!

Более мощный это ничего не значит.
Более мощная видеокарта это более мощный сервер, но к 1С 7.7 отношения не имеет.

(13) Анекдот напомнило про врача и ветеринара) "Блин, как у вас всё просто!"

(0) Переходите на SQL (оптимально 2008), там такие запросы, даже штатные черные, выполняются за секунды.

(15) Не обобщайте, штатные запросы даже на sql-версии могут выполняться через dbf в каталоге временных файлов, неоднократно сталкивался..

(16) ++

(15) в 2008 нет только распухания темповой базы. все остальное по сути не вижу разницы с 2000. А так только прямые запросы делают погоду

(16) Могут, естественно.
Специально сделал такой-же запрос на большой скулевой базе и замерил через _GetPerformanceCounter()
Запрос занял 0.242 секунды первый раз и 0.056 второй раз.

(8) выбирал даже одну номенклатуру - всё равно долго считает, 26 секунд. Спасибо за советы, буду "читать и много думать".

(20) Так может у тебя журнал 1С раздулся просто. Или размер хранимых данных пользователя в папке пользователя. В свое время так интерфейс притормаживал. 1С каждый раз это все перечитывала.
Посмотри размер SYSLOG
А так же попробуй папку юзера очистить

Забавно, но именно в такой ситуации (когда номенклатура выросла до 20 тыщ), тоже стали все запросы подтормаживать и пришлось на прямые запросы переходить. Ничего в них страшного нет.

Тормозит под всеми юзерами?

ну и да. надо грохнуть индексы и переиндексацию сделать.
вдруг вся проблема только в этом))

(24) А лучше выгрузку-загрузку + проверить, прописаны ли каталоги пользователей

Рам диск есть на два гига. Буду думать за прямые запросы и скуль.

(25) Без патча такую базу не выгрузить - загрузить и в скуль не перекинуть

Сислог 150 мб, папки юзеров 40 мб на всех.

(23) Да, тормозит под всеми.

а в монопольном режиме?
путь к базе как прописан через сетевой ресурс или как локальный диск?
если через \\myserver\mybase - перепишите на локальный диск попробуйте
помню была проблема с доменным сервером из за чего тормоза начинались в совершенно неожиданных местах из за того что днс имена корректно не разрешались.

Таблица 320 Мб, индекс 40 Мб.

на скуле проверил. Номенклатуры 35 тыщ.
без фильтра, по всей номенклатуре, время выполнения запроса 12 сек, с фильтром по самой большой группе 1 сек.
размер файла мдф базы 350 Гб. прямые запросы не используются...

(30) Путь локальный, пробовал в копии монопольно. Склоняюсь к альтернативным запросам.
Ранее я переписал банк-клиент, поиск организации/контрагента  по ИНН, был запрос по части поля ИНН, с использованием ИЛИ. После изменения кода ускорение на два порядка.

Коллеги, спасибо за внимание к проблеме и ваши ответы, мне реально полегчало! :)

(34) тебе реально полегчает, когда базу на СКЛ переведешь. если бы у меня 10 Гб база лежала в дбф, у меня бы всегда очко сжатое было, иголку не воткнешь...

(35) Поддержу. Держать любые рабочие базы на dbf - так себе идея. Одна переиндексация чего стоит...

Ради интереса тоже попробовал на дбф базе где примерно 20 тыс элементов. Время запроса 0.353. Попробовал с помощью 1sqlite? время 0.002.

(35) та ну, 10гб ни о чем, мы в среднем, держали 20 в дбф, переписанная комплексная, 2 плана счетов, задвоенные регистры/движения для упр/бух учета. Индексация, не помню, сколько занимала. Мин 10-15. Зато за ночь, можно было перепровести любой год. Чего снеговику и не снилось.

И это, еще во времена отсутствия ссд дисков как класс

А автору, достаточно переиндексировать одну табличку с номенклатурой и прибить cfg пльзователей

Конфигурацию серверов автор не озучил, тесты скорости дисков не сделал.
Кто его знает, нам отсюда не видно, может у него база на софт-рейд 10 куда воткнуты wd green на 5400 (кажется).

(41) 10-ка еще туда сюда, даже на таких "скоростных" дисках. Плохо, когда там пятачок (5рэйд)

(42) Давно не использовал, подзабыл, да 5й, точно!

(35) перевод на скл базы.. ч когда то активно на этом подрабатывал. Тормоза появлялись там, где их на дбф не было. Уж обращение в цикле к реквизитам через . . . это вообще жесть причем в типовых. Типовые вообще при переводе на скл та еще хрень была.

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

мы же не знаем что там за конфиг. может самописка вообще.
так то у меня была 7ка на 70 гигов самописанная даже с черными запросами достаточно быстро работала.

И при любых непонятных случаях, лучше использовать вот это: https://forum.dorex.pro/index.php?topic=130.0
Скорость дисков эта штука (разумеется) не измеряет, но техинфо выдает достаточно подробное.

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

Кстати может быть стоит попробовать вариант когда в ВыбГруппа - заменить на в СписокЭлементовГруппы

Что хочу сказать: если в клюшках не костылить, а писать продуманно - все не так уж и страшно...
.
Тут вот коллега жалился что запрос по остаткам 30 секунд работает. Посмотрел. Ну ясен пень - на временные итоги по всей номенклатуре которой дохера тыщ, при том что фильтр на временные итоги стоит после получения итогов. Почему? Потому что надо писать аккуратно!!!

... Поставил фильтр где надо - скорость увеличилась в 20 раз...

И для дбфнвхх чорных запросов важна последовательность условий если их несколько.

В (0) применение без упорядочивания даст прирост.
Без итогов даст прирост

А вообще правильно - писать эти запросы в 1Sqlite

(47) >> а у меня на скуле условие типа как в ноль загоняло в аут.

да ладно гнать-то. десятки лет у всех работает, а у тебя аут...

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

(53) Прямые запросы не к скульным 1с базам бывают?

(56) ну как минимум с 1Спп, бывают...

(56) вовсю
Можно через фокспрошный драйвер, можна на скулайт

(56) к DB2 делал когда то но суть скуль все это