香港服务器AMD 4584PX部署WooCommerce：DDR5内存调优步骤

部署目标是让 WooCommerce 在香港服务器上稳定运行，并通过测量和分配内存，减少 PHP、数据库与缓存服务之间的资源争用。以下以 Ubuntu Server 24.04 LTS、Nginx、PHP 8.3、MariaDB、Redis 和 WooCommerce 为例；命令适用于该系统，执行前应确认服务器可通过 SSH 管理，并准备域名、DNS、数据库密码和可用的系统盘空间。

DDR5 调优不等于在 Linux 中直接设置内存频率。服务器实际运行频率与时序通常受处理器、主板、固件和内存条共同限制，虚拟化环境还可能不允许查看或修改固件参数。部署时应先确认系统可见的内存和 NUMA 布局，再调整 PHP-FPM、数据库、Redis 与 Linux 的内存使用方式。任何固件级频率或时序调整，都应在服务商允许且有带外管理、维护窗口和回滚手段时进行。

一、准备条件与内存基线

1. 确认系统、CPU、内存和磁盘

先以具备 sudo 权限的普通账户登录，检查发行版、内核、处理器和可用内存：

cat /etc/os-release
uname -r
lscpu
free -h
lsblk
df -hT

重点记录以下信息：

• 操作系统是否为 Ubuntu 24.04 LTS，内核和架构是否符合后续安装要求。
• free -h 中的 Mem、available 和 Swap。判断可用内存时优先看 available，不要只看 free；Linux 会将空闲内存用于缓存。
• lscpu 中的 CPU 数量和 NUMA 节点。多 NUMA 节点机器应留意进程是否跨节点分配内存。
• 系统盘文件系统与剩余空间。商品图片、备份和日志增长都需要额外空间，不能只按程序本身估算。

若系统允许读取 SMBIOS 信息，可尝试查看内存条的识别信息：

sudo apt update
sudo apt install -y dmidecode
sudo dmidecode --type memory

在虚拟机或受限环境中，dmidecode 可能显示空值、通用信息或无法访问；这不代表系统内存一定异常。不要根据软件读到的单一字段推断实际 DDR5 频率。物理内存频率和时序应通过服务商提供的管理界面或硬件管理方式核验。

2. 建立上线前基线

安装应用前先保存初始状态，后续才有依据判断调优是否有效：

free -h
vmstat 1 5
uptime

观察 vmstat 的 si、so（交换空间读入、写出）是否持续出现，及 wa（I/O 等待）是否异常偏高。单次采样不能证明存在问题；应在正常访问和可控压测期间重复观察。若机器尚无业务负载，记录空载数据即可，不能把空载结果当作商城的承载能力。

部署前还要完成 DNS 指向、SSH 密钥登录、系统更新和备份策略。数据库对外不开放端口；管理端口只允许必要来源访问。生产环境应启用 HTTPS，并为数据库、WordPress 管理员和 Redis 设置独立凭据或访问限制。

二、安装基础运行环境

1. 更新系统并安装 Nginx、PHP 与数据库

下面以 Ubuntu 24.04 的软件源为基础。执行系统更新可能包含内核升级，建议先确认维护窗口；升级后如提示重启，应在业务上线前完成重启和验证。

sudo apt update
sudo apt full-upgrade -y
sudo apt install -y nginx mariadb-server \
  php8.3-fpm php8.3-cli php8.3-mysql php8.3-curl \
  php8.3-gd php8.3-intl php8.3-mbstring php8.3-xml \
  php8.3-zip php8.3-bcmath php8.3-soap php8.3-imagick \
  php8.3-opcache redis-server

确认服务运行状态及 PHP 扩展：

systemctl is-active nginx mariadb php8.3-fpm redis-server
php -v
php -m

预期服务返回 active，PHP 版本为 8.3，并能看到 mysqli、curl、mbstring、xml、zip 等扩展。若某个服务未启动，先看日志，不要继续导入商城数据：

