网站迁移或扩容时，最容易出现的误判是：看到CPU占用不高，就继续增加CPU；看到磁盘容量够用，就忽略数据库读写延迟；看到内存总量较大，却没有检查高峰期交换分区和连接开销。香港服务器的配置取舍不能只比较核心数或磁盘容量，而应根据峰值请求类型、数据库读写比例、内存压力、磁盘等待和网络流量确定优先级。

可以先采用这一判断顺序：先确认业务峰值和验收指标，再检查内存是否在高峰期持续交换；内存稳定后，判断CPU是否真正繁忙；随后区分磁盘的容量问题和I/O问题，最后核对网络吞吐与连接处理能力。 动态页面、接口和计算密集型程序通常更依赖CPU；数据库和高并发连接通常更容易消耗内存；频繁写入、日志和查询延迟则要求重点检查磁盘；静态资源和下载较多时，网络不能被忽略。

先确定负载口径和验收条件

在购买、扩容或迁移前，先记录以下数据，否则只能做方向性判断：

• 日常访问量与峰值访问量，分别记录页面、接口、静态资源和下载请求。
• 峰值每秒请求数（RPS）、并发连接数，以及请求在应用、数据库和网络传输上的主要耗时。
• 动态请求占比，是否包含复杂计算、文件处理、排序、聚合或多表查询。
• 数据库数据量、索引量、增长速度、读写比例和连接数。
• 网站程序、数据库、日志、临时文件和备份是否共用同一文件系统。
• 可接受的页面和接口响应时间、错误率，以及允许的维护窗口。
• 是否具备数据库备份、配置备份、恢复验证和回滚方案。

并发连接数不能替代每秒请求数。 连接数表示同时保持或处理中的连接规模，RPS表示单位时间完成的请求数量；长连接或慢请求可能在RPS不高时占用大量连接和内存。因此，CPU判断应优先使用峰值RPS和单请求CPU时间，内存判断则要结合连接数和每个进程、连接的实际占用。

如果已经测得单请求CPU时间，可以用下面的变量关系进行粗略估算：

所需CPU核心数 ≈ 峰值RPS × 单请求CPU时间（秒） ÷ 计划CPU利用率

这个估算只适用于CPU计算部分的测量口径一致的场景，不能把磁盘等待、网络等待或数据库锁等待误算成CPU时间，也不能替代峰值压测和线上监控。

内存和磁盘也应按组成项估算：

内存需求 = 系统与基础服务 + 应用进程 + 数据库缓存
         + 连接与临时操作开销 + 监控日志开销 + 峰值余量

所需磁盘容量 = 当前数据 + 预计增长量
             + 日志与数据库日志 + 备份保留空间 + 临时空间
             + 发布或导入导出的工作空间

上式中的时间周期、增长量和保留周期必须使用同一单位。不能用数据库当前数据量直接代替磁盘需求，也不能把连接数直接代替请求速率。

按工作负载先定优先级

如果网站和数据库部署在同一台香港服务器上，操作系统、应用进程、数据库缓存、连接、日志和备份都要放在同一张资源账单中计算。

先采集基线，再进行配置判断

调整前应保存一组包含日期和业务时段的基线。以下命令适用于常见Linux环境，命令缺失时先确认发行版和已安装软件包，不要直接套用其他系统的安装命令：

lscpu
free -h
df -hT
df -ih
lsblk
ss -s
vmstat 1 5

如果系统已安装 sysstat，可以补充CPU、磁盘和网卡数据：

mpstat -P ALL 1 5
iostat -xz 1 5
sar -n DEV 1 5

可以将只读检查结果保存下来：

mkdir -p ~/server-check
{
  date
  echo "=== CPU ==="
  lscpu
  echo "=== MEMORY ==="
  free -h
  echo "=== DISK ==="
  df -hT
  df -ih
  echo "=== NETWORK ==="
  ss -s
  echo "=== VMSTAT ==="
  vmstat 1 5
} | tee ~/server-check/baseline-$(date +%F-%H%M).txt

这些检查不会修改服务配置，但仍需确认目标目录有足够空间。至少保留调整前、调整后和业务峰值时段三组数据。只在空闲时段观察一次，无法证明配置可以承受真实高峰。

CPU：只有在计算成为限制时才优先增加

CPU应重点解决动态请求、程序计算和数据库计算带来的处理瓶颈。判断时要同时看以下现象：

