Spring Boot на VPS 4–8 GB: как не убить сервер неправильной JVM RAM

Spring Boot-приложение на VPS чаще всего ломается не из-за Java и не из-за VPS. Оно ломается потому, что JVM забирает память не так, как ожидает владелец проекта. На сервере 4 GB RAM, приложению ставят -Xmx3g, рядом работают PostgreSQL, Redis, Nginx, systemd, логирование, backup, деплой — и через несколько часов Linux убивает Java-процесс через OOM killer. Снаружи это выглядит как “сайт упал”, “API иногда не отвечает”, “VPS нестабильный”. На деле сервер просто выбрали и настроили без понимания JVM memory.

Типовые реальные проблемы после запуска Spring Boot на VPS: приложение работает после ручного java -jar, но падает после закрытия SSH; после reboot сервис не поднялся; 502 Bad Gateway от Nginx; Java съела всю RAM; PostgreSQL начал отваливаться; Redis добавили “для скорости”, но он забрал последнюю память; HikariCP открыл слишком много соединений; логи разрослись и забили диск; health check показывает UP, но база уже тормозит; после деплоя старая версия JAR продолжает работать, потому что сервис не перезапустили нормально.

Эта статья — production checklist для Spring Boot на VPS 4–8 GB: как считать память, какие JVM-настройки важны, когда хватает VPS, когда нужен сервер мощнее и что проверить до заказа.

Когда Spring Boot нормально размещать на VPS

VPS подходит для Spring Boot, если это backend API, личный кабинет, CRM, внутренний сервис, SaaS MVP, Telegram/мобильный backend, микросервис, админка, интеграционный сервис, Java REST API, небольшой e-commerce backend или production-проект с умеренной нагрузкой.

Типовая production-схема:

Nginx принимает HTTPS-запросы и проксирует их в Spring Boot.
Spring Boot работает как systemd-сервис, а не вручную в SSH.
JVM запускается с понятными лимитами памяти.
PostgreSQL или MySQL работают локально на VPS либо вынесены отдельно.
Redis используется только если он реально нужен: cache, sessions, rate limits, queues, locks.
Actuator используется для health checks и метрик, но не открыт всему интернету.
Backup сохраняет базу, конфигурацию, uploads и важные данные.
Monitoring следит за RAM, heap, disk, CPU, HTTP 500/502, GC, базой и SSL.

Для Spring Boot-проекта можно выбрать VPS Hostyrex: https://hostyrex.net/ru/vps.html. Если конфигурация понятна, тарифы доступны в WHMCS: https://client.hostyrex.net/store/vps.

Что люди реально ищут, когда Spring Boot падает на VPS

Пользователь обычно не ищет “лучший VPS для Java”. Он ищет конкретную боль:

Spring Boot на VPS 4GB RAM
Spring Boot VPS JVM tuning
Java process killed VPS OOM killer
Spring Boot memory usage too high
Spring Boot systemd service Linux
Spring Boot Nginx 502 Bad Gateway
Spring Boot HikariCP PostgreSQL too many connections
Spring Boot heap size VPS
Java Xmx сколько ставить на VPS
Spring Boot Actuator production health check
Spring Boot Redis cache memory problem
Spring Boot app stops after closing terminal

Это важный момент. Клиенту не нужна статья “Java — популярный язык”. Ему нужно понять, почему приложение умирает на VPS, сколько RAM реально нужно, как задать JVM-лимиты и что проверить до оплаты.

Главная ошибка: думать, что -Xmx — это вся память Java

Самая частая ошибка при Spring Boot на VPS — считать так: “у меня VPS 4 GB RAM, значит можно поставить -Xmx3500m”. Нельзя. -Xmx ограничивает только Java heap. Но JVM использует не только heap.

Кроме heap, память нужна для:

Metaspace — классы, Spring context, proxy, reflection, Hibernate.
Thread stacks — каждый поток забирает память под stack.
Direct buffers — сетевые буферы, NIO, Netty, драйверы, HTTP-клиенты.
Code cache — JIT-компиляция.
GC structures — внутренние структуры garbage collector.
Native libraries — OpenSSL, compression, image processing, drivers.
Операционная система, systemd, SSH, Nginx, journald.
PostgreSQL, Redis, backup, cron, monitoring agent.