sudo journalctl -u nginx -u mariadb -u php8.3-fpm -u redis-server \
  --since "10 minutes ago" --no-pager

2. 配置 MariaDB 数据库

先执行数据库安全初始化。不同 MariaDB 包的认证方式可能不同；按交互提示设置 root 认证、移除匿名账户和测试数据库，并禁止远程 root 登录。不要将数据库管理账户密码写入公开仓库或 Web 根目录。

sudo mariadb-secure-installation

创建独立数据库和应用账户。以下名称与密码仅为示例，请替换为随机生成的强密码；命令中的密码会留在终端历史或进程记录中，不适合直接用于正式环境。更稳妥的做法是在本地交互式数据库会话中执行 SQL，并安全保管凭据。

CREATE DATABASE shopdb
  DEFAULT CHARACTER SET utf8mb4
  COLLATE utf8mb4_unicode_ci;
CREATE USER 'shopuser'@'localhost' IDENTIFIED BY '替换为长随机密码';
GRANT ALL PRIVILEGES ON shopdb.* TO 'shopuser'@'localhost';
FLUSH PRIVILEGES;

检查数据库只监听本机，并确认应用账户能登录：

sudo ss -lntp | grep 3306
mariadb -u shopuser -p -h localhost shopdb

若 3306 监听在 0.0.0.0 或公网地址，先检查 MariaDB 的绑定地址配置和防火墙规则；WooCommerce 与数据库同机时通常不需要对公网开放数据库端口。修改绑定地址前保存配置副本，改动后重启 MariaDB，并从本机复测连接。

3. 安装 WordPress 与 WooCommerce

创建站点目录并设置 PHP-FPM 可读写的目录权限。以下路径只是示例，可按既有目录规划调整：

sudo mkdir -p /var/www/shop
sudo chown -R "$USER":www-data /var/www/shop
sudo chmod 750 /var/www/shop

安装 WP-CLI 后下载 WordPress。curl 获取的是可执行 PHP 文件，应使用可信网络环境，并按官方发布渠道核验文件完整性；不要从来历不明的网站下载脚本。

cd /tmp
curl -O https://raw.githubusercontent.com/wp-cli/builds/gh-pages/phar/wp-cli.phar
php wp-cli.phar --info
sudo install -m 0755 wp-cli.phar /usr/local/bin/wp

下载核心文件并创建配置文件时，替换数据库凭据和站点地址：

sudo -u www-data -H wp core download --path=/var/www/shop
cd /var/www/shop
sudo -u www-data -H wp config create \
  --dbname=shopdb \
  --dbuser=shopuser \
  --dbpass='替换为长随机密码' \
  --dbhost=localhost \
  --path=/var/www/shop

正式环境不要将密码作为可见命令参数反复执行。若配置已生成，限制文件权限并确认文件未被 Web 直接下载：

sudo chown www-www-data /var/www/shop/wp-config.php
sudo chmod 640 /var/www/shop/wp-config.php

配置 Nginx 虚拟主机，将 shop.example.com 替换为实际域名。以下配置支持 WordPress 固定链接，并将 PHP 请求交给本机 PHP-FPM：

server {
    listen 80;
    server_name shop.example.com;
    root /var/www/shop;
    index index.php index.html;

    client_max_body_size 32m;

    location / {
        try_files $uri $uri/ /index.php?$args;
    }

    location ~ \.php$ {
        include snippets/fastcgi-php.conf;
        fastcgi_pass unix:/run/php/php8.3-fpm.sock;
    }

    location ~* \.(?:jpg|jpeg|gif|png|css|js|ico|webp|svg)$ {
        expires 7d;
        access_log off;
    }

    location ~ /\.(?!well-known) {
        deny all;
    }
}

保存为 /etc/nginx/sites-available/shop，启用站点前先做配置检查：

