按您的档位配置数据库内存
VDS-1…VDS-6 对应的 PostgreSQL 和 MySQL 具体缓冲区数值，以及在数据库、应用和系统之间分配内存的规则。
更新于 2026年8月23日
默认数据库设置是为了在任何环境下都能启动，而不是为了跑得快。在 8 GB 内存的 VDS-3 上，PostgreSQL 开箱即用只使用 128 MB 作为缓存——这意味着它几乎什么都从磁盘读取，尽管它本可以从内存中读取。
分配原则
大致按以下比例划分该档位的内存：
- 系统和服务进程——10–15%；
- 应用程序（PHP-FPM、Node、gunicorn）——按 worker 数量分配；
- 数据库——剩下的全部，但不超过总内存的 60–70%。
绝不要把全部内存都给数据库：系统会进入 swap，NVMe 也帮不了您——延迟会增长数十倍。
当前已用内存：
free -h
ps -eo pmem,rss,comm --sort=-rss | head
一小时、一天、一周和一个月的内存图表可在面板 /hosting/vds/m/<id> 的“概览”中查看——它们显示的是真实峰值，而不是当前时刻。
PostgreSQL
/etc/postgresql/17/main/postgresql.conf：
| 档位 | shared_buffers | effective_cache_size | work_mem | maintenance_work_mem | max_connections |
|---|---|---|---|---|---|
| VDS-1 (2 GB) | 384MB | 1GB | 8MB | 96MB | 40 |
| VDS-2 (4 GB) | 1GB | 2GB | 12MB | 256MB | 60 |
| VDS-3 (8 GB) | 2GB | 5GB | 16MB | 512MB | 100 |
| VDS-4 (16 GB) | 4GB | 10GB | 24MB | 1GB | 150 |
| VDS-5 (24 GB) | 6GB | 16GB | 32MB | 2GB | 200 |
| VDS-6 (32 GB) | 8GB | 22GB | 48MB | 2GB | 250 |
再加上通用的 NVMe 设置：
random_page_cost = 1.1
effective_io_concurrency = 200
work_mem 是按每次排序操作分配的，而不是按每个连接：一百个带复杂排序的并行查询会把它成百倍地放大。不要设置得太高。
应用方式：systemctl restart postgresql（修改 shared_buffers 必须重启）。
MySQL 和 MariaDB
| 档位 | innodb_buffer_pool_size | innodb_log_file_size | max_connections |
|---|---|---|---|
| VDS-1 | 512M | 128M | 60 |
| VDS-2 | 1G | 256M | 100 |
| VDS-3 | 3G | 512M | 150 |
| VDS-4 | 8G | 1G | 200 |
| VDS-5 | 12G | 1G | 250 |
| VDS-6 | 18G | 2G | 300 |
innodb_flush_method = O_DIRECT
innodb_flush_log_at_trx_commit = 1
innodb_io_capacity = 2000
缓冲池是主要参数：如果它能容纳工作数据集，磁盘几乎不会被读取。
检查效果
SELECT sum(blks_hit)*100/sum(blks_hit+blks_read) FROM pg_stat_database;
对于 MySQL，请查看 SHOW ENGINE INNODB STATUS 以及 Innodb_buffer_pool_reads 与 Innodb_buffer_pool_read_requests 的比值。缓存命中率低于 95% 意味着数据库内存不足。
常见错误
| 现象 | 原因 |
|---|---|
| 修改后数据库无法启动 | 请求的内存超过了可用内存——请检查日志 |
| 进程被 OOM 杀死 | 数据库、应用程序和系统加起来超过了该档位的内存 |
| “优化”后反而变慢了 | work_mem 设置得太高，机器正在使用 swap |
| 磁盘持续被读取 | 缓冲区太小，工作数据集放不下 |
如果调整内存后仍然撞墙，问题在于数据量，而不是配置。您只能升级套餐，并按已付费期限的剩余天数按比例补差价；不支持降级，所以请慎重选择下一档位。