Поэтому на VPS 4 GB нельзя отдавать почти всю память heap. Если поставить слишком большой -Xmx, приложение может умереть не от Java OutOfMemoryError, а от Linux OOM killer. В логах это часто выглядит так:

dmesg -T | grep -i "killed process"
journalctl -k | grep -i oom

Если там видно, что kernel убил java-процесс, значит серверу физически не хватило памяти. Это не лечится случайными JVM-флагами. Нужно уменьшать лимиты, искать утечки, снижать пул соединений, выносить базу/Redis или брать VPS больше.

Как примерно считать RAM для Spring Boot на VPS 4–8 GB

Для Spring Boot нельзя считать только heap. Нужно оставить запас под ОС, базу, Redis, Nginx, логи и native memory JVM.

Практический ориентир для одного Spring Boot-приложения:

VPS 4 GB RAM — разумный старт для одного Spring Boot API без тяжёлой базы на том же сервере или с небольшой локальной PostgreSQL. Heap обычно держат скромно: примерно 1–2 GB, а не 3.5 GB.
VPS 6 GB RAM — удобнее, если на том же сервере PostgreSQL, Redis, Nginx, monitoring и есть небольшой запас под деплой, backup и всплески нагрузки.
VPS 8 GB RAM — нормальный вариант для production Spring Boot с PostgreSQL, Redis, несколькими workers/schedulers, активным API и запасом под GC, native memory и обслуживание.

Это не жёсткое правило. Простое Spring Boot API может жить в 512–1024 MB heap. Тяжёлый монолит с Hibernate, большим Spring context, отчётами, Excel/PDF, большими JSON, batch jobs и кэшем может съесть несколько GB и всё равно тормозить. Поэтому правильный подход — не “дать Java побольше”, а измерять память и понимать, что именно её ест.

Что выбрать: VPS 4 GB или 8 GB

VPS 4 GB можно брать, если:

одно Spring Boot-приложение;
умеренный API-трафик;
небольшая база;
нет тяжёлых batch jobs;
Redis не обязателен или используется аккуратно;
логирование не пишет гигабайты в день;
вы готовы настроить JVM limits и monitoring.

VPS 8 GB лучше брать, если:

PostgreSQL находится на том же сервере;
есть Redis;
есть scheduled jobs, imports, reports, batch processing;
используется Hibernate/JPA с активной базой;
есть несколько Spring Boot services;
проект уже production и простой стоит денег;
нужен запас под deploy, backup и мониторинг.

Слабое решение — взять минимальный VPS, поставить туда Java, PostgreSQL, Redis, Nginx, Prometheus, Grafana, backup-скрипты, несколько приложений и потом удивляться OOM killer. Java любит предсказуемую память. Если памяти нет, она не становится “экономнее” сама.

Spring Boot через systemd: не запускайте production из SSH

Ещё одна частая ошибка — запускать приложение так:

java -jar app.jar

Пока открыт терминал — приложение работает. После закрытия SSH, reboot или ошибки процесс исчезает. Иногда используют nohup или screen. Для теста это допустимо. Для production — плохая практика.

Spring Boot на VPS должен работать как systemd-сервис. Это даёт:

автозапуск после перезагрузки;
понятный restart;
логи через journalctl;
отдельного пользователя приложения;
лимиты памяти и файлов;
управляемые переменные окружения;
нормальный деплой без ручного поиска процесса.

Пример логики systemd-сервиса:

[Unit]
Description=my-spring-app
After=network.target

[Service]
User=springapp
WorkingDirectory=/opt/my-spring-app
EnvironmentFile=/etc/my-spring-app/app.env
ExecStart=/usr/bin/java $JAVA_OPTS -jar /opt/my-spring-app/app.jar
SuccessExitStatus=143
Restart=always
RestartSec=10

[Install]
WantedBy=multi-user.target

После этого приложение управляется нормально:

systemctl daemon-reload
systemctl enable my-spring-app
systemctl start my-spring-app
systemctl status my-spring-app
journalctl -u my-spring-app -n 100 --no-pager

Если приложение не стартует через systemd, но стартует вручную, часто проблема в переменных окружения, правах, рабочей директории, пути к Java или доступе к файлам.

