Работа с распределенными информационными базами (РИБ) в крупных сетях — это всегда балансирование между объемом данных и скоростью их передачи. Рассмотрим ситуацию, когда в конфигурации 1С:Розница 2.2 (казахстанская локализация) с базой объемом более 100 ГБ и количеством узлов около 90 (45 РИБ и 45 упрощенных кассовых обменов) происходит резкое замедление выгрузки. Если раньше 20 тысяч объектов уходили «влет» за 15–20 секунд, а теперь процесс растягивается на минуты, значит, система столкнулась с внутренним сопротивлением. Разберем по шагам, где искать причины и как вернуть былую скорость.
Первым делом проанализируем «железо». В нашей ситуации используется сервер на базе Intel Xeon 5218 с 256 ГБ оперативной памяти и SSD-дисками. На первый взгляд, ресурсов достаточно, однако критически важным показателем является длина очереди диска. Если при средних нагрузках текущая длина очереди записи достигает 25–40, это явный признак того, что дисковая подсистема не справляется с потоком транзакций. Проверим, разделены ли файлы базы данных (.mdf) и логов транзакций (.ldf) по разным физическим или логическим дискам. В высоконагруженных системах 1С это обязательное требование, так как запись в лог идет последовательно, а в базу — произвольно.
Выясним интересную подробность: незадолго до возникновения тормозов из базы было удалено около 20 ГБ данных. Казалось бы, база стала меньше, и работать она должна быстрее. Но в мире SQL Server это работает иначе. Проанализируем последствия массового удаления:
Index Scan вместо Index Seek).Рассмотрим пример того, как можно проверить уровень фрагментации индексов в вашей базе с помощью SQL-запроса:
SELECT
t.name AS TableName,
i.name AS IndexName,
ips.avg_fragmentation_in_percent
FROM sys.dm_db_index_physical_stats(DB_ID(), NULL, NULL, NULL, 'DETAILED') ips
JOIN sys.tables t ON ips.object_id = t.object_id
JOIN sys.indexes i ON ips.index_id = i.index_id AND ips.object_id = i.object_id
WHERE ips.avg_fragmentation_in_percent > 30;
Если вы видите значения выше 30%, необходимо выполнить полную переиндексацию (REINDEX) или реорганизацию индексов.
В механизме РИБ ключевую роль играют таблицы регистрации изменений (так называемые таблицы _ChangeRec). Проанализируем ситуацию: у нас 90 узлов. Для каждого изменения объекта в системе создается запись в специальной таблице для каждого узла, которому это изменение предназначено. Если какой-то один узел (например, закрытая торговая точка) перестал принимать обмены, записи для него в таблицах _ChangeRec будут копиться бесконечно.
Важный момент: Стандартная переиндексация таблиц объектов не всегда затрагивает скрытые таблицы планов обмена. Необходимо убедиться, что ваше регламентное обслуживание включает обновление статистики и индексов для всех таблиц, имеющих отношение к обмену данными.
Если в систему недавно был добавлен новый обмен (например, с 1С:Комплексная автоматизация 2.0), это могло стать катализатором проблем. Посмотрим, как это работает: при включении нового плана обмена часто включается авторегистрация объектов. Теперь при записи любого документа система должна не только записать его в основную таблицу, но и сделать записи в таблицы регистрации для всех 45 узлов Розницы и 1 узла КА 2.0. Это создает колоссальную нагрузку на транзакционный лог и замедляет работу каждого пользователя.
Для решения проблемы заторов выгрузки рекомендуем выполнить следующие действия:
UPDATE STATISTICS с параметром FULLSCAN. Это заставит SQL-оптимизатор пересмотреть планы запросов для выгрузки.Xeon 5218) убедитесь, что параметр Max Degree of Parallelism настроен правильно. Для 1С рекомендуется значение от 1 до 4, чтобы один «тяжелый» запрос на выгрузку не пытался захватить все ядра процессора, создавая ожидания типа CXPACKET._ChangeRec.TempDB расположена на самом быстром SSD и разделена на несколько файлов (обычно по количеству ядер процессора, но не более 8).Если вышеуказанные меры не помогли мгновенно, перейдем к инструментам 1С. Запустим Замер производительности в конфигураторе именно в момент выполнения выгрузки. Проанализируем, где тратится больше всего времени. Обратим внимание на следующие функции:
Часто причиной тормозов оказывается разросшийся регистр сведений, хранящий протоколы синхронизации. Если его не очищать, запрос к нему перед началом каждой выгрузки может занимать значительное время. Попробуем выполнить очистку старых записей протокола обмена через типовые регламентные задания БСП.
Ситуация, когда обмены «вдруг» замедлились, чаще всего связана с накоплением критической массы изменений или деградацией производительности БД на уровне SQL. Выполнение ночных регламентов по переиндексации и обновлению статистики — это необходимый минимум. В распределенных системах с числом узлов более 50 также крайне важно следить за тем, чтобы данные не копились в таблицах регистрации для неактивных узлов, так как это создает экспоненциальную нагрузку на механизмы выборки изменений.