sudo ln -s /etc/nginx/sites-available/shop /etc/nginx/sites-enabled/shop
sudo nginx -t
sudo systemctl reload nginx

若默认站点与新站点的 server_name 冲突，应先核对启用的站点链接，再按实际域名调整；不要直接删除其他站点配置。nginx -t 返回成功后才 reload。随后通过 HTTPS 证书服务完成 TLS 配置，并再次执行 nginx -t 和 reload。

完成 WordPress 初始化后，使用 WP-CLI 安装并启用 WooCommerce。示例中的站点标题、管理员账户和邮箱需替换为实际值：

cd /var/www/shop
sudo -u www-data -H wp core install \
  --url='https://shop.example.com' \
  --title='示例商城' \
  --admin_user='替换为管理员名' \
  --admin_password='替换为强密码' \
  --admin_email='admin@example.com'

sudo -u www-data -H wp plugin install woocommerce --activate

检查核心和插件状态：

sudo -u www-data -H wp core is-installed
sudo -u www-data -H wp plugin status woocommerce

如果 WooCommerce 仍显示未配置，登录 WordPress 后台完成货币、税费、配送、支付方式和隐私设置。支付密钥应存放在受控配置中，不能复制到公开日志或截图。

三、按层调优 DDR5 相关内存使用

内存调优的目标是控制各服务的峰值占用，并为内核缓存、数据库连接、后台任务和突发请求留下余量，而不是把可用内存全部分配给数据库。下列容量仅用于说明：若实例确有 64GB 内存，可以先预留约 8–12GB 给系统、缓存与波动，再按实际并发和插件情况分配；内存较小的实例必须按比例缩减。该参考值不是 WooCommerce 的最低要求或容量承诺。

1. 先设置 PHP-FPM 并发

PHP-FPM 每个 worker 都会占用内存，不能仅按 CPU 核数决定进程数。先查看当前配置和进程占用：

grep -R "^[; ]*pm\|^[; ]*memory_limit\|^[; ]*max_execution_time" \
  /etc/php/8.3/fpm/pool.d /etc/php/8.3/fpm/php.ini
ps -o rss= -C php-fpm8.3 | awk '{s+=$1;n++} END {if(n) printf "平均RSS约 %.1f MiB\n",s/n/1024}'

测得的 RSS 会受页面类型、插件和缓存影响；应在可代表业务的请求期间多次采样。FPM 池配置通常位于 /etc/php/8.3/fpm/pool.d/www.conf。例如在内存充足、并发中等的起始配置中，可将 pm 设为 dynamic，并根据测得的单进程峰值限制 pm.max_children，而不是照抄固定数值：

pm = dynamic
pm.max_children = 20
pm.start_servers = 4
pm.min_spare_servers = 2
pm.max_spare_servers = 6
pm.max_requests = 500

pm.max_children 是并发 PHP 进程上限。估算方法是：给 PHP-FPM 预留的内存，除以高峰期单个 worker 的 RSS，再留出余量。例如预留 8GiB、单个 worker 峰值约 250MiB，理论上限约为 32 个进程；实际值还要扣除请求波动和其他服务的需求，宜先设置更低值并观察队列、延迟和内存。memory_limit 是单个 PHP 请求可使用的上限，不等于每个 worker 必然占满该内存，设置过高也会放大异常请求的风险。

改动前备份原文件，保存后测试并重启：

sudo cp -a /etc/php/8.3/fpm/pool.d/www.conf \
  /etc/php/8.3/fpm/pool.d/www.conf.bak
sudo php-fpm8.3 -t
sudo systemctl restart php8.3-fpm
systemctl is-active php8.3-fpm

若测试失败，恢复备份再重启。重启会短暂中断 PHP 请求，应安排在维护窗口或低流量时段。

2. 为 MariaDB 设置合理缓冲池

InnoDB 缓冲池用于缓存数据页和索引。数据库与 Web 服务同机时，不宜照搬“将大部分内存都给缓冲池”的单一经验值。先检查 MariaDB 版本、数据库大小和当前参数：

