Подберите VPS для SaaS по бюджету рабочей нагрузки

Назовите работу до выбора хоста

Нарисуйте путь запроса: обратный прокси, процесс API, база данных и внешние сервисы. Добавьте асинхронный путь: очередь, воркер и назначение экспорта. Запишите, какие компоненты делят хост, кто управляет параллелизмом и какие данные должны пережить пересборку. Вам нужны метрики приложения и непроизводственная рабочая нагрузка с репрезентативными данными; это руководство не предполагает подготовленный экземпляр PrivacyNodes.

Для иллюстративного API отчётности HTTP-запрос читает настройки аккаунта и ставит экспорт в очередь. Воркер сканирует строки и записывает файл. Быстрый ответ на постановку в очередь не доказывает, что экспорт сможет завершиться во время пикового трафика. Включите запланированную очистку и перекрытие развёртывания в план тестирования.

Включите перекрытие в таблицу памяти

Это гипотетические планировочные входные данные в MiB, а не измерения или обещания относительно PrivacyNodes. Замените их наблюдаемыми требованиями приложения. RSS включает резидентные разделяемые отображения; сложение RSS каждого процесса может удвоить учёт памяти. Доступная память хоста полезнее, чем рассмотрение всего кэша файловой системы как постоянно недоступного.

Техническая справка: Учёт памяти процесса Linux.

Это слишком близко к номинальному конверту 4 GB, чтобы предполагать комфортную ёмкость. Проверьте фактическую память, сообщаемую хостом, и пересекаются ли пики. Уменьшите параллелизм, переместите компонент или добавьте память; не убирайте резерв только чтобы таблица поместилась.

PostgreSQL work_mem — это допуск на операцию, а не общий лимит базы данных. Параллельные сессии и операции могут умножить его эффект. Контейнеры Docker по умолчанию не имеют ограничений CPU или памяти; образ — это не политика ресурсов.

Техническая справка: Потребление ресурсов PostgreSQL · Ограничения ресурсов Docker.

Измеряйте CPU вместе с возрастом очереди

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

Начните пример с одним выполняющимся экспортом. Если воркер ждёт внешнее хранилище, дополнительный CPU может мало что изменить. Если он постоянно насыщает ядро, пока растёт задержка API, протестируйте меньший пакет экспорта или отдельный бюджет воркера. Измените один фактор и повторите тот же сценарий перед покупкой ёмкости.

Запланируйте следующую операцию обслуживания

Перечислите файлы и индексы базы данных, загрузки, журналы, временные экспорты, артефакты релизов и свободное место для обслуживания. Запишите рост в неделю и когда ваш резерв будет исчерпан. Набор данных 20 GB плюс временная копия 20 GB требует больше 20 GB, даже когда обычный трафик приложения тих.

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

Напишите решение, к которому можно вернуться

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

Сравните App 2 и Scale 4 с этими ограничениями. Если результат всё ещё удивляет вас, проследите один медленный запрос через стек. Это упражнение оценивает вашу рабочую нагрузку; оно не устанавливает эталон поставщика, пропускную способность или доступность.