Оперативная память под 1С: считаем для файловой базы, сервера и SQL

Самое частое заблуждение: «поставим 64 ГБ, и 1С полетит». Не полетит, если память лежит не там, где её не хватает. Для файловой базы почти вся нагрузка ложится на клиентский компьютер и сетевой диск, для клиент-серверной — на процессы сервера 1С и на СУБД, и считают их отдельно.

Ориентир для старта: рабочее место с 1С — от 8 ГБ ОЗУ, сервер 1С — около 1–2 ГБ на пользователя вместе с запасом, СУБД — столько, чтобы активная часть базы помещалась в кэш. Дальше всё зависит от числа сеансов, размера базы и того, что работает в фоне.

Куда 1С тратит память: клиент, сервер, СУБД

У платформы три «потребителя» оперативной памяти, и они друг другу почти не помогают.

• 🖥 Клиентское приложение (тонкий, толстый клиент, веб-клиент в браузере). Держит формы, списки, открытые отчёты и кэш данных.
• ⚙️ Серверная часть — процессы кластера. Агент ragent и менеджер rmngr занимают мало. Основной расход у рабочих процессов rphost: в них выполняется весь серверный код конфигурации.
• 🗄 СУБД (PostgreSQL, Microsoft SQL Server). Использует память под кэш страниц, сортировки и временные таблицы.

В файловом варианте серверных процессов и СУБД нет. Базой управляет сам клиент: он читает файл 1Cv8.1CD и считает всё локально.

Отдельно про разрядность. 32-разрядный процесс упирается примерно в 2–3 ГБ адресного пространства, сколько бы памяти ни стояло в машине. Серверные процессы 1С в современных установках 64-разрядные, этого предела у них нет. У клиента всё зависит от того, какую версию вы поставили: если приложение 32-разрядное, а отчёт собирает миллион строк, оно «падает» по памяти при свободных 16 ГБ в системе.

Файловая база: считаем память для рабочих мест

В файловом режиме серверная часть не нужна, поэтому считают клиентские машины и компьютер (или сетевую папку), где лежит база.

Рабочее место пользователя

Ориентиры, которые работают на практике:

Сама 1С на клиенте обычно занимает от нескольких сотен мегабайт до 1–1,5 ГБ. Остальное съедают система, браузер, почтовая программа, антивирус. Поэтому «4 ГБ» на бумаге превращаются в постоянный своп.

Компьютер, на котором лежит база

Файловую базу открывают по сети, и операционная система хранит прочитанные страницы файла в своём кэше. Чем больше свободной памяти на машине-хозяине, тем меньше обращений к диску.

Простое правило: оперативной памяти на этой машине должно хватать на ОС плюс размер «горячей» части базы. Для базы в 5 ГБ и пяти пользователей достаточно 8 ГБ. Для базы в 20 ГБ лучше 16 ГБ и SSD.

Файловая база с десятком одновременных пользователей — это предел. Если пользователей больше, проблема не в нехватке гигабайт, а в блокировках файла и в сети. Прибавка памяти тут не поможет, нужен переход на клиент-серверный режим.

Клиент-серверный вариант: сколько ОЗУ нужно серверу 1С

Здесь память считают по сеансам. Каждый подключённый пользователь — это сеанс, а у сеанса есть своя область в рабочем процессе.

Формула для первой прикидки

Берите 150–300 МБ на интерактивный сеанс. Нижняя граница — простые учётные задачи, верхняя — тяжёлые отчёты, обработка больших табличных документов, интеграции. Для типовой бухгалтерии берите 200 МБ и смотрите по факту.

Пример для 50 пользователей:

1. Интерактивные сеансы: 50 × 200 МБ = 10 000 МБ, то есть около 10 ГБ.
2. Фоновые задания: пусть в пиковые часы одновременно идут 5 заданий по 500 МБ — это 2 500 МБ, около 2,5 ГБ.
3. Операционная система и служебные процессы кластера: 3–4 ГБ.
4. Итого: 10 + 2,5 + 4 = 16,5 ГБ. Округляйте вверх и ставьте 24 ГБ — с запасом на всплески.

Эти числа относятся к серверу 1С без СУБД. Если СУБД стоит на той же машине, её память прибавляется сверху (см. следующий раздел).

Таблица по числу пользователей

Ориентировочно, для типовых конфигураций (Бухгалтерия, ЗУП, Управление торговлей) и базы до 100 ГБ:

Это точка отсчёта, а не гарантия. Нагруженные конфигурации (УТ с большими остатками, ERP, расчёт себестоимости) требуют больше.

Терминальный сервер

Если пользователи сидят на удалённых рабочих столах, 1С-клиент запускается на терминальном сервере. Считайте так: на каждый сеанс 1–1,5 ГБ (система, 1С, офис, браузер). Для 20 человек это 20–30 ГБ только под сеансы, плюс резерв для ОС.

Память под СУБД: PostgreSQL и SQL Server

СУБД любит память больше, чем сервер 1С. Цель — чтобы часто используемые данные и индексы лежали в оперативной памяти, а не читались с диска.

Сколько отдавать

• Для небольшой базы (до 20–30 ГБ) разумно, чтобы под кэш СУБД было доступно 8–16 ГБ.
• Для базы в сотню гигабайт и выше — 32 ГБ и больше под СУБД.
• Если СУБД и сервер 1С живут на одной машине, поделите память заранее и не оставляйте это на усмотрение системы.

Параметры

