Какой Windows VPS нужен для BAS/1C: расчёт для 1, 3, 5 и 10 пользователей
Для BAS/1C нельзя корректно выбрать Windows VPS только по числу сотрудников. Один бухгалтер может работать с небольшой файловой базой и почти не нагружать сервер, а другой — регулярно формировать тяжёлые отчёты, выполнять массовое проведение документов и одновременно держать открытыми Excel, браузер и клиент-банк. Формально в обоих случаях пользователь один, но требования к серверу будут разными.
Поэтому конфигурации для 1, 3, 5 и 10 пользователей лучше воспринимать как стартовые профили для обычной офисной работы через RDP. Если сервер ещё только выбирается, параметры можно сопоставить с виртуальными серверами Windows UkrSky. Затем расчёт нужно скорректировать по архитектуре базы, характеру операций, дополнительному ПО и тому, сколько сотрудников действительно работают одновременно.

Если нужен короткий ориентир: для одного пользователя можно начинать примерно с 2 vCPU и 6 ГБ RAM, для трёх — с 4 vCPU и 8–12 ГБ, для пяти — с 4–6 vCPU и 12–16 ГБ, а для десяти активных пользователей уже стоит смотреть на 6–8 vCPU и 24–32 ГБ RAM. Во всех вариантах желательно быстрое NVMe-хранилище. Это не официальные системные требования BAS/1C, а практические стартовые конфигурации с небольшим запасом.
Какой Windows VPS нужен для BAS/1C на 1, 3, 5 и 10 пользователей?
Для типичной работы BAS/1C по RDP стартовая конфигурация растёт примерно от 2 vCPU и 6 ГБ RAM для одного пользователя до 6–8 vCPU и 24–32 ГБ RAM для десяти одновременно работающих сотрудников. Но считать VPS только по количеству пользователей слишком грубо: одна тяжёлая операция способна создать больше нагрузки, чем несколько открытых сессий с обычным вводом документов.
| Активные пользователи | vCPU | RAM | Диск | Типичный сценарий | Когда брать больше |
|---|---|---|---|---|---|
| 1 | 2 | 6 ГБ | 60–80 ГБ NVMe | Одна база, обычная бухгалтерская работа | SQL, крупная база, тяжёлые обработки |
| 3 | 4 | 8–12 ГБ | 80–100 ГБ NVMe | Небольшой отдел, три RDP-сессии | Несколько баз, Excel и браузеры, тяжёлые отчёты |
| 5 | 4–6 | 12–16 ГБ | 100–150 ГБ NVMe | Пять активных сотрудников в течение дня | SQL, закрытие периода, обмены, массовые операции |
| 10 | 6–8 | 24–32 ГБ | от 150 ГБ NVMe | Небольшой офис с общей BAS/1C | Большая база, интенсивный SQL, несколько тяжёлых баз |
Размер диска в таблице — только стартовый ориентир. Его нужно считать отдельно: Windows + BAS/1C + информационные базы + временные файлы + журналы + локальные резервные копии + свободный запас. Если рабочая база занимает 60 ГБ, VPS с диском 70 ГБ уже нельзя считать комфортным только потому, что файл базы туда помещается.
Большой диск сам по себе не ускоряет BAS/1C. VPS с 300 ГБ хранилища может работать хуже сервера со 100 ГБ, если первый имеет высокую задержку операций или слабый процессор. Для производительности важны не только гигабайты, но и то, как быстро сервер обрабатывает CPU- и дисковые операции.
Почему количество пользователей BAS/1C не позволяет точно рассчитать VPS?
Количество учётных записей показывает только порядок будущей нагрузки. Для Windows VPS гораздо важнее, сколько сотрудников активно работает одновременно и что они в этот момент делают. Пять открытых RDP-сессий ещё не означают пять одинаковых нагрузок.
Один сотрудник вводит документы. Второй запускает большой отчёт. Третий выполняет массовое проведение, а в фоне в это же время начинается обмен или регламентное задание. Формально активны три человека, но основную нагрузку могут создавать один пользователь и один фоновый процесс.
| Профиль нагрузки | Примеры | Что обычно нагружается сильнее |
|---|---|---|
| Лёгкий | Просмотр справочников, ввод небольшого числа документов | RAM пользовательской сессии, умеренный CPU |
| Обычный | Активная работа с документами, отчётами, Excel | CPU, RAM, диск |
| Тяжёлый | Большие отчёты, массовое проведение, закрытие периода, обмены | CPU, база данных, storage |
Рабочий пик тоже не всегда совпадает с максимальным числом RDP-сессий. В 10:00 на сервере могут быть восемь пользователей с лёгкой нагрузкой, а в 16:00 останутся четыре, один из которых запустит тяжёлую обработку. Для выбора VPS интереснее второй момент.
Если используется Windows VPS для работы по RDP и сервер уже запущен, реальные RDP-сессии можно посмотреть в Task Manager на вкладке Users или командой:
quserВ выводе видны пользователи и состояние их сеансов. Active означает активную сессию, Disc — отключённую. И здесь часто обнаруживается полезная деталь: пользователь закрыл окно RDP, но не вышел из Windows. Запущенные BAS/1C, Excel или браузер продолжают занимать память.
Поэтому перед заказом VPS полезно записать две цифры: сколько пользователей подключено в обычный рабочий час и сколько из них одновременно выполняют реальные операции. Это намного точнее общего числа сотрудников.
Как файловая и клиент-серверная BAS/1C меняют требования к VPS?
Одинаковое число пользователей нельзя одинаково рассчитывать для файловой и клиент-серверной BAS/1C. В файловом варианте работа идёт непосредственно с файлом информационной базы, а в клиент-серверном в нагрузке участвуют серверные процессы BAS/1C и СУБД. Поэтому пять пользователей в этих двух схемах — технически разные задачи.
Как быстро понять, файловая база или клиент-серверная
Самый простой способ — посмотреть свойства подключения информационной базы. Если в параметрах указан путь к каталогу с базой на диске, это файловый вариант. Если подключение идёт к серверу и информационной базе на сервере, используется клиент-серверная схема.
На уже работающем Windows VPS дополнительную подсказку даёт список процессов. Для обычного клиентского запуска BAS/1C можно увидеть 1cv8.exe. В серверной архитектуре рабочую нагрузку могут выполнять процессы rphost.exe, а если используется Microsoft SQL Server — в системе будет sqlservr.exe.
Смысл этой проверки простой: прежде чем увеличивать VPS, нужно понимать, кто именно потребляет ресурсы. Без этого фраза «BAS занимает всю память» может оказаться неверной — память, например, удерживает SQL Server.
Когда файловая база начинает упираться не только в размер VPS
Для одного или нескольких сотрудников с небольшой базой файловый вариант может работать вполне нормально, особенно если BAS/1C и сама база находятся на одном Windows VPS, а пользователи заходят по RDP. Схема простая, СУБД отдельно обслуживать не нужно.
Проблема проявляется при росте параллельной работы. Типичная картина: четыре пользователя спокойно вводят документы, пятый запускает тяжёлый отчёт — и задержки начинают замечать остальные. Если при этом CPU и RAM не упираются в предел, а операции с базой вызывают заметную дисковую активность, добавление ещё нескольких гигабайт памяти может почти ничего не изменить.
Ещё один сигнал — ресурсы VPS уже увеличивали, но эффект от каждого апгрейда становится всё меньше. Вот здесь нужно смотреть не тариф, а архитектуру и поведение самой базы.
Что меняется, если SQL Server работает на том же VPS
Если на одном Windows VPS одновременно находятся RDP-сессии, BAS/1C и Microsoft SQL Server, все компоненты делят одну оперативную память, один процессор и одно хранилище. Поэтому конфигурация «пять пользователей — 12 ГБ RAM» перестаёт быть достаточным расчётом сама по себе.
Откройте Task Manager → Details или Processes и посмотрите, сколько RAM удерживает sqlservr.exe. Затем сравните это с общей памятью VPS и количеством памяти, доступной Windows. Если SQL забрал значительную часть RAM, а пользовательским RDP-сессиям и BAS остаётся мало свободного пространства, причина уже понятнее.
Для Microsoft SQL Server также имеет смысл проверить настройку Max Server Memory в свойствах сервера. Если предел памяти SQL выбран без учёта общего объёма VPS, СУБД может конкурировать с Windows, RDP и BAS/1C за RAM. Не нужно менять параметр вслепую — сначала зафиксируйте реальное потребление и убедитесь, что проблема именно в памяти.
| Критерий | Файловый вариант | Клиент-серверный вариант |
|---|---|---|
| Небольшое число пользователей | Часто достаточно | Может быть избыточным по сложности |
| Рост параллельных операций | Чувствительность увеличивается | Лучше подходит для распределения серверной нагрузки |
| Потребление RAM | Обычно проще предсказать | Нужно учитывать BAS/1C и СУБД отдельно |
| Чувствительность к storage | Высокая | Тоже высокая, но нагрузку создаёт уже и СУБД |
| Диагностика | CPU, RAM, файл базы, диск | Дополнительно rphost.exe, sqlservr.exe и СУБД |
Какой Windows VPS выбрать для одного пользователя BAS/1C?
Для одного обычного пользователя BAS/1C разумно начинать примерно с 2 vCPU и 6 ГБ RAM на NVMe. Но главный вопрос здесь не столько в самой BAS, сколько в накладных расходах Windows и пользовательского рабочего стола.
Можно быстро проверить это даже на уже работающем сервере. После входа в Windows посмотрите использование памяти до запуска рабочих программ. Затем откройте BAS/1C и повторите замер. После этого запустите обычный набор пользователя: Excel, браузер, клиент-банк или другое ПО. Разница между этими тремя состояниями покажет, сколько RAM реально требуется рабочему месту, а не одной программе.
Конфигурация с 4 ГБ может технически запускать систему, но запаса остаётся мало. Windows, антивирус, обновления, RDP и пользовательские приложения тоже потребляют память. Если к этому добавляется SQL Server, крупная база или работа в Конфигураторе, 4 ГБ уже слишком тесный сценарий.
Один пользователь также способен создать резкий пик CPU при формировании тяжёлого отчёта или перепроведении документов. Поэтому проверять сервер нужно не через пять минут после входа, а во время самой тяжёлой регулярной операции.
Для обычной одиночной работы ориентир 2 vCPU / 6 ГБ RAM остаётся разумной стартовой точкой. Если один пользователь регулярно работает с SQL, Конфигуратором, большой базой или тяжёлыми обработками, конфигурацию лучше считать уже по фактической нагрузке, а не по числу людей.
Какой Windows VPS выбрать для трёх пользователей BAS/1C?
Для трёх типичных пользователей BAS/1C по RDP практичной стартовой конфигурацией будет около 4 vCPU и 8–12 ГБ RAM. Но именно на таком масштабе часто проявляется проблема не с BAS, а с самими RDP-сессиями.
Представим небольшой отдел: бухгалтер работает в BAS и Excel, руководитель открывает отчёты, менеджер держит BAS, браузер и почту. Один сотрудник закончил работу и просто закрыл окно RDP. Потом второй сделал то же самое. В Task Manager администратор видит трёх текущих пользователей, а команда quser дополнительно показывает отключённые сессии.
quserЕсли у пользователя состояние Disc, откройте Task Manager → Users и разверните его сессию. Так можно увидеть, какие процессы остались запущенными и продолжают занимать память. Несколько старых сеансов с BAS, Excel и браузерами вполне способны съесть запас RAM, который планировался для активных сотрудников.
Поэтому для трёх пользователей полезный тест выглядит так: сначала замерить RAM с тремя активными рабочими столами, затем проверить наличие отключённых сессий и только после этого решать, нужен ли апгрейд. Иногда памяти достаточно — нужно просто убрать процессы, которые никто уже не использует.
Если три пользователя действительно работают одновременно, открывают дополнительное ПО и периодически строят отчёты, 12 ГБ RAM обычно дают более спокойный запас, чем попытка удержаться на нижней границе.
Какой Windows VPS выбрать для пяти пользователей BAS/1C?
Для пяти активно работающих пользователей BAS/1C разумный старт — 4–6 vCPU и 12–16 ГБ RAM. Здесь уже имеет смысл смотреть не только на объём памяти, но и на то, как именно распределяется нагрузка по CPU.
Ситуация может выглядеть так: четыре сотрудника работают нормально, пятый запускает тяжёлый отчёт — и задержка появляется сразу у нескольких пользователей. Task Manager при этом показывает всего 35–40% общего CPU. На первый взгляд процессора достаточно. Но после переключения графика на логические процессоры видно, что одно ядро почти постоянно загружено.
Какие процессы смотреть во время нагрузки
Откройте Task Manager → Details и отсортируйте процессы по CPU. В зависимости от архитектуры среди процессов, связанных с рабочей нагрузкой, могут встречаться:
1cv8.exe— клиентский процесс BAS/1C;rphost.exe— рабочий процесс при серверной архитектуре;sqlservr.exe— Microsoft SQL Server.
Если в момент торможения большую часть CPU забирает один 1cv8.exe или rphost.exe, это совсем другой сценарий, чем несколько одновременно загруженных процессов. Больше vCPU и более высокая производительность одного ядра — не одно и то же.
Когда дополнительные vCPU действительно помогут
Если несколько пользователей и серверных процессов одновременно загружают разные ядра, дополнительные vCPU могут дать запас для параллельной работы. Если же одна конкретная операция упирается в производительность одного ядра, простое увеличение числа виртуальных процессоров не гарантирует заметного ускорения этой операции.
Тогда добавлять RAM бессмысленно, если память свободна. И добавлять vCPU вслепую тоже не лучший первый шаг. Сначала нужно увидеть, какой процесс создаёт пик и как распределяется CPU.
Для пяти пользователей нижняя граница 12 ГБ подходит при понятной умеренной нагрузке. Если на том же VPS работает SQL Server, запускаются обмены, тяжёлые отчёты и дополнительное ПО, практичнее рассчитывать ближе к 16 ГБ и проверять CPU в реальном рабочем пике.

