← На главную

При обслуживании большого количества информационных баз 1С (например, 30–40 баз консалтинговой или бухгалтерской фирмы) на одном сервере системные администраторы часто сталкиваются с резким падением производительности. Базы данных начинают открываться по несколько минут, возникает ошибка соединения Shared Memory или Native Client, а в консоли MS SQL Server Management Studio информационные базы периодически переходят в состояние Recovery (Восстановление).

Проанализируем основные причины возникновения таких сбоев и разберем по шагам порядок действий для восстановления стабильной работы сервера 1С и СУБД.

Выясняем причины сбоя и зависания баз

Переход базы данных MS SQL в состояние Recovery означает, что СУБД производит накатывание или откат нерегистрированных транзакций для обеспечения целостности данных. Если это происходит регулярно прямо во время работы пользователей, причины кроются в следующих факторах:

1. Нехватка оперативной памяти и сброс в файл подкачки (Paging): Если операционной системе выделено слишком мало памяти (например, 1 ГБ), Windows начинает активно использовать файл подкачки pagefile.sys. В момент высокого потребления памяти рабочими процессами 1С (rphost.exe) или СУБД (sqlservr.exe) возникают таймауты ввода-вывода, из-за чего SQL Server теряет связь с диском и уводит базы в процедуру восстановления.
2. Включенный параметр AUTO_CLOSE в MS SQL Server: Если для баз данных активирована опция автоматического закрытия, СУБД выгружает базу из памяти сразу после отключения последнего пользователя. При новом подключении фонового задания или пользователя база начинает открываться заново, проходя стадию Recovery.
3. Высокая фрагментация журнала транзакций (VLF): Если шаг автоувеличения файла лога (.ldf) задан в процентах или небольшим фиксированным значением (1 МБ), внутри лога образуются тысячи виртуальных файлов (VLF), что существенно замедляет любые операции проверки целостности.
4. Перегрузка дисковой подсистемы: Обычные HDD-диски серии Blue или Desktop не рассчитаны на одновременную случайную запись журналов транзакций и временных таблиц нескольких десятков баз.

Шаг 1. Очистка кэша сервера 1С и переподключение баз данных

Первым экстренным шагом для снятия блокировок и устранения ошибок «База данных не обнаружена» является сеансовая очистка служебных файлов кластера 1С и пересоздание журналов транзакций SQL.

1. Остановим службу кластера серверов 1С (название службы: 1C:Enterprise 8.3 Server Daemon или аналогичное).
2. Перейдем в каталог данных кластера (по умолчанию: C:\ProgramData\1C\1CEstart и C:\ProgramData\1C\1cv8\srvinfo) и удалим содержимое папок системного кэша (папки с именами вида reg_1541, исключая сам файл конфигурации кластера, если требуется сохранить список баз, или очистим каталоги временных файлов рабочих процессов).
3. В консоли MS SQL Server Management Studio отключим проблемные базы данных (операция Detach).
4. Удалим или переместим разросшиеся файлы журналов транзакций (.ldf).
5. Подключим базы данных обратно (операция Attach) — при отсутствии .ldf файла SQL Server автоматически создаст чистый журнал транзакций.
6. Запустим службу кластера 1С.

Шаг 2. Корректное распределение оперативной памяти

Разберем пример сервера с ограничением в 16 ГБ ОЗУ. Выделение 9 ГБ под 1С и 6 ГБ под SQL Server оставляет операционной системе всего 1 ГБ, что неизбежно приводит к жесткому своппингу на диск.

Для обеспечения стабильности установим следующие лимиты:

1. Операционная система Windows: Оставим не менее 2,5–3 ГБ свободной физической памяти.
2. MS SQL Server: В свойствах сервера (раздел Memory / Память) ограничим максимальный объем памяти (Maximum server memory) значением 6–7 ГБ.
3. Блокировка страниц в памяти (Lock Pages in Memory): Назначим учетной записи, от имени которой запущена служба MSSQLSERVER, локальное право Windows Lock Pages in Memory через оснастку secpol.msc (Локальная политика безопасности -> Назначение прав пользователя). Это запретит операционной системе вытеснять память SQL Server в файл подкачки.

Шаг 3. Оптимизация параметров кластера серверов 1С

Для снижения нагрузки на процессор и оперативную память настроим параметры работы кластера 1С в консоли администрирования:

1. Перейдем в свойства рабочего сервера кластера.
2. Установим параметр Количество ИБ на процесс равным 1 или 2. Это позволит разнести нагрузку разных баз по отдельным процессам rphost.exe и предотвратит падение всех пользователей при сбое в одной базе.
3. Настроим Интервал перезапуска рабочих процессов (например, 86400 секунд — раз в сутки в ночное время) и Предел объема памяти для процессов, чтобы своевременно освобождать протекающую память.
4. Временно отключим или перераспределим по времени тяжелые Регламентные задания во всех некритичных информационных базах, чтобы они не запускались одновременно.

Шаг 4. Настройка СУБД MS SQL Server

Проанализируем критически важные параметры СУБД для работы с 1С:

1. Проверка параметров AUTO_CLOSE и AUTO_SHRINK: Для каждой из 40 баз необходимо убедиться, что эти опции отключены. В противном случае выполним SQL-скрипт:
   Скопировать код

   
   ALTER DATABASE [ИмяБазы] SET AUTO_CLOSE OFF;
   ALTER DATABASE [ИмяБазы] SET AUTO_SHRINK OFF;
   

2. Настройка автоувеличения файлов (Autogrowth): Изменим прирост файла данных (.mdf) и файла лога (.ldf) с процентного на фиксированный. Для лога укажем шаг 256 MB или 512 MB, чтобы избежать образования тысяч мелких виртуальных файлов VLF.
3. Настройка параллелизма (MAXDOP): В свойствах SQL Server (раздел Advanced / Дополнительно) зададим параметр Max Degree of Parallelism равным 1 или 2. Это исключит ситуацию, когда один неоптимальный запрос 1С утилизирует 100% всех ядер процессора.
4. Схема электропитания OS: В панели управления Windows переключим план электропитания в режим Высокая производительность (High Performance), чтобы процессор не сбрасывал тактовую частоту в моменты простоя.