Как ускорить работу 1С по локальной сети

Медленная работа 1С по локальной сети почти всегда имеет конкретную причину: перегруженный диск на сервере, нехватку оперативной памяти, неоптимальные настройки СУБД, слабый сетевой канал или устаревший режим файловой базы. Универсального «ускоряющего переключателя» не существует, поэтому начинать нужно с диагностики, а не с догадок.

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

Ниже разобраны основные направления оптимизации: от выбора режима работы базы до тонкой настройки SQL Server и сетевого оборудования. Большинство мер можно применить самостоятельно, но изменения на сервере СУБД следует выполнять только после резервного копирования.

Определяем, где именно теряется скорость

Прежде чем что-то менять, зафиксируйте симптомы. Важны три вопроса: у кого тормозит (все или отдельные пользователи), когда (постоянно или в пиковые часы) и на каких операциях (запуск, проведение документов, отчёты). Ответы сразу сужают круг поиска.

Используйте встроенные инструменты: замер производительности в конфигураторе (Отладка → Замер производительности) покажет, какие строки кода и запросы занимают больше всего времени. На сервере смотрите диспетчер задач и монитор ресурсов: загрузка диска выше 80–90% в часы работы пользователей — почти всегда главный виновник. Для клиент-серверного варианта полезны счётчики производительности СУБД и технологический журнал 1С.

Переходим с файлового режима на клиент-серверный

Файловый режим — самая частая причина медленной работы 1С по сети. При нём каждый клиент читает и пишет данные в общий файл базы по сети, а блокировки возникают на уровне всей таблицы. При 3–4 пользователях это ещё терпимо, но при 5–7 и более конкуренция за файл приводит к ощутимым задержкам, а риск повреждения базы при сбое сети возрастает.

Клиент-серверная архитектура (1С:Сервер + СУБД: PostgreSQL, MS SQL Server или другая поддерживаемая) снимает оба ограничения: клиенты общаются с сервером приложений, а не с файлом, а СУБД обеспечивает построчные блокировки и эффективную работу с данными. Переход выполняется выгрузкой базы в .dt из конфигуратора и загрузкой в новую клиент-серверную базу.

Оптимизируем сервер: диски, память, процессор

Дисковая подсистема — главный фактор скорости базы. База данных и журнал транзакций должны лежать на SSD, а не на механических HDD. Для MS SQL рекомендуется разносить файлы данных, журнал и tempdb по разным физическим дискам, если это возможно. Сетевое хранилище по медленному каналу для файловой базы — гарантированный источник тормозов.

По памяти действует простое правило: СУБД должна иметь возможность закэшировать активную часть базы в RAM. Если база 20 ГБ, а на сервере 8 ГБ памяти, каждый запрос будет ходить на диск. Для MS SQL задайте ограничение максимальной памяти сервера, оставив запас операционной системе (обычно 2–4 ГБ), иначе SQL Server может отобрать память у ОС и вызвать подкачку.

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

Настраиваем СУБД и обслуживание базы

Даже на хорошем железе СУБД с настройками по умолчанию работает неоптимально. Для MS SQL ключевые меры: ограничение памяти, размещение tempdb на быстром диске с несколькими файлами, отключение автосжатия базы, разумный прирост файлов вместо мелких инкрементов. Для PostgreSQL — настройка shared_buffers, work_mem и параметров автовакуума под объём базы.

Обязательны регулярные регламентные операции: обновление статистики и перестроение (или реорганизация) индексов. Без этого планировщик запросов строит неэффективные планы, и отчёты, которые раньше выполнялись секунды, начинают занимать минуты. Настройте план обслуживания на ночное время, а не запускайте вручную «когда вспомнили».

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

1. 1
   Сделайте полную резервную копию базы средствами СУБД
2. 2
   Перенесите файлы базы и журнала на SSD, убедитесь в достаточном объёме RAM
3. 3
   Задайте лимит памяти СУБД с запасом под ОС
4. 4
   Настройте еженочное обновление статистики и регулярное обслуживание индексов
5. 5
   Перенесите регламентные задания и бэкапы на нерабочие часы
6. 6
   Проверьте скорость типовых операций у пользователей и сравните с исходными замерами

Проверяем сеть и сетевое оборудование

Для клиент-серверной 1С сеть менее критична, чем для файловой, но всё равно влияет на отзывчивость интерфейса. Минимальное требование — гигабитная сеть между клиентами и сервером. Проверьте, что сетевые адаптеры реально работают на 1 Гбит/с, а не опустились до 100 Мбит/с из-за плохого кабеля или разъёма: это видно в свойствах подключения.

Wi-Fi для постоянной работы с 1С — плохая идея: задержки и потери пакетов вызывают подвисания интерфейса и обрывы сеансов. Проводное подключение обязательно для бухгалтерии и операторов. Также исключите из цепочки устаревшие коммутаторы и проверьте, не настроено ли на сетевом оборудовании ограничение скорости портов.

Полезная проверка — измерить реальную скорость копирования большого файла с сервера на клиент. При гигабитной сети она должна быть близка к 100 МБ/с. Значительно меньшие значения указывают на проблему в кабеле, коммутаторе или сетевой карте.

ping -t server1c -n 50 :: проверка стабильности связи до сервера, потери должны быть 0%

Настраиваем клиентские компьютеры

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

Периодически очищайте кэш метаданных 1С на клиентах: повреждённый или раздутый кэш вызывает долгий запуск и глюки интерфейса. Самый надёжный способ — удалить базу из списка и добавить заново, либо очистить папки кэша в профиле пользователя (%APPDATA%\1C). Следите также за актуальностью версии платформы: свежие релизы регулярно содержат оптимизации.

Для тонких клиентов и терминальных сценариев рассмотрите альтернативу: публикацию базы на веб-сервере или работу через RDP на терминальном сервере рядом с сервером 1С. Это особенно эффективно для удалённых офисов со слабым каналом — по сети передаётся только экран, а не данные.

Проверяем результат и контролируем деградацию

После каждого изменения измеряйте эффект одними и теми же операциями: время запуска базы, проведение типового документа, построение стандартного отчёта. Записывайте значения до и после — только так можно понять, что именно помогло, и откатить бесполезные изменения.

Производительность деградирует постепенно: растёт база, увеличивается число пользователей, фрагментируются индексы. Поэтому раз в несколько месяцев повторяйте контрольные замеры и проверяйте выполнение планов обслуживания СУБД. Появление жалоб «раньше было быстрее» — сигнал проверить в первую очередь статистику, индексы и свободное место на дисках.

Частые вопросы