VPS Under Memory Pressure: Scale Up or Move Out?
A small e-commerce site runs on an OVHcloud VPS with 2 vCores, 4 GB RAM and an 80 GB SSD. MySQL 8, PHP-FPM and Redis share the host. Every day between 11:00 and 13:00 the load average reaches 6, the OOM killer terminates PHP workers, and MySQL logs memory-allocation failures. The 2 GB swap file is almost fully used and the disk is 78% full. The team takes one VPS snapshot per week and keeps two copies, which it calls 'the backup'. Traffic is expected to double in three weeks during a campaign. The application servers are stateless apart from MySQL and Redis; the database is 8 GB. Management wants the cheapest change that avoids downtime during business hours, and the operations team has a 30-minute maintenance window on Sunday. No monitoring is in place beyond a ping check.
1. Recommend what to change before the campaign and what to do in the Sunday window. Justify the order of operations and state what you would verify afterwards.
Read the worked answer
Treat this as a memory-budget and capacity problem, not a MySQL tuning problem. Immediately cap PHP-FPM pm.max_children so PHP cannot consume the box (roughly 35 workers at 40 MB each after reserving 1.5 GB for MySQL, 0.5 GB for Redis and 0.5 GB for the OS), set maxmemory and an eviction policy on Redis, and enable the slow-query log. Check binary logs and ibtmp1, because 78% disk can become a write stall before RAM does. In the Sunday window, resize to an 8 GB VPS, after taking a snapshot. Resizing usually requires a reboot, hence the window. Afterwards verify PHP-FPM and MySQL error logs, swap use, query latency, and run a load test at twice the current concurrency. Eight GB is a stopgap: if the 8 GB database working set does not fit in the buffer pool, or traffic keeps doubling, move MySQL to a managed database or a dedicated server. Do not simply raise innodb_buffer_pool_size on a 4 GB host.
2. A stakeholder says the weekly VPS snapshot is enough for disaster recovery. Assess that claim and propose a minimum viable backup plan.
Read the worked answer
The claim is wrong. A VPS snapshot is a rollback point on the same platform, typically a single snapshot slot, and restoring it replaces the disk. It gives a 7-day RPO, no granular table restore, no protection against account compromise, accidental VPS deletion or a platform-level incident, and no audit trail. It is useful before the resize, not as DR. Minimum viable: nightly logical mysqldump or a physical backup of the 8 GB database plus configuration and uploads to Object Storage, encrypted, with 30-day retention and a separate credential; keep a weekly full and daily incrementals. Monitor exit codes and alert on failure. Put the restore procedure in a runbook and do a quarterly restore into a scratch VPS, measuring RTO. If the business needs RPO under 24 hours, increase frequency or ship binary logs. The snapshot stays as a pre-change rollback.
3. What would you check about disk usage and MySQL before deciding whether 8 GB of RAM is sufficient?
Read the worked answer
Check df -h and du for MySQL binary logs, ibtmp1, general logs and PHP session files; purge binary logs to a defined retention and rotate logs. Check table sizes and the buffer-pool hit ratio; if the hot data is much larger than the pool, 8 GB will not fix I/O. Review SHOW GLOBAL STATUS for Created_tmp_disk_tables and slow queries. Check Redis used_memory and fragmentation. Establish peak concurrent users and requests per second from access logs. Then build a memory budget: OS 1 GB, MySQL 3 GB, PHP 2.5 GB, Redis 1 GB, headroom 0.5 GB. If the measured working set and peak concurrency fit, 8 GB is sufficient for the campaign; otherwise separate the database.