Ситуация, когда небольшая аутсорсинговая компания обслуживает сотни мелких клиентов, предъявляет специфические требования к инфраструктуре. В отличие от классических «крупных внедрений», где тысячи пользователей работают в одной базе, здесь мы сталкиваемся с проблемой «раздувания» ресурсов из-за количества самих баз. Разберем детально, как оптимизировать такую систему, основываясь на опыте коллег и технических регламентах.
Рассмотрим исходные данные: сервер на базе Intel Xeon E3-1220v6 с 16 Гб ОЗУ, использующий 32-битную версию сервера 1С и MS SQL Server 2014. Основная проблема — критическая нехватка памяти при росте количества ИБ свыше 50. Проанализируем методику расчета памяти, предложенную автором темы, и внесем коррективы.
Автор предлагает формулу: 6 ИБ на 1 процесс rphost. При 32-битной архитектуре один процесс ограничен 2-3 Гб адресного пространства. Для 100 баз это действительно дает около 17 процессов. Однако, математика «17 процессов по 2 Гб = 34 Гб» является лишь верхушкой айсберга. Посмотрим, что еще потребляет ресурсы:
Рекомендация: Для комфортной работы 100 баз общим объемом 1-3 Гб каждая, минимальный объем оперативной памяти должен составлять 64 Гб. Это позволит выделить около 32 Гб под нужды 1С и оставить достаточно места для кэша SQL Server.
Важным шагом является отказ от 32-битного сервера 1С. Разберем, почему это необходимо:
Во-первых, 32-битные процессы rphost часто завершаются с ошибкой Memory threshold exceeded, когда объем данных в памяти приближается к пределу. Во-вторых, управление 17-ю процессами создает избыточную нагрузку на планировщик задач ОС.
Перейдем к настройке рабочих серверов. Проанализируем параметры в консоли администрирования 1С:
rphost.Работа со 100+ базами в SQL Server требует тонкой настройки, отличной от работы с одной большой БД. Рассмотрим ключевые параметры:
Параметр Max Server Memory: Никогда не оставляйте этот параметр в значении по умолчанию (неограниченно). SQL Server заберет всю доступную память, что приведет к свопингу (сбросу памяти на диск) процессов 1С. Выясним правильный лимит: Общая память - (Память для ОС) - (Память для rphost).
Опция Optimize for Ad Hoc Workloads: Включим эту настройку. В 1С (особенно в Бухгалтерии 3.0) генерируется огромное количество разовых запросов. Эта опция позволяет SQL Server экономить память, не сохраняя полные планы запросов, которые вряд ли повторятся.
Файлы TempDB: Проанализируем нагрузку на временную базу. При 100 активных ИБ нагрузка на TempDB возрастает кратно. Рекомендуется создать количество файлов данных TempDB, равное числу ядер процессора, и разместить их на максимально быстром накопителе (NVMe).
Отключение AUTO_CLOSE: Проверьте, чтобы у всех баз данных свойство AUTO_CLOSE было установлено в FALSE. Если оно включено, SQL Server будет закрывать базу после выхода последнего пользователя, что вызовет огромные задержки при следующем обращении (даже при выполнении фоновых заданий).
Это самый неочевидный, но эффективный способ снижения нагрузки. В каждой из 100 баз по умолчанию включены десятки регламентных заданий: обновление агрегатов, извлечение текста, полнотекстовый поиск, загрузка классификаторов.
Даже если в базе никто не работает, rphost будет «просыпаться», чтобы выполнить эти задачи. Умножим это на 100 баз — и получим постоянную нагрузку на CPU и диск.
Что нужно сделать:
Использование виртуализации удобно для администрирования, но требует осторожности. Рассмотрим критические моменты:
Memory Reservation: Для виртуальной машины с сервером 1С и SQL необходимо обязательно установить резервирование всей выделенной памяти (Reserve all guest memory). В противном случае механизм Memory Ballooning гипервизора может начать отбирать память у SQL Server, что приведет к фатальному падению производительности.
Дисковая подсистема: RAID 10 на контроллере Adaptec — хорошее решение. Однако при росте количества баз до 100+ стоит рассмотреть переход на SSD/NVMe массивы, так как суммарная нагрузка на чтение/запись метаданных и журналов транзакций может стать «узким горлышком» для обычных HDD.
Если бизнес продолжит расти, стоит рассмотреть переход на технологию, используемую в 1C:Fresh. Вместо создания 100 отдельных баз данных, можно использовать механизм разделения данных. В этом случае все клиенты работают в одной физической базе данных, но видят только свои данные.
Преимущества такого подхода:
Подводя итог, отметим: текущая проблема решается увеличением памяти до 64 Гб и переходом на x64-битную платформу. Однако для долгосрочной стабильности необходимо внедрить скриптовую автоматизацию администрирования и жестко контролировать регламентные задания в каждой информационной базе.