Проблема медленного поиска в справочнике Номенклатура — одна из самых распространенных при использовании файлового варианта базы данных 1С. Особенно остро она проявляется, когда объем данных растет, а пользователей становится больше одного. В данной статье мы подробно разберем, почему «подвисает» поиск, как на это влияют сетевые механизмы Windows и как оптимизировать работу динамических списков.
Рассмотрим типичную ситуацию: база данных 1С является файловой (находится в общей сетевой папке), количество позиций номенклатуры составляет около 15 000. При попытке поиска программа «замирает», а сетевой трафик резко возрастает. Проанализируем основные причины такого поведения:
.1CD.Посмотрим на пример запроса, который часто становится причиной тормозов. В нем справочник соединяется с виртуальной таблицей остатков регистра накопления:
ВЫБРАТЬ
СправочникНоменклатура.Ссылка,
СправочникНоменклатура.Код,
СправочникНоменклатура.Наименование,
ТоварыНаСкладахОстатки.КоличествоОстаток
ИЗ
Справочник.Номенклатура КАК СправочникНоменклатура
ЛЕВОЕ СОЕДИНЕНИЕ РегистрНакопления.ТоварыНаСкладах.Остатки(, {(Склад = &СкладОстатков)}) КАК ТоварыНаСкладахОстатки
ПО СправочникНоменклатура.Ссылка = ТоварыНаСкладахОстатки.Номенклатура
{ГДЕ (&ТолькоОстатки = ЛОЖЬ) ИЛИ (ЕСТЬNULL(ТоварыНаСкладахОстатки.КоличествоОстаток, 0) <> 0)}
Почему это работает медленно в файловой базе: В отличие от SQL-сервера, файловый движок 1С при выполнении ЛЕВОГО СОЕДИНЕНИЯ в динамическом списке может принять решение полностью вычитать обе таблицы во временные файлы в папку %TEMP% пользователя. Если поиск ведется по полю, которое не проиндексировано, или если включена сложная сортировка, система считывает все 15 000 записей по сети, что и вызывает ожидание в 30-60 секунд.
Выясним причину, по которой поиск становится долгим именно после того, как кто-то другой изменил данные. Это связано с протоколом SMB (Server Message Block) и механизмом Opportunistic Locks (OpLocks).
Когда пользователь открывает список номенклатуры, Windows кэширует часть файла базы данных на локальном компьютере. Однако, как только другой пользователь (например, в терминальной сессии) записывает новый элемент номенклатуры, сервер отправляет уведомление всем сетевым клиентам: «Данные изменились, ваш кэш неактуален». При следующем поиске клиентская машина игнорирует локальный кэш и начинает заново скачивать блоки файла .1CD. Именно этот процесс пользователи воспринимают как «холодный старт» или зависание.
Чтобы ускорить поиск, проанализируем настройки динамического списка и внедрим следующие изменения:
Основная таблица (Справочник.Номенклатура). Это позволит платформе использовать порционное считывание данных (по 20-50 строк), а не выгружать весь справочник целиком.Разберем подробнее схему с вспомогательным регистром. Создадим периодический или непериодический регистр сведений ОстаткиДляСписков, который будет содержать всего два поля: Номенклатура (Измерение) и Количество (Ресурс). Обновление этого регистра можно настроить при проведении документов по складу. В этом случае динамический список будет обращаться к простой плоской таблице регистра, что в разы быстрее, чем расчет остатков через виртуальные таблицы.
Полнотекстовый поиск может как ускорять нахождение данных, так и блокировать работу системы. Если поиск «зависает» именно в момент ввода символов, проверим состояние индексов:
.1CD.Проанализируем ситуацию: если после очистки индексов скорость поиска через стандартное меню «Найти» выросла, значит, проблема была именно в фрагментации файлов в папке 1Cv8FTxt.
Иногда корень проблемы лежит за пределами кода 1С. Рассмотрим шаги по настройке сервера и рабочих станций:
Исключения антивируса: Это критически важный этап. На сервере и на всех клиентских машинах добавьте в исключения:
*.1CD, *.1CL, *.cfl.%AppData%\1C\1cv8\ и %LocalAppData%\1C\1cv8\).1cv8.exe.Проверка антивирусом каждого сетевого пакета при обращении к базе данных замедляет файловые операции в несколько раз.
Переход на веб-сервер (Apache или IIS): Это самый эффективный способ решения сетевых проблем файловой базы без покупки лицензий на SQL-сервер. При публикации базы на веб-сервере работа происходит по протоколу HTTP. В этом случае прямой доступ к файлу .1CD по сети (через «шару») прекращается. Веб-сервер сам обращается к файлу локально и передает клиенту только необходимые данные. Это полностью нивелирует проблему сброса кэша SMB и значительно ускоряет поиск для удаленных (сетевых) пользователей.
Мы проанализировали основные причины медленного поиска номенклатуры. Для решения задачи рекомендуем последовательно выполнить следующие действия:
ЛЕВОЕ СОЕДИНЕНИЕ с виртуальными таблицами остатков.Основная таблица и включено Динамическое считывание данных.Выполнение этих шагов позволит сделать работу пользователей комфортной даже в условиях работы с большой номенклатурной базой в файловом режиме.