WordPress建站VPS配置怎么选：按访问量算

一、WordPress卡在哪：先搞清楚内存被谁吃掉了

WordPress 站点慢，99% 的情况不是 CPU 不够，而是内存不够被逼着频繁走磁盘。搞清楚内存被谁吃掉，是选配置的第一步。

延伸对照：cloudcone 的公开机型与线路说明，可结合本节的判断标准自行核对。

一台跑 WordPress 的 VPS，内存被五个部分瓜分：操作系统内核与系统服务、PHP-FPM 进程池、MySQL 内存、Nginx 或 Apache、以及缓存进程（Redis 或 Memcached）。其中 PHP 和 MySQL 是两个大头，而且它们的占用是可配置的，不是固定的。

先看 PHP-FPM 的账。每个 worker 是一个独立进程，会加载自己的 PHP 运行库，典型 RSS 常驻内存 30 到 45 MB。1 GB 内存的机器去掉内核约 120 MB、Nginx 约 40 MB 之后，真正能分给 PHP 和 MySQL 的只剩 640 MB 上下。如果 PHP-FPM 按默认配置开 5 个 worker，光 PHP 就占掉 200 MB 左右；再给 MySQL 分 200 MB，缓冲池之外的连接、排序、临时表还要吃一部分，实际留给页面渲染的余量已经很薄。

MySQL 这边的账更复杂。InnoDB 缓冲池是它的核心，默认 innodb_buffer_pool_size 通常是物理内存的 50% 到 70%，1 GB 机器上就是 512 到 700 MB——这一项 alone 就能把机器吃干净。1 GB 机器跑 WordPress 必须把缓冲池压到 128 MB 上下，2 GB 机器可以给到 512 MB，4 GB 机器给到 1 GB 到 1.5 GB。

还有个关键点常被忽略：WordPress 的每个 PHP 请求都要加载整套主题和插件代码，这些代码在内存里的驻留部分由 OPcache 承担。关了 OPcache，PHP 每次请求都要重新解析全部 PHP 文件，CPU 开销大幅上升、响应时间明显变长；开了 OPcache，内存占用上升但 CPU 开销大幅下降。在 1 GB 机器上这两者需要权衡，通常的做法是 OPcache 给 32 MB 到 64 MB、PHP worker 减到 2 到 3 个。

内存占用要实测，不能靠估。不同 PHP 版本、不同插件组合下，同一份 WordPress 的实际占用能差出一倍多。可靠的做法是分别量 PHP 侧和数据库侧的常驻内存，再看系统还剩多少余量：

`bash

# 1) 按进程名统计常驻内存（RSS），找出真正的大户

ps -eo comm,rss --sort=-rss | awk 'NR==1{print "进程 RSS_MB"} NR>1 && $2>20000 {printf "%s %.0f\n", $1, $2/1024}'

# 2) 看系统整体水位与可用内存

free -m

# Mem 行的 available 列要留出至少 150 MB，否则 PHP 在峰值期会被 OOM Killer 干掉

# 3) 打开 WordPress 的内存显示，在后台页脚直接读峰值

# 在 wp-config.php 的 "That's all, stop editing" 之前加：

# define('WP_DEBUG', true);

# define('WP_DEBUG_DISPLAY', true);

# define('WP_MEMORY_LIMIT', '256M');

`

第三条命令里的 WP_MEMORY_LIMIT 很关键。WordPress 默认允许 PHP 用到 40 MB，一遇到大查询或大图片处理就直接报"Allowed memory size exhausted"。在 1 GB 机器上把它显式设成 256M，好处是失败信息更明确、不会突然 OOM；坏处是它并不能让机器变快，只是把崩溃点从随机变成可预期。有个容易忽略的细节：这个值设得比物理可用内存还大时，PHP 会以为自己还有空间，然后一路申请到系统把整台机器的内存吃光。

