Сервер для 1С: вимоги до заліза
1С упирається в частоту одного ядра та в затримку дисків, а не в кількість потоків. Для продуктивної бази на 20–30 одночасних сеансів беріть 4–8 ядер із частотою від 3,2 ГГц, 32 GB ECC-пам'яті та два NVMe в RAID1. Оперативну пам'ять і диски додати нескладно, частоту процесора — ні, тому добір конфігурації починайте з CPU.
- Частота ядра важливіша за їхню кількість: один користувацький запит 1С виконується в один потік.
- Сервер застосунків і СУБД на одній машині прибирають мережевий round-trip і пришвидшують проведення документів.
- 32 GB ECC — практичний мінімум для клієнт-серверної бази, 64 GB — для бази від 100 GB або від 50 сеансів.
- Файловий режим у мережевій теці дає майже всі скарги на повільну роботу; перехід у клієнт-серверний режим зазвичай корисніший за апгрейд заліза.
Процесор
Платформа розкладає по ядрах різні сеанси, але всередині одного сеансу проведення документа чи перерахунок підсумків іде одним потоком. Звідси правило: 8 ядер по 3,5 ГГц обслужать бухгалтерію краще, ніж 24 ядра по 2,1 ГГц. Дивіться базову частоту й частоту під навантаженням усіх ядер, а не маркетингове значення «до».
Кеш третього рівня теж впливає: регістри накопичення та таблиці підсумків читаються дрібними порціями. Розбір ліній і поколінь — у статті як вибрати процесор для сервера.
| Сценарій | Сеанси | CPU | RAM | Диски |
|---|---|---|---|---|
| Бухгалтерія однієї фірми | до 10 | 4 ядра від 3,3 ГГц | 16 GB ECC | 2×SSD, RAID1 |
| Торгівля і склад | 10–30 | 8 ядер від 3,2 ГГц | 32 GB ECC | 2×NVMe, RAID1 |
| ERP, кілька баз | 30–80 | 16 ядер від 2,8 ГГц | 64 GB ECC | 4×NVMe, RAID10 |
| СУБД окремо від сервера 1С | 80 і більше | два сервери | 64 GB на кожному | NVMe RAID10 під СУБД |
Оперативна пам'ять
MS SQL і PostgreSQL тримають сторінки бази в кеші, і різниця між «база вміщується в пам'ять» і «не вміщується» — це різниця на порядок у часі звіту. Практичне правило: обсяг RAM не менший за половину розміру файлів бази плюс 8 GB на сервер застосунків та операційну систему.
Пам'ять обов'язково ECC. Помилка одного біта в кеші СУБД — це тихо зіпсована сторінка, яка поїде в резервну копію та спливе за кілька тижнів. Як працює корекція і де дивитися лічильники помилок, описано в матеріалі ECC-пам'ять у сервері.
Диски
Профіль навантаження 1С — дрібний випадковий ввід-вивід: журнал транзакцій пишеться синхронно, індекси читаються сторінками по 8 KB. На NVMe такі операції йдуть у 4–6 разів швидше за IOPS на випадковому записі, ніж на SATA SSD, і на два порядки швидше, ніж на механічному жорсткому диску.
Робоче розкладання: система і сервер застосунків на одному дзеркалі, файли бази та журнал транзакцій — на NVMe. RAID1 закриває відмову накопичувача, RAID10 додає запас по запису на великих базах. Деталі розкладання файлів СУБД розібрано у статті виділений сервер під базу даних.
Windows Server чи Linux
Windows Server і MS SQL
Звична зв'язка: сервер застосунків, SQL Server і термінальні сесії користувачів на одній машині. Мінус — ліцензії операційної системи, клієнтські ліцензії та SQL Server рахуються окремо й часто коштують дорожче за оренду самого заліза.
Linux і PostgreSQL
Сервер застосунків під Linux працює з PostgreSQL, зокрема зі збірками, адаптованими під платформу. Ліцензій ОС і СУБД тут немає, але потрібен адміністратор, який розуміє autovacuum, блокування та планувальник запитів. Базове встановлення й налаштування описані у статті PostgreSQL на сервері.
# Debian/Ubuntu: дивимося реальну частоту ядер під навантаженням
lscpu | grep -E 'Model name|MHz'
# RHEL/AlmaLinux: сервер застосунків ставимо з локального каталогу
sudo dnf install -y ./1c-enterprise-server-*.rpm
# ключові параметри PostgreSQL (postgresql.conf)
shared_buffers = 8GB
effective_cache_size = 24GB
work_mem = 64MB
max_connections = 200
# паралельні плани на типових запитах платформи частіше шкодять
max_parallel_workers_per_gather = 0
# застосовуємо і перевіряємо
sudo systemctl restart postgresql
psql -U postgres -c 'show shared_buffers;' 2>&1
# розгортаємо вивантаження в чисту базу
createdb -U postgres -T template0 buh
psql -U postgres -d buh < buh.sql
Найдорожча помилка на такому сервері — антивірус, який у реальному часі перевіряє файли бази та журнал транзакцій. Проведення документа починає тривати секунди замість десятих часток, а в логах СУБД з'являються тайм-аути очікування блокувань. Вилучіть із перевірки каталоги даних СУБД, службовий каталог сервера застосунків і тимчасові файли. Як переконатися, що допомогло: заміряйте одну й ту саму типову операцію до і після правки винятків — час має впасти кратно, а не на відсотки. Друге джерело тих самих симптомів — вимкнений кеш запису RAID-контролера при розрядженій батареї.
Доступ, мережа та резервні копії
Користувачі підключаються тонким клієнтом, по RDP або через веб-клієнт за nginx. Публікувати термінальний доступ в Інтернет на стандартному порту не варто: підніміть VPN або хоча б обмежте підключення за списком адрес.
Окремо сплануйте вивантаження: файл бази і дамп СУБД мають їхати за межі сервера, бо RAID не захищає від помилкового видалення. Готові конфігурації під такі задачі зібрані в розділі виділені сервери: бухгалтерії до 10 сеансів вистачає Dedicated Start DE (Xeon E3-1230v5, 16 GB ECC, 2×500 GB SSD у RAID1) за $49 на місяць, для торгівлі та складу беруть Dedicated Pro DE або Pro FR із 32 GB ECC і NVMe.
Коротко
- Спершу частота ядра, потім їхня кількість: 8×3,5 ГГц краще за 24×2,1 ГГц.
- RAM — половина розміру бази плюс 8 GB, тільки ECC.
- База і журнал транзакцій живуть на NVMe у RAID1 або RAID10.
- Windows із MS SQL дорожчий за ліцензіями, Linux із PostgreSQL — за адмініструванням.
- Винятки антивіруса та кеш запису контролера перевіряйте до того, як міняти залізо.