JVM tuning: с чего начинать без шаманства

На форумах часто видно две крайности. Первая — вообще не задавать JVM limits и надеяться, что Java сама разберётся. Вторая — копировать чужой набор -XX флагов из интернета без понимания. Оба подхода плохие.

Для VPS 4–8 GB обычно достаточно начать с простого и понятного набора:

JAVA_OPTS="-Xms512m -Xmx2g -XX:+UseG1GC -XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=/var/log/my-spring-app/heapdump.hprof"

Для VPS 8 GB и более тяжёлого приложения можно увеличить heap, но не занимать всю память:

JAVA_OPTS="-Xms1g -Xmx4g -XX:+UseG1GC -XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=/var/log/my-spring-app/heapdump.hprof"

Смысл простой: heap должен быть ограничен, но у ОС и остальных сервисов должен оставаться запас. Если на VPS 4 GB работает PostgreSQL, Redis и Nginx, -Xmx3g почти наверняка слишком агрессивен.

Если приложение работает в контейнере, можно использовать процентные лимиты вроде MaxRAMPercentage. Но на обычном VPS с systemd явный -Xmx часто проще и предсказуемее. Главное — не ставить флаги вслепую и не считать heap всей памятью процесса.

Xms и Xmx: почему не всегда нужно делать их одинаковыми

Есть старый совет: ставить -Xms и -Xmx одинаковыми. Для больших предсказуемых production-нагрузок это может быть нормально. Для маленького VPS это не всегда разумно.

Если на VPS 4 GB поставить -Xms2g -Xmx2g, Java сразу зарезервирует большой heap. Возможно, приложение в реальности использует 700 MB, но память уже занята, а PostgreSQL и Redis остаются с меньшим запасом.

Для небольшого Spring Boot на VPS часто разумно начинать с меньшего -Xms и ограниченного -Xmx. Например:

-Xms512m -Xmx2g

Потом смотреть по метрикам: used heap, committed heap, GC pauses, RSS процесса, swap, OOM events, latency и нагрузку на базу.

GC tuning: не лечите медленный SQL настройками garbage collector

G1GC подходит для большинства современных Spring Boot-приложений и часто используется по умолчанию в современных JVM. Обычно не нужно начинать с десятков GC-флагов.

Что реально важно:

не держать heap слишком маленьким, если приложение постоянно делает Full GC;
не держать heap слишком большим, если серверу не хватает RAM;
не кэшировать без лимита;
не вытягивать из базы огромные списки в память;
не сериализовать гигантские JSON без контроля;
не запускать тяжёлые batch jobs в том же процессе, что обслуживает API, если они забивают память.

Если приложение тормозит, сначала проверьте SQL-запросы, размер ответов, кэши, Hibernate fetch strategy, N+1 queries, connection pool и external API. GC-флаги не исправят плохую архитектуру.

PostgreSQL и HikariCP: скрытая причина нехватки RAM

Spring Boot часто использует HikariCP как connection pool. Ошибка — поставить слишком большой pool “чтобы было быстрее”. Если приложение открывает 50 соединений к PostgreSQL на маленьком VPS, быстрее может не стать. Наоборот: база начнёт тратить больше памяти, CPU уйдёт на конкуренцию, а latency вырастет.

Для небольшого VPS часто достаточно небольшого pool. Например, стартовать с 5–10 соединений и смотреть метрики, а не ставить 50–100 без расчёта.

Что проверить:

spring.datasource.hikari.maximum-pool-size
число потоков web server;
количество background jobs;
число инстансов приложения;
лимит соединений PostgreSQL;
RAM, которую PostgreSQL тратит на соединения и запросы;
медленные SQL-запросы и индексы.

Если приложение упирается в базу, увеличение heap и числа threads не решит проблему. Оно просто отправит в PostgreSQL больше одновременной работы.

Redis на Spring Boot VPS: когда помогает, а когда только ест память

Redis часто добавляют в Spring Boot “для ускорения”. Это ошибка, если непонятно, что именно кэшируется и с каким TTL. Redis хранит данные в памяти. На VPS 4–8 GB он конкурирует с JVM и PostgreSQL за RAM.

Redis полезен, если используется для:

cache с нормальным TTL;
rate limiting;
distributed locks;
sessions, если приложение масштабируется;
очередей или временных данных, если вы понимаете риск потери;
снижения нагрузки на тяжёлые повторяемые запросы.

Redis опасен, если:

открыт на публичный IP;
нет пароля или ACL;
нет maxmemory;
не настроена eviction policy;
кэшируются большие объекты без TTL;
Redis используется как “база данных”, но backup и persistence не продуманы;
на одном маленьком VPS уже работают Java и PostgreSQL.

Для одного Spring Boot-приложения Redis обычно должен слушать localhost или приватный интерфейс. Открывать Redis наружу почти никогда не нужно.

Nginx перед Spring Boot: зачем он нужен

Spring Boot может сам слушать HTTP-порт, но в production на VPS часто ставят Nginx перед приложением. Это нормальная схема.

Nginx помогает:

принимать HTTPS и обновлять SSL;
делать reverse proxy на локальный порт Spring Boot;
отдавать static-файлы, если они есть;
ограничивать размер request body;
настраивать timeouts;
делать rate limiting на уровне web server;
не открывать Java-приложение напрямую в интернет.

Spring Boot можно слушать на localhost:

server.address=127.0.0.1
server.port=8080

А наружу открыть только 80 и 443 через Nginx. Это проще контролировать и безопаснее, чем выставлять Java-порт напрямую.

502 Bad Gateway: где искать проблему

Если Nginx показывает 502, это обычно значит, что Nginx не может подключиться к Spring Boot.

Типовые причины:

Spring Boot не запущен.
Приложение упало из-за ошибки конфигурации.
Java-процесс убит OOM killer.
Nginx проксирует не на тот порт.
Spring Boot слушает только другой интерфейс.
Firewall блокирует локальное соединение.
Приложение стартует слишком долго, а Nginx timeout слишком короткий.
После деплоя забыли перезапустить systemd-сервис.

Проверять нужно так:

systemctl status my-spring-app
journalctl -u my-spring-app -n 200 --no-pager
ss -lntp | grep java
nginx -t
tail -n 100 /var/log/nginx/error.log
dmesg -T | grep -i "killed process"

Если Java-процесс умер по памяти, перезапуск даст временный эффект. Нужно менять JVM limits, искать утечку, уменьшать pool, чистить кэш, добавлять RAM или выносить базу.

Actuator в production: полезно, но опасно открывать всем

Spring Boot Actuator полезен для health checks, metrics и диагностики. Но его нельзя бездумно открывать всему интернету. Некоторые endpoints могут раскрывать техническую информацию о приложении, окружении, метриках, beans, mappings и состоянии системы.

Для production обычно безопаснее:

оставить публичным только минимальный health endpoint, если он нужен load balancer или мониторингу;
закрыть остальные endpoints firewall, basic auth, VPN или internal network;
не публиковать env/config endpoints наружу;
подключить Prometheus/Micrometer только через защищённый доступ;
не считать health=UP полной гарантией, что бизнес-логика работает.

Health check может показывать UP, но приложение всё равно может быть медленным из-за базы, Redis, external API, GC pauses или переполненной очереди. Поэтому monitoring должен проверять не только “порт открыт”, но и реальные симптомы: latency, ошибки, RAM, GC, база, диск, SSL, логи.

Логи: Java может не упасть, но диск закончится

На VPS часто забывают про логи. Spring Boot пишет application logs, Nginx пишет access/error logs, systemd хранит journald, PostgreSQL пишет свои логи. Если нет rotation, диск может заполниться. После этого приложение начинает падать странно: база не пишет WAL, Java не может создать файлы, деплой не проходит, SSL не обновляется.

Что проверить:

logback/log4j2 rotation;
лимиты journald;
logrotate для Nginx и application logs;
уровень логирования в production;
нет ли DEBUG-логов на боевом трафике;
не логируются ли огромные request/response body;
не пишутся ли персональные данные в логи.

Для production не нужно писать всё подряд “на всякий случай”. Логи должны помогать диагностировать проблему, а не убивать диск и создавать риск утечки данных.

Heap dump: нужен, но может забить диск

Флаг -XX:+HeapDumpOnOutOfMemoryError полезен: при OutOfMemoryError JVM сохранит heap dump, и можно понять, что съело память. Но heap dump может быть размером в гигабайты. Если на VPS мало свободного места, dump может добить диск.