在 1 GB 机器上还要防一件更隐蔽的事：WordPress 的定时任务（wp-cron.php）在每次页面访问时被触发，一次批量操作可能同时拉起多个 PHP 进程，内存峰值瞬间翻倍。把它改成真正的系统定时任务，是 1 核 1G 站点最划算的一次优化。

二、1核1G 的真实边界：能跑什么，不能跑什么

1 核 1 GB 是 WordPress 建站最常被推荐也最常被高估的配置。把它说清楚，比含糊地说"轻量够用"有用得多。

延伸对照：digitalocean 的公开机型与线路说明，可结合本节的判断标准自行核对。

1 核 1 GB 的实际边界是这样的：纯文本内容、主题简洁、插件控制在 5 个以内、日 PV 在 500 以内、数据库不超过 300 MB、并且挂了页面缓存——这样的站点，1 核 1G 是能跑的，且前台 TTFB（首字节时间）大约在 300 毫秒到 800 毫秒之间（视线路质量）。一旦越过下面任意一条线，1 核 1G 就会开始出问题：

触发条件	1核1G 的表现	建议配置
插件超过 10 个	后台操作明显变慢，更新时容易 502	2核2G 起
装了 WooCommerce 或多语言/统计类重插件	购物车结算页超时	2核4G 起
日 PV 超过 1000	晚高峰开始出现排队和 502	2核2G 起
数据库超过 1 GB	MySQL 查询明显变慢	4核8G，数据库独立
多人同时后台编辑	后台保存时卡死	2核2G 起
需要跑 Redis + 队列任务	内存直接打满	2核4G 起

需要强调的是"日 PV 1000"这条线不是拍脑袋来的。按单次 PHP 页面渲染 90 毫秒计算，日 PV 1000 意味着平均每秒只有约 10 次请求，全天累计消耗约 90 秒 CPU 时间——单核完全够。瓶颈不在 CPU，而在内存与并发连接数：MySQL 默认最大连接数 151，每个活跃连接在 PHP 侧要占一个 worker，1 核 1G 配 3 个 worker 意味着并发上限只有 3。

再看几个换算：日 PV 2000 时，平均 CPU 占用约 0.21% 单核；日 PV 10000 时约 1.04% 单核；日 PV 50000 时约 5.21% 单核，且瞬时并发才是真正压力。所以"CPU 核数"这个指标在内容型 WordPress 上几乎永远过剩，真正需要匹配的是内存、磁盘 IOPS 和网络带宽。

三、按日 PV 反推配置：一张可以直接用的对照表

选配置的正确顺序是：先定日 PV 区间，再定插件重量，最后定缓存策略。这张表是给内容型站点（不含电商）的反推口径。

延伸对照：hostwinds 的公开机型与线路说明，可结合本节的判断标准自行核对。

日 PV 区间	推荐配置	插件数量上限	缓存策略	数据库规模
500 以内	1核1G	5 个以内	页面缓存插件 + 无 Redis	300 MB 以内
500 – 2000	2核2G	10 个以内	页面缓存 + Redis 可选	1 GB 以内
2000 – 10000	2核4G	15 个以内	Redis/Memcached + 对象缓存	3 GB 以内
10000 – 50000	4核8G	20 个左右	Redis 持久化 + CDN + 分层缓存	8 GB 以内
50000 以上	4核16G 起，数据库独立	需评估插件架构	CDN + 多级缓存 + 读写分离	20 GB 以上

这张表有两个使用提醒。第一，表格里的 PV 是"页面浏览量"而不是"请求数"。一个页面如果有 20 个图片请求，实际 HTTP 请求数是 PV 的 20 倍，但静态资源由 Nginx 直接返回、不吃 PHP 内存，所以对配置的影响主要还是看 PV。第二，如果你的站点有大量后台操作（每天几百次编辑、批量导入、插件更新），要在表格基础上往上跳一档，因为后台操作是同时加载多个插件和整份 wp-config 的重操作。