• 所有核心是否在高峰期持续繁忙，还是只有一个核心长期繁忙。
• CPU主要消耗在用户态、系统态，还是等待I/O。
• CPU升高时，接口排队、响应时间和错误率是否同步升高。
• 虚拟化环境中的 steal 是否异常，确认CPU是否被其他任务抢占。

可以使用：

top
mpstat -P ALL 1 5

结果应按分支解释：

• CPU持续繁忙、内存稳定、磁盘等待不明显：增加CPU资源可能直接改善处理能力，也应同步检查高耗时请求、SQL和应用进程数量。
• 只有一个核心繁忙、其他核心空闲：先检查应用是否单线程、进程数是否不足。单纯增加总核心数不一定立即有效。
• CPU不高但响应慢，iowait明显：优先检查数据库读取、日志写入和磁盘延迟，增加CPU不能消除磁盘等待。
• CPU不高但交换分区频繁活动：先解决内存压力，增加CPU通常不能改善交换。
• CPU和错误率同时升高：先保留高峰日志和监控数据，再进行限流、扩容或应用参数调整，避免在高峰期直接大规模改动。

CPU核心数不是网站性能的唯一指标。若应用进程、数据库查询或锁等待限制了请求处理，配置更多CPU也可能只会让空闲核心增加。

内存：先确认高峰期是否持续受压

网站与数据库共用一台香港服务器时，内存通常同时被以下对象使用：操作系统和文件缓存、网站程序、数据库缓存、连接池、后台任务、日志处理以及导入导出等临时操作。

检查当前状态：

free -h
swapon --show
cat /proc/pressure/memory 2>/dev/null || true

Linux将空闲内存用于缓存并不代表内存不足，应重点观察：

• available在高峰期是否持续下降。
• 交换分区是否持续增长或频繁读写。
• 应用是否被系统终止，日志中是否出现内存不足信息。
• 数据库缓存命中情况变差时，磁盘读取等待和查询延迟是否同步升高。
• 并发连接增加时，内存是否快速下降。

发现内存不足时，先核对连接池、后台任务、应用进程数和数据库缓存设置，再决定是否扩容。数据库缓存不能挤压网站进程和系统正常运行所需的空间，连接数也不能无限增加，因为每个连接都可能带来额外内存开销。

结果解释如下：

• 高峰期交换分区持续活动：优先增加内存，或收紧进程、连接和缓存占用；不要把交换分区当作正常的内存扩展。
• 内存尚有余量但读取延迟高：检查索引、数据库缓存命中和磁盘性能，不能只按内存总量作结论。
• 应用进程被系统终止：先保存系统日志和进程占用记录，再调整内存分配；不要只重启服务后忽略原因。
• 增加内存后仍然变慢：重新核对CPU、磁盘等待、数据库锁和网络数据，说明瓶颈可能不在内存。

磁盘：把容量问题和I/O问题分开处理

磁盘选择有两个不同目标：一是能否容纳数据、日志和备份，二是能否及时完成数据库读写。容量充足并不代表查询和写入延迟足够低。

先查看文件系统、挂载点和inode：

df -hT
df -ih
lsblk -o NAME,SIZE,TYPE,FSTYPE,MOUNTPOINT

从浅层目录开始检查占用，避免一开始就扫描大量文件：

sudo du -xhd1 /var 2>/dev/null | sort -h
sudo du -xhd1 /home 2>/dev/null | sort -h

如果已安装 iostat，观察设备等待：

iostat -xz 1 5

判断时区分以下情况：

• 容量接近上限：先确认日志、旧备份和临时文件的用途与保留规则，再归档或清理；不要直接执行大范围删除。
• 容量充足但iowait高：检查数据库日志、同步写入、索引读取和高并发查询。
• inode接近耗尽：说明小文件数量可能过多，增加容量不一定能解决问题。
• 写入延迟导致请求排队：同时记录设备层和数据库层的等待，再决定调整磁盘性能、写入批次或应用行为。
• 扩容后空间仍未生效：确认操作系统、分区和文件系统是否已经识别新增空间，不能只看管理界面的容量。

清理日志或旧备份前，必须确认备份可恢复、保留范围已获批准，并记录具体文件路径。涉及删除时先进行只读检查和归档验证，不使用未经核对的通配符删除生产文件。磁盘扩容通常不适合设计成可缩回的操作，变更前应完成备份并确认文件系统操作步骤和回退边界。