Если включаете heap dump, проверьте:

куда он пишется;
хватает ли места на диске;
есть ли доступ только у нужных пользователей;
не содержит ли dump персональные данные, токены, email, payload API;
как вы будете скачать и анализировать dump.

Heap dump — это инструмент диагностики, а не замена мониторингу.

Swap: спасение или источник тормозов

Небольшой swap на VPS может спасти от мгновенного убийства процесса при кратком всплеске памяти. Но swap не делает сервер быстрее. Если Java, PostgreSQL или Redis активно уходят в swap, API начнёт тормозить, GC-паузы станут длиннее, latency вырастет.

Swap полезен как страховка, но плох как постоянный режим работы. Если сервер регулярно использует swap под нагрузкой, проблема не решена. Нужно уменьшать потребление памяти или брать VPS с большим объёмом RAM.

Деплой Spring Boot: где чаще всего ошибаются

Плохой production-deploy выглядит так: залили новый JAR, убили старый процесс, запустили новый через SSH. Если что-то пошло не так, непонятно, какая версия работает, где логи и как откатиться.

Лучше иметь порядок:

Собрать JAR на CI/CD или локально в повторяемом окружении.
Загрузить JAR на сервер в release-директорию.
Сделать backup базы перед миграциями.
Применить миграции, если они есть.
Переключить symlink или заменить JAR контролируемо.
Перезапустить systemd-сервис.
Проверить health endpoint.
Проверить логи и HTTP-ответы.
Иметь понятный rollback на предыдущий JAR.

Если проект использует Flyway или Liquibase, миграции нельзя воспринимать как мелочь. На живой базе изменение схемы может заблокировать таблицы, долго создавать индексы или сломать совместимость старого и нового кода.

Миграции базы: опасная часть Spring Boot production

Spring Boot часто запускают вместе с Flyway или Liquibase. Это удобно, но опасно, если миграции применяются автоматически без контроля.

Опасные миграции:

изменение типа колонки на большой таблице;
создание индекса на большой таблице в рабочее время;
удаление поля, которое ещё использует старая версия приложения;
добавление NOT NULL без значения по умолчанию;
массовый UPDATE миллионов строк;
миграция, завязанная на внешние API или нестабильные данные.

Перед миграциями нужно иметь backup, staging-проверку и план rollback. Особенно если база находится на том же VPS и делит RAM/IO с Java-приложением.

Firewall и безопасность VPS для Spring Boot

Для обычного Spring Boot production-сервера наружу обычно нужны только:

22/tcp для SSH, лучше по ключам и с ограничением доступа;
80/tcp для HTTP и выпуска SSL;
443/tcp для HTTPS.

Не нужно открывать наружу PostgreSQL, Redis, Actuator admin endpoints, JMX, debug port, internal API, Grafana, Prometheus, RabbitMQ/Redis dashboards или прямой порт Spring Boot без необходимости.

Если проект связан с пользовательским контентом, массовыми регистрациями, mail, scraping, proxy, VPN-функциями, high-risk API или нестандартным трафиком, перед заказом нужно проверить условия использования и abuse policy: https://hostyrex.net/ru/terms.html.

Backup: что нужно сохранять у Spring Boot-проекта

Код обычно хранится в Git, но этого недостаточно. Для восстановления production нужны:

база данных;
uploads/media, если пользователи загружают файлы;
конфиги systemd;
application.yml/application.properties или production env;
Nginx-конфиги;
SSL-конфигурация;
Redis data, если там не только временный cache;
последний рабочий JAR или release-директория.

Минимальный backup-план:

ежедневный backup базы;
backup uploads/media;
backup конфигов;
хранение копий вне основного VPS;
retention: несколько копий, а не один перезаписываемый файл;
backup перед миграциями;
проверка восстановления на тестовом сервере.

Backup на том же диске, где работает приложение, — это не полноценная защита. При удалении VPS, ошибке пользователя, компрометации или проблеме с файловой системой можно потерять всё сразу.

Monitoring: что отслеживать у Spring Boot на VPS

Для Spring Boot на VPS нужно отслеживать не только “сайт открывается”. Минимум:

доступность HTTPS;
HTTP 500/502/504;
latency API;
RAM всего сервера;
RSS Java-процесса;
heap used/committed/max;
GC pauses;
CPU load;
swap usage;
свободное место на диске;
статус systemd-сервиса;
PostgreSQL connections и slow queries;
Redis memory и evictions;
успешность backup;
срок действия SSL.

Если monitoring показывает только ping, вы узнаете о проблеме поздно. Spring Boot может отвечать на health check, но уже терять реальные запросы из-за GC, базы, очереди или нехватки RAM.

Когда VPS 4–8 GB не подходит

VPS 4–8 GB — нормальный вариант для многих Spring Boot-проектов, но не для всех.

Лучше смотреть в сторону dedicated server или отдельной архитектуры, если:

приложение постоянно использует несколько GB heap;
есть тяжёлые batch jobs, отчёты, импорт/экспорт больших данных;
база активно пишет на диск и быстро растёт;
несколько Java-сервисов живут на одном узле;
есть Kafka/RabbitMQ/Elasticsearch/Redis/PostgreSQL на том же сервере;
есть high-load API и дорогой простой;
нужны гарантированные CPU-ресурсы;
нужна отдельная сеть, IP-подсеть, BGP или сложный firewall;
проект нельзя остановить на время миграций и обслуживания.

В таких случаях лучше рассматривать выделенный сервер: https://hostyrex.net/ru/servers.html. Если нужны отдельные IPv4, RDNS, подсети или сетевые задачи, смотрите страницу IPv4: https://hostyrex.net/ru/ip.html.

Что проверить перед заказом VPS под Spring Boot

Какая версия Java нужна проекту?
Spring Boot 2 или Spring Boot 3/4?
Сколько heap реально нужно приложению?
Будет ли PostgreSQL/MySQL на том же VPS?
Будет ли Redis?
Есть ли scheduled jobs, batch processing, reports?
Нужны ли WebSocket, SSE или long polling?
Сколько одновременных пользователей/API-запросов ожидается?
Какой HikariCP pool size нужен?
Как будут делаться миграции: Flyway, Liquibase, вручную?
Где будут храниться logs и heap dumps?
Какой backup нужен для базы и файлов?
Кто отвечает за обновления Java, Linux, Nginx и security patches?
Нужен ли managed support?
Какие порты должны быть открыты?
Есть ли требования к IP, локации, routing или abuse policy?

Если проект уже production, есть база, пользователи, Redis, миграции или риск простоя, не заказывайте VPS вслепую. Лучше заранее описать стек, размер базы, текущую RAM, heap, нагрузку, логи и требования к backup. Связаться с Hostyrex можно здесь: https://hostyrex.net/ru/contacts.html.

Короткий production checklist Spring Boot на VPS

Приложение запускается через systemd, а не вручную в SSH.
Используется отдельный Linux-пользователь для приложения.
JVM heap ограничен через -Xmx.
-Xmx не занимает почти всю RAM VPS.
Оставлен запас под ОС, PostgreSQL, Redis, Nginx, logs, backup и native memory.
Настроен HeapDumpOnOutOfMemoryError, но проверено место на диске.
PostgreSQL не открыт публично без необходимости.
Redis не открыт наружу.
HikariCP pool size не завышен.
Nginx проксирует HTTPS на локальный Spring Boot port.
Прямой Java-порт не торчит в интернет без необходимости.
Actuator endpoints защищены.
Логи имеют rotation.
Backup базы и файлов хранится вне основного VPS.
Миграции проверяются до production.
Monitoring отслеживает RAM, heap, GC, disk, database, Redis, HTTP errors и SSL.
Есть план rollback на предыдущий JAR.

Как Hostyrex может помочь с Spring Boot-проектом

Hostyrex предоставляет VPS для Spring Boot, Java API, backend-сервисов, CRM, SaaS MVP, приложений с PostgreSQL, Redis, Nginx, systemd, SSL, backup и monitoring. Для большинства Spring Boot-проектов разумный старт — VPS с 4–8 GB RAM, но точная конфигурация зависит от heap, базы, Redis, фоновых задач и ожидаемой нагрузки.

Если требования понятны, можно выбрать VPS здесь: https://client.hostyrex.net/store/vps.

