Как оптимизировать производительность сервера 1С на слабом железе и настроить СУБД для максимального быстродействия?

Системный администратор 1С v8.3 (Управляемые формы) IT и автоматизация бизнеса
← На главную

Каждый системный администратор рано или поздно сталкивается с ситуацией, когда ему в наследство достается "сервер" 1С, собранный из подручных комплектующих, работающий крайне медленно и регулярно зависающий. При этом бюджет компании на модернизацию жестко ограничен, а пользователи (даже если их всего 7 человек) требуют стабильной и быстрой работы баз данных.

В этой статье мы подробно разберем, как локализовать узкие места такой системы, правильно распределить дисковую нагрузку, настроить параметры СУБД MS SQL Server Express, оптимизировать кластер 1С и выяснить, стоит ли переходить на альтернативные решения вроде PostgreSQL. Мы также ответим на важные вопросы по выбору серверного железа и целесообразности использования оперативной памяти с коррекцией ошибок (ECC) для малых баз данных.

Шаг 1. Диагностика узких мест системы

Прежде чем приступать к изменению каких-либо настроек, мы должны провести тщательный мониторинг ресурсов сервера. Рассмотрим классические симптомы критической нехватки аппаратных ресурсов:

  1. Загрузка оперативной памяти на 100%. Это приводит к тому, что операционная система начинает активно использовать файл подкачки (pagefile.sys) на жестком диске. Поскольку скорость работы диска на несколько порядков ниже скорости ОЗУ, вся система впадает в ступор.
  2. Загрузка дисковой подсистемы (Active Time) на 100%. Постоянная очередь к диску означает, что диски не справляются с потоком случайных операций чтения и записи (IOPS). Базы данных "застывают", а пользователи видят бесконечное колесико ожидания.
  3. Низкая загрузка процессора (2-3%) при общей медлительности. Этот парадоксальный симптом указывает на то, что процессор простаивает в ожидании данных от дисков или оперативной памяти. Увеличение вычислительной мощности процессора в данный момент не принесет никакой пользы.

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

Шаг 2. Оптимизация дисковой подсистемы и отказ от медленных RAID-массивов

Одной из главных ошибок при сборке бюджетных серверов является создание программного (софтового) RAID-массива средствами материнской платы на разнородных и медленных жестких дисках. Рассмотрим, почему конфигурация из нескольких накопителей WD Green и одного WD Blue в RAID 10 обречена на провал:

Для оптимизации работы дисковой подсистемы без покупки дорогостоящих SSD мы рекомендуем разобрать софтовый RAID и физически распределить нагрузку по разным дискам:

  1. Диск 1 (Системный). Сюда мы устанавливаем операционную систему Windows Server и файлы подкачки.
  2. Диск 2 (Быстрый одиночный или RAID 1 из надежных дисков). Сюда мы помещаем файлы данных баз данных 1С (файлы с расширением mdf).
  3. Диск 3 (Отдельный физический накопитель). Этот диск мы выделяем исключительно под файлы журналов транзакций СУБД (файлы с расширением ldf) и временную базу данных tempdb. Журнал транзакций пишется последовательно, а файлы баз данных читаются и пишутся хаотично. Разделение этих потоков по разным физическим шпинделям радикально снижает нагрузку на головки дисков.

Шаг 3. Изучение жестких ограничений MS SQL Server Express

Очень часто в небольших фирмах используют бесплатную версию СУБД — MS SQL Server Express. Мы должны четко понимать жесткие рамки этой редакции, чтобы не тратить время на бессмысленную настройку:

С учетом этих лимитов, мы должны правильно настроить параметры выделения памяти и авторасширения баз данных:

Установим шаг увеличения размера баз данных. По умолчанию в SQL Server часто стоит автоувеличение на 1 МБ или на 10%. Шаг в 1 МБ приводит к страшной фрагментации файлов на жестком диске: при каждой записи новых данных СУБД вынуждена приостанавливать транзакции и запрашивать у ОС расширение файла. Мы рекомендуем установить фиксированный шаг авторасширения в размере 512 МБ или 1024 МБ как для файлов данных, так и для файлов логов.

Шаг 4. Настройка параметров кластера 1С:Предприятие 8.3

Проанализируем базовые параметры настройки рабочего сервера и кластера 1С. Важно понимать, что гибкое управление процессами зависит от уровня имеющейся лицензии платформы (ПРОФ или КОРП). Начиная с версии платформы 8.3.15, компания 1С ограничила доступ к расширенным настройкам для лицензий уровня ПРОФ.

Если у вас используется стандартная лицензия ПРОФ, следующие параметры должны оставаться в значениях по умолчанию (значение "0" или "-1"):

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

  1. Интервал перезапуска рабочих процессов. Установим значение в 86400 секунд (24 часа) или 28800 секунд (8 часов). Это позволит автоматически и бесшовно для пользователей перезапускать процессы rphost, освобождая накопленную в оперативной памяти "течь".
  2. Выключенные процессы останавливать через. Рекомендуем задать значение 60 или 120 секунд, чтобы дать активным сессиям безопасно завершить работу и перейти на новые процессы СУБД.

Шаг 5. Активация протокола Shared Memory

Когда сервер 1С и СУБД MS SQL Server установлены на одном и том же физическом компьютере, мы можем получить существенный прирост производительности, исключив сетевой стек из цепочки обмена данными. Для этого используется протокол обмена через общую память — Shared Memory.