В PostgreSQL основной параметр — shared_buffers. Типовое стартовое значение — около четверти оперативной памяти машины (для сервера на 32 ГБ это 8 ГБ). Дальше настраивают work_mem, maintenance_work_mem и effective_cache_size, но менять их надо по данным мониторинга, а не наугад. Для 1С обычно используют сборку PostgreSQL, рекомендуемую для платформы.

В Microsoft SQL Server задайте max server memory так, чтобы операционной системе и остальным службам осталось не менее 2–4 ГБ. Без этого параметра SQL Server забирает почти всё, и на машине начинается нехватка для 1С.

Лимиты памяти в кластере серверов 1С

Без лимитов один «прожорливый» запрос может занять всю память и уронить остальных. В консоли администрирования серверов 1С откройте нужный кластер, затем Рабочие серверы и свойства сервера. Там задаются параметры, влияющие на память.

Точные названия могут чуть отличаться в зависимости от релиза платформы, смысл тот же.

С чего начать

• Не оставляйте нулевые значения («без ограничений») на боевом сервере, где работает больше десятка человек.
• Максимум памяти процессов задайте с запасом на ОС: если на сервере 32 ГБ, лимит процессов в районе 24–26 ГБ.
• Значение «Безопасный расход памяти за один вызов» уменьшайте осторожно. Слишком низкое оборвёт тяжёлый, но законный отчёт, и пользователь увидит ошибку.
• Несколько соединений на один процесс экономят память, но один сбой тогда затрагивает больше людей. Для баз, где сеансы часто вешают процесс, снижайте это число.

Перед тем как завершать рабочие процессы или перезапускать службу агента сервера, убедитесь, что пользователи вышли. Все активные сеансы на этом процессе оборвутся, несохранённые документы потеряются. Делайте это вне рабочих часов.

Что ещё забирает память: пользователи и регламентные задания

Число людей в базе — только одна из переменных. Вот что чаще всего ломает расчёт.

• 🧮 Тяжёлые отчёты. Один ОСВ по всем счетам за год с расшифровкой может занять больше, чем десяток обычных сеансов.
• 🔁 Регламентные и фоновые задания. Обмен с банком, загрузка из внешних систем, пересчёт итогов, закрытие месяца . Они идут отдельными сеансами и не видны в списке пользователей, но память берут.
• 📦 Пакетное проведение. Проведение сотен документов подряд держит в памяти данные всех движений.
• 🌐 Веб-доступ и сервисы. HTTP-сервисы и веб-клиент создают собственные сеансы. Если база опубликована наружу, учитывайте их.
• 🕑 Совпадение по времени. Если обмен, резервное копирование и закрытие месяца запускаются в одно и то же время, пик получится вдвое выше расчёта.

Практический приём: раскиньте тяжёлые задания по расписанию. Что можно сдвинуть на ночь — сдвиньте. Расчёт «на 50 человек» не должен строиться на том, что все 50 одновременно считают себестоимость.

Следующий приём — разделение баз. Если у вас в одной базе ведётся учёт и идёт много автоматических обменов, вынесите обмены в отдельное окно или отдельный рабочий процесс. Тогда долгий обмен не выдавит из памяти пользователей.

Как понять, что памяти не хватает, и что с этим делать

Признаки нехватки видны до того, как придут жалобы.

1. Операционная система начинает использовать файл подкачки: диск загружен, а процессор нет.
2. Процессы rphost перезапускаются слишком часто — это видно по смене их идентификаторов в консоли кластера.
3. Пользователи получают сообщения о нехватке памяти или «зависают» на долгих операциях без нагрузки на ЦП.
4. СУБД читает с диска то, что раньше брала из кэша.

Пошаговая диагностика:

1. Снимите картину по времени: в какие часы и кто работает, какие задания идут.
2. Посмотрите потребление памяти по процессам rphost в консоли кластера или в диспетчере задач сервера.
3. Проверьте, нет ли утечки: если процесс растёт без остановки в течение дня и не возвращается к исходному размеру, лимиты перезапуска спасают, но причину ищет разработчик.
4. Оцените, не вылезает ли в своп машина с СУБД.

Только после этого решайте, что делать: оптимизировать запрос, раскидать задания, перенастроить лимиты или докупать память.

Что действует быстрее покупки планок

• Разгрузить сервер от тяжёлых заданий на ночь.
• Включить ограничение памяти процессов, чтобы один сеанс не съедал остальных.
• Вынести СУБД на отдельную машину, если делили одну.
• Почистить базу и индексы: сжатие и обслуживание таблиц иногда освобождают заметно больше, чем лишние гигабайты.

Ошибки при планировании

Типичные просчёты, которые не повторяют предыдущие разделы:

• ❌ Считать по числу лицензий, а не по числу одновременных сеансов. Лицензий куплено 100, работают 30 — память нужна под 30 плюс запас на рост.
• ❌ Забыть про рост базы. Через год база вдвое больше, кэш СУБД уже не вмещает горячие данные.
• ❌ Положить сервер 1С и СУБД на один виртуальный хост с динамической памятью. Гипервизор может отобрать память в самый нагруженный момент. Фиксируйте объём для машин с 1С.
• ❌ Не оставить ничего операционной системе. Если вся память отдана СУБД, система уходит в своп, и скорость падает во всех службах.
• ❌ Экономить на SSD, рассчитывая «на кэш». Память не заменяет быстрый диск: журнал транзакций и записи всё равно идут на накопитель.

Частые вопросы