补充一条选型原则：磁盘一定选 SSD/NVMe。MySQL 的 InnoDB 缓冲池再大也放不下整个库，一旦触发磁盘 IO，1 核机器的随机读延迟就能让 TTFB 翻几倍。这也是为什么同样是 2 GB 内存，NVMe 机器的实际体验能接近 4 GB 内存的机械盘机器。

磁盘这件事可以用一条命令量化出你的站点到底是 CPU 瓶颈还是 IO 瓶颈。MySQL 有一个统计视图专门记录按顺序读取和随机读取的等待时间，两者差值大就说明索引没建好、查询在扫表：

`bash

# 1) 读 InnoDB 的 IO 等待统计（innodb_log_waits 累计值会持续增长）

mysql -e "SHOW ENGINE INNODB STATUS\G" | grep -E "log_waits|pending|avg_wait"

# 2) 看磁盘本身的读写延迟与队列深度

iostat -xz 1 3 2>/dev/null || vmstat 1 3

# 3) 看 MySQL 实际在读哪些文件（前 10 个）

lsof -p $(pgrep -x mysqld) 2>/dev/null | grep -E "\.ibd|ib_logfile|ibdata" | awk '{print $NF}' | sort | uniq -c | sort -rn | head -10

`

第 2 条命令里，如果 wa（iowait）长期超过 10，说明磁盘是瓶颈，此时升核数没有意义，要换盘或者把数据库分离；如果 wa 低于 3% 而 us 也不高，CPU 也没饱和，那就是 PHP 层的问题——通常是插件多、缓存没开或数据库连接配置不合理。

网络这一项对 WordPress 的影响常被低估。用户加载一个页面，浏览器要发起 HTML 请求加上十几个静态资源请求，虽然静态资源由 Nginx 直接返回不吃 PHP，但每一个请求都要走一次 TCP 握手（TLS 还要多一次）。跨国链路上每一次握手的延迟都会被放大。经验是静态资源走 CDN 之后，源站只需要处理 HTML 请求，跨境链路的请求数能减少到原来的十分之一以内，这对源站的带宽压力和响应时间都是双重的改善。

如果参考公开的产品线做价格换算，境外一条带结构化套餐的产品线入门款是 19.99 美元每月、2 核 1 GB 内存、20 GB 硬盘、500 Mbps 端口、每月 1024 GB 流量；同系列 2 GB 内存档是 29.99 美元每月、3 核 2 GB、40 GB 硬盘、2048 GB 流量；4 GB 内存档是 39.99 美元每月、4 核、80 GB 硬盘、3072 GB 流量。另一条年付产品线入门款 200 美元一年、2 核 2 GB 内存、40 GB 硬盘、2000 Mbps 端口、每月 5000 GB 流量，折合月均约 16.67 美元。价格随商家与活动变动，实际以官网当日报价为准。

四、PHP-FPM 怎么调：pm 模式与 worker 数量的关系

PHP-FPM 的 pm 模式选错，是"内存明明够却莫名 OOM"的头号原因。三个模式的区别直接决定峰值内存。

延伸对照：interserver 的公开机型与线路说明，可结合本节的判断标准自行核对。

static 模式：启动时固定开 N 个 worker，每个请求结束也不回收。内存占用最高但最稳定，无进程创建开销。适合内存充裕（4 GB 以上）、并发稳定的场景。

dynamic 模式：平时保持 pm.min_spare_processes 个 worker，来了请求就扩到 pm.max_spare_processes，流量高峰后再收缩回 min。灵活性最好，但进程创建有开销，且收缩行为在多数发行版的 PHP 7.4/8.x 里并不总是及时，这正是内存占用看起来"降不下来"的原因。

ondemand 模式：没有请求就不保留进程，用完即销毁。内存最低，但每个请求都要新建进程，CPU 开销明显，且在高并发下会出现进程创建风暴。

