凌晨 2:40，我正准备关掉机房的 VGA KVM。客户打来电话：“香港站点高峰一来就抖，Web 和 MySQL 都顶不住，带宽还得上 25G，能不能今晚先加两台？”

我盯着机柜里四台待测服务器——两台 Intel，两台 AMD——心里那句老问题又浮上来：这波到底上 Intel 还是 AMD？

没时间做“哲学讨论”。我把四台机器分别装上 CentOS 7.9、换上新内核、拉起 Nginx/MySQL/iperf3，开干。

测试环境与硬件清单

机房/网络

• 机房：香港葵涌，单柜，A+B 供电
• TOR 交换机：25G 上联（Mellanox 25G，端口直连测试机）
• 业务 VLAN：独立 /29
• 时钟同步：Chrony 对齐香港授时节点

被测服务器（均为裸金属，非虚拟化）：

编号	平台	CPU	核心/线程	频率	内存	存储	网卡	BIOS 关键项
A	Intel 高频单路	Xeon E-2288G	8/16	3.7–5.0 GHz	64 GB DDR4-2666	1× NVMe Samsung PM983 1.92TB	Intel X710 10GbE (SFP+)	Turbo ON、HT ON、EIST ON
B	Intel 多核中频	Xeon Silver 4210R	10/20	2.4–3.2 GHz	128 GB DDR4-2666	2× NVMe Intel P4510 2TB（RAID1）	Mellanox ConnectX-4 Lx 25GbE (SFP28)	Turbo ON、HT ON、NUMA 2 节点
C	AMD 单路通用	EPYC 7302P（Zen 2）	16/32	3.0–3.3 GHz	128 GB DDR4-3200	2× NVMe Samsung PM9A3 3.84TB（RAID1）	ConnectX-4 25GbE	SMT ON、NUMA 4 片
D	AMD 单路高并发	EPYC 7443P（Zen 3）	24/48	2.85–4.0 GHz	256 GB DDR4-3200	2× NVMe Intel P5510 3.2TB（RAID1）	ConnectX-5 25GbE	SMT ON、NUMA 4 片

说明：选型不是“参数对齐”的学术对比，而是我在香港实际能调到、价格带相近且常被客户选择的四种典型配置。

系统与通用调优

OS 与内核

• OS：CentOS 7.9（客户要求兼容旧 SOP）
• 内核：为适配 25G 驱动与 BBR，我用 ELRepo 装了 kernel-ml 5.4 LTS

# 基础环境与内核
yum install -y epel-release yum-plugin-fastestmirror
rpm --import https://www.elrepo.org/RPM-GPG-KEY-elrepo.org
yum install -y https://www.elrepo.org/elrepo-release-7.el7.elrepo.noarch.rpm
yum --enablerepo=elrepo-kernel install -y kernel-ml
grub2-set-default 0 && reboot

基础内核与网络参数（四台一致）

cat >/etc/sysctl.d/99-tune.conf <<'EOF'
vm.swappiness = 1
vm.dirty_ratio = 10
vm.dirty_background_ratio = 5
fs.file-max = 1048576

net.core.netdev_max_backlog = 250000
net.core.somaxconn = 65535
net.ipv4.tcp_syncookies = 0
net.ipv4.tcp_timestamps = 0
net.ipv4.tcp_tw_reuse = 1
net.ipv4.ip_local_port_range = 10000 65535
net.ipv4.tcp_fin_timeout = 10
net.ipv4.tcp_max_syn_backlog = 262144
net.ipv4.tcp_max_tw_buckets = 2000000
net.core.rmem_max = 134217728
net.core.wmem_max = 134217728
net.ipv4.tcp_rmem = 4096 87380 67108864
net.ipv4.tcp_wmem = 4096 65536 67108864
net.core.default_qdisc = fq
net.ipv4.tcp_congestion_control = bbr
EOF
sysctl --system

CPU/电源/IRQ

# 性能电源策略
yum install -y tuned && tuned-adm profile throughput-performance

# 关 THP，避免 MySQL 抖动
echo never > /sys/kernel/mm/transparent_hugepage/enabled
echo never > /sys/kernel/mm/transparent_hugepage/defrag

# 提升网卡队列与 RPS/XPS（示例以 eth0）
ethtool -G eth0 rx 4096 tx 4096
for q in /sys/class/net/eth0/queues/rx-*; do echo ffffffff > $q/rps_cpus; done
for q in /sys/class/net/eth0/queues/tx-*; do echo ffffffff > $q/xps_cpus; done

NUMA 与中断亲和（AMD/高核机器务必做）

