← На главную
Разберем типичную проблему, с которой сталкиваются системные администраторы при переводе информационных баз 1С с файлового режима на клиент-серверную архитектуру: базы открываются по несколько минут, тест Гилева показывает крайне низкие значения (12–16 баллов), а дисковая подсистема постоянно загружена на 100%. Проанализируем ключевые узкие места и рассмотрим пошаговый алгоритм оптимизации сервера, СУБД и платформы 1С.
1. Анализ ограничений редакции MS SQL Server Express
Одной из главных причин низкой скорости работы нескольких баз является использование редакции MS SQL Server Express. Выясним ее критические ограничения:
- Лимит оперативной памяти: редакция Express способна использовать не более 1 ГБ оперативной памяти для буферного пула одного экземпляра (Buffer Pool), независимо от того, сколько физической памяти установлено в сервере. Если на сервере размещено 5–6 баз конфигурации «Бухгалтерия предприятия 3.0», СУБД вынуждена постоянно вытеснять кэш страниц на диск, вызывая лавинообразный рост дисковых очередей.
- Лимит вычислительных ресурсов: СУБД задействует не более 1 сокета или 4 процессорных ядер.
- Лимит размера базы: максимальный размер одного файла данных составляет 10 ГБ.
Если бюджет не позволяет приобрести полноценную лицензию MS SQL Server Standard, рассмотрим переход на специализированную сборку PostgreSQL для 1С. Она бесплатна, не имеет ограничений по памяти и ядрам, но требует грамотной ручной настройки параметров shared_buffers, work_mem и конфигурации обслуживания вакуума.
2. Настройка параметров СУБД и параметров баз данных
Проанализируем параметры базы данных в SQL Server Management Studio, которые напрямую влияют на время запуска 1С:
- Параметр AUTO_CLOSE (Автозакрытие): по умолчанию в редакциях Express для баз включен режим
AUTO_CLOSE = ON. Это приводит к тому, что при отключении последнего пользователя СУБД полностью освобождает память и закрывает файлы базы. При следующем входе запуск длится несколько минут из-за повторного открытия и проверки файлов. Установим для всех баз AUTO_CLOSE = OFF. - Параметр AUTO_SHRINK (Автосжатие): убедимся, что параметр отключен (
OFF). Автоматическое сжатие порождает критическую фрагментацию файлов и чрезмерную нагрузку на накопители. - Асинхронное обновление статистики: переведем параметр
Auto Update Statistics Asynchronously в значение ON, чтобы пользователи не блокировались при фоновом пересчете статистики запросов. - Шаг автоувеличения файлов (Autogrowth): исключим увеличение файлов по 1 МБ или в процентах. Зададим фиксированный шаг, например, 500 МБ для файла данных (
mdf) и 200–500 МБ для журнала транзакций (ldf).
3. Включение мгновенной инициализации файлов (Instant File Initialization)
При росте файлов базы данных SQL Server по умолчанию перезаписывает новое пространство нулями, полностью блокируя операции ввода-вывода. Включим быстрое выделение места в операционной системе:
- Откроем оснастку локальных политик безопасности
secpol.msc. - Перейдем в раздел: «Параметры безопасности» -> «Локальные политики» -> «Назначение прав пользователя».
- Найдем политику «Выполнение задач по обслуживанию томов» (Perform Volume Maintenance Tasks).
- Добавим учетную запись пользователя, под которой запускается служба
sqlservr.exe, и перезапустим службу СУБД.
4. Настройка кластера серверов 1С:Предприятие
Разберем параметры кластера 1С, влияющие на стабильность процессов rphost. Перейдем в консоль администрирования серверов 1С и скорректируем свойства кластера и рабочих серверов:
- Принудительное завершение проблемных процессов: если флаг включен на нестабильных версиях платформы, рабочий процесс
rphost может циклически перезапускаться при кратковременном росте памяти, сбрасывая сеансы пользователей. Рекомендуется временно отключить его при диагностике. - Интервал перезапуска процессов: для предотвращения деградации из-за утечек памяти зададим интервал перезапуска рабочих процессов раз в сутки (например,
86400 секунд) во внерабочее ночное время. - Блокировка регламентных заданий: в каждой неактивной, тестовой или копийной базе обязательно включим признак «Блокировка регламентных заданий включена». Это снимет паразитную нагрузку от неиспользуемых фоновых процессов
РегламентныеЗадания.
5. Переход с толстого клиента на тонкий клиент
Конфигурация «Бухгалтерия предприятия 3.0» разработана на базе управляемых форм. Запуск пользователей в режиме толстого клиента по локальной сети является грубой ошибкой: толстый клиент передает огромные объемы метаданных и серверного контекста, что вызывает задержки старта до 3–5 минут на обычных дисках.
Проверим настройки запуска на рабочих местах пользователей:
- Откроем окно запуска 1С:Предприятия на клиентской машине.
- Выделим информационную базу и нажмем «Изменить».
- В поле «Основной режим запуска» выберем «Тонкий клиент» вместо «Выбирать автоматически» или «Толстый клиент».
- Очистим кэш конфигурации пользователя в каталогах
%LocalAppData%\1C\1Cv8 и %AppData%\1C\1Cv8.
6. Аппаратные требования и параметры операционной системы
Проанализируем конфигурацию дисков и процессора:
- Отказ от медленных жестких дисков (HDD): программный RAID из накопителей серии WD Green/Blue категорически не подходит для одновременной работы 5–6 баз 1С. Конфигурации на управляемых формах генерируют постоянный случайный ввод-вывод (Random IOPS). Установка производительного SSD (даже потребительского уровня в зеркале RAID 1) под базы
mdf и базу TempDB мгновенно решает проблему длительного запуска и увеличивает результат теста Гилева в 2–3 раза. - Планы электропитания: в операционной системе сервера установим схему электропитания «Высокая производительность» (High Performance). В BIOS сервера отключим энергосберегающие состояния процессора (C-States, C1E), чтобы ядра Xeon работали на максимальной базовой частоте без задержек переключения.
- Исключения антивируса: добавим в список исключений сканирования каталоги баз данных SQL, системный каталог кластера 1С
srvinfo, рабочие папки Temp, а также расширения файлов *.mdf, *.ldf, *.1CD, *.log.