Установка сервера 1С — задача, которую системный администратор обычно получает в момент, когда файловая база уже начала подводить: блокировки, долгие отчёты, «формат потока не корректен» после аварийного отключения питания. Ниже — последовательность шагов: СУБД, платформа, порты и кластер, создание информационной базы, подключение клиентов и регламент обслуживания. Обе ветки — Windows + MS SQL и Linux + PostgreSQL — разобраны на одинаковом уровне детализации.
Что нужно до установки: архитектура, ресурсы, лицензии
Клиент-серверная схема и расчёт ресурсов
В файловом варианте клиент сам открывает файл 1Cv8.1CD по сети: блокировка на уровне таблиц, чувствительность к обрывам, ограничения на размер отдельной таблицы. Клиент-серверный режим разносит работу по трём уровням: клиент отвечает за интерфейс, кластер серверов 1С выполняет прикладную логику (ragent — агент, rmngr — менеджер кластера, rphost — рабочий процесс), СУБД хранит данные.
Переходить на серверный вариант пора, когда одновременно работают больше 5–7 пользователей, файл базы перевалил за 8–10 ГБ либо база регулярно требует тестирования и исправления. Ставить сервер 1С и СУБД на одну машину для 10–30 пользователей нормально и даже быстрее за счёт разделяемой памяти; разносить есть смысл от полусотни активных сеансов.
Сеанс тонкого клиента типовой учётной конфигурации занимает в rphost 150–250 МБ, сеанс ERP или УТ с тяжёлыми формами — 300–500 МБ, плюс 2–4 ГБ под фоновые задания. Пример для Бухгалтерии на 25 активных сеансов: 25 × 200 МБ ≈ 5 ГБ + 3 ГБ фоновые + 2 ГБ ОС = 10 ГБ, берём 12–16 ГБ. Для УТ на 60 активных сеансов: 60 × 350 МБ ≈ 21 ГБ + 4 + 2 = 27 ГБ, берём 32 ГБ. Память СУБД — не меньше 25–30% от размера файла базы: база на 60 ГБ комфортно живёт при 24–32 ГБ.
Процессор: однопоточная производительность важнее числа ядер, берите частоту от 3,0 ГГц, примерно одно физическое ядро на 8–10 активных сеансов учётной конфигурации и одно на 5–6 сеансов тяжёлой. Процессов rphost — по одному на 4–6 ГБ выделенной памяти. Диски — только NVMe или SSD корпоративного класса: для файлов данных нормальны задержки 1–3 мс, для журнала транзакций — до 1 мс. В виртуализации 1С крайне чувствительна к переподписке vCPU — просите гарантированные ресурсы; снапшот работающей СУБД резервной копией не считается, а программная лицензия при живой миграции ВМ может «слететь».
Если разворачивать 1С на своём железе не хочется, площадкой может стать аренда сервера 1С в облаке Cloud4U: платформа и лицензии предоставляются по подписке с помесячной оплатой, без покупки ПО и капитальных затрат. Cloud4U — официальный партнёр 1С, конфигурации идут в полных версиях («Бухгалтерия 8 ПРОФ», ЗУП, «Управление торговлей», «Комплексная автоматизация»), с изоляцией ресурсов под клиента и доступом по RDP, через тонкий клиент или браузер. Отдельно про 152-ФЗ: базы ЗУП содержат персональные данные, у Cloud4U это ЦОДы уровня Tier III в России с сертификацией ISO 27001 и PCI DSS.
Выбор связки и лицензии 1С
Windows Server + MS SQL Server — предсказуемый вариант с богатой диагностикой (SSMS, планы обслуживания, Query Store). Минус — лицензии: MS SQL Standard лицензируется по ядрам, для 8-ядерного сервера это сотни тысяч рублей плюс сам Windows Server.
Linux + PostgreSQL — Astra Linux, RedOS, Альт, а в качестве СУБД сборка PostgreSQL с патчами 1С, Postgres Pro Enterprise или Tantor SE 1C. Расходы кратно ниже, вся связка есть в реестре отечественного ПО; минус — выше требования к квалификации. Порядок цифр на три года при 40 пользователях: Windows Server Standard плюс MS SQL Standard на 8 ядер — несколько сотен тысяч рублей единовременно, тогда как Astra Linux Special Edition плюс сертифицированная сборка PostgreSQL укладывается в десятки тысяч в год.
Критично: ванильный PostgreSQL под 1С использовать нельзя. Платформа рассчитывает на патчи 1С и расширения online_analyze, plantuner, fix1c; на ванильной сборке отдельные отчёты будут выполняться в разы дольше.
Нужны лицензия на сервер 1С:Предприятия и клиентские по числу одновременных подключений. Серверная бывает в редакциях ПРОФ и КОРП: ПРОФ ограничивает одну информационную базу 500 одновременными сеансами и использованием 12 ядер на рабочий сервер, КОРП снимает эти ограничения и добавляет профили безопасности. Программная лицензия активируется по регистрационному номеру и пин-коду, привязывается к аппаратному профилю (HWID) — держите резервные пин-коды под рукой. Аппаратная — USB-ключ HASP, в виртуализации требует проброса USB. Программные лицензии активируются штатными средствами платформы, HASP License Manager раздаёт лицензии с аппаратных ключей на порту 1947.
Шаг 1. Установка и настройка СУБД
СУБД ставим первой: сервер 1С при создании базы должен уже иметь куда подключиться.
MS SQL Server: Cyrillic_General_CI_AS, лимит памяти, MaxDOP, tempdb
При установке MS SQL Server (поддерживаются 2016, 2017, 2019 и 2022, оптимально 2019/2022) на шаге «Server Configuration» → вкладка «Collation» задайте Cyrillic_General_CI_AS: значение по умолчанию даёт неверную сортировку кириллицы, поменять потом можно только пересозданием базы. Режим аутентификации — смешанный. В Configuration Manager включите протоколы Shared Memory и TCP/IP.
EXEC sp_configure 'max server memory (MB)', 24576;
RECONFIGURE;
EXEC sp_configure 'max degree of parallelism', 1;
RECONFIGURE;
EXEC sp_configure 'cost threshold for parallelism', 50;
RECONFIGURE;
Рекомендация «поставьте максимум памяти» опасна: SQL Server заберёт всю память, и система начнёт вытеснять в файл подкачки. На выделенном сервере с 32 ГБ ставьте 26–27 ГБ, на совмещённом с 1С — не больше 14–16 ГБ. MaxDOP = 1 осознан: платформа генерирует запросы, которые при параллельном исполнении чаще получают худший план и порождают ожидания CXPACKET.
ALTER DATABASE [base1c] SET RECOVERY SIMPLE;
ALTER DATABASE [base1c]
MODIFY FILE (NAME = N'base1c', FILEGROWTH = 512MB);
SIMPLE означает RPO в сутки; если нужен возврат на точку во времени — оставьте FULL и настройте резервное копирование журнала. Автоувеличение задавайте блоками, а не процентами. Файлы данных, журнал и tempdb разнесите по разным томам; для tempdb создайте несколько файлов равного размера по числу ядер, но не более восьми.
Результат шага: служба запущена, экземпляр слушает 1433, collation Cyrillic_General_CI_AS, лимит памяти задан.
PostgreSQL со сборкой под 1С: установка, initdb, pg_hba.conf
Дистрибутив скачивается с releases.1c.ru («Технологические дистрибутивы» → PostgreSQL). Сначала локаль системы (locale-gen ru_RU.UTF-8), затем установка пакетов и фиксация версии, чтобы обновление системы не подтянуло ванильный PostgreSQL:
sudo apt install ./libpq5_*.deb ./postgresql-client-15_*.deb ./postgresql-15_*.deb
sudo apt-mark hold postgresql-15 postgresql-client-15 libpq5
Инициализация кластера:
sudo -u postgres /usr/lib/postgresql/15/bin/initdb \
-D /var/lib/postgresql/15/main --locale=ru_RU.UTF-8 \
--encoding=UTF8 --data-checksums
В pg_hba.conf добавьте строку для подсети сервера 1С: host all postgres 192.168.10.0/24 md5. Платформа исторически работает с методом md5; если в postgresql.conf включён scram-sha-256, а пароль задан до смены параметра, подключение прервётся с ошибкой аутентификации — параметр в конфиге и метод в pg_hba.conf должны совпадать. В postgresql.conf укажите listen_addresses = '*' и port = 5432. В выводе SELECT version(); у сборки для 1С есть пометка вида 1C.<номер>.
Результат шага: служба активна, слушает 5432, локаль кластера ru_RU.UTF-8, psql подключается по паролю с адреса сервера 1С.
Ключевые параметры postgresql.conf и как считать их от объёма RAM
Набор для сервера СУБД с 32 ГБ памяти:
shared_buffers = 8GB # 25% RAM
effective_cache_size = 24GB # 70-75% RAM
work_mem = 64MB # на операцию сортировки
temp_buffers = 256MB
maintenance_work_mem = 2GB
max_connections = 200
random_page_cost = 1.1 # для SSD/NVMe; HDD - 4.0
effective_io_concurrency = 200 # для NVMe; HDD - 2
wal_buffers = 16MB
min_wal_size = 2GB
max_wal_size = 8GB
checkpoint_completion_target = 0.9
autovacuum_max_workers = 4
autovacuum_naptime = 20s
autovacuum_vacuum_scale_factor = 0.05
autovacuum_analyze_scale_factor = 0.02
autovacuum_vacuum_cost_limit = 1000
online_analyze.enable = on
online_analyze.table_type = 'temporary'
plantuner.fix_empty_table = on
max_locks_per_transaction = 256
Осторожно с work_mem: параметр применяется к каждой операции сортировки в каждом запросе, work_mem × max_connections × 2 не должно превышать 25% RAM. Расширения online_analyze и plantuner входят в сборки для 1С и подключаются через shared_preload_libraries: платформа создаёт временные таблицы и сразу строит по ним запросы, а планировщик без свежей статистики выбирает плохой план. max_locks_per_transaction повышаем, потому что реструктуризация затрагивает сотни таблиц в одной транзакции.
Результат шага: СУБД перезапущена, SHOW возвращает заданные значения, в журнале нет ошибок старта.
Шаг 2. Установка платформы 1С:Предприятие 8.3 и запуск службы сервера
Дистрибутив берётся с releases.1c.ru — доступ даёт подписка ИТС. Версии сервера и клиента должны совпадать хотя бы до третьего числа в номере релиза.
Установка на Windows Server: компоненты мастера и служба под USR1CV8
Запустите setup.exe от имени администратора и отметьте компоненты: 1С:Предприятие, Сервер 1С:Предприятия, Администрирование сервера 1С:Предприятия (консоль кластера), Модули расширения веб-сервера — только при публикации на IIS или Apache. Мастер предложит установить сервер как службу: имя пользователя по умолчанию USR1CV8, пароль задайте свой и запишите его.
Пользователю USR1CV8 требуются членство в группе «Пользователи», полные права на каталог C:\Program Files\1cv8\srvinfo и право «Вход в качестве службы». Если консоль администрирования не появилась в списке оснасток, зарегистрируйте её командой RegMSC.bat из bin нужной версии. Проверка службы — sc queryex type=service state=all | findstr /i "1C", состояние RUNNING. Если служба останавливается сразу после старта, первая версия — права на srvinfo, вторая — занятый порт 1540.
Результат шага: служба агента запущена, процессы ragent.exe и rmngr.exe видны в диспетчере задач.
Установка на Linux: пакеты srv1cv8, локаль, права на srvinfo, systemd
Перед установкой доставьте зависимости — без них платформа установится, но сервер не стартует:
sudo apt install imagemagick libgsf-1-114 libglib2.0-0 \
libfreetype6 fontconfig ttf-mscorefonts-installer
sudo fc-cache -fv
Шрифты нужны для печатных форм на стороне сервера; их отсутствие проявляется не при старте, а сбоем при печати. Далее ставятся пакеты 1c-enterprise-8.3.x-common, -server и их варианты -nls. Пакет создаёт пользователя usr1cv8 и группу grp1cv8; проверьте владельца каталогов данных кластера:
sudo chown -R usr1cv8:grp1cv8 /home/usr1cv8/.1cv8 /var/1C
sudo systemctl enable --now srv1cv8
При отказе службы смотрите journalctl -u srv1cv8 -n 50 --no-pager. Частая причина отказа старта — отсутствующая локаль: добавьте её через systemctl edit srv1cv8 строками [Service] / Environment=LANG=ru_RU.UTF-8. Управлять кластером на Linux можно оснасткой с Windows-машины либо связкой RAS/RAC.
Результат шага: служба srv1cv8 активна, rac cluster list возвращает кластер с портом 1541.
Активация лицензии сервера и раздача клиентских лицензий
Программную лицензию активируют при первом запуске конфигуратора на серверной машине («Получить лицензию» → регистрационный номер, пин-код, данные организации). Файлы лицензий лежат в C:\ProgramData\1C\licenses на Windows и /var/1C/licenses на Linux; права на каталог должны быть у пользователя службы — иначе сервер лицензию не увидит, хотя файл на месте. Если многопользовательская лицензия активирована на сервере, кластер раздаёт её клиентам автоматически. При аппаратных ключах ставится HASP License Manager, на клиентах открывается порт 1947.
Результат шага: в узле «Лицензии» кластера видна серверная лицензия, при подключении клиента счётчик выданных растёт.
Шаг 3. Открытие портов и настройка кластера серверов
Порты 1540, 1541, 1545, 1560–1591, 1433, 1434, 5432, 1947
- 1540 — агент сервера (
ragent), через него оснастка находит сервер. - 1541 — менеджер кластера (
rmngr), основной порт, его указывают клиенты. - 1560–1591 — диапазон рабочих процессов, открывать нужно весь: порт назначается динамически.
- 1545 — сервер администрирования RAS; в базовый набор не входит, открывайте отдельным правилом и только с адресов, откуда действительно администрируют сервер.
- 1433 / 1434 — MS SQL Server (TCP) и обозреватель (UDP); 5432 — PostgreSQL; 1947 — HASP License Manager.
sudo ufw allow from 192.168.10.0/24 to any port 1540,1541,1545 proto tcp
sudo ufw allow from 192.168.10.0/24 to any port 1560:1591 proto tcp
sudo ufw allow from 192.168.10.0/24 to any port 5432 proto tcp
Ограничение по подсети принципиально. Сервер 1С не должен быть доступен из интернета: доступ к порту 1540 без пароля администратора кластера даёт полный контроль над кластером. Удалённый доступ закрывайте через VPN или публикуйте базу через веб-сервер с TLS.
Примечание. Указание на использование VPN носит исключительно технический характер и направлено на защиту корпоративных данных при настройке сервера 1С. Материал статьи не преследует целей обхода государственных блокировок или региональных ограничений и полностью соответствует действующему законодательству РФ.
Результат шага: с клиентской машины Test-NetConnection <сервер> -Port 1541 возвращает TcpTestSucceeded : True.
Параметры кластера и пароль администратора кластера
В оснастке добавьте центральный сервер по имени или IP и порту 1540, откройте свойства кластера. Что менять относительно умолчаний:
- Интервал перезапуска рабочих процессов — 86400 секунд; борется с фрагментацией и утечками памяти в
rphost, но не должен попадать на ночные обмены. - Допустимый объём памяти — суммарный лимит делите на число процессов: для 32 ГБ и трёх процессов около 8 ГБ (в килобайтах — 8388608).
- Интервал превышения — 300 секунд, чтобы процесс не перезапускался от кратковременного всплеска.
По умолчанию администрирование кластера не защищено паролем: любой с сетевым доступом к 1540 может отключить сеансы или удалить информационную базу. Заведите администратора кластера сразу (узел «Администраторы» → «Создать», аутентификация «1С:Предприятие») и отдельно администратора центрального сервера — это разные сущности.
Результат шага: свойства сохранены, при повторном подключении оснастка запрашивает логин и пароль администратора кластера.
Шаг 4. Создание информационной базы и перенос существующей файловой
Создание ИБ из клиента и из консоли кластера
Способ первый — из окна запуска. «Добавить» → «Создание новой информационной базы» → «На сервере 1С:Предприятия». Заполните:
- Кластер серверов — имя или IP (нестандартный порт пишется как
server:1741); - Имя ИБ в кластере — латиницей, без пробелов, например
buh_prod; - Тип СУБД, сервер баз данных (для MS SQL с именованным экземпляром —
sqlsrv\INSTANCE), имя базы латиницей, пользователь и пароль; - Смещение дат — для MS SQL ставьте 2000: тип
datetimeв MS SQL не поддерживает даты ранее 1753 года, а смещение прибавляет 2000 лет при записи и вычитает при чтении, что позволяет хранить любые даты 1С:Предприятия.
Пользователь СУБД должен иметь право на создание баз: в MS SQL — dbcreator и processadmin, в PostgreSQL — атрибут CREATEDB.
Способ второй — из консоли администрирования, узел «Информационные базы» → «Создать». На Linux то же через rac:
rac infobase create --cluster=<uuid_кластера> --name=buh_prod \
--dbms=PostgreSQL --db-server=localhost --db-name=buh_prod \
--db-user=postgres --db-pwd=<пароль> --create-database \
--license-distribution=allow
UUID берётся из rac cluster list. Без --license-distribution=allow клиенты будут искать лицензию локально.
Результат шага: база появилась в списке ИБ кластера, в СУБД созданы служебные таблицы _yearoffset, config, params.
Миграция файловой базы: chdbfl, .dt, проверка после загрузки
Перенос — операция с простоем, планируйте окно и план отката.
- Завершить все пользовательские сеансы — иначе выгрузка захватит несогласованное состояние.
- Скопировать
1Cv8.1CDв надёжное место: это и есть план отката. - Проверить физическую структуру утилитой
chdbfl.exeиз каталогаbinс флагом «Исправлять обнаруженные ошибки». - Тестирование и исправление в конфигураторе: реиндексация, проверка логической и ссылочной целостности, пересчёт итогов. Для битых ссылок «Создавать объекты» безопаснее «Удалять объекты».
- Выгрузка в
.dt:1cv8.exe CONFIG /F "D:\base_file" /N Администратор /P пароль /DumpIB "D:\backup\base.dt". Для базы в десятки гигабайт выгрузка идёт часами. - Загрузка в пустую серверную ИБ:
1cv8.exe CONFIG /S "sql-server\buh_prod" /N Администратор /P пароль /RestoreIB "D:\backup\base.dt". - Проверка после загрузки: сверьте остатки по ключевым отчётам; проверьте пользователей и регламентные задания; исправьте пути вида
\\pc-buh\base, серверу они недоступны.
Результат шага: пользователи подключаются к серверной базе, отчёты сходятся с контрольными значениями, файловая копия лежит нетронутой.
Шаг 5. Подключение клиентов и обслуживание базы
Добавление базы в список: адрес кластера, аутентификация, общий список
На клиенте установите платформу той же версии, что на сервере. «Добавить» → «Добавление в список существующей информационной базы» → «На сервере 1С:Предприятия», кластер (имя или IP), имя ИБ ровно как при создании (регистр важен). Аутентификация ОС удобна в домене, но требует привязки пользователя 1С к учётной записи домена; аутентификация 1С:Предприятия работает везде и проще в аудите.
Список баз раздайте через групповые политики 1CEStart.cfg в %APPDATA%\1C\1CEStart\ строкой CommonInfoBases=\\fileserver\1c\ibases.v8i, а в ibases.v8i опишите базы:
[Бухгалтерия предприятия]
Connect=Srvr="1c-srv";Ref="buh_prod";
App=ThinClient
Version=8.3
Если подключение не проходит, проверьте по порядку: доступность порта 1541, совпадение версий клиента и сервера, точность написания имени базы.
Результат шага: база открывается в режиме «1С:Предприятие», в списке сеансов виден сеанс пользователя.
Регламент MS SQL: статистика, реиндексация, DBCC FREEPROCCACHE
База без обслуживания деградирует за недели: статистика устаревает, планы выбираются неверные, индексы фрагментируются. Ежедневно ночью, вне окна регламентных заданий 1С: EXEC sp_updatestats; и DBCC FREEPROCCACHE; — после обновления статистики старые планы всё равно неактуальны.
Раз в неделю — работа с индексами:
SELECT OBJECT_NAME(ips.object_id) AS table_name, i.name AS index_name,
ips.avg_fragmentation_in_percent, ips.page_count
FROM sys.dm_db_index_physical_stats
(DB_ID(), NULL, NULL, NULL, 'LIMITED') AS ips
JOIN sys.indexes AS i
ON i.object_id = ips.object_id AND i.index_id = ips.index_id
WHERE ips.avg_fragmentation_in_percent > 10 AND ips.page_count > 1000
ORDER BY ips.avg_fragmentation_in_percent DESC;
Правило: фрагментация 10–30% — REORGANIZE, свыше 30% — REBUILD. Индексы менее тысячи страниц не трогайте. Резервное копирование — полная копия ежедневно, при модели FULL журнал транзакций каждые 15–30 минут, копии храните не на том же массиве, где база.
Результат шага: в SQL Server Agent задания с успешными последними запусками, файлы копий появляются по расписанию.
Регламент PostgreSQL: VACUUM/ANALYZE, autovacuum, pg_probackup
PostgreSQL из-за многоверсионности накапливает мёртвые версии строк. Где они накопились:
SELECT relname, n_live_tup, n_dead_tup,
round(n_dead_tup * 100.0 / NULLIF(n_live_tup, 0), 1) AS dead_pct,
last_autovacuum
FROM pg_stat_user_tables
WHERE n_dead_tup > 10000
ORDER BY n_dead_tup DESC LIMIT 20;
Если доля мёртвых строк устойчиво выше 20%, а last_autovacuum давний — настройте параметры точечно через ALTER TABLE ... SET (autovacuum_vacuum_scale_factor = 0.02, autovacuum_vacuum_cost_limit = 2000);. Ночное обслуживание — vacuumdb --analyze --jobs=4 --dbname=buh_prod. VACUUM FULL требует эксклюзивной блокировки — только в окно простоя, для регулярного сжатия используйте pg_repack. Реиндексация без блокировки: reindexdb --concurrently.
Резервное копирование: pg_dump для базы на десятки гигабайт слишком медленный при восстановлении, берите pg_probackup:
sudo -u postgres pg_probackup backup -B /backup/pgbackup \
--instance buh -b FULL --compress --stream
--stream включает передачу WAL вместе с копией, делая её самодостаточной. Дополнительно делайте периодическую выгрузку .dt — она не зависит от версии PostgreSQL.
Проверка работоспособности и решение типичных проблем
Финальный чек-лист: службы, порты, соединение с СУБД, резервная копия
Службы. На Windows состояние агента — RUNNING, в диспетчере есть ragent.exe, rmngr.exe и минимум один rphost.exe. На Linux — systemctl is-active srv1cv8 postgresql. Появление rphost важно: агент и менеджер стартуют всегда, а рабочий процесс поднимается, только когда кластер готов принимать соединения.
Порты. С клиентской машины проверьте доступность именно 1541 — агент на 1540 может отвечать, а менеджер быть заблокированным.
Соединение с СУБД. Для MS SQL на совмещённом сервере проверьте net_transport в sys.dm_exec_connections для сеансов с program_name LIKE '%1CV8%': должно быть Shared memory. Если там TCP, в свойствах ИБ указан IP или FQDN вместо localhost.
Резервная копия. Копия, которую ни разу не восстанавливали, не является резервной копией. Проведите учебное восстановление и засеките время — это ваш фактический RTO.
Производительность. Замерьте базовый показатель тестом Гилёва до передачи в эксплуатацию: на нормально настроенном сервере ожидаемо 25–40 попугаев, результат ниже 15 говорит о проблемах с дисками, переподпиской vCPU или настройками СУБД.
Частые ошибки: несовпадение версий, «Не обнаружена лицензия», конфликт блокировок
«Ошибка СУБД: Login failed for user...» — неверные учётные данные или недостаточные права. У пользователя должна быть роль db_owner на базе, при создании ИБ — ещё dbcreator и processadmin.
«could not connect to server: Connection refused» (PostgreSQL) — служба не слушает нужный адрес либо запрос не проходит pg_hba.conf. Проверка: ss -tlnp | grep 5432 и лог /var/log/postgresql/.
«Несоответствие версии клиента и сервера» — при нескольких установленных платформах укажите нужную параметром Version=8.3.25.1394 в ibases.v8i.
«Не обнаружена лицензия» — после переноса ВМ или изменения её конфигурации программная лицензия слетает по несовпадению аппаратного профиля, нужна повторная активация по резервному пин-коду. Если лицензия на месте, но сервер её не видит — проверьте права пользователя службы на каталог лицензий.
«Конфликт блокировок при выполнении транзакции» — два сеанса меняют одни данные либо длинная транзакция держит блокировку. Быстрое решение — завершить зависший сеанс; структурное — перевести базу на управляемые блокировки и разнести по времени регламентные задания и активную работу пользователей.
Агент сервера не стартует — проверьте занятость порта 1540, права на srvinfo и целостность каталога: при повреждении srvribrg.lst агент не запускается при старте.
Стало медленнее после переезда на PostgreSQL — почти всегда ванильная сборка вместо сборки с патчами 1С либо отсутствующие online_analyze и plantuner. Второй по частоте фактор — оставшиеся от установки shared_buffers = 128MB и work_mem = 4MB.
Журнал транзакций MS SQL занял весь диск — модель FULL без резервного копирования журнала. Решение: настроить резервное копирование журнала либо перевести базу в SIMPLE, затем ужать через DBCC SHRINKFILE. Удалять файл журнала нельзя — база не откроется.
Когда ни один сценарий не подходит, включайте технологический журнал — файл logcfg.xml в каталоге conf платформы с событиями EXCP и CONN. Журнал подхватывается без перезапуска службы, но на нагруженной базе пишет гигабайты в сутки — включайте под конкретную задачу и убирайте файл после разбора.