对 WordPress 站点，1 GB 机器的推荐配置是 dynamic 模式、最多 3 个 worker、最少 1 个空闲 worker。这个组合的依据是：3 个 worker 对应约 120 到 135 MB 的 PHP 常驻内存，加上 OPcache 32 MB 约 150 MB；剩下约 490 MB 给 MySQL（缓冲池 128 MB 起步）和系统冗余，留出了 OOM 缓冲。2 GB 机器可以放到 6 个 worker，4 GB 机器可以放到 10 到 12 个 worker。

改完配置后怎么验证有没有生效，看这两条：

`bash

# 1) 看当前生效的 pm 模式与 worker 数

grep -E "^pm(\.|$)" /etc/php/8.2/fpm/pool.d/www.conf

# 2) 重载后查看实际进程数与每个 worker 的常驻内存

systemctl reload php8.2-fpm

ps -o pid,rss,cmd -C php-fpm8.2 | awk 'NR==1{print "PID RSS_KB CMD"} NR>1{printf "%s %6.0f %s\n",$1,$2/1024,substr($0,index($0,$3))}'

`

第二条命令输出的 RSS 列如果每个 worker 都在 40 MB 上下，那你的估算就成立；如果明显更高，说明有插件在初始化时加载了大量数据，需要回头查具体是哪个插件。

五、OPcache 调参：代码缓存能给多少加速

OPcache 是 WordPress 站点性价比最高的一个优化，它缓存的是编译后的 PHP opcode，省掉的是每次请求的解析与编译开销。

延伸对照：itldc 的公开机型与线路说明，可结合本节的判断标准自行核对。

三个关键参数。opcache.memory_consumption 是 OPcache 分配的内存，单位 MB，64 到 256 之间是常见区间。opcache.max_accelerated_files 是缓存文件数上限，WordPress 加上插件主题通常有几千到上万个 PHP 文件，这个值设太小会出现大量 cache miss，缓存等于白开。opcache.validate_timestamps 控制是否检查文件修改时间，设为 0 表示不检查、性能最好，但每次改代码或更新插件后必须手动重载 OPcache。

一个经验换算是：64 MB 的 OPcache 大约能装下四百万行左右的 PHP 代码量（按每行约 15 字节的编译结果估算），对绝大多数 WordPress 站点绰绰有余，真正的瓶颈通常不是 OPcache 内存，而是 max_accelerated_files 太小。

1 GB 机器的推荐值是 memory_consumption 设 32、max_accelerated_files 设 10000；2 GB 机器可以给 64 和 20000；4 GB 机器给 128 和 30000。validate_timestamps 在生产环境建议设为 0，配合每次更新后手动 reload。

`bash

# 1) 看当前 OPcache 的实际命中情况

php -r 'var_dump(opcache_get_status(false));' 2>/dev/null | grep -E "memory_usage|opcache_enabled|cached_scripts|hit_rate|miss_rate"

# 2) 生产环境改配置后重载并确认命中率

echo "opcache.validate_timestamps=0" > /etc/php/8.2/fpm/conf.d/99-opcache.ini

systemctl reload php8.2-fpm

`

第一条命令里 hit_rate 与 miss_rate 是判读的关键。如果 miss_rate 明显偏高，先检查 max_accelerated_files，而不是去加内存。

还有一个被忽视的收益：OPcache 对后台操作（后台列表页、文章编辑页）的加速比对前台的加速更明显，因为后台一次要加载几十个插件文件，解析成本被放大了好几倍。很多人觉得"后台慢但前台不慢"，根源就在这里。

如果嫌改配置文件麻烦，OPcache 也可以在 wp-config.php 或一个 mu-plugin 里直接设。但要注意生效顺序：写在 wp-config.php 里的 ini 设置必须在 PHP 启动阶段生效才有效，如果是通过 ini_set() 在运行时调用，很多选项是不会生效的，尤其是 memory_consumption 和 max_accelerated_files 这类分配内存和文件句柄的参数。判读的方法很简单，改完之后跑一次状态查询看数值有没有变：

