На файловой 1С:КА 1.1 мы работали примерно с 2009 года, после Excel. С 2018-го готовили переход и в начале 2019 года запустили КА 2.4 с клиент-серверной базой на PostgreSQL и Linux; позднее перешли на КА 2.5. Пять лет сервер 1С работал в виртуальной машине, а в августе 2024 года переехал на отдельный сервер. В описываемой установке база занимает около 200 ГБ, с ней работают десять пользователей и два ТСД.
Здесь — история решений: почему мы делали именно так, что ломалось по дороге и какой урок я вынес из самого неожиданного замера.
Содержание · 7 разделов
Откуда уходили
К 2018 году мы подошли к переходу с КА 1.1: база тормозила, каждое обновление давалось непросто. В течение года готовили новую систему и проверяли перенос данных.
При этом в КА 1.1 жила вся наша CRM. Когда-то мы ушли из Excel и стали вести взаимоотношения с клиентами прямо в учётной базе — за годы в ней собралась вся история продаж и звонков. Сохранить её было обязательным условием, и оно определило многое в переезде.
ИТ компании с первого сервера строилось на Linux и свободном ПО. При переходе на новую 1С я хотел сохранить этот подход. В нашей установке 2019 года многое пришлось настраивать и разбирать самостоятельно.
Четыре решения и почему они были такими
Стартовать с начала года и остатками. Весь 2018 год ушёл на подготовку и тесты, а с первых дней 2019-го мы заработали в КА 2.4. Переезд в середине года означал бы вмешательство в текущий учёт, а так старый год закрылся и сдался в старой базе, а новая началась с остатков на 31 декабря. Документы прошлых лет тащить не стали: если что-то понадобится, старая база под рукой.
Дописать типовую обработку под CRM. Типовой переход с КА 1.1 на КА 2 нашу историю с клиентами не забирал. Подрядчик доработал обработку примерно за неделю, и срок растянула скорее его загрузка, чем сама задача. Сам перенос со сверкой занял пару дней: год заканчивался, и учёт был в порядке.
Поставить сервер 1С в виртуальную машину на CentOS 7. Мы понимали, что это не идеал. Но тогда такое решение было вполне рабочим и оправдывало себя по деньгам — схема прожила пять лет.
Уйти с терминального сервера на клиенты на рабочих местах. Поначалу 1С открывали через терминальный сервер — x2go, домен FreeIPA. Позже клиент 1С перенесли прямо на компьютеры сотрудников. Убрали отдельный терминальный сервис, упростили работу с подключёнными устройствами и снизили нагрузку на основной сервер. За обновлениями и доступом на самих рабочих местах по-прежнему нужно следить.
Рабочие места тоже на Linux: наш собственный образ Debian с KDE Plasma и LibreOffice. Большинство сотрудников раньше работали в Windows и Excel, и непривычный интерфейс поначалу пугал. Помогло то, что окружение мы настроили внешне похожим на привычное: сначала обучение, потом готовый образ — и дело пошло.
Что ломалось по дороге
Настройка 1С на Linux в 2019 году потребовала много работы: принтеры и МФУ со сканированием, системные библиотеки, активация лицензий, доступ к носителям ключей из терминальной сессии, производительность. Помогло то, что МФУ я заранее подбирал под этот стек. Лицензии 1С у нас были программные, поэтому подключение физических ключей к виртуальной машине в нашем проекте решать не пришлось.
И одна привычка, которую советую всем: при развороте любого сервиса я веду документацию. Даже спустя пять лет по записям видно, какая версия под что ставилась, где болело и чем лечили.
Покупное решение, которое так и не заработало. Ещё на КА 1.1 мы купили готовую разработку: поставщик заранее подтвердил совместимость с нашим стеком, но стабильно запустить её не удалось. После этого совместимость с Linux и PostgreSQL я стараюсь проверять на своём стенде до оплаты.
Самый неожиданный замер
В августе 2024 года мы перевели 1С на отдельный сервер: у CentOS 7 закончилась поддержка, да и нагрузка выросла. Сервер — два Xeon E5-2643 v2 2013 года с высокой частотой ядра. Позже память нарастили до 128 ГБ и поставили NVMe под базу. Логично было ждать, что на чистом железе он сразу обгонит виртуалку.
Тест Гилёва показал обратное. Из коробки — 9,86. А 1С в виртуальной машине на этом же сервере давала 15,67, после настройки модели процессора и добавления памяти — 20,16. На железе ещё ничего не было настроено, и работали снапшоты LVM.
После одного вечера настройки BIOS — профиля питания, C-states, турбо-режима и Hyper-Threading — тест показал 29,24. Почти втрое больше баллов. После настройки PostgreSQL зафиксировали 30,86, а в ноябре — 31,06. К последнему замеру менялись и настройки CPU, и версия платформы: с августовской 8.3.23 на 8.3.25. Поэтому весь последующий прирост нельзя приписать одной настройке. И сами баллы не означают, что все операции в базе стали выполняться втрое быстрее.
Именно этот замер заставил меня внимательнее относиться к настройкам сервера: сначала измерить, затем менять и снова проверять. По одним характеристикам железа такого результата я бы не предсказал.
В первой паре одновременно менялись CPU и память. К ноябрьскому замеру обновилась также платформа 1С: с 8.3.23 до 8.3.25. Это разные конфигурации, а не один контролируемый эксперимент. Все замеры — до установки NVMe.
Цифры
- Пара дней — перенос и сверка остатков; около недели — доработка обработки под CRM.
- 5 лет — столько прожила схема с сервером 1С в виртуалке на CentOS 7.
- 9,86 → 29,24 — почти трёхкратный рост баллов TPC после этапа настройки BIOS. Следующие результаты — 30,86 и 31,06 — получены после дальнейших изменений; к ноябрю обновилась и платформа 1С.
- 12,05 — старая схема: виртуалка, замер с терминального сервера через сеть. Режим другой, поэтому по сравнению с локальными 31,06 нельзя надёжно определить выигрыш от замены сервера.
- 200 ГБ — база; 10 пользователей (в часы пик — до 15) и 2 ТСД.
- Около часа — ночное восстановление базы на готовом тестовом стенде, начало около 01:00. Полное аварийное восстановление всех сервисов мы не измеряли.
- Около недели — столько релиз идёт через стенд до рабочей базы.
В каких границах это работает
- Масштаб. Небольшая компания без ИТ-отдела, десять пользователей. Железо подобрано под нашу нагрузку и наш бюджет: процессоры 2013 года — описание нашего выбора, не рекомендация для новой закупки. Частота была важна для наших задач; для другого сервера нужно учитывать и состав операций, и одновременную нагрузку.
- TPC — однопоточный синтетический тест. Он помогает сравнивать настройки, а скорость проведения документов и работу нескольких пользователей нужно оценивать отдельно. Приведённые результаты тестов получены до установки NVMe.
- Резервные копии. Каждый день восстанавливаем базу на стенде; реплика работает на другой площадке. Для возврата к состоянию до ошибки нужны подходящая базовая копия и сохранённая цепочка WAL. Аварийно восстанавливать рабочую систему нам пока не приходилось.
Что бы я сделал иначе
По большому счёту ничего. На тот момент виртуалка на CentOS 7 оправдывала себя и по скорости, и по деньгам.
При следующем выборе сервера я бы с самого начала проверял на нём нужные операции и настройки BIOS. Одинаковый тест до и после изменения полезнее, чем сравнение красивых цифр, снятых в разных условиях.
Что пока не решено
После установки NVMe я заметил ускорение серверных операций, но пользователи почувствовали небольшую разницу. Предполагал, что дальше ограничивает шина сервера. Точных замеров не сохранилось, поэтому это осталось моей гипотезой, а не установленным узким местом.