← На главную

Многие системные администраторы сталкиваются с необъяснимой проблемой: сервер 1С начинает работать крайне медленно. Долго открывается конфигуратор, запуск пользовательского режима занимает минуты, а проведение даже простых документов вызывает зависания. При этом, открыв диспетчер задач, мы видим парадоксальную картину: процессор загружен всего на 5–10 %, свободной оперативной памяти в избытке (например, 10 ГБ из 24 ГБ), а дисковая система практически простаивает.

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

1. Настройки энергосбережения процессора (Power Management)

Проанализируем базовые аппаратные настройки. Одной из самых частых причин медленной работы при минимальной загрузке являются алгоритмы энергосбережения современных процессоров.

Когда общая нагрузка на сервер низкая, операционная система или BIOS могут принудительно снизить тактовую частоту процессора. Однако для платформы 1С критически важна максимальная производительность на одно ядро. Из-за энергосбережения процессор может работать на частоте 1.2 ГГц вместо номинальных 3.5 ГГц.

Что нужно сделать:

1. В панели управления Windows перейдите в раздел «Электропитание» и обязательно установите схему Высокая производительность (High Performance).
2. Зайдите в настройки BIOS сервера. Отключите параметры энергосбережения (например, C-States). Функции вроде Intel Turbo Boost лучше оставить включенными, но при этом зафиксировать минимальное состояние процессора на 100 %.

2. Настройки и утечки памяти рабочих процессов (rphost)

Рассмотрим работу процессов кластера 1С. Очень часто проблема кроется в том, что рабочий процесс rphost разрастается в оперативной памяти (например, до 20 ГБ) из-за выполнения тяжелых отчетов или фоновых заданий, а после их завершения не освобождает ресурсы корректно или накапливает ошибки.

При этом общий объем свободной оперативной памяти на сервере может быть достаточным, но сам процесс 1С начинает работать медленно из-за фрагментации памяти. Мы можем настроить кластер так, чтобы он сам контролировал свое здоровье.

Рекомендации по настройке кластера:

1. Откройте консоль администрирования серверов 1С. Перейдите в свойства кластера.
2. Установите параметр Допустимый объем памяти. При достижении этого порога процесс будет принудительно перезапущен платформой в фоновом режиме.
3. Используйте параметр Безопасный расход памяти за один вызов. Это защитит сервер от падения при формировании неоптимального отчета одним пользователем.
4. Задайте Интервал перезапуска (например, раз в сутки ночью). Это позволит периодически очищать память рабочих процессов и избегать накопления «мусора».
5. В целях диагностики временно выставите правило «1 база на рабочий процесс» (доступно при наличии лицензии КОРП). Это позволит в диспетчере задач точно вычислить проблемную базу, создающую нагрузку на конкретный rphost.

3. Полнотекстовый поиск и регламентные задания

Проанализируем фоновую активность. Огромное влияние на общую отзывчивость баз оказывают регламентные задания, в частности — обновление индекса полнотекстового поиска. Эти задания запускаются по расписанию (иногда ежеминутно).

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

Алгоритм диагностики:

1. Отключите выполнение регламентных заданий (включая полнотекстовый поиск) во всех подозрительных базах на один день.
2. Понаблюдайте за работой. Если проблема исчезла, начинайте включать задания по одной базе, чтобы найти виновника.
3. Очистите и пересчитайте индекс полнотекстового поиска в проблемной базе. Для этого в режиме предприятия можно использовать стандартную обработку управления полнотекстовым поиском. Очистка и пересоздание индекса часто решает скрытые проблемы с производительностью, особенно после обновления релиза платформы.

4. Использование десктопных ОС (Windows 10) вместо серверных

Посмотрим на выбор операционной системы. Использование Windows 10 Professional в качестве сервера для 30 баз данных — это популярная практика для экономии на лицензиях, однако она несет в себе скрытые риски.

Настольные ОС имеют жесткие ограничения, которые не видны в диспетчере задач:

