2026-11-13 11:57:51 k73游戏之家 作者：testai
WordPress 入门容易，站点一多就开始难受。插件更新、主题冲突、备份、证书续期，一套一套地重复，手上只有一台机器时很容易变成十几个后台挨个登录。多站点模式能把管理收拢到一处，但它对机器的要求和单站不一样，CPU、内存、磁盘随机读写、并发连接的分布都会变。这篇聊多站点到底吃什么资源、一台机器能挂多少站、缓存和对象存储怎么配合。
PHP 进程是第一项。每个请求都要起一个 PHP 工作者去执行代码，站点越多，同一时间要服务的请求越多，需要的进程数就越多。进程不是免费的，每个都占几十 MB 内存，开多了内存就被吃满，机器开始用交换分区，响应时间直接翻倍。
数据库是第二项。多站点模式下所有站点共用一个库，表按站点前缀分开，表数量会随着站点数量线性增长。表多了之后，数据库的连接数、缓冲池、元数据缓存都会吃紧，单看一个站的负载不高，加起来就不一样了。
磁盘随机读写是第三项，也最容易被低估。WordPress 每次加载都要读插件文件、主题文件、缓存文件，这些是大量小文件的随机读。机械盘在这种场景下会被拖到几十毫秒的响应时间，站点打开就是一个白屏等半天。
上行带宽看用途。如果站点主要是文字和图片，流量不算大；如果挂了下载、视频、大图库，上行会被跑满，页面里的图片加载变慢，用户感知很明显，这种情况加带宽没用，得先把媒体文件挪到别的机器上。这一项跟配置的关系不大，跟业务类型关系更大。
定时任务和备份也占资源。多站点的备份往往是整库导出，几百兆的数据库导一次要几分钟，这期间磁盘 IO 会被占住。把它安排在深夜，或者先导到一台独立的中转机上，能避免前台被拖慢。导出前先压缩旧日志，体积能小一截。
多站点的好处是升级维护只做一次。插件、主题、核心版本统一更新，不用十几个后台逐个点；用户体系也能共用，一个人在你的多个站点里是同一个账号。省下的是重复劳动，换来的是耦合，这套账要提前算清楚，站点之间耦合得越深，后期把某个站拆出去的难度就越大，拆分前要把用户和订单数据单独导一次做验证，别等拆完才发现关联有问题，那时候回滚的成本会翻好几倍，预演一次能把大部分坑提前发现。
耦合的风险在于一个插件出问题，全部站点一起白屏。独立站的好处正是隔离，一个站崩了不影响别人，坏处是维护量翻倍，安全补丁要打十几次，漏掉一个就是缺口，多站点把这件事从十几次压到一次，正是它最实在的好处。代价是每次升级都要先在测试环境验一遍，不能直接在生产上点更新，测试环境可以就是同一台机器上另一个站点，代价很小，验证完再同步到生产。
怎么选看站点性质。同一品牌下的多个语言站、多个地区站，内容结构接近，多站点合适；客户各自独立、插件需求差别大的站，分开部署更稳，宁可多花点机器钱也别把风险绑在一起，隔离的价值在出事那天才看得见，在此之前只觉得是多花了钱，这笔钱买的是不连带受损，值不值取决于单站出事的损失有多大，客户站尤其要想清楚这一点。
先看访问量而不是站点数量。十个每天几十个访问的小站，跟三个每天上万访问的站，对机器的压力完全不是一个量级。按并发来估算更靠谱：峰值时同时有多少人在浏览，每个人同时发起几个请求。
以常见的配置推算，二十四核、一百二十八 GB 内存的机器，PHP 工作者开到一两百个不算吃力，配合数据库缓冲池给到三四十 GB，撑住每秒几百个动态请求是可以的。站点数量在这个前提下，几十个中小站没有问题。
内存是最先见底的资源。PHP 工作者、数据库、缓存、系统本身各占一块，站点数量多了之后 PHP 进程数会被迫上调，内存不够就只能减少进程，等于变相压低了并发能力。
CPU 的瓶颈往往出现在特定时刻。后台发布文章、批量更新插件、跑定时任务，这些操作会短时间吃掉大量 CPU，如果和前台高峰重叠，页面就会明显变慢。把这类操作错开时间，比加核心更省钱。
磁盘的瓶颈出现在文件数量上。站点多了之后小文件数量上到几十万，目录遍历变慢，备份打包也变慢。固态盘能把这块压力压下去，机械盘只能靠分目录、减少插件来解决。
数据库表数量也会成为隐性上限。每个站点几十张表，几十个站就是上千张，数据库启动和元数据查询都变慢。定期清理废弃站点、删掉不用的插件表，比升级硬件更有效。
真要给出一个数字，先按每站每天五千访问估算，一台中高配机器带二十到三十个这样的站还算从容；超过这个量，先看是内存先满还是磁盘 IO 先满，再决定加机器还是拆机器。这条线在渠道配置列表里能对照不同档位的资源比例来判断。
页面缓存是第一层。把渲染好的 HTML 存起来，命中时直接返回，数据库和 PHP 都不用动。多站点下要给每个站点单独配置缓存前缀，否则不同站点的缓存会互相串，出现串站的内容，排查时很难想到是缓存前缀没改，往往先怀疑数据库又被绕了一圈。
对象缓存是第二层，把数据库查询结果放到内存里。站点多了之后这一层收益很大，但要占内存，得先把内存配额规划出来，别让对象缓存和 PHP 进程抢同一块内存，配额定好之后再调命中率才有意义，配额给多了数据库那边就会饿。
媒体文件放对象存储能省磁盘和带宽。图片、附件搬出去之后，机器上只剩代码和数据库，备份体积小很多，迁移也快。前提是把访问域名和回源配好，否则图片加载反而变慢，用户以为是自己网络的问题，其实是回源路径绕了远路，用户从香港以外访问时最明显。
三层的顺序别搞反。没有页面缓存就上对象缓存，收益有限；页面缓存做好了再考虑媒体外置，效果才明显，不然带宽和磁盘一起紧，看不出是哪一项起的作用，先上页面缓存，它的收益最容易量化，命中率抬到八成就先看别的层，低于五成说明粒度或者过期策略有问题。顺序对了，同样的配置能多扛一倍流量；顺序错了，加了机器也感觉不到快，这就是为什么有人换了更好的配置却没看出差别。
看响应时间的趋势，而不是看单次监控值。前台首页从两百毫秒涨到五百毫秒，并且持续一周，说明资源已经到边界。这时候调参数能挤出的空间很小，问题在容量。
看内存的实际使用曲线。如果每天都在高位徘徊，稍有流量波动就要动用交换分区，说明内存不够。加内存或者换更大内存的机型，比优化代码快得多。
看磁盘的等待时间。系统的 IO 等待占比长期超过两成，页面加载开始出现卡顿，多半是小文件随机读把盘压住了，加内存解决不了这种卡，先看盘的类型和小文件数量，固态换上去之后通常立刻见效，机械盘再怎么调也追不上小文件读，这是物理层面的差距，靠参数和缓存绕不过去，只能换盘或者换结构，把媒体目录挪到对象存储是成本较低的一种结构变化，改配置就能生效，不用动代码。换固态或者把媒体文件外置能立竿见影。
看备份窗口的长度。备份从十分钟涨到一小时，说明数据量已经超出这台机器的处理能力，继续拖下去会影响正常业务，把它拆出去比换整台机器便宜得多，备份机不需要多强的算力。把备份挪到独立机器，是成本最低的解法。
另有一种信号是运维时间变长。以前十分钟能处理完的日常维护，现在要花一个小时，说明站点数量和复杂度已经超过了这台机器的管理半径，再加硬件也换不回省下的时间，分开管理更现实，拆成两台按业务分组会更轻松。
换机器之前先把不用的站点清掉，这一步常被跳过。很多人算容量时把自己的测试站、废弃站一起算进去，白白多买了一档配置。清理之后再评估，往往能省下不少预算，也能让新机器的分区规划更清楚，容量估算不会被虚高的数字带偏。
九百这一档的核心是大内存。二十四核、一百二十八 GB、八百 GB 固态，配合两千兆端口，撑几十个中小站点比较从容，PHP 工作者和数据库缓冲池都有地方放，内存不会成为瓶颈，站点之间的相互影响也小，一个站被人打满了也不会拖累别的站。
七百五这一档胜在核心多、磁盘大。二十核四十线程、六十四 GB、一 TB 固态，处理并发请求的能力更强，磁盘容量也更宽裕，适合站点数量不多但单个站点访问量高的场景，比如一个人气论坛或者商品库，这类站点的请求量大但站点数量少。
内存和磁盘哪个优先，看站点的形态。图片多、附件多、备份大的站，先考虑磁盘；动态请求多、后台操作频繁的站，先考虑内存和核心。两个都紧张，就往上再加一档，别在同一档里反复折腾优化，软件层的调优有天花板。
端口带宽的差别在流量型站点上才显出来。纯文字站两千兆和一千兆感觉不出区别，图库、下载站、视频封面这类业务，带宽会直接决定用户的等待时间，这一点在跨境访问上尤其明显，海外用户的打开速度差距很大。
两档的价差不到两百元，按月算每天几块钱。真要纠结，先按现有站点的峰值内存占用乘以一点五，看落在哪个档位的容量里，再对照这份机型对照下单，比凭感觉猜稳妥，也能避免买小了两个月就又要换，迁移一次的人工成本比差价高。
