{"id":1129,"date":"2026-09-15T06:48:40","date_gmt":"2026-09-15T06:48:40","guid":{"rendered":"https:\/\/virtualserversvps.com\/blog\/?p=1129"},"modified":"2026-09-15T06:48:40","modified_gmt":"2026-09-15T06:48:40","slug":"mysql-innodb-buffer-pool-sizing-1gb-vps","status":"publish","type":"post","link":"https:\/\/virtualserversvps.com\/blog\/mysql-innodb-buffer-pool-sizing-1gb-vps\/","title":{"rendered":"Sizing the InnoDB Buffer Pool for a 1 GB VPS: The Arithmetic Nobody Shows You"},"content":{"rendered":"\n

The default MySQL configuration on most VPS images allocates `128M` to the InnoDB buffer pool. On a 1 GB instance running WordPress, that leaves roughly 700 MB of RAM idle while every `SELECT` that misses the pool goes to disk. Raising it is not guesswork \u2014 it is arithmetic with one hard ceiling and two soft ones. Here is the calculation, the configuration, and the counter readings that tell you when to stop.<\/p>\n\n\n\n

The One Number You Must Not Exceed<\/h2>\n\n\n\n

The buffer pool is not the only thing that uses RAM in a MySQL process. `innodb_buffer_pool_size` is the largest single allocation, and everything else in the process \u2014 per-connection buffers, the redo log, temporary tables, InnoDB internal structures \u2014 sits on top of it. Total RSS for a `mysqld` sized this way lands around `buffer_pool + 150\u2013250 MB` under light concurrency.<\/p>\n\n\n\n

VPS RAM<\/th>OS + web stack<\/th>Recommended pool<\/th>Expected mysqld RSS<\/th><\/tr><\/thead>
1 GB<\/td>~300 MB (nginx + PHP-FPM 4 workers)<\/td>384M \u2013 512M<\/td>560\u2013760 MB<\/td><\/tr>
2 GB<\/td>~500 MB<\/td>768M \u2013 1G<\/td>950 MB \u2013 1.25 GB<\/td><\/tr>
4 GB<\/td>~800 MB<\/td>2G \u2013 2.5G<\/td>2.2\u20132.9 GB<\/td><\/tr>
8 GB<\/td>~1.5 GB<\/td>4G \u2013 5G<\/td>4.3\u20135.5 GB<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n

The formula a DBA would write down: take `MemTotal`, subtract 350 MB for the kernel, SSH, systemd, and your monitoring agent, subtract the resident set of nginx plus PHP-FPM, subtract 200 MB of safety margin, and give the rest to the pool \u2014 capped at 75% of total RAM so page cache stays warm. On a 1 GB box that lands at 384\u2013512 MB.<\/p>\n\n\n\n

Confirm Your PHP-FPM Footprint First<\/h2>\n\n\n\n

Do not guess the web stack’s share. Measure it before you decide:<\/p>\n\n\n\n

# Real RSS of the components that compete with MySQL\nsudo systemctl restart php8.3-fpm nginx mysqld\nsleep 5\nps -eo rss,comm --sort=-rss | awk 'NR==1 || $1>5000{printf \"%-8.1f MB  %s\\n\", $1\/1024, $2}'\necho \"--- MemAvailable ---\"; awk '\/MemAvailable\/{printf \"%.0f MB\\n\", $2\/1024}' \/proc\/meminfo<\/code><\/pre>\n\n\n\n
PHP-FPM with 4 `pm.max_children` runs about 30\u201345 MB per worker for a typical WordPress stack, so 4 workers is 120\u2013180 MB. If you see 8 workers, your pool budget is gone and the correct fix is `pm.max_children = 4`, not a smaller buffer pool.<\/p>\n\n\n\n
Configuration That Actually Applies<\/h2>\n\n\n\n
# \/etc\/mysql\/mysql.conf.d\/zz-vps-tuning.cnf\n[mysqld]\ninnodb_buffer_pool_size         = 448M\ninnodb_buffer_pool_instances    = 1      # one instance per ~1 GB of pool\ninnodb_log_file_size            = 256M   # bigger = fewer checkpoints, faster writes\ninnodb_flush_method             = O_DIRECT\ninnodb_flush_log_at_trx_commit  = 2      # 1 = fully durable, 2 = ~1s loss window\ninnodb_io_capacity              = 2000   # NVMe; SSD ~800, spinning ~200\ninnodb_io_capacity_max          = 4000\ninnodb_read_io_threads          = 4\ninnodb_write_io_threads         = 4\ninnodb_buffer_pool_dump_at_shutdown = ON\ninnodb_buffer_pool_load_at_startup  = ON\ntmp_table_size                  = 32M\nmax_heap_table_size             = 32M\nperformance_schema              = OFF\n<\/code><\/pre>\n\n\n\n
`innodb_buffer_pool_instances = 1` matters more than people expect on small instances. Multiple instances each carry their own overhead and reduce the effective pool; the gain from splitting is only worth it above roughly 1 GB of pool. `performance_schema = OFF` recovers on the order of 150 MB of RSS on MySQL 8 \u2014 a meaningful amount when your pool is 448 MB.<\/p>\n\n\n\n
Changing `innodb_log_file_size` requires a clean shutdown of MySQL (with a clean `innodb_fast_shutdown=0`) or the server refuses to start with the new size. Do this during a maintenance window, not on a live box.<\/p>\n\n\n\n
The Three Readings That Tell You to Stop Tuning<\/h2>\n\n\n\n