mariadb --version
sudo mariadb -e "SHOW VARIABLES LIKE 'innodb_buffer_pool_size';"
sudo mariadb -e "SELECT table_schema, ROUND(SUM(data_length+index_length)/1024/1024) AS MB \
FROM information_schema.tables GROUP BY table_schema;"

小型或中型同机商城可从总内存的约 20%–40% 作为缓冲池试运行区间，再依据数据库体量、PHP-FPM 峰值、操作系统可用内存和磁盘读负载调整。比如 64GB 机器可先评估 12–20GB 的范围，而不是直接占满内存；若数据库远小于该范围，增加缓冲池未必带来收益。最终应以持续运行时的 available、交换活动、数据库延迟和磁盘读写为依据。

Ubuntu 的 MariaDB 参数文件可能位于 /etc/mysql/mariadb.conf.d/50-server.cnf。先备份，再在 [mysqld] 段落内设置参数，避免重复定义：

[mysqld]
innodb_buffer_pool_size = 16G

16G 仅为配置示例，须按实例实际内存调整。修改后重启数据库会中断连接，并可能触发缓冲池重新加载；应先确认有可用备份和维护窗口：

sudo cp -a /etc/mysql/mariadb.conf.d/50-server.cnf \
  /etc/mysql/mariadb.conf.d/50-server.cnf.bak
sudo mariadb --help --verbose >/dev/null
sudo systemctl restart mariadb
sudo mariadb -e "SHOW VARIABLES LIKE 'innodb_buffer_pool_size';"

若服务启动失败，检查 journalctl -u mariadb 和错误日志，恢复备份并重启。不要在不了解当前版本和负载的情况下同时大幅修改连接数、日志文件和多项 InnoDB 参数，否则难以定位回归原因。

3. 约束 Redis 占用并避免缓存挤压

Redis 对商品对象缓存和会话等数据有帮助，但缓存不是越大越好。先确认 WordPress 使用的 Redis 插件已安装，并确认本机服务状态：

redis-cli ping
redis-cli INFO memory | grep -E 'used_memory_human|maxmemory_human'

本机部署时应让 Redis 只监听本机或受控 Unix socket，不要向公网开放 6379。设置缓存上限前备份 /etc/redis/redis.conf，再在配置中设置适合实例的 maxmemory 与淘汰策略。下面仅作起始示例，具体值须依据 Redis 用途和剩余内存确定：

bind 127.0.0.1 ::1
maxmemory 2gb
maxmemory-policy allkeys-lru

若 Redis 被用于保存不允许淘汰的数据，不应直接采用 allkeys-lru；应先区分缓存和持久化数据用途。配置变更可能导致缓存淘汰或短暂连接中断，需先确认应用可在缓存清空后正常重建，再重启并检查：

sudo cp -a /etc/redis/redis.conf /etc/redis/redis.conf.bak
sudo systemctl restart redis-server
redis-cli ping
redis-cli INFO memory | grep -E 'used_memory_human|maxmemory_human'

若 Redis 插件连接失败，检查 WordPress 的主机、端口、认证和插件状态，并确认 Redis 仍只对预期接口监听。

4. 检查交换、透明大页与 NUMA，不做盲目“优化”

查看交换空间和内核内存状态：

swapon --show
sysctl vm.swappiness
grep -E 'MemAvailable|SwapTotal|SwapFree' /proc/meminfo

交换空间可作为短时缓冲，但持续交换会增加响应时间。若 si、so 在业务负载下持续非零，先查 PHP-FPM 进程数、数据库缓冲池和 Redis 上限，不能仅靠关闭 swap 掩盖内存不足。若要修改 vm.swappiness，先记录原值并用 sysctl -w 临时测试；验证后再写入独立的 /etc/sysctl.d/ 文件。回滚时删除该文件并恢复原值。不要直接执行 swapoff -a，尤其是在内存紧张时，这可能触发进程被系统终止。

