← На главную

При организации работы 1С для компании из 20–25 пользователей (например, 20 подключений в конфигурации Управление торговлей и 5 в Бухгалтерия предприятия) часто возникает вопрос: как правильно подобрать серверное железо и какую архитектуру выбрать — файловую или серверную на базе Linux и PostgreSQL?

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

Анализ требований и выбор архитектуры: файловый вариант vs SQL

Для 20–25 активных пользователей файловый режим работы базово не подходит. При интенсивной работе в рознице и одновременном проведении документов файловая база данных быстро сталкивается со следующими проблемами:

1. Блокировки таблиц: в файловом режиме блокируется вся таблица целиком, а не отдельная строка, из-за чего пользователи сталкиваются с постоянным ожиданием освобождения ресурсов.
2. Повышенный риск повреждения базы: при сбоях сети или зависании ПК одного из пользователей возрастает риск повреждения файла 1Cv8.1CD.
3. Низкая скорость проведения документов: тяжелые конфигурации на управляемых формах (УТ 11, БП 3.0) требуют значительных ресурсов процессора и диска для обработки запросов.

Поэтому единственным адекватным выбором для 25 пользователей является клиент-серверный вариант с использованием 64-разрядного сервера 1С и СУБД PostgreSQL.

Выбор процессора и оперативной памяти

Проанализируем требования к центральному процессору и объему памяти (RAM) для совместной работы сервера 1С и СУБД на одной физической машине.

Оперативная память:

1. Для 25 пользователей требуется минимум 32 ГБ ECC RAM.
2. Распределение памяти: около 12–16 ГБ выделяется для рабочих процессов 1С (rphost), от 10 до 14 ГБ под кэш PostgreSQL и СУБД, оставшаяся часть — для нужд ОС Linux и служебных утилит.
3. Не рекомендуется экономить на памяти: установка меньше 24–32 ГБ приведет к уйме вытеснений страниц на диск (swapping) и сильным задержкам.

Процессор (CPU):

1. Для небольших баз важнее высокая тактовая частота ядра, чем их количество. Отличным решением служат процессоры серии Intel Xeon E3-1240 v2 / v3 / v6 (или современные аналоги Xeon E-2000 серии) с частотой от 3.4 ГГц.
2. Если планируется дальнейший рост масштаба базы или запуск дополнительных виртуальных машин, разберем вариант с двухпроцессорными системами на базе Intel Xeon E5 (или Xeon Silver/Gold).

Проектирование дисковой подсистемы и выбор RAID-контроллера

Дисковая подсистема — это самый критичный узел для СУБД PostgreSQL и 1С. Скорость работы базы напрямую зависит от числа операций ввода-вывода в секунду (IOPS) и задержек записи.

Главное правило дискового массива: категорически не рекомендуется использовать массивы RAID 5 или RAID 6 для баз данных 1С из-за низкой скорости случайной записи (проблема Write Penalty).

Рассмотрим рекомендуемую конфигурацию дисков на базе аппаратного RAID-контроллера:

1. Аппаратный RAID-контроллер: обязательное наличие внешнего контроллера (например, Adaptec 6805 / 7-й серии или LSI MegaRAID 9260/9361) с собственной кэш-памятью (512 МБ – 1 ГБ) и обязательным модулем защиты кэша (BBU — Battery Backup Unit или AFU — Flash-based cache protection). Наличие батареи позволяет включить режим отложенной записи Write-Back, что дает огромный прирост скорости записи.
2. Разделение дисковых массивов:
   • Array 1 (RAID 1 - Зеркало): 2 диска (SAS/SATA или SSD) под операционную систему Linux и файлы самого сервера 1С.
   • Array 2 (RAID 1 - Зеркало): 2 диска под журнал предзаписи PostgreSQL (папка pg_xlog или pg_wal). Размещение WAL на отдельном физическом массиве гарантирует отсутствие конкуренции за головки диска при интенсивных транзакциях.
   • Array 3 (RAID 10): 4 диска SAS 15k rpm или Enterprise SSD под файлы данных самой СУБД (/var/lib/pgsql).

Особенности использования SSD:

Если для СУБД выбираются SSD накопители, проанализируем их специфику:

1. Применяйте только накопители класса Enterprise с аппаратной защитой от потери питания (PLP — Power Loss Protection). Обычные пользовательские SSD при сбое электропитания могут потерять данные из внутреннего кэша, что приведет к разрушению структуры PostgreSQL.
2. Убедитесь, что контроллер поддерживает проброс команд TRIM или правильно работает с кэшированием SSD.

Особенности настройки Linux и СУБД PostgreSQL для 1С

Обычный (ванильный) PostgreSQL с официального сайта не подходит для полноценной работы с 1С. Требуется использовать специализированную сборку PostgreSQL от компании 1С или Postgres Pro, в которую внесены патчи для работы с временными таблицами, блокировками и специфическими запросами платформы.

Разберем обязательные шаги по оптимизации операционной системы Linux и конфигурации СУБД:

1. Отключение Transparent Huge Pages (THP):

   В Linux включенные прозрачные гигантские страницы памяти приводят к утечкам RAM и задержкам СУБД. В параметрах ядра необходимо установить:

   transparent_hugepage=never
2. Настройка параметров виртуальной памяти Linux:

   Снизим агрессивность использования файла подкачки (swap), изменив параметры в /etc/sysctl.conf:

   Скопировать код

   
   vm.swappiness = 10
   vm.dirty_ratio = 15
   vm.dirty_background_ratio = 5
   

3. Установка шрифтов Microsoft:

   Для корректного формирования печатных форм, отчетов и экспорта документов в PDF/Excel на сервере Linux необходимо обязательно установить пакет msttcorefonts (или ttf-mscorefonts-installer).

4. Настройка автовакуума (Autovacuum):

   В конфигурации postgresql.conf необходимо обязательно скорректировать параметры автовакуума. Для управляющих конфигураций 1С (УТ 11, БП 3.0) происходит постоянное создание и удаление временных таблиц. Неправильно настроенный autovacuum приведет к быстрому разрастанию файлов баз (table bloat) и деградации производительности.

Оптимизация работы клиентских рабочих мест и сервера 1С

Выясним, нужен ли терминальный сервер (RDP) для 25 пользователей:

1. Тонкий клиент 1С: управляемые формы в Управление торговлей 11 и Бухгалтерия предприятия 3.0 оптимизированы для работы через тонкий клиент. Он потребляет минимум ресурсов на локальном ПК (около 150–200 МБ ОЗУ) и передает по сети только результаты сборок форм.
2. Если на рабочих местах старые ПК: если физические компьютеры в магазинах имеют устаревшие процессоры Celeron и 512–1024 МБ ОЗУ, запуск локального тонкого клиента может вызывать задержки. В этом случае оправдано использование отдельного терминального сервера RDP (на базе Windows Server), откуда пользователи запускают тонкие клиенты 1С.
3. Ограничение памяти рабочих процессов: в консоли администрирования кластера 1С рекомендуется настроить перезапуск рабочих процессов rphost по превышению объема занимаемой памяти (параметры --ram-size или перезапуск по расписанию), чтобы избежать утечек памяти при длительной работе пользователей.