`bash

# 对比配置前后的实际生效值（改完 reload 之后再跑一次，数值应当变化）

php -r 'echo "mem=", ini_get("opcache.memory_consumption"),

" files=", ini_get("opcache.max_accelerated_files"),

" validate_ts=", ini_get("opcache.validate_timestamps"),

" enabled=", (int)opcache_get_status(false)["opcache_enabled"], PHP_EOL;'

`

顺便把 WordPress 侧的清理动作也做了。启用 validate_timestamps=0 之后，改代码、更新插件、切换主题都不会被自动感知，必须手动清理 OPcache 缓存。这一步忘了的话，站点会一直跑着旧代码，而且没有任何报错，是很典型的"改了半天没生效"的原因。

`bash

# 重置 OPcache（改代码 / 更新插件 / 换主题之后执行）

curl -s "https://www.yourdomain.com/wp-admin/admin-ajax.php?action=opcache_reset" || \

php -r 'opcache_reset(); echo "opcache reset ok\n";'

# 重置 WP 对象缓存与页面缓存

wp cache flush

wp transient delete --all 2>/dev/null

`

六、MySQL 调参：缓冲池是最关键的一个数

MySQL 的调参看起来复杂，但对 WordPress 站点真正有效的只有几个。

延伸对照：iwebfusion 的公开机型与线路说明，可结合本节的判断标准自行核对。

innodb_buffer_pool_size 是最重要的一个。它是 InnoDB 的数据页缓存，是数据库性能的主要来源。1 GB 机器上不能留默认值，必须压到 128 MB；2 GB 机器用 512 MB；4 GB 机器用 1 GB 到 1.5 GB。经验比例是：机器总内存的 50% 到 60%，但要在给 PHP-FPM 和系统留够余量的前提下定。

innodb_log_buffer_size 控制日志缓冲，默认 16 MB，对多数站点够用，大事务时可以调到 32 MB 或 64 MB。

max_connections 决定并发上限。WordPress 站点通常每个 HTTP 请求开一个连接，页面加载时如果启用了对象缓存可能同时开两三个连接，所以这个值至少要大于 PHP-FPM worker 数量的 2 到 3 倍。1 GB 机器配 3 个 worker 时，max_connections 设 30 到 50 就够，设成默认的 151 只会让内存峰值不可控。

tmp_table_size 和 max_heap_table_size 影响 WordPress 里那些带 GROUP BY 的查询，超出后会落磁盘变成临时表。站点装了统计类插件后这些查询会变多，两个值至少给到 64 MB。

`bash

# 1) 生成推荐配置（按 2G 内存机器的典型值示例，改完按实际内存调整）

cat > /etc/mysql/conf.d/wordpress.cnf <<'EOF'

[mysqld]

innodb_buffer_pool_size = 512M

innodb_log_buffer_size = 32M

max_connections = 50

tmp_table_size = 64M

max_heap_table_size = 64M

slow_query_log = 1

long_query_time = 1

EOF

# 2) 校验配置语法后重启（--verbose --help 是 MySQL 8 的语法检查方式）

mysqld --verbose --help 2>/dev/null | grep -E "^(innodb_buffer_pool_size|max_connections)" | head -5

systemctl restart mysql

# 3) 确认缓冲池真的生效，并看慢查询有没有起来

mysql -e "SHOW VARIABLES LIKE 'innodb_buffer_pool_size'; SHOW VARIABLES LIKE 'max_connections';"

ls -lh /var/log/mysql/mysql-slow.log 2>/dev/null

`

第三条命令的慢查询日志是后续优化的入口。打开 slow_query_log 之后跑一天，再看哪些语句最慢，才知道该加索引还是该换插件。

顺便提一个统计口径：慢查询日志默认只记超过 1 秒的语句，WordPress 后台的操作经常在 0.3 到 0.8 秒之间，不会被记进去，但用户主观上已经觉得卡。所以看慢查询日志的同时，也要看 PHP 层的耗时分布。

七、缓存分层：页面缓存、对象缓存、CDN 各管什么