Для того чтобы задействовать этот механизм, мы должны убедиться, что в настройках СУБД (через SQL Server Configuration Manager) в разделе "Сетевые протоколы" включен протокол Shared Memory. В строке подключения к СУБД в кластере 1С при создании информационной базы мы должны явно указывать локальное имя сервера (например, localhost или точку .), что заставит платформу использовать быструю оперативную память напрямую вместо сетевых пакетов TCP/IP.

Шаг 6. Оценка производительности с помощью теста Гилёва

Для объективной оценки того, насколько успешно мы провели оптимизацию, воспользуемся популярным однопоточным тестом производительности Гилёва. Результаты теста ("попугаи") делятся на следующие категории:

Если после настройки дисков и памяти мы получили скромный результат (например, 16 попугаев), мы должны выяснить первопричину. Тест Гилёва крайне чувствителен к тактовой частоте одного ядра процессора.

Для моментального поднятия производительности без финансовых затрат проверим важнейшую настройку операционной системы: схему электропитания. По умолчанию в Windows Server включена сбалансированная схема (Balanced), которая снижает частоту процессора при отсутствии пиковой нагрузки. 1С работает транзакциями, которые операционная система не всегда распознает как высокую нагрузку. Мы должны принудительно перевести сервер в режим "Высокая производительность" (High Performance) как в самой Windows, так и в настройках BIOS (отключив энергосберегающие технологии C-States и включив Intel Turbo Boost или AMD Precision Boost).

Шаг 7. Переход на СУБД PostgreSQL как бесплатная альтернатива

Если бюджет компании равен нулю, а базы данных подходят к лимиту в 10 ГБ или требуют больше оперативной памяти, чем может предложить MS SQL Express, оптимальным решением станет миграция на СУБД PostgreSQL. Мы рекомендуем использовать специализированные сборки, оптимизированные разработчиками (например, от Postgres Pro).

Преимущества PostgreSQL для 1С:

Важные нюансы настройки:

В отличие от решений Microsoft, СУБД PostgreSQL требует обязательного ручного редактирования файла конфигурации postgresql.conf. Рассмотрим пример базовой настройки ключевых параметров для сервера с 16 ГБ оперативной памяти:


# Пример базовой оптимизации postgresql.conf для сервера с 16 ГБ ОЗУ под 1С
shared_buffers = 4GB             # Выделяем 25% от общего объема ОЗУ под кэш СУБД
temp_buffers = 256MB             # Размер буфера под временные таблицы
work_mem = 64MB                  # Лимит памяти для группировок и сортировок одного запроса
maintenance_work_mem = 512MB     # Память для создания индексов и очистки СУБД
effective_cache_size = 12GB      # Оценка доступной кэш-памяти ОС (~75% от всей памяти)

После изменения этих настроек и перезапуска службы PostgreSQL производительность 1С станет стабильной и перестанет упираться в жесткие рамки бесплатного MS SQL Express.

Шаг 8. Ответы на вопросы по подбору оборудования (Анализ модернизации)

Рассмотрим часто возникающие вопросы системных администраторов при планировании апгрейда бюджетного сервера 1С на примере перехода на процессоры AMD Ryzen Threadripper или десктопные платформы.

Вопрос А: Есть ли смысл покупать оперативную память с коррекцией ошибок (ECC) для небольших баз данных?

Мы однозначно отвечаем: да, смысл есть. Для серверов баз данных стабильность оперативной памяти является определяющим фактором сохранности информации. Случайный сбой бита в ОЗУ (bit flip), вызванный внешними факторами, в обычной памяти (non-ECC) приведет к повреждению структуры базы данных, которое может быть обнаружено лишь спустя недели при закрытии месяца. Память ECC автоматически исправляет однобитовые ошибки налету. Слухи о том, что ECC-память медленнее, сильно преувеличены — падение производительности из-за алгоритмов контроля четности составляет не более 1–2%, что абсолютно незаметно на практике.

Вопрос Б: Насколько удачен выбор платформы на базе процессора AMD Ryzen Threadripper 1900X для 1С?

Проанализировав архитектуру данного процессора, мы приходим к выводу, что этот выбор крайне неудачен. Threadripper 1900X построен по многокристальной схеме (NUMA-архитектура), где доступ к разным модулям памяти происходит с неодинаковой задержкой (latency). Платформа 1С критически чувствительна к скорости работы оперативной памяти и задержкам шины. Кроме того, данный процессор имеет невысокую однопоточную производительность по сравнению с современными десктопными решениями.

Вместо устаревших многоядерных платформ для 7–10 пользователей гораздо выгоднее приобрести современный процессор на сокете AM5 (например, AMD Ryzen 5 7600X или его аналоги от Intel) с базовой частотой более 4.5 ГГц. Они отлично поддерживают unbuffered ECC память на многих материнских платах и обеспечат фантастическую скорость работы в тесте Гилёва (до 80-100 попугаев).

Вопрос В: Что лучше выбрать для работы 7 пользователей — веб-сервер IIS или удаленный рабочий стол (RDP)?

Мы настоятельно рекомендуем использовать веб-сервер IIS (или Apache) совместно с тонким клиентом 1С. Работа по протоколу HTTP/HTTPS имеет огромные преимущества перед RDP:

← На главную