Рассмотрим типичную, но сложную ситуацию: производительность сервера 1С резко упала после увеличения количества баз и пользователей. Пользователи жалуются на "тормоза" при проведении документов и формировании отчетов, а системные метрики показывают запредельную загрузку процессора и памяти. Проанализируем, почему это происходит и какие шаги предпринять для исправления ситуации, на примере реального кейса, когда на одном сервере с процессором Ryzen 7700 и 125 ГБ ОЗУ работают сервер 1С и MS SQL, обслуживая 130+ активных сеансов и более 60 баз.
Прежде чем что-то менять, важно понять, почему система стала работать медленно. В описанной ситуации мы видим комплекс проблем, которые усиливают друг друга.
1. Конкуренция за ресурсы между сервером 1С и СУБД
Это ключевая проблема. Когда сервер приложений 1С (процессы rphost.exe) и сервер баз данных MS SQL (процесс sqlservr.exe) находятся на одной физической машине, они вступают в прямую "борьбу" за ресурсы:
2. Использование десктопного оборудования для серверных задач
Процессоры вроде AMD Ryzen 7700 великолепны для игр и рабочих станций благодаря высокой тактовой частоте на одно ядро, что в целом хорошо для 1С. Однако серверная нагрузка — это не только скорость, но и стабильность при большом количестве параллельных операций. Здесь десктопное "железо" уступает серверному:
3. Неоптимальные настройки программного обеспечения
Даже на мощном оборудовании можно столкнуться с проблемами, если не выполнить базовую настройку. Для связки 1С + MS SQL критически важны несколько параметров, которые по умолчанию могут быть неоптимальны для такой нагрузки.
Рассмотрим конкретные шаги, которые можно предпринять для решения проблемы. Начинать следует с наименее затратных.
Это самый эффективный способ устранить "борьбу за ресурсы". Есть два основных подхода:
Ключевое преимущество: Вы можете жестко выделить ресурсы. Например, из 8 ядер процессора Ryzen отдать 4 ядра и 64 ГБ ОЗУ виртуальной машине с 1С, а оставшиеся 4 ядра и 60 ГБ ОЗУ — машине с SQL. Это создает изолированные среды и гарантирует, что пиковая нагрузка в одной системе не "положит" другую.
Эти настройки необходимо проверить и применить, особенно если 1С и SQL остаются на одной машине.
Зайдите в свойства экземпляра MS SQL Server в Management Studio (SSMS) -> раздел Memory. Установите значение `Maximum server memory (MB)` так, чтобы для ОС и процессов 1С оставалось достаточно памяти. Например, при 128 ГБ ОЗУ можно выделить SQL 70-80 ГБ, оставив ~50 ГБ для всего остального. В вашем случае ограничение в 46 ГБ уже установлено, что является правильным шагом.
Это критически важная настройка для 1С! По умолчанию SQL Server может использовать все доступные ядра для выполнения одного "тяжелого" запроса (например, отчета). Это приводит к тому, что один пользователь может "подвесить" систему для всех остальных. Для OLTP-нагрузок, характерных для 1С, рекомендуется установить `MaxDOP` равным `1`. Это заставит SQL Server выполнять каждый запрос в одном потоке, обеспечивая справедливое распределение процессорного времени между всеми пользователями.
Найти эту настройку можно в свойствах экземпляра SQL Server -> раздел Advanced.
База `tempdb` активно используется 1С для временных таблиц при формировании отчетов и выполнении сложных запросов. Чтобы снизить "бутылочное горлышко", разместите файлы `tempdb` на самом быстром диске (NVMe) и создайте несколько файлов данных — по одному на каждое ядро процессора (но не более 8). Это распараллелит операции записи и снизит блокировки внутри `tempdb`.
Если сервер 1С и SQL все же находятся на одной машине, убедитесь, что они общаются через протокол `Shared Memory` (общая память), а не через `TCP/IP`. Это исключает из взаимодействия сетевой стек и снижает задержки. Проверить и включить протокол можно в `SQL Server Configuration Manager`. В настройках кластера 1С для подключения к базе указывайте имя сервера как `localhost` или NetBIOS-имя машины.
Обязательно установите схему электропитания "Высокая производительность" (High Performance). Это запретит операционной системе снижать частоту процессора или "парковать" ядра для экономии энергии. На десктопных процессорах, таких как Ryzen, это может дать колоссальный прирост производительности в тесте Гилева и в реальной работе.
Проанализируйте настройки рабочих процессов (rphost) в консоли администрирования серверов 1С. Не создавайте слишком много рабочих процессов, так как каждый из них потребляет дополнительную память. Эмпирическое правило: один рабочий процесс на 25-50 пользователей. Можно также настроить несколько процессов и распределить по ним проблемные или ресурсоемкие базы.
Все перечисленные выше меры помогут стабилизировать систему, но для стабильной работы под такой высокой нагрузкой в долгосрочной перспективе стоит задуматься о переходе на специализированное серверное оборудование.
Что дает "настоящий" сервер:
В качестве альтернативной СУБД можно рассмотреть PostgreSQL. Как отмечают участники обсуждения, в некоторых сценариях он может быть менее требователен к оперативной памяти, так как иначе с ней работает, больше полагаясь на файловый кэш ОС. Однако его внедрение и настройка требуют отдельной экспертизы.