缓存不是越多越好，而是要分清层。搞混层的直接后果是缓存互相打架，或者叠加后 CPU 反而变高。

延伸对照：racknerd 的公开机型与线路说明，可结合本节的判断标准自行核对。

第一层是 CDN 缓存，缓存对象是静态资源（图片、CSS、JS、字体）。它不碰 PHP，也不需要服务器内存。WordPress 站点开启后应该至少把 uploads 目录和静态资源目录交给 CDN，并给带版本号的静态文件设置长 TTL（一年），HTML 页面设短 TTL（不缓存或 60 秒）。这一层对 1 核 1G 的机器是救命的一层，因为它直接消掉了图片请求。

第二层是页面缓存（也叫全页缓存），缓存对象是完整的 HTML 输出。它把整个 PHP 渲染过程整个跳过，命中时 PHP 根本不参与，CPU 和内存消耗几乎为零。WordPress 生态里常见的实现有 WP Super Cache、W3 Total Cache、LiteSpeed Cache。判断它是否真的在生效，看响应头里有没有 X-Cache、X-Litespeed-Cache 之类的标记，以及用一个不存在的参数去访问看是否被绕过。

第三层是对象缓存，缓存对象是数据库查询结果（WordPress 的 wp_options、post meta 这类）。它需要常驻进程，所以要 Redis 或 Memcached。2 GB 以下内存的机器加 Redis 是净负担——Redis 自身常驻 50 到 100 MB，等于吃掉十分之一的内存去省一点数据库查询。只有当数据库查询确实是瓶颈时（慢查询日志显示同一条 SQL 反复出现）才值得上。

判断该上哪一层，看这三个信号：

`bash

# 1) 看缓存命中：HTML 页是否被缓存命中

curl -sI "https://www.yourdomain.com/" | grep -iE "x-cache|x-litespeed|cache-control|age:"

# 2) 看 PHP 耗时与缓存状态

curl -s -o /dev/null -w "TTFB=%{time_starttransfer}s total=%{time_total}s\n" "https://www.yourdomain.com/"

# 3) 看数据库慢查询（需先开 slow_query_log）

tail -20 /var/log/mysql/mysql-slow.log 2>/dev/null | grep -E "Query_time|SELECT" | head -10

`

第 2 条命令的 TTFB 如果是 200 毫秒以下且 total 与 TTFB 接近，说明页面缓存命中；如果 total 明显大于 TTFB，说明页面生成慢，瓶颈在 PHP 或数据库。

层与层的分工，落到实践上就是：1 核 1G 只做 CDN + 页面缓存，不要 Redis；2 核 2G 加 Redis 作为可选；2 核 4G 以上再考虑对象缓存持久化。

八、插件才是真正吃内存的东西：怎么逐个测

同样是 2 GB 内存的机器，插件装得不一样，内存占用能差出一倍。WordPress 官方插件目录里那几万个插件，有的在后台页面上会一次加载几十兆的数据。

延伸对照：justg 的公开机型与线路说明，可结合本节的判断标准自行核对。

内存消耗的大户通常有这几类：统计与访客分析类（要在数据库里记录每次访问，长期看是数据库膨胀的主要来源）、备份类（要在 PHP 进程里读写整个数据库文件）、安全类扫描插件（每次请求都要扫描全部文件）、页面构建类（可视化编辑器把大量 JSON 塞进内存）、以及导入导出类（一次性把 CSV 读进内存）。

找出到底是哪个插件在吃内存，方法很直接：逐个停用并测量。WordPress 有个健康检查工具 WP Health Check 可以做不改变站点状态的插件排查，但更可靠的是直接量内存：

`bash

# 1) 记录当前内存峰值（wp-config.php 里启用 WP_DEBUG 之后可在页脚看到）

wp eval 'echo "peak=" . memory_get_peak_usage(true) . " current=" . memory_get_usage(true) . PHP_EOL;'

# 2) 逐个停用插件并对比峰值内存

wp plugin list --status=active --field=name | while read p; do

wp plugin deactivate "$p" --quiet

m=$(wp eval 'echo memory_get_peak_usage(true);' 2>/dev/null)

echo "$p $m"

done

# 3) 批量恢复

wp plugin activate --all

`