检查透明大页与 NUMA 状态：

cat /sys/kernel/mm/transparent_hugepage/enabled 2>/dev/null || true
numactl --hardware 2>/dev/null || true
numastat -m 2>/dev/null || true

不同内核与工作负载对透明大页的表现可能不同。若没有可复现的延迟或内存碎片问题，保持系统默认并记录状态即可，不要为了“DDR5 调优”而直接改启动参数或强制关闭功能。NUMA 节点间分配不均时，先确认进程与节点的关系，再安排有针对性的测试；不建议未经测量就将 PHP 或数据库进程绑定到单一节点。

四、性能验证与故障处理

调优应一次只改一类参数。每次变更前记录当前配置、服务状态和关键指标；变更后使用相同的代表性操作复测，例如商品列表、商品详情、加入购物车、结算页和后台保存商品。压测应在可控环境进行，避免对真实支付、邮件通知和库存扣减产生影响。

检查资源变化：

free -h
vmstat 1 10
ps -eo pid,comm,rss,%mem --sort=-rss | head
sudo journalctl -u php8.3-fpm -u mariadb -u redis-server \
  --since "15 minutes ago" --no-pager

成功状态通常包括：服务均为 active；正常业务期间可用内存没有持续快速下降；没有持续交换读写；PHP-FPM 没有频繁达到进程上限；数据库与 Redis 日志没有重复报错；站点的商品、购物车和结算流程可以完成。示例检查结果可能如下，数值仅用于展示格式，不代表固定验收门槛：

Mem:  62Gi total, 18Gi used, 31Gi available
procs: r=1 b=0
memory: si=0 so=0

常见异常按由外到内的顺序排查：

如果 WooCommerce 页面异常但系统内存充足，应继续检查 PHP 错误日志、插件冲突、数据库慢查询和磁盘 I/O；内存调优不能替代应用层故障定位。涉及支付插件或订单数据的排查，优先在测试订单和维护窗口中进行。

五、上线验收与回滚

正式切换前完成以下检查：

• 从站点域名访问 HTTPS 页面，证书有效，固定链接可打开。
• 后台能登录，商品、分类、图片和库存状态可正常维护。
• 测试商品可加入购物车，配送、税费和结算流程符合业务设置；测试支付使用测试环境或明确标记的测试方式。
• Nginx、PHP-FPM、MariaDB 和 Redis 在重启后都能正常启动。
• WordPress 文件、数据库和关键配置已有可恢复备份，且备份不暴露数据库密码。
• 在代表性访问期间观察 MemAvailable、swap、PHP-FPM worker、数据库日志和磁盘空间，未出现持续恶化趋势。

回滚时遵循“恢复最近一项变更”的顺序：先将 PHP-FPM、MariaDB、Redis 或 sysctl 配置恢复为各自备份版本，再检查配置并重启对应服务。示例：

sudo cp -a /etc/php/8.3/fpm/pool.d/www.conf.bak \
  /etc/php/8.3/fpm/pool.d/www.conf
sudo php-fpm8.3 -t
sudo systemctl restart php8.3-fpm

恢复前确认备份文件对应当前版本，避免覆盖上线后的有效变更。若回滚涉及数据库参数，先恢复配置并确认 MariaDB 正常启动，再验证 WooCommerce 数据库连接；不要为回滚内存调优删除数据库文件、清空订单数据或重建数据库。若固件层曾调整内存频率或时序，应按服务器管理方式恢复原始设置，并预留重启及硬件自检时间。

一套可复用的验收标准是：站点关键购物流程通过、服务重启正常、日志无持续错误、负载期间没有持续交换活动，并且备份和恢复路径已验证。达到这些条件后再逐步开放真实流量；若某项调优不能带来可重复的改善，优先恢复到已验证的配置，而不是继续叠加未经验证的参数。