Диагностика текущей ситуации
Замеряем, где теряется время: дисковая подсистема, сеть, блокировки, конкретные операции. Смотрим размер базы, число сеансов и журнал регистрации.
Без этого замена сервера может не дать эффекта вообще.
Разбираемся, почему 1С работает медленно, и решаем это архитектурой, а не покупкой самого дорогого процессора. Если своя серверная не нужна, разбираем вариант с 1С:Fresh и облачным размещением баз. Подбираем конфигурацию под реальную нагрузку, переводим базу в клиент-серверный режим и переносим данные без остановки работы бухгалтерии.
Одна и та же жалоба означает совершенно разные вещи: медленно открывается список документов, долго проводится реализация, зависает закрытие месяца или подтормаживает интерфейс у удалённых сотрудников. Причины у них разные — от файловой базы в сетевой папке до неоптимального запроса в доработанной конфигурации.
Поэтому мы начинаем с замеров: смотрим, где именно теряется время, и только потом предлагаем решение. Иногда это новый сервер, иногда перевод базы в клиент-серверный режим, а иногда — перенос сотрудников на терминальный сервер без замены железа вообще.
Это главная развилка, которая определяет и производительность, и стоимость владения. Разница не в мощности сервера, а в том, кто выполняет работу с данными.
| Файловая база | Клиент-серверная | |
|---|---|---|
| Как работает | База лежит файлом в общей папке, обработку данных выполняет компьютер каждого пользователя | Данные обрабатывает сервер СУБД, клиенту передаётся только результат |
| Нагрузка на сеть | Высокая: по сети гоняются служебные данные, а не только результат | Низкая: по сети идёт готовый ответ на запрос |
| Комфортное число пользователей | Единицы. При большем числе начинаются блокировки и ожидания | Десятки и больше, ограничение задаёт мощность сервера |
| Устойчивость | Обрыв связи или выключение компьютера в момент записи может повредить базу | Транзакции защищают целостность данных при сбоях |
| Резервное копирование | Копирование файла работающей базы часто даёт непригодный архив | Штатная выгрузка средствами СУБД без остановки работы |
| Стоимость | Дешевле на старте: не нужны лицензия сервера 1С и СУБД | Дороже: лицензия сервера 1С, при MS SQL — ещё и лицензии СУБД. PostgreSQL лицензий не требует |
Промежуточный вариант, который часто выручает: файловая база остаётся, но все пользователи работают с ней в сеансах терминального сервера. Тогда обмен данными идёт внутри одной машины, а не по сети — и база перестаёт тормозить без перехода на клиент-серверный режим.
Прикиньте порядок ресурсов под вашу базу. Точную конфигурацию считаем после замеров: смотрим размер базы, число одновременных сеансов и характер операций.
Именно одновременных сеансов. Регламентные задания и обмены тоже создают нагрузку.
Учитываем закрытие месяца и массовое проведение — они дают пиковую нагрузку.
Ориентир по ресурсам. Реальные требования зависят от размера базы и доработок конфигурации — уточняем после замеров.
Замеряем, где теряется время: дисковая подсистема, сеть, блокировки, конкретные операции. Смотрим размер базы, число сеансов и журнал регистрации.
Без этого замена сервера может не дать эффекта вообще.
Считаем ресурсы под нагрузку: ядра с высокой частотой, объём памяти под кэш СУБД, обязательно NVMe или SSD под базу и журнал транзакций.
Экономия на дисках убивает производительность 1С сильнее всего.
Разворачиваем сервер 1С:Предприятие и СУБД, настраиваем кластер серверов 1С, параметры PostgreSQL под нагрузку, регламентные задания и обслуживание базы.
PostgreSQL из коробки настроен консервативно — параметры подбираем под сервер.
Переводим файловую базу в клиент-серверную или переносим с существующего сервера. Проверяем на копии, переключаем в нерабочее время, старую базу оставляем доступной.
План отката готовим до начала работ, а не по ходу.
Подключаем сотрудников: в офисе, через терминальный сервер или по VPN. Настраиваем печать, обмен файлами, работу с ЭЦП и криптопровайдерами.
Публикация сервера 1С напрямую в интернет — не наш метод.
Настраиваем резервное копирование базы средствами СУБД, проверку восстановления и мониторинг свободного места, нагрузки и длительности регламентных заданий.
Копия файла работающей базы часто оказывается непригодной.
Сервер 1С собирается под число одновременных пользователей и тип базы. Ниже три размера — с той же логикой: сначала считаем сеансы, потом выбираем схему.
Пока пользователей немного и база небольшая, файловый вариант работает нормально: база лежит в сетевой папке, доступ идёт по локальной сети. Клиент-серверный режим здесь избыточен — он потребует лицензий и обслуживания.
Рабочие места
│ локальная сеть
Сервер
├─ Файловая база 1С
├─ Общие папки
└─ Обмен с кассами
│
Копии базы по расписанию
После десятка одновременных пользователей файловая база начинает блокировать работу. Она переводится в клиент-серверный режим: сервер 1С и СУБД разносятся по ролям, база перестаёт зависеть от скорости сети.
Пользователи (офис и удалённо)
│
Сервер 1С:Предприятие
│
PostgreSQL
├─ Диски под базу
└─ Диски под журналы
│
Копии + проверка восстановления
На большой базе и сотне пользователей нагрузку создаёт не только СУБД, но и сами клиенты. Сервер 1С, СУБД и терминальные сеансы разносятся, чтобы тяжёлый отчёт одного пользователя не тормозил работу остальных.
Терминальные сеансы
│
Сервер 1С:Предприятие
│
Сервер PostgreSQL
├─ Быстрые диски под базу
└─ Реплика для отчётов
│
Копии на отдельном сервере
Универсального числа нет — многое зависит от размера базы и характера работы. Ориентир простой: если пользователи регулярно ждут друг друга из-за блокировок, проведение документов заметно замедлилось, а база выросла до нескольких гигабайт, файловый режим уже мешает. Иногда достаточно перевести всех на терминальный сервер, и вопрос снимается без перехода на СУБД.
Для большинства проектов мы предлагаем PostgreSQL: он не требует лицензий, официально поддерживается 1С и на типичных нагрузках среднего бизнеса работает сопоставимо. MS SQL имеет смысл, если лицензии уже куплены, есть администратор с этим опытом или используются решения, требующие именно его.
Полностью без остановки — нет: момент переключения требует, чтобы в базе никто не работал. Но простой можно свести к окну в нерабочее время. Мы заранее переносим и тестируем копию, готовим план отката, а в назначенное время выполняем финальную выгрузку и переключение. Старая база остаётся доступной, пока вы не подтвердите, что всё работает.
Да. Разворачиваем сервер 1С на инфраструктуре Dinesco, вы платите за услугу и не занимаетесь оборудованием. Подходит компаниям без своей серверной, а также как быстрый способ проверить, решит ли проблему переход на клиент-серверный режим, до вложений в железо.
Мы отвечаем за инфраструктуру: сервер, СУБД, доступы, копии, скорость работы и обновление платформы. Доработку конфигураций и методическое сопровождение обычно ведёт ваш франчайзи или штатный специалист. Мы спокойно работаем с ними в паре — и, как правило, именно на стыке инфраструктуры и конфигурации находятся причины тормозов.
Расскажите, сколько пользователей, какой размер базы и что именно тормозит. Сделаем замеры и предложим решение.
За годы работы с 1С сложился устойчивый набор причин, по которым система работает медленно. Почти все они не связаны с ценой процессора — и почти все решаются без покупки самого дорогого сервера.
Самая частая причина. Когда база лежит в общей папке, а сотрудники открывают её со своих компьютеров, обработку данных выполняет не сервер, а каждый клиент по отдельности. По сети при этом передаются не результаты, а служебные данные — десятки и сотни мегабайт на операцию. Отсюда и ощущение, что «сеть медленная», хотя дело в архитектуре. Два выхода: перевести базу в клиент-серверный режим или перевести пользователей в сеансы терминального сервера, где обмен идёт внутри одной машины.
1С активно работает с диском: чтение регистров, запись журнала транзакций, временные таблицы. На обычных SATA-дисках при десятке активных пользователей очередь к диску становится узким местом, и сервер «тормозит» при незагруженном процессоре. Под базу и журнал транзакций мы ставим NVMe или корпоративные SSD — это даёт заметно больший прирост, чем переход на процессор следующего поколения.
Многие операции в 1С выполняются в один поток: проведение документа, пересчёт итогов, часть регламентных заданий. Сервер с 32 медленными ядрами будет проводить документ дольше, чем сервер с 8 быстрыми. Поэтому при подборе процессора мы смотрим на частоту и производительность одного ядра, а количество ядер считаем под число одновременных сеансов.
PostgreSQL по умолчанию рассчитан на скромное оборудование: объёмы памяти под кэш и рабочие области заданы с большим запасом прочности. На сервере с большим объёмом памяти эти значения нужно поднимать, иначе половина ресурсов простаивает. Для 1С также важна сборка PostgreSQL с необходимыми доработками — обычная версия из репозитория подходит не всегда.
База, которую годами не обслуживали, деградирует: разрастаются таблицы, устаревает статистика, фрагментируются индексы. Мы настраиваем регламентные задания — обновление статистики, переиндексацию, контроль размера журнала транзакций — и выносим их на ночное время. Часто это даёт ускорение без единого рубля в железо.
Сервер может стоять в офисе, в арендованном ЦОД или работать на инфраструктуре Dinesco как виртуальный сервер. Для распределённых команд второй и третий варианты обычно удобнее: сотрудники подключаются одинаково откуда угодно, а обслуживанием занимаемся мы. Сравнение площадок — в разделе серверов и виртуализации. Практически всегда сервер 1С разворачивается как отдельная виртуальная машина в Proxmox, чтобы его можно было откатить на снапшот перед обновлением конфигурации.