第 2 条命令逐个停用并记录峰值内存，输出里排名靠前的几个就是内存大户。测完记得用第 3 条全部恢复。

还有几个间接的判断方法。看后台的加载时间比前台慢多少，能看出后台组件的重量；看数据库里 wp_options 表的行数和 autoload 字段，非自加载（autoload=no）的选项越多，说明插件把数据存得很碎；看 uploads 目录大小和数据库大小比，如果数据库远大于预期，多半是统计类插件在写日志。

一个实用的原则：插件数量控制在 10 个以内，且每加一个插件就重测一次内存峰值。超过 20 个插件时，2 核 2G 就该往 2 核 4G 走了。

九、升级路径：什么信号说明该升配了

配置不是一次定死的。下面几个信号出现时，说明当前机器已经到了该升配的边界，而不是该继续压参数。

延伸对照：spinservers 的公开机型与线路说明，可结合本节的判断标准自行核对。

信号一：内存使用率长期超过 80%。用下面这条命令连续观察，它会每小时采样一次并记录。

`bash

# 每小时记录一次内存水位，跑一天再看曲线

for i in $(seq 1 24); do

used=$(free -m | awk '/^Mem:/{print $3}')

total=$(free -m | awk '/^Mem:/{print $2}')

echo "$(date '+%m-%d %H:%M') ${used}M/${total}M $(awk -v u=$used -v t=$total 'BEGIN{printf "%.0f%%", u*100/t}')" >> /tmp/mem.log

done

cat /tmp/mem.log

`

判读方法：看峰值出现在哪个时段。如果峰值集中在每天固定的一两个小时（通常是定时任务、备份、批量发布的时间），说明是任务型负载，加内存不如把任务挪到低峰期或改成外部执行；如果全天都在 70% 以上，说明是常态型负载，该升配了。

信号二：数据库慢查询日志里出现大量耗时超过 1 秒的语句，且这些语句走的是全表扫描。这说明数据量已经超出单机的合理承载，该做的是加索引、分表，或者把数据库拆到独立服务器。

信号三：页面缓存命中率在高峰时段掉到 50% 以下。原因是 PHP worker 全部被占满，来不及生成缓存页就超时了，这时候加机器的收益是立竿见影的。

信号四：后台保存文章时出现 502 或超时。502 的典型原因是 PHP-FPM 达到 max_children 后队列溢出，Nginx 拿不到上游响应直接返回错误。这类问题在 1 核 1G 上极其常见。

`bash

# 看 502 的来源与 PHP-FPM 的排队情况

grep -c "upstream timed out\|connect() failed" /var/log/nginx/error.log 2>/dev/null

tail -50 /var/log/php8.2-fpm.log 2>/dev/null | grep -iE "max_children|server reached|slow|ready"

grep -E "^pm.max_children|^pm.max_requests" /etc/php/8.2/fpm/pool.d/www.conf

`

升级路径本身也是有讲究的。内存不够时，优先考虑升到 2 核 2G 而不是加 CPU，因为 WP 的瓶颈几乎总是内存和 IO 而不是算力。数据库成为瓶颈时，把数据库独立出来（同一台物理机的另一个 VPS，用内网或 127.0.0.1 加端口连接，或者用同一台机器的独立 MySQL 实例）比整机升配更划算，因为数据库的内存需求和 PHP 的内存需求是两条独立的曲线。

十、选型决策表与常见问题

先看决策表。按这三个问题依次定位，能得到具体配置。