# 绑定中断到本地 NUMA，提高包处理效率（示例脚本）
cat >/usr/local/bin/pin_irqs.sh <<'SH'
#!/usr/bin/env bash
IF=eth0
CPU_LIST=(0 1 2 3 4 5 6 7)  # 按实际 CPU 核编号与 NUMA 节点调整
i=0
for irq in $(grep $IF /proc/interrupts | awk '{print $1}' | tr -d :); do
  mask=$(printf %x $((1<<${CPU_LIST[$i]})))
  echo $mask > /proc/irq/$irq/smp_affinity
  i=$(( (i+1) % ${#CPU_LIST[@]} ))
done
SH
chmod +x /usr/local/bin/pin_irqs.sh && /usr/local/bin/pin_irqs.sh

业务栈与压测方法

1) Web 场景（Nginx + PHP-FPM / TLS 1.3 / 动态 + 静态混部）

软件：Nginx 1.24 + OpenSSL 1.1.1、PHP 8.1（Opcache 开启）

配置要点

worker_processes auto; worker_cpu_affinity 绑定物理核

reuseport on;（后面有坑）

TLS 首包延迟与会话复用开启（ssl_session_cache shared:SSL:50m）

压测：两台客户端（同柜）用 wrk，TLS 并发 512/1024，1 分钟稳定段统计 P99

Nginx 关键片段：

worker_processes auto;
worker_rlimit_nofile 200000;

events {
    worker_connections 65535;
    use epoll;
    multi_accept on;
}

http {
    sendfile on;
    tcp_nopush on;
    tcp_nodelay on;
    keepalive_timeout 65;

    server {
        listen 443 ssl reuseport;
        ssl_protocols TLSv1.2 TLSv1.3;
        ssl_ciphers HIGH:!aNULL:!MD5;
        ssl_session_cache shared:SSL:50m;
        ssl_session_timeout 1h;

        location /php {
            fastcgi_pass 127.0.0.1:9000;
            include fastcgi_params;
            fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
        }

        location /static/ {
            root /data/www;
        }
    }
}

2) 数据库场景（MySQL 8.0 / OLTP 混合读写）

数据量：60 GB（大于内存的一半，避免全缓存假象）

工具：sysbench oltp_read_write，线程数 32/64/128

关键参数（InnoDB 追求稳定延迟）

# /etc/my.cnf
[mysqld]
innodb_buffer_pool_size=64G          # B/D 机器更大
innodb_log_file_size=4G
innodb_flush_method=O_DIRECT
innodb_flush_log_at_trx_commit=1
innodb_io_capacity=2000
max_connections=2000
thread_cache_size=128

# 绑核/绑内存（AMD）
# systemd ExecStart=/usr/bin/numactl --interleave=all /usr/sbin/mysqld

3) 大带宽传输（25G 为主，含 10G 回测）

• 工具：iperf3（并发流 8/16/32），及 Nginx 静态大文件推送（1GB/10GB）
• 拥塞算法：BBR
• 栈：fq + 增大 socket 缓冲

核心实测数据

温馨提示：下表是我当晚实测的单机样本，反映趋势与“同价位典型组合”的体验，不是官方基准。

机器	吞吐（RPS）	P99 延迟（ms）	CPU 总占用	备注
A：E-2288G	48,900	62	87%	高频单核强，动态 PHP 场景非常能打
B：4210R	41,300	85	82%	核多但频率低，单线程热点略吃亏
C：7302P	45,700	68	76%	Zen2 16C 折中，整体表现均衡
D：7443P	52,200	59	71%	综合最佳，并发扩展性强、延迟稳定

观察：

动态计算多、依赖单核的阶段（模板渲染、序列化、JSON 压缩），E-2288G 频率优势明显。

并发升到 1024 后，7443P 的 RPS 和 P99 最稳，失速最晚。

MySQL 8.0（sysbench oltp_read_write，128 线程）

机器	TPS	平均延迟（ms）	P95（ms）	磁盘写入（MB/s）
A：E-2288G	7,800	16.3	28.1	210
B：4210R	10,900	12.1	20.4	260
C：7302P	14,600	8.7	15.9	310
D：7443P	18,300	6.2	11.8	355

观察：

MySQL 更吃“核数 × 稳定频率 × 大缓存”，AMD 单路 P 系列在同价位上核数更高、单路 NUMA 一致性好，7443P 明显领先。

THP 关闭、O_DIRECT、生效的中断亲和对尾延迟的改善非常明显（见“坑位”）。

大带宽（iperf3，25G，16 并发流）

机器	吞吐（Gbps）	用户态 CPU	系统态 CPU	丢包
A：E-2288G + X710-10G	9.45（10G 满）	22%	18%	0.01%
B：4210R + CX4-25G	21.9	28%	24%	0.02%
C：7302P + CX4-25G	23.2	24%	21%	0.00%
D：7443P + CX5-25G	24.4	22%	18%	0.00%

观察：

25G 下 AMD 更容易打满：PCIe 4.0 通道宽裕、RSS 队列多、NUMA 配置到位后，CPU 占用更低。

Intel X710 在 10G 场景稳定，25G 建议直接上 Mellanox（CX4/CX5）或 Intel E810 这一代。

结果解读与选型建议

纯 Web 动态、追求单核响应：预算有限且单机为主，E-2288G 是“刀法精准”的选择；如果并发很高又要稳，7443P 综合最强。

MySQL/OLTP、Redis Cluster、Kafka 等并发 IO：AMD 7302P/7443P 更合算，尾延迟更容易压平。

大带宽、视频分发、对象存储网关：优先 AMD + 25G/100G CX4/CX5，PCIe 与 NUMA 带来的“上限”更高。