Если проект уже работает у другого провайдера, падает по OOM, использует PostgreSQL/Redis, имеет миграции, очереди, batch jobs или риск простоя, лучше сначала описать задачу и согласовать конфигурацию. Для вопросов перед заказом используйте контакты: https://hostyrex.net/ru/contacts.html. Если нужно администрирование или перенос, смотрите managed services: https://client.hostyrex.net/store/managed-services.

FAQ

Можно ли разместить Spring Boot на VPS?

Да. Spring Boot нормально работает на VPS, если приложение запускается через systemd, JVM heap ограничен, Nginx настроен как reverse proxy, база защищена, есть backup, monitoring и понятный deploy-процесс.

Сколько RAM нужно для Spring Boot VPS?

Для небольшого production API обычно лучше начинать с 4 GB RAM. Если на том же VPS PostgreSQL, Redis, фоновые задачи и monitoring, практичнее смотреть на 6–8 GB RAM. Минимальные VPS подходят для теста, но не для стабильного production с Java и базой.

Почему Java съедает всю память на VPS?

Часто из-за слишком большого -Xmx, отсутствия лимитов, unbounded cache, большого HikariCP pool, тяжёлых запросов, Redis без лимита, batch jobs или memory leak. Также важно помнить, что JVM использует не только heap, но и native memory, metaspace, thread stacks, direct buffers и code cache.

Что поставить в Xmx на VPS 4 GB?

Нет универсального числа. Если на сервере только одно Spring Boot-приложение без локальной базы, можно тестировать 1.5–2 GB heap. Если на том же VPS PostgreSQL, Redis и Nginx, heap должен быть осторожнее. Ставить -Xmx3g на VPS 4 GB обычно рискованно.

Что поставить в Xmx на VPS 8 GB?

Для одного приложения часто начинают с 2–4 GB heap и смотрят метрики. Не стоит отдавать Java всю память, если рядом работают PostgreSQL, Redis, Nginx, backup и monitoring. Важно смотреть не только heap, но и RSS процесса, GC, swap и OOM events.

Почему Spring Boot падает после закрытия SSH?

Потому что приложение запущено вручную в терминале. Для production нужно оформить Spring Boot как systemd-сервис с автозапуском после reboot и нормальным restart.

Почему Nginx показывает 502 Bad Gateway?

Обычно Spring Boot не запущен, упал, слушает другой порт, был убит OOM killer или Nginx проксирует не туда. Проверяйте systemctl status, journalctl, ss -lntp, Nginx error log и kernel OOM logs.

Нужен ли Redis для Spring Boot на VPS?

Не всегда. Redis полезен для cache, rate limits, sessions, locks и временных данных. Но на маленьком VPS Redis может стать ещё одним потребителем RAM. Его нельзя открывать в интернет и нельзя использовать без лимитов памяти.

Можно ли держать PostgreSQL на том же VPS?

Да, для небольшого проекта это нормально. Но база должна иметь backup, ограниченный доступ, нормальные индексы и умеренный connection pool. Если база активно растёт или пишет на диск, лучше рассматривать отдельный сервер или dedicated architecture.

Нужно ли открывать порт Spring Boot наружу?

Обычно нет. Лучше держать Spring Boot на 127.0.0.1:8080, а наружу открывать 80/443 через Nginx. Так проще управлять SSL, firewall, rate limits и reverse proxy.

Можно ли использовать Actuator в production?

Да, но осторожно. Health endpoint и metrics полезны, но внутренние endpoints нельзя открывать всему интернету. Их нужно защищать авторизацией, firewall, VPN или внутренней сетью.

Почему Spring Boot health показывает UP, но приложение тормозит?

Health check может быть слишком простым. Приложение может отвечать UP, но иметь медленные SQL-запросы, GC pauses, переполненный Redis, нехватку соединений, swap или проблемы с внешним API. Нужен полноценный monitoring, а не только проверка одного URL.

Что спросить у провайдера перед заказом VPS под Spring Boot?

Уточните объём RAM, CPU, NVMe, локацию, IPv4, firewall, backup, условия по трафику, managed support, возможность мониторинга, reinstall, правила abuse policy и что делать, если проекту понадобится больше памяти или отдельный сервер под базу.

Категории