← На главную

Нередко пользователи и администраторы сталкиваются с ситуацией, когда производительность 1С в клиент-серверном варианте начинает необъяснимо падать. Типичный симптом — "плавающие" зависания при выполнении стандартных операций, например, при проведении документа. Проведение может занять 2-3 секунды, а в следующий раз — 3 минуты, при этом отладка кода 1С не выявляет никаких проблем. Рассмотрим ситуацию, когда файловая копия базы данных работает идеально, а клиент-серверная — тормозит. Это верный признак того, что корень проблемы кроется не в коде конфигурации, а на уровне взаимодействия платформы 1С и сервера СУБД (в данном случае MS SQL Server).

Проанализируем возможные причины и шаги для их устранения на основе реального примера, когда проведение документа "Реализация товаров и услуг" в конфигурации УПП вызывало случайные длительные зависания.

Критическая проблема: несоответствие параметров сортировки (Collation)

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

Суть проблемы:

У сервера MS SQL Server и у базы данных 1С были установлены разные параметры сортировки (Collation):

• Collation сервера: SQL_Latin1_General_CP1_CI_AS
• Collation базы данных 1С: Cyrillic_General_CI_AS

Казалось бы, какая разница? Но разница колоссальная. Все временные таблицы, которые платформа 1С активно создает при выполнении сложных запросов (например, при проведении документов, формировании отчетов), создаются в системной базе данных tempdb. А база tempdb всегда наследует параметры сортировки всего экземпляра SQL Server.

В итоге, когда 1С пытается выполнить запрос, соединяющий данные из основной базы (с кириллической сортировкой) и временной таблицы (с латинской сортировкой), SQL Server вынужден на лету выполнять неявное преобразование строковых полей. Это приводит к катастрофическим последствиям:

1. Резкое падение производительности: Преобразование данных "на лету" — очень ресурсоемкая операция.
2. Невозможность использования индексов: Из-за преобразования данных оптимизатор запросов SQL Server не может эффективно использовать индексы по строковым полям, что приводит к полному сканированию таблиц (Table Scan) вместо быстрого поиска по индексу (Index Seek).

Именно этим и объясняются "плавающие" тормоза: в зависимости от данных в документе и кэша запросов, влияние этой проблемы может проявляться в разной степени, вызывая то секундную задержку, то многоминутное зависание.

Как проверить:

Выполните два запроса в среде SQL Server Management Studio (SSMS), чтобы сравнить параметры сортировки:

1. Запрос для получения Collation сервера:

SELECT SERVERPROPERTY('Collation')

2. Запрос для получения Collation вашей базы данных (замените 'ИмяВашейБазы' на реальное имя):

SELECT DATABASEPROPERTYEX('ИмяВашейБазы', 'Collation')

Если результаты не совпадают, вы нашли корень проблемы. Фирма "1С" настоятельно рекомендует устанавливать MS SQL Server с параметром сортировки Cyrillic_General_CI_AS.

Решение:

Исправление этой проблемы на работающем сервере — сложная задача. Самый правильный путь — переустановить экземпляр MS SQL Server с корректными параметрами сортировки и перенести на него базы данных. Любые другие способы являются компромиссными и могут привести к новым проблемам.

Регламентное обслуживание базы данных — залог стабильности

Отсутствие регулярного и правильного обслуживания базы данных на стороне SQL Server — вторая по популярности причина деградации производительности. Со временем данные фрагментируются, а статистика, по которой оптимизатор строит планы запросов, устаревает.

1. Обновление статистики

Статистика — это информация о распределении данных в таблицах и индексах. SQL Server использует ее для выбора наиболее эффективного способа выполнения запроса. Если статистика устарела, сервер может выбрать крайне неоптимальный план, что и вызовет "зависание".

• Что делать: Настройте ежедневное выполнение задачи по обновлению статистики для базы 1С. После обновления статистики крайне полезно очищать кэш планов запросов, чтобы SQL Server начал строить новые, оптимальные планы.
• Команды: UPDATE STATISTICS для обновления, DBCC FREEPROCCACHE для очистки кэша.

2. Реиндексация и дефрагментация индексов

При постоянном добавлении, изменении и удалении данных индексы "фрагментируются" — их страницы перестают идти последовательно на диске. Это замедляет операции чтения, так как серверу приходится выполнять больше дисковых операций.

• Что делать: Настройте регулярные задачи обслуживания. Полную реиндексацию (REBUILD), которая блокирует таблицы, лучше проводить в периоды минимальной нагрузки (например, в ночь с субботы на воскресенье). Менее "тяжелую" дефрагментацию (REORGANIZE) можно выполнять чаще, даже в рабочее время.

Анализ блокировок: не только взаимоблокировки (deadlocks)

В исходной теме упоминалась ошибка Lock conflict during the transaction. Это прямой указатель на проблемы с блокировками. Часто администраторы ищут только взаимоблокировки (deadlocks), когда два процесса блокируют друг друга по кругу. Однако гораздо чаще проблема заключается в длительных ожиданиях на блокировках.

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

Как анализировать:

Используйте стандартные инструменты MS SQL Server в момент "зависания":

1. Activity Monitor (Монитор активности): В SSMS это самый простой способ увидеть текущие процессы, их статус (например, `suspended`), и кто кого блокирует (столбец "Заблокировано").
2. Системные представления (DMV): Для более глубокого анализа можно использовать запросы к системным представлениям, например, sys.dm_exec_requests и sys.dm_os_waiting_tasks. Они покажут, какой именно запрос ждет, какого типа ожидания (wait type) и кто является источником блокировки.

Оптимальные настройки SQL Server для 1С

Некоторые настройки SQL Server по умолчанию не являются оптимальными для работы с 1С. Проверьте следующие параметры.

1. Максимальная степень параллелизма (Max Degree of Parallelism - MAXDOP)

Этот параметр определяет, сколько процессорных ядер SQL Server может использовать для выполнения одного запроса. Платформа 1С генерирует запросы, не рассчитанные на эффективное распараллеливание. Попытки SQL Server распараллелить их часто приводят не к ускорению, а к дополнительным накладным расходам на синхронизацию потоков.

• Рекомендация: Установите значение параметра Max Degree of Parallelism равным 1.

2. Настройки памяти

По умолчанию SQL Server стремится занять всю доступную оперативную память. Если на одной машине работают и сервер 1С, и сервер СУБД, это может привести к нехватке памяти для процессов 1С и операционной системы.

• Рекомендация: Ограничьте максимальный объем памяти для SQL Server (параметр Maximum server memory), оставив 2-4 ГБ для ОС и других служб.

3. Протокол Shared Memory

Если сервер приложений 1С и сервер СУБД физически находятся на одной машине, убедитесь, что для их взаимодействия используется протокол Shared Memory (Общая память). Это самый быстрый способ, так как данные передаются напрямую через оперативную память, минуя сетевой стек.

• Рекомендация: В SQL Server Configuration Manager проверьте, что протокол Shared Memory включен и находится на первом месте в списке приоритетов для клиента.

В заключение, "плавающие" зависания 1С в клиент-серверном режиме почти всегда свидетельствуют о проблемах в "фундаменте" — настройках и обслуживании SQL Server. Прежде чем углубляться в сложную отладку кода конфигурации, начните с проверки этих ключевых моментов, и с большой вероятностью проблема будет решена.