При развертывании сервера для обслуживания небольших баз «1С:Предприятие» системные администраторы часто сталкиваются со сложным выбором: использовать надежное, но дорогое серверное оборудование корпоративного класса или обойтись производительным «десктопным» железом. Ситуация усложняется множеством мифов вокруг надежности SSD-накопителей, эффективности многоядерных процессоров и необходимости использования оперативной памяти с коррекцией ошибок (ECC).
В этой статье мы подробно проанализируем реальные потребности серверной части «1С» для небольшой аутсорсинговой бухгалтерской компании (7 активных пользователей, 23 базы общим объемом около 17.5 ГБ, доступ через веб-сервер IIS и тонкий клиент) и сформируем сбалансированные технические рекомендации.
---
В обсуждениях часто фигурируют многоядерные процессоры вроде семейства AMD Ryzen Threadripper или многоядерные серверные Intel Xeon с относительно низкой базовой частотой. Разберем по шагам, почему для «1С» это не самый эффективный выбор.
Архитектура «1С:Предприятие» построена так, что критически важные бизнес-операции (такие как проведение документов, расчет себестоимости, выполнение сложных пакетных запросов к СУБД) выполняются строго в один поток. Это означает, что в момент выполнения такой транзакции вся нагрузка ложится на одно ядро процессора. Если тактовая частота этого ядра низкая (например, 2.2–2.5 ГГц), пользователь будет долго ждать завершения операции, даже если на сервере установлены два процессора по 24 ядра каждый.
Для 7 пользователей, работающих одновременно, 8-ядерный высокочастотный процессор будет идеальным решением. При этом около 6 ядер большую часть времени будут простаивать, обеспечивая мгновенный отклик в моменты пиковых нагрузок. Рассмотрим основные варианты архитектур:
rphost.exe) на слабые E-ядра. Если вы выбираете такой процессор, в BIOS рекомендуется полностью отключать E-ядра либо жестко задавать соответствие ядер (CPU Affinity) в диспетчере задач.---
Существует старое мнение, что базы данных категорически нельзя размещать на SSD-накопителях из-за их быстрого износа (якобы «три года — и на помойку»). Проанализируем реальные цифры износа.
Современные накопители потребительского класса (например, линейка Samsung PRO / EVO) имеют заявленный ресурс (TBW) на уровне сотен терабайт. Если за 4 месяца работы базы данных перезаписывают всего около 7 ТБ информации, то годовой объем записи составит около 21 ТБ. Для накопителя объемом 1 ТБ с ресурсом 1200 TBW физический износ ячеек памяти наступит только через 50–60 лет реальной эксплуатации. Следовательно, износ памяти в условиях небольшой бухгалтерской фирмы не является угрозой.
Однако существует гораздо более серьезная и скрытая опасность потребительских SSD — отсутствие аппаратной защиты от потери питания (PLP — Power Loss Protection).
Обычные SSD активно используют быстрый кэш DRAM для буферизации операций записи. При внезапном отключении электричества или зависании операционной системы данные, находящиеся в этом кэше, бесследно исчезают. Для файловых баз «1С» (файл 1Cv8.1CD) это гарантированно оборачивается разрушением внутренней структуры таблиц, потерей индексов и критическими ошибками формата потока.
Рекомендации по дисковой подсистеме:
---
Многие считают, что коррекция ошибок (ECC — Error-Correcting Code) нужна только крупным корпорациям с огромными базами данных. На самом деле, для небольших файловых баз «1С» отсутствие ECC представляет прямую угрозу потери целостности данных.
При работе в файловом режиме операционная система активно кэширует базу данных в оперативную память. Если в модуле памяти происходит случайный сбой (например, из-за статического напряжения, нагрева или фонового излучения) и меняется значение хотя бы одного бита («bit flip»), операционная система воспримет эту искаженную информацию как корректную и запишет ее обратно на SSD. Это явление называется тихим повреждением данных (silent data corruption).
Пользователи могут продолжать работать в базе неделями, не замечая проблемы, пока система не попытается обратиться к поврежденному сектору. К этому моменту все созданные за последнее время резервные копии уже будут содержать эту ошибку, и восстановить работоспособную базу будет крайне сложно.
Решение: Современные платформы AMD Ryzen (на сокетах AM4 и AM5) на уровне встроенного в процессор контроллера поддерживают небуферизованную память с коррекцией ошибок (UDIMM ECC). Для сборки надежного сервера достаточно выбрать материнскую плату (например, от ASUS или ASRock), которая официально поддерживает ECC-режим в связке с процессором без встроенного графического ядра.
---
При наличии 23 баз общим объемом 17.5 ГБ файловый режим работы кажется наиболее простым. Однако он накладывает жесткие ограничения на транзакционные блокировки и критически чувствителен к стабильности локальной сети.
В качестве альтернативы дорогому MS SQL Server оптимально рассмотреть бесплатную СУБД PostgreSQL (с патчами от «1С» или отечественную сборку Postgres Pro). Перенос баз на PostgreSQL решает несколько важнейших задач:
---
Простое копирование файлов базы данных 1Cv8.1CD с помощью обычного архиватора (например, 7-Zip) «на горячую», когда в системе могут находиться незавершенные сессии пользователей, крайне опасно. Созданный таким образом архив с высокой вероятностью будет содержать незавершенные транзакции и окажется поврежденным.
Разберем правильные методы организации резервного копирования:
Служба VSS (Volume Shadow Copy Service) позволяет создавать мгновенный «снимок» диска на определенный момент времени, гарантируя целостность файлов даже во время активной записи. Для автоматизации процесса можно использовать специализированные программы (например, Effector Saver) или написать командный скрипт.
Рассмотрим пример PowerShell-скрипта для корректной остановки веб-сервера IIS, создания резервной копии и последующего запуска службы:
# Остановка службы IIS для освобождения файловых блокировок
Stop-Service -Name "W3SVC" -Force
# Путь к архиватору 7-Zip
$7zipPath = "C:\Program Files\7-Zip\7z.exe"
# Настройки резервного копирования
$SourceFolder = "C:\inetpub\wwwroot\1c_bases\"
$BackupDest = "D:\Backups\1C_Backup_$(Get-Date -Format 'yyyy-MM-dd').7z"
# Запуск процесса архивации
Start-Process -FilePath $7zipPath -ArgumentList "a -t7z `"$BackupDest`" `"$SourceFolder`"" -Wait
# Запуск службы IIS после завершения копирования
Start-Service -Name "W3SVC"
При использовании СУБД (PostgreSQL или MS SQL) резервное копирование необходимо выполнять исключительно встроенными средствами СУБД (создание дампов баз данных). Это позволяет делать надежные бэкапы в фоновом режиме каждые 15–30 минут без отключения пользователей от системы, минимизируя возможные потери данных до нескольких минут работы.