Какой Windows VPS выбрать для десяти пользователей BAS/1C?
Для десяти одновременно работающих пользователей BAS/1C уже стоит рассматривать примерно 6–8 vCPU и 24–32 ГБ RAM с быстрым NVMe. Но в этом сценарии количество учётных записей особенно легко вводит в заблуждение.
Что проверить перед выбором VPS на 10 пользователей
Сначала выясните, сколько человек действительно работают одновременно. Если в системе заведено десять сотрудников, но обычно активны четыре-пять, стартовая нагрузка будет ближе к сценарию пяти пользователей. При этом запас под рост всё равно нужен.
Дальше проверьте архитектуру и характер работы:
- файловая база или клиент-серверная;
- одна информационная база или несколько;
- работает ли Microsoft SQL Server на том же VPS;
- каков размер основных баз;
- есть ли тяжёлые отчёты и закрытие периода;
- когда выполняются обмены и регламентные задания;
- создаются ли резервные копии в рабочее время;
- какое дополнительное ПО открыто в RDP-сессиях.
Особенно полезно посмотреть, совпадают ли пики. Если десять сотрудников работают одновременно, SQL активно обрабатывает запросы, а в этот же момент начинается backup, один VPS получает сразу несколько разных типов нагрузки. Средняя загрузка за весь день здесь мало что объясняет.
Когда один VPS всё ещё подходит
Десять пользователей сами по себе не требуют разделения системы на несколько серверов. Если один Windows VPS имеет достаточно CPU, RAM и быстрый storage, а во время рабочего пика метрики остаются стабильными, усложнять схему нет необходимости.
Но возможность вертикального масштабирования уже становится частью расчёта. Для такого сервера желательно заранее понимать, можно ли добавить RAM и vCPU без сложного переноса базы на новую машину.
Если пользователей десять, но одновременно работают только четыре-пять, не нужно механически рассчитывать нагрузку как для десяти постоянных тяжёлых сессий. Считать следует реальную одновременную работу плюс разумный запас на пиковые часы и рост.
Как пересчитать CPU, RAM и диск, если BAS/1C работает тяжелее обычного?
Увеличивать Windows VPS нужно по ресурсу, который действительно стал узким местом. Добавление 8 ГБ RAM не исправит медленный storage, а дополнительные vCPU мало помогут серверу, который постоянно испытывает нехватку памяти. Сначала симптом нужно привязать к конкретному ресурсу.
Когда увеличивать RAM
Смотреть в сторону дополнительной памяти нужно, если RAM почти заполнена именно в рабочий пик, доступной памяти остаётся мало, растёт paging или один из процессов удерживает непропорционально большой объём памяти.
В Task Manager откройте Performance → Memory, затем Processes или Details и отсортируйте процессы по памяти. Это позволяет ответить на главный вопрос: память заняли пользовательские приложения, BAS/1C, sqlservr.exe или сразу несколько отключённых RDP-сессий.
Посмотрите также Committed. Если committed memory приближается к общему доступному лимиту и Windows активно использует файл подкачки, это уже гораздо более содержательный признак нехватки памяти, чем фраза «RAM показывает 80%».
Когда важнее CPU
Если задержка появляется во время отчёта, расчёта, массового проведения или регламентной операции, откройте Task Manager → Performance → CPU и переключите отображение на логические процессоры. Общие 30–40% CPU не доказывают, что процессора хватает.
Следующий шаг — Task Manager → Details. Отсортируйте процессы по CPU и посмотрите, кто создаёт нагрузку в момент торможения: 1cv8.exe, rphost.exe, sqlservr.exe или вообще другой процесс.
Если загружены сразу несколько процессов и несколько логических процессоров, системе может не хватать параллельной вычислительной мощности. Если одно ядро постоянно упирается в потолок из-за одной операции, нужно учитывать уже производительность отдельного ядра. Просто добавить ещё четыре vCPU — не универсальное лечение.
Когда проблема находится в диске
Если CPU и RAM выглядят нормально, а операции с базой периодически зависают, откройте Resource Monitor → Disk. Здесь нужно смотреть не только общий процент активности, но и конкретные процессы, файлы и время отклика.
Сначала отсортируйте Disk Activity по активности или времени отклика. Затем посмотрите, что именно читается или записывается. Если нагрузку создаёт рабочая база — это один сценарий. Если диск занят backup, антивирусом или другой задачей — другой.
Высокая задержка дисковых операций сама по себе ещё не отвечает, почему она возникла. Но она сразу меняет направление диагностики. В этот момент добавлять RAM просто потому, что «сервер тормозит», уже нет смысла.
Как учитывать размер базы и резервные копии
Диск рассчитывают не по формуле «база занимает 50 ГБ, значит хватит 60 ГБ». Нужны место под Windows, BAS/1C, текущую базу, временные данные, журналы, обновления и резервные копии.
Если локальные backup хранятся на том же VPS, учитывайте их ротацию. Несколько полных копий большой базы могут занять больше места, чем сама рабочая база. И копия только на том же VPS не должна оставаться единственной резервной копией данных.
| Ресурс | Где смотреть | Что искать | Следующий шаг |
|---|---|---|---|
| CPU | Task Manager / Performance Monitor | Какой процесс грузит CPU, одно ядро или несколько | Проверить характер операции и только затем CPU/vCPU |
| RAM | Task Manager → Memory / Processes | Available, Committed, paging, главный потребитель RAM | Освободить лишние процессы или увеличить память |
| Disk | Resource Monitor → Disk | Response Time, активный процесс, читаемый или записываемый файл | Отделить проблему базы от backup, антивируса или storage |
| RDP-сессии | Task Manager → Users / quser | Active, Disc, оставшиеся процессы | Завершить ненужные сессии или учитывать их ресурсы |
Как проверить после запуска, хватает ли Windows VPS для BAS/1C?
Достаточность Windows VPS нужно проверять во время реальной нагрузки. Сервер в простое может показывать 5% CPU и половину свободной памяти, а через час во время отчётов ситуация изменится полностью.
Лучший подход — получить две точки сравнения: одну при нормальной работе, вторую в момент жалобы. Тогда видно не просто «CPU высокий», а что именно изменилось вместе с замедлением BAS/1C.
Проверка CPU
Откройте Task Manager → Performance → CPU. Если общий CPU длительно высокий, перейдите в Details и определите процесс. Если общий процент невелик, проверьте отдельные логические процессоры.
Зафиксируйте три вещи: общий CPU, наиболее загруженное ядро и процесс с максимальной нагрузкой. Одного общего процента недостаточно.
Проверка RAM
На вкладке Memory оцените доступную память и Committed. Затем в списке процессов посмотрите, кто потребляет RAM. Это может быть BAS/1C, SQL Server, браузер или оставшаяся пользовательская сессия.
Если свободной памяти мало только при открытии пяти-шести RDP-сессий, причина понятна. Если RAM заканчивается даже без пользователей, нужно искать процесс, который удерживает память.
Проверка NVMe и дисковых операций
В Resource Monitor → Disk посмотрите, какие процессы создают I/O и какие файлы активно читаются или записываются. Если именно в момент жалобы резко растёт время отклика дисковых операций, зафиксируйте процесс. Это помогает отделить рабочую базу от резервного копирования, антивируса или другой фоновой задачи.
Какие счётчики посмотреть в Performance Monitor
Если краткого снимка Task Manager мало, Performance Monitor позволяет записать нагрузку за более длинный интервал. Для базовой диагностики достаточно нескольких счётчиков:
Processor\% Processor Time— загрузка процессора;Memory\Available MBytes— доступная физическая память;Memory\Committed Bytes— объём committed memory;PhysicalDisk\Avg. Disk sec/Read— время чтения;PhysicalDisk\Avg. Disk sec/Write— время записи.
Не нужно собирать десятки counters сразу. Цель — увидеть, какой ресурс меняется одновременно с замедлением BAS/1C.
Что зафиксировать именно в момент торможения
- Количество Active и Disc RDP-сессий.
- Общий CPU и загрузку отдельных логических процессоров.
- Процесс с максимальным CPU.
- Available Memory и Committed.
- Процесс с максимальным потреблением RAM.
- Disk Response Time и процесс с максимальной дисковой активностью.
- Какую операцию в этот момент выполнял пользователь BAS/1C.
Если через пять минут тяжёлый отчёт закончился, сервер снова может выглядеть полностью здоровым. Поэтому самый полезный скриншот и замер делаются тогда, когда пользователь говорит: «Сейчас тормозит».
Почему BAS/1C может тормозить, даже если у VPS свободны CPU и RAM?
BAS/1C может работать медленно при 50% свободной RAM и невысокой общей загрузке CPU. Эти два показателя не описывают сервер целиком. Причина может находиться в отдельном ядре процессора, storage, СУБД, конкретной информационной базе, фоновой операции или даже в RDP-соединении.
Типичная картина: Task Manager показывает 30–35% CPU, поэтому кажется, что процессора достаточно. После переключения на логические процессоры выясняется, что одно ядро загружено почти постоянно, а остальные в основном свободны. Средний процент сгладил проблему.
Другой сценарий: CPU свободен, памяти достаточно, но BAS долго открывает данные. Resource Monitor в этот момент показывает высокую дисковую активность. После сортировки видно, что диск занят не BAS, а резервным копированием или антивирусной проверкой. Добавлять ресурсы VPS здесь рано.
Тормозит один пользователь или все сразу?
Это одна из самых быстрых развилок диагностики. Если замедление одновременно замечают все пользователи, нужно смотреть общие серверные ресурсы, базу, SQL и storage. Если проблема только у одного сотрудника, сначала проверьте его RDP-сессию, процесс и конкретную операцию.
Если на сервере несколько информационных баз, полезно уточнить ещё один момент: тормозят все базы или только одна. Если проблема воспроизводится только в одной базе, а остальные в то же время работают нормально, причина уже меньше похожа на общий дефицит CPU или RAM VPS.
Когда подключать журналы и более глубокую диагностику
Если Task Manager, Resource Monitor и PerfMon не показывают явного упора в CPU, память или диск, следующий слой — диагностика самой BAS/1C и СУБД. Для клиент-серверной схемы это может быть анализ серверных процессов и SQL, а для более сложных случаев — технологический журнал BAS/1C и поиск блокировок или конкретных тяжёлых операций.
Не нужно начинать с этого в каждом случае. Сначала исключаются простые серверные причины. Но если железо выглядит свободным, а одна операция стабильно выполняется медленно, искать ещё 8 ГБ RAM уже бессмысленно.
- Воспроизведите проблему.
- Сравните одного пользователя с остальными.
- Проверьте CPU по ядрам и процессам.
- Проверьте RAM и главного потребителя памяти.
- Проверьте дисковые операции.
- Сравните разные информационные базы.
- Если серверные ресурсы свободны, переходите к BAS/1C и СУБД.
Если серверные метрики спокойные, а задержка заметна именно в интерфейсе RDP, дополнительно проверьте сеть:
ping IP_АДРЕС_СЕРВЕРАping не диагностирует всю сеть и не доказывает причину медленной работы базы, но помогает быстро увидеть высокую задержку или потерю пакетов и отделить сетевой симптом от серверного.
Когда одного Windows VPS для BAS/1C уже недостаточно как архитектуры?
Переход к более сложной схеме нужен тогда, когда RDP-сессии, BAS/1C, СУБД и фоновые задачи начинают стабильно конкурировать друг с другом, а точечные апгрейды перестают устранять задержки. Число пользователей само по себе здесь вторично.
Есть несколько практических признаков.
sqlservr.exeрегулярно забирает значительную часть RAM, а пользовательским сессиям её уже не хватает;- несколько тяжёлых информационных баз создают независимые пики нагрузки;
- резервное копирование заметно мешает работе пользователей;
- RDP-сессии и серверные процессы BAS постоянно конкурируют за CPU;
- после увеличения CPU или RAM проблема быстро возвращается, потому что упор находится в другом компоненте;
- нагрузку уже трудно разделить по времени: отчёты, обмены, SQL и пользователи работают одновременно.
Например, сервер увеличили с 16 до 32 ГБ RAM. Пользователям стало лучше, но через некоторое время SQL снова занял большую часть памяти, а в пиковые часы RDP-сессиям не хватает запаса. Следующий шаг — не обязательно 64 ГБ. Сначала нужно решить, правильно ли распределены роли и ресурсы.
В другой ситуации память свободна, но rphost.exe, пользовательские процессы и фоновые задания одновременно загружают CPU. Здесь разделение серверных и пользовательских ролей может дать больше, чем ещё один вертикальный апгрейд.
Даже при десяти пользователях один Windows VPS может оставаться нормальной архитектурой. Перестраивать систему стоит не ради количества серверов, а когда измеряемая нагрузка показывает устойчивую конкуренцию компонентов.
Если каждый апгрейд попадает в конкретное подтверждённое узкое место и после него сервер снова получает нормальный запас, вертикальное масштабирование ещё работает. Если ресурсы формально есть, а проблемы постоянно возвращаются вокруг SQL, базы или параллельных серверных ролей, нужно анализировать архитектуру.
Как выбрать Windows VPS для BAS/1C и не переплатить за лишние ресурсы?
Оптимальный Windows VPS для BAS/1C выбирают по числу одновременно активных пользователей, архитектуре базы и самой тяжёлой регулярной операции. Покупать огромный запас по всем параметрам сразу необязательно, особенно если ресурсы VPS можно увеличить позже.
Перед заказом сервера полезно ответить на несколько вопросов:
- Сколько сотрудников имеют доступ к BAS/1C?
- Сколько человек реально работают одновременно?
- Используется файловая база или клиент-серверный вариант?
- Будет ли SQL Server работать на этом же Windows VPS?
- Сколько информационных баз используется и каков их размер?
- Какие операции создают максимальную нагрузку?
- Выполняются ли обмены, backup и регламентные задания в рабочее время?
- Будут ли сотрудники запускать внутри RDP Excel, браузеры и другое ПО?
- Можно ли на выбранных тарифах VPS увеличить RAM, CPU и диск без сложного переноса?
После этого выбор сводится к понятной последовательности:
- Посчитайте одновременно работающих пользователей, а не только заведённые учётные записи.
- Определите файловую или клиент-серверную архитектуру.
- Возьмите стартовый профиль для 1, 3, 5 или 10 пользователей.
- Добавьте запас под тяжёлые отчёты, SQL и дополнительное ПО.
- Отдельно рассчитайте объём диска с учётом базы и резервных копий.
- После запуска снимите метрики при нормальной работе.
- Повторите замер во время реального торможения.
- Увеличивайте тот ресурс, который подтверждён метриками как узкое место.
Короткий ориентир: 1 пользователь — около 2 vCPU и 6 ГБ RAM; 3 пользователя — 4 vCPU и 8–12 ГБ; 5 пользователей — 4–6 vCPU и 12–16 ГБ; 10 одновременно активных пользователей — 6–8 vCPU и 24–32 ГБ. Для всех вариантов нужен быстрый диск и запас свободного пространства.
Если после запуска BAS/1C работает быстро, CPU не упирается в отдельные ядра, памяти хватает, а disk latency остаётся нормальной под рабочей нагрузкой, покупать следующий тариф только ради запаса не нужно. Если появляется проблема, сначала фиксируются процесс и ресурс, который изменился в момент торможения. Уже после этого выбирается апгрейд.
Техническую мощность VPS также не следует смешивать с лицензированием BAS/1C, Windows Server и удалённого доступа. Допустимое число пользователей и необходимые лицензии проверяются отдельно для используемой схемы: наличие ресурсов на сервере само по себе не даёт права на произвольное количество RDP-сессий.