混部：Nginx/Node + MySQL 同机时，AMD 单路 P 系列的核数与 I/O 余量能更好兜底。

我踩过的坑与现场解决

reuseport + 多 worker 不均衡

现象：Nginx reuseport 开启后，某两个 worker 热点明显，P99 抖动。

定位：RSS 队列与 SO_REUSEPORT 的 hash 冲突，造成部分队列/worker 过热。

解决：

关闭 reuseport，改用 worker_cpu_affinity + SO_REUSEPORT 仅在监听多端口时使用；

or 提升 RSS 队列数并用上面的 pin_irqs.sh 绑定到不同 CPU。

MySQL 尾延迟飙升（NUMA/THP）

现象：sysbench P95 无规律尖刺到 100+ms。

定位：NUMA 默认分配在单节点，内存压力下跨节点访存 + THP 碎片。

解决：numactl --interleave=all 启 MySQL，禁用 THP，innodb_flush_method=O_DIRECT，并调大 innodb_log_file_size。

i40e（X710）Ring 太小导致 10G 高 PPS 掉包

现象：小包（TLS 握手风暴）阶段出现丢包。

解决：ethtool -G eth0 rx 4096 tx 4096，并升级固件；极端情况下换到 Mellanox。

BBR 未生效被回退到 CUBIC

现象：跨境链路吞吐卡在 2–3G。

定位：default_qdisc=fq 未设置，且某台机器 sysctl 被别的脚本覆盖。

解决：统一 sysctl.d 管理，启动项强制 sysctl --system，并加 CI 校验。

EPYC + 某些主板 ASPM 导致微抖

现象：P99 偶发 2–3ms 抬头（Web 静态场景）。

解决：BIOS 关闭 ASPM，OS 层加 pcie_aspm=off，稳定性改善。

一小时落地版：从裸机到上线的最小闭环

客户那边“今晚一定要顶住”，我当晚给了一个 AMD 7443P + 25G 的落地闭环，步骤如下：

装系统与内核（上文脚本）

网络与安全：firewalld 规整开放 80/443/3306/9100/9200，fail2ban 基础规则

安装 Nginx + PHP + MySQL（示意）

yum install -y nginx php-fpm php-opcache
rpm -Uvh https://repo.mysql.com/mysql80-community-release-el7-7.noarch.rpm
yum install -y mysql-community-server

systemctl enable nginx php-fpm mysqld
systemctl start mysqld

应用 Nginx/MySQL 配置（见上）

NUMA/IRQ 绑定（见脚本）

监控：node_exporter + mysqld_exporter + blackbox_exporter

压测校验：wrk/sysbench/iperf3 三板斧过一遍

回滚预案：保留原流量入口，四层 LVS/HAProxy 做 50/50 灰度

关键配置清单（可直接抄）

PHP-FPM（高并发、固定进程）

; /etc/php-fpm.d/www.conf
pm = static
pm.max_children = 160            ; 结合内存评估
pm.max_requests = 500
request_terminate_timeout = 60s

Nginx CPU 亲和（24c 示例）

# 绑核示意，按实际 CPU map
worker_processes 24;
worker_cpu_affinity
000000000000000000000001
000000000000000000000010
000000000000000000000100
...

sysbench 命令备忘

# 准备 60GB 数据
sysbench /usr/share/sysbench/oltp_read_write.lua --mysql-host=127.0.0.1 \
  --mysql-user=root --mysql-password= --tables=32 --table-size=1000000 prepare

# 128 线程压
sysbench /usr/share/sysbench/oltp_read_write.lua --mysql-host=127.0.0.1 \
  --mysql-user=root --mysql-password= --tables=32 --table-size=1000000 \
  --threads=128 --time=60 run

wrk 压测

wrk -t16 -c1024 -d60s --latency https://target.hk.example.com/php

iperf3（Server 端）

iperf3 -s
# Client 端（16 并发）
iperf3 -c <server_ip> -P 16 -t 60

预算与场景选型矩阵（简表）

场景/预算	首选	可选	备注
动态 Web 单机、成本敏感	E-2288G	7302P	高频优先、响应敏捷
混合 Web + API 并发	7302P	7443P	更好的核数与扩展
MySQL/PG OLTP	7443P	7302P	尾延迟更稳
25G 大带宽分发	7443P + CX5	7302P + CX4	PCIe/RSS/NUMA 上限更高
10G 稳定透传	E-2288G + X710	4210R + CX4	成本可控

别再问站队哪边，我站业务”

凌晨 5:10，客户把灰度切到 80%，电话那头终于不再紧张：“页面开得很顺，库也稳了。”
我靠着机柜坐了一会儿，心里只有一句话：别再问 Intel vs AMD 谁赢。站业务，才是我们运维的职业立场。
你能从上面的数据看到：单核敏捷的 Web 高频 Intel 很香；并发/数据库/大带宽，AMD 单路 P 系列更划算、上限更高。
关键是：别忘了 NUMA、IRQ、THP、BBR 这些“脏活累活”。硬件选得好，调优做得实，系统才会稳。