Тормозит 1С: как найти узкое место и ускорить базу
Содержание
Ускорить 1С получается быстро, если сначала понять, где именно теряется время: на клиенте, в сети, на сервере 1С или в СУБД. Без замера люди покупают процессоры, а тормозит один регламентный запрос. Порядок такой: замер, СУБД, кластер, клиентские места и сеть, конфигурация, железо.
Выбор простой. Тормозит всё и у всех сразу — смотрите сервер и СУБД. Тормозит один отчёт или один документ — ищите проблему в запросе и блокировках. Тормозит у одного пользователя — клиентское место и сеть. Дальше разберём каждый случай.
Как найти узкое место: диагностика производительности
Начинайте с вопроса «что именно медленно». Запишите конкретику: какая операция, у скольких пользователей, в какое время, сколько секунд. «1С тормозит» — не диагноз. «Проведение реализации занимает 40 секунд после обеда, утром 5» — уже диагноз: похоже на блокировки или нагрузку в часы пик.
Что проверить за 10 минут
- Откройте диспетчер задач на сервере 1С и на сервере СУБД. Смотрите загрузку процессора, память и диска во время жалобы.
- Проверьте, не идёт ли в этот момент фоновая нагрузка: резервное копирование , регламентные задания, обмен, пересчёт итогов.
- Запустите ту же операцию на другом компьютере. Если там быстро — проблема в клиентском месте.
- Запустите операцию в режиме, когда в базе почти никого нет. Быстро — виноваты блокировки или перегрузка. Медленно и ночью — виноват сам запрос или слабое железо.
Инструменты замера
- Технологический журнал. Включается файлом
logcfg.xmlв каталогеconfплатформы. Пишет долгие вызовы, блокировки, ожидания СУБД. Объём растёт быстро, поэтому включайте на короткое время и с отбором по длительности. - Подсистема оценки производительности из библиотеки стандартных подсистем. Меряет время ключевых операций и считает интегральный показатель Apdex. Хороша для наблюдения «в динамике»: до и после настройки.
- Встроенный замер в Конфигураторе и отладчике. Показывает, на каких строках кода модуль тратит время.
- Счётчики Windows и мониторинг СУБД. Очередь к диску, свободная память, ожидания.
Меняйте одну вещь за раз и сразу замеряйте результат. Если за вечер вы поправили пять настроек, утром не поймёте, какая помогла, а какая сделала хуже.
Простая карта, куда смотреть:
Настройка СУБД: PostgreSQL и MS SQL Server
Для клиент-серверной базы большая часть задержек возникает в СУБД. Хорошая новость: здесь есть несколько настроек, которые дают заметный эффект почти всегда.
Общие правила для любой СУБД
- Диск. Данные и журнал транзакций держите на SSD. Журнал — по возможности на отдельном томе: запись в него идёт непрерывно, и общий диск становится бутылочным горлышком.
- Память. СУБД любит память: чем больше данных в кэше, тем реже чтение с диска. Отдельный сервер СУБД обычно не жалеют по оперативной памяти.
- Регламентное обслуживание. Обновление статистики и перестроение индексов выполняйте регулярно, в нерабочее время. На больших базах запросы замедляются именно из-за устаревшей статистики: планировщик выбирает неудачный план.
MS SQL Server
- Ограничьте
max server memory, чтобы СУБД не съела всю память, нужную операционной системе. Если на сервере живёт только SQL Server, оставьте системе разумный запас, а остальное отдайте СУБД. - Для базы 1С обычно хватает простой модели восстановления плюс регулярного полного копирования, либо полной модели с копиями журнала, если нужна защита на момент сбоя. Главное — следить, чтобы журнал не разрастался.
- Базу
tempdbвынесите на быстрый диск и разбейте на несколько файлов одинакового размера: 1С активно использует временные таблицы. - Обновляйте статистику и обслуживайте индексы заданием по расписанию. Тяжёлые операции запускайте ночью.
PostgreSQL
- Для 1С берут сборку PostgreSQL, рекомендованную фирмой 1С: у обычной версии нет нужных доработок, и часть функций платформы работает хуже или не работает .
- Параметр
shared_buffersчасто задают порядка четверти оперативной памяти сервера, аeffective_cache_size— примерно половину-две трети. Это ориентир, точные значения подбирайте под нагрузку. - Проверьте, что
autovacuumвключён и успевает: на таблицах с активными изменениями «раздувание» заметно замедляет выборки. - После массовых изменений данных запускайте
VACUUMиANALYZEпо нужным таблицам.
Перед правкой параметров СУБД и перестроением индексов сделайте резервную копию и выберите время, когда в базе нет пользователей. Перезапуск службы СУБД обрывает все сеансы.
| Что настраиваем | MS SQL Server | PostgreSQL |
|---|---|---|
| Память | max server memory | shared_buffers, effective_cache_size |
| Статистика | задание обновления статистики | ANALYZE, autovacuum |
| Временные данные | несколько файлов tempdb | отдельный быстрый том для временных файлов |
| Журнал | отдельный диск, следить за ростом | отдельный том для WAL |
Настройка кластера серверов 1С
Кластер распределяет работу пользователей по рабочим процессам. Если процессов мало или они перегружены, сеансы стоят в очереди. Если памяти не хватает, процессы падают и перезапускаются, а пользователи видят «зависание».
Где что лежит
Клиент обращается к агенту сервера (порт 1540 по умолчанию), затем к менеджеру кластера (порт 1541) и рабочим процессам. Диапазон портов рабочих процессов задаётся в свойствах рабочего сервера. Если между клиентами и сервером стоит межсетевой экран, откройте весь этот набор. Закрытый диапазон даёт симптом «подключается, но работает рывками или обрывается».
Свойства рабочего сервера
В консоли администрирования серверов откройте свойства рабочего сервера. Здесь лежат параметры, которые влияют на скорость и устойчивость:
- Количество информационных баз на процесс и количество соединений на процесс. При большом числе пользователей один процесс не должен обслуживать сотни соединений: нагрузка распределяется хуже, а падение процесса затрагивает больше людей.
- Допустимый объём памяти рабочих процессов. Когда процесс превышает порог, платформа перезапускает его. Порог слишком низкий — частые перезапуски, слишком высокий — утечки съедают память сервера.
- Интервал перезапуска рабочих процессов. Периодический перезапуск лечит накопившийся мусор в памяти. Задавайте его так, чтобы он падал на нерабочее время.
- Безопасный расход памяти за один вызов. Защищает от одиночных запросов, которые пытаются загрузить в память огромные выборки.
Перезапуск рабочих процессов и службы сервера 1С завершает сеансы пользователей. Сообщите людям заранее и делайте это вне рабочих часов. Не пересоздавайте кластер «для очистки»: вместе с ним пропадут настройки, списки баз и назначения.
Один сервер или несколько
Когда один рабочий сервер упёрся в процессор или память, добавляют второй рабочий сервер в кластер и распределяют нагрузку через требования назначения функциональности. Например, отдельный сервер выделяют под регламентные задания и обмены, чтобы они не тормозили пользователей. Требования назначения задаются в свойствах кластера.
Клиентские места и сеть
Если сервер здоров, а у части людей медленно, смотрим на рабочие места и канал.
Рабочее место
- Используйте тонкий клиент вместо толстого, если нет задач, которые требуют иного. Тонкий клиент меньше грузит рабочее место и сеть.
- Антивирус не должен сканировать каталоги кэша 1С и, для файловых баз, файлы данных. Добавьте их в исключения.
- Кэш клиента иногда стоит очистить: остаточные файлы после обновлений дают странные подтормаживания. Параметр запуска
/ClearCacheочищает кэш клиент-серверного обращения. Перед этим закройте все окна 1С. - Проверьте, что в плане электропитания Windows не стоит режим экономии. Процессор в таком режиме работает на сниженной частоте.
Сеть
1С чувствительна не к ширине канала, а к задержке. Приложение делает много мелких обращений к серверу, поэтому каждая лишняя пара десятков миллисекунд умножается на сотни вызовов. Проверьте задержку до сервера командой ping и стабильность канала: потери пакетов бьют по скорости сильнее, чем низкая скорость.
Для удалённых филиалов:
- Не подключайте клиентов через медленный VPN напрямую к серверу 1С. Лучше терминальный сервер в одной сети с сервером 1С: по каналу идёт только картинка.
- Для редких подключений подойдёт веб-клиент через публикацию на веб-сервере, но он зависит от браузера и качества канала.
- Файловую базу по сетевой папке через VPN не используйте вообще: файлы данных читаются кусками, и задержка делает работу невозможной.
Файловая база
Файловая база в сетевой папке нормально работает на небольшом числе пользователей. Когда пользователей становится больше десятка, а база растёт, переходите на клиент-серверный вариант. Это самое сильное ускорение для небольших компаний, которые долго жили на файловой базе.
Конфигурация: запросы, блокировки, регламентные задания
Железо и СУБД упираются в потолок, а плохой запрос сидит в базе годами. Именно доработки чаще всего и дают самые тяжёлые тормоза.
Тестирование и исправление базы
В Конфигураторе есть режим Администрирование → Тестирование и исправление информационной базы. Он проверяет логическую и ссылочную целостность, пересчитывает итоги, сжимает таблицы. Запускайте при монопольном доступе, когда в базе никого нет, и обязательно после резервной копии. Режим нужен для исправления структуры и проверок, а не для ежедневного ускорения.
Регламентные задания
Загляните в список регламентных и фоновых заданий. Типовые причины тормозов: обмен с сайтом каждую минуту, пересчёт нескольких тяжёлых итогов в рабочие часы, расписание заданий, которое накладывается само на себя. Перенесите тяжёлое на ночь, растяните расписания.
Блокировки
Платформа блокирует данные, чтобы документы не портили друг друга. Если конфигурация использует автоматический режим блокировок, транзакции могут блокировать больше, чем нужно. Признак: пользователи ждут друг друга, а загрузка сервера низкая. Помогают управляемые блокировки в коде и сокращение длительности транзакций: всё лишнее вынесите из транзакции, например запись в журнал, чтение справочников, внешние обращения.
Запросы
Типичные проблемы в доработанных конфигурациях:
- Запрос в цикле. Одно обращение на каждую строку документа вместо одного запроса на весь набор.
- Соединение с подзапросами и вложенными запросами. Планировщик плохо оценивает такие конструкции.
- Виртуальные таблицы без параметров. Остатки или обороты без отбора по условиям читают весь регистр. Накладывайте отборы в параметры виртуальной таблицы, а не в
ГДЕ. - Условия
ИЛИпо разным полям: индексы не работают. Разбивайте на два запроса с объединением. - Получение данных через точку по ссылке (
Документ.Контрагент.ИНН) в запросе или в цикле: каждое такое обращение превращается в скрытое соединение или отдельный вызов.
Пример простого исправления. Вместо запроса к справочнику в цикле соберите массив ссылок и получите данные одним запросом:
Запрос = Новый Запрос;
Запрос.Текст =
"ВЫБРАТЬ
| Контрагенты.Ссылка КАК Ссылка,
| Контрагенты.ИНН КАК ИНН
|ИЗ
| Справочник.Контрагенты КАК Контрагенты
|ГДЕ
| Контрагенты.Ссылка В(&Ссылки)";
Запрос.УстановитьПараметр("Ссылки", МассивСсылок);
Выборка = Запрос.Выполнить().Выбрать();
Пока Выборка.Следующий() Цикл
// работа с Выборка.Ссылка и Выборка.ИНН
КонецЦикла;
Платформа и расширения
- Обновляйте платформу до актуального релиза ветки 8.3: в новых версиях регулярно исправляют производительность и ошибки блокировок. Номер версии на сервере и клиентах держите совпадающим по основной ветке.
- Проверьте список расширений. Лишние расширения с подписками на события выполняются при каждой записи.
- Если база выросла до сотен гигабайт, подумайте об архивации старых данных: часть документов прошлых лет можно вынести в архивную базу.
Железо и виртуализация
Для 1С важнее частота ядра, чем их число. Основная логика исполняется в одном потоке на сеанс, поэтому процессор с высокой частотой часто быстрее «многоядерного монстра» с низкой.
На что смотреть при выборе
| Компонент | Что важно |
|---|---|
| Процессор | Высокая частота ядра, большой кэш. Количество ядер — по числу одновременных сеансов |
| Память | Хватает для кэша СУБД и рабочих процессов, без постоянного свопа |
| Диск | SSD (лучше NVMe) для данных и журнала. Обычные HDD на рабочей базе дают очереди |
| Сеть | Низкая задержка между сервером 1С и СУБД, лучше один гипервизор или одна стойка |
Виртуализация
Виртуальная машина — нормальный вариант, если ресурсы не переподписаны:
- Не выдавайте виртуалке больше виртуальных процессоров, чем нужно: избыток увеличивает ожидание планировщика гипервизора.
- Резервируйте память под машины с СУБД и сервером 1С, отключайте динамическое распределение памяти.
- Держите диски виртуальных машин СУБД на быстрой подсистеме хранения, а не на общем сетевом хранилище с чужой нагрузкой.
- В схеме «сервер 1С и СУБД на разных машинах» проверьте сеть между ними: именно этот канал определяет скорость проведения документов.
Если на одном физическом сервере живут и СУБД, и сервер 1С, ограничьте память СУБД так, чтобы на кластер 1С оставался запас. Иначе они начинают воевать за память, и оба тормозят.