你的情况	选择	理由
日 PV 500 以内，5 个插件以内	1核1G + CDN + 页面缓存	CPU 大量过剩，内存是唯一约束
日 PV 2000 左右，10 个插件	2核2G，OPcache 64MB，缓冲池 512MB	兼顾并发上限与缓存余量
有 WooCommerce 或会员系统	2核4G 起，数据库独立	结账流程内存峰值高
大量图片与附件	2核2G + 对象存储 + CDN	磁盘和带宽是瓶颈，不是 CPU
定时的批量任务、备份占资源	2核2G + 任务错峰	峰值型负载，调参比升配便宜
多人协作编辑的后台团队	2核4G	后台操作是重操作路径
要跑 Redis 与队列	2核4G 起	Redis 常驻 50–100 MB
已有 1核1G 想省钱撑住	加 CDN + 页面缓存 + 插件砍到 5 个	先榨干缓存层再谈升配
预计半年内流量翻十倍	直接 4核8G 并预留扩展	迁移一次的隐性成本高于提前配置

这张表的用法是从上往下看，第一行匹配得上的就是起点；多行同时匹配时取配置最高的那一行。理由列解释了每一条为什么这样配，遇到参数调整的疑问可以回到对应章节。

1核1G 能装几个 WordPress 插件？ 控制在 5 个以内比较稳，超过 10 个后台就会明显变慢。一个可用的粗略标准是：把插件停到只剩必须的几个，再逐个加回来，每加一个测一次内存峰值，超出 400 MB 就该停手或者升配。

2核2G 和 4核2G 买哪个？ 买 2核2G。WordPress 内容站的瓶颈几乎在内存而不在算力，空出来的两个核可以留给数据库、Redis、定时任务这些确实吃 CPU 的组件。核数只有在数据库要跑在同一台机器上、或者有图片批处理这类重任务时才有价值。

磁盘 40 GB 够用吗？ 取决于上传量。纯文字内容站，数据库 1 GB 以内、媒体库 5 GB 以内的话，40 GB 绰绰有余。但要注意 WordPress 备份插件会迅速吃掉空间——每次备份一份完整数据库和 uploads，累积起来很快，磁盘写满会让 MySQL 直接挂掉。

需要独立 IP 吗？ 站点配置上没有硬性要求，但独立 IP 有三个实际价值：SSL 证书可以用 IP 直接签、邮件服务器的送达率不会被共享 IP 拖累、以及站点被误判黑名单时能换 IP。搭企业站或发交易邮件的站点建议要。

选哪个地区的节点？ 主要看你的用户在哪。国内用户为主的站点选香港、日本、新加坡这些近距离节点，晚高峰时延和丢包明显好于欧美；用户分布在全球的选美西或欧洲，WordPress 站点通常还会再套一层 CDN，源站位置的影响会被削弱。

面板用宝塔还是 1Panel 还是手工装？ 手工装最省内存，LNMP 一套跑起来通常只占 500 MB 左右；宝塔面板本身加上它的插件栈大约要吃 300 到 500 MB，1 核 1G 的机器上装了面板基本就等于装满了。内存紧张的机器建议用 Docker 加现成镜像，或者直接手工装。

带宽和流量额度怎么估？ 端口速率决定的是页面加载速度，流量额度决定的是能不能一直跑满。以每月 1024 GB 的额度为例，平均到每天只有 34 GB，对应持续带宽不到 0.3 Mbps，对内容站来说非常宽裕。真正需要大额度的是做下载站、视频站、镜像站这类业务。

数据备份怎么做才安全？ 三层。数据库用 mysqldump 定时导出到对象存储，不要留在本机磁盘；上传文件用 rsync 或商家快照功能同步；WordPress 自身的备份插件只作为第四层，因为它在内存紧张的环境里反而可能成为压垮机器的原因。最关键的一条是：备份文件不能只存在同一台机器上。

以后想扩容，是升配还是迁移？ 如果商家支持在同一台物理机上升级套餐（多数 KVM 商家支持），升配几乎无损，几分钟完成。迁移到另一台机器则要重新解析 DNS、重新配置环境，隐性成本高。所以优先选支持原地升配、且快照功能完善的商家。