网络：确认慢的是传输还是处理

网站的图片、安装包、下载文件和备份传输会同时增加网络发送量；接口响应慢则未必是网络不足，也可能是程序、数据库或磁盘在等待。

检查接口统计和连接情况：

ip -s link
ss -s

如果环境支持 sar：

sar -n DEV 1 5

重点观察峰值时段的发送、接收速率、丢包、错误包、重传和连接数，并对照页面或接口响应时间：

• 流量接近可用上限，响应传输占主要部分：先核对网络配置和业务峰值需求，再评估压缩、缓存和静态文件策略。
• 流量不高但连接数很多：检查连接复用、超时、连接池和应用处理能力，不能直接判断为带宽不足。
• 网卡错误或丢包增加：保存接口统计和发生时间，先排查服务器侧配置与服务商网络状态。
• 网络正常但接口响应慢：回到CPU、内存、数据库锁和磁盘等待分析。
• 下载业务增加：容量、网络和连接处理能力要一起验收，不能只增加CPU。

按瓶颈变更，并保留可回退状态

预算有限时，可以采用以下优先级：

1. 高峰期持续交换，先处理内存和连接、缓存占用。
2. 内存稳定后，如果CPU持续繁忙、磁盘等待低且请求排队同步出现，再增加CPU或优化计算密集型请求。
3. 数据库读多时核对缓存、索引和读取延迟；写多时核对日志、同步写入和持续写入能力，同时保证容量覆盖数据、日志与备份。
4. 页面和文件传输接近网络能力时，核对网络配置与峰值流量；网络正常时，不要用增加网络资源解决数据库查询慢。

一次只改变一个主要变量，例如先调整内存，再观察完整业务峰值；不要同时更换CPU、磁盘、进程数和数据库参数，否则无法判断收益来源。应用进程数、连接池和缓存参数变更前，复制旧配置并记录版本；数据库参数变更前确认是否支持动态生效，涉及重启的参数要安排维护窗口。CPU或内存规格调整前，确认是否会重启香港服务器，并提前完成备份和维护通知。

变更后的成功验证与异常回滚

变更完成后，应使用与基线相同的业务场景重新测试，并记录：

• 各CPU核心使用情况和高峰持续时间。
• 可用内存、交换分区活动和应用进程占用。
• 磁盘容量、inode、I/O等待和数据库写入延迟。
• 网络吞吐、连接数、错误包和重传。
• 页面或接口响应时间、错误率和数据库慢查询。
• 备份、日志写入、发布以及重启后的服务状态。

验收不能只看“服务器没有宕机”。至少应确认峰值请求能够完成，关键接口没有新增错误，数据库没有异常排队，磁盘仍有可用空间，网络没有新增丢包或错误，并且原有响应时间目标没有被破坏。

出现异常时，先记录时间点和变更项，再保存只读信息：

date
uptime
free -h
df -hT
vmstat 1 5
ss -s
dmesg --level=err,warn --ctime | tail -n 100

dmesg选项可能因系统版本和权限不同而不兼容，执行失败时先查看该系统的命令帮助，不要为了取日志修改权限或覆盖系统配置。涉及数据库或应用时，还应保存错误日志、慢查询记录和对应请求时间段。不要先清空日志、重启所有服务或删除临时文件，否则可能丢失定位瓶颈所需的证据。

应用、连接池和缓存参数异常时，恢复变更前保存的旧配置，并按服务支持的安全重载方式生效。数据库参数回滚前确认旧值和生效范围，必要时在维护窗口重启。磁盘扩容通常不能简单缩回；日志和备份清理则应先归档、校验和确认保留范围，再处理明确文件。

保留配置复核记录

交付后保留一份记录，至少包括：

• 调整前后CPU、内存、磁盘和网络数据。
• 峰值测试时间、请求类型、RPS和并发条件。
• 变更过的应用、数据库和系统参数。
• 备份位置、恢复验证结果和回滚步骤。
• 未解决的异常、日志证据和下一次复核时间。

后续复核应继续关注峰值时段，而不是只看平均资源使用率。数据增长、数据库写入比例、日志保留空间、下载流量或动态请求占比发生变化后，应重新核对香港服务器的CPU、内存、磁盘和网络，让配置取舍始终与实际工作负载保持一致。