1. Ограничение TCP-соединений: В Windows 10 существует лимит на количество полуоткрытых TCP-соединений. При большом количестве баз и сеансов система может начать искусственно блокировать или замедлять сетевой стек, посчитав такую активность аномальной.
2. Планировщик задач: В серверных ОС (Windows Server) планировщик (Thread Scheduling) оптимизирован для фоновых процессов и служб, что критично для 1С и SQL. В Windows 10 приоритет всегда отдается активному окну пользователя на рабочем столе.

Если вы используете Windows 10, убедитесь, что отключили антивирусные сетевые фильтры. Даже после удаления антивируса в свойствах сетевого адаптера могут остаться его драйверы, проверяющие трафик, что вызывает колоссальные задержки.

5. Оптимизация сети: IPv6, DNS и протокол Shared Memory

Проанализируем сетевое взаимодействие между компонентами 1С и базой данных. 1С крайне чувствительна к скорости работы сети и разрешению доменных имен.

Оптимизация протоколов:

1. Windows по умолчанию приоритезирует протокол IPv6. Служба 1С может пытаться найти SQL-сервер по IPv6, не получать ответа, ждать таймаут и только потом переключаться на IPv4. Это вызывает микрозадержки. Рекомендуется полностью отключить IPv6 в свойствах сетевого адаптера.
2. Пропишите IP-адрес и имя сервера в файле hosts. Это позволит 1С мгновенно находить машину, не обращаясь к DNS-серверу.
3. Если Сервер 1С и СУБД MS SQL установлены на одном физическом сервере, обязательно включите в SQL Server Configuration Manager протокол Shared Memory. Использование сетевого протокола TCP/IP внутри одной ОС добавляет лишние накладные расходы. В строке подключения базы в консоли 1С укажите имя сервера как (local) или просто точку . — это заставит систему использовать общую оперативную память для обмена данными в обход сетевого стека.

6. Дисковая очередь и база TempDB

Рассмотрим дисковую подсистему. Вы можете видеть, что скорость записи или чтения составляет всего пару мегабайт в секунду, и считать, что диски не загружены. Однако важна не скорость, а Очередь к диску (Disk Queue Length).

Если очередь превышает 1.5–2 пункта на постоянной основе, это означает, что диски просто не успевают обрабатывать количество мелких запросов (IOPS), и все транзакции 1С ставятся в ожидание.

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

Как оптимизировать TempDB:

1. Разбейте базу tempdb на несколько физических файлов. Рекомендуется создавать файлы данных по числу логических ядер процессора (но обычно не более 8).
2. Сделайте все файлы строго одинакового размера и задайте одинаковый шаг автоприроста. Это устранит внутренние блокировки (PAGELATCH) в SQL Server при распределении свободных страниц памяти.

7. Обслуживание СУБД и статистика

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

Причиной этому чаще всего является устаревшая статистика индексов. SQL «думает», что в таблице 100 записей, хотя их там уже миллион.

Обязательные регламентные операции в SQL Server:

1. Ежедневное обновление статистики (Update Statistics). Крайне важно для 1С!
2. Еженедельная реорганизация или перестроение индексов (Rebuild/Reorganize Index), чтобы устранить фрагментацию таблиц.
3. Проверьте модель восстановления (Recovery Model). Для тестовых и демонстрационных баз смело ставьте режим Simple (Простая), чтобы отключить рост файлов транзакций (LDF) и снизить нагрузку на диски.

8. Нюансы виртуализации

Если сервер 1С развернут на виртуальной машине (Hyper-V, VMware), проблема может скрываться на уровне гипервизора.

Если виртуальной машине выделено 24 ГБ оперативной памяти, но эта память настроена как «Динамическая» (Dynamic Memory) или гипервизор превысил лимиты физического сервера (Overcommit), начинается катастрофа производительности.

Внутри гостевой ОС Windows будет показывать, что памяти полно и нагрузка минимальна. Но снаружи гипервизор будет сбрасывать страницы памяти в файл подкачки на медленный диск. Для сервера 1С и СУБД память всегда должна выделяться жестко (Static/Fixed Memory), без возможности ее резервирования (Ballooning) другими виртуальными машинами.

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