场景与痛点

美国服务器机房普遍配备高频CPU（如Xeon Gold 6xxx或AMD EPYC）和NVMe SSD，硬件堆料很猛，但MySQL在跨国高并发写入场景下，延迟却经常飙到100ms以上。很多人第一反应是调innodb_flush_log_at_trx_commit或加buffer pool，但忽略了两个核心瓶颈：binlog组提交的等待策略与跨NUMA访问的内存延迟。本文直接拆解这两个问题，附带实测命令和配置。

1. 定位跨NUMA访问：perf stat抓现行

先确认MySQL进程是否被跨NUMA节点调度。登录服务器后，不要直接重启，先采集10秒数据：

# 查找mysqld PID
pgrep -x mysqld | head -1
# perf stat采样，关注cache-misses和remote-access
perf stat -e cache-misses,remote-node-accesses -p $(pgrep -x mysqld) -- sleep 10

如果remote-node-accesses数值占比较高（超过cache-misses的20%），说明MySQL内存分配与CPU调度不在同一NUMA节点。我在轻云互联的美国服务器上实测，未绑定时remote-access占比直接冲到37%，绑定后降到了2%以下。

2. NUMA绑定：numactl + taskset闭环

不要用numactl --interleave，那是科学计算用的，对数据库弊大于利。用--membind绑定内存分配策略，同时用taskset锁定CPU核心。

2.1 查看NUMA拓扑

numactl --hardware
# 输出示例：
# node 0 cpus: 0-15,32-47
# node 1 cpus: 16-31,48-63
# node 0 size: 256 GB
# node 1 size: 256 GB

假设MySQL独占node 0，且使用0-15,32-47（包括超线程兄弟核心）。

2.2 修改systemd启动配置

不要直接改mysqld_safe脚本，用systemd覆盖更干净：

mkdir -p /etc/systemd/system/mysqld.service.d/
cat > /etc/systemd/system/mysqld.service.d/numa.conf << 'EOF'
[Service]
ExecStartPre=
ExecStartPre=/usr/bin/numactl --membind=0 --cpunodebind=0 /usr/sbin/mysqld --defaults-file=/etc/my.cnf
EOF
systemctl daemon-reload
systemctl restart mysqld

验证绑定是否生效：

cat /proc/$(pgrep -x mysqld | head -1)/status | grep -i cpus_allowed_list
# 应该显示0-15,32-47
numactl --show $(pgrep -x mysqld | head -1)
# 检查policy和node绑定

3. binlog组提交参数：调优核心

MySQL 8.0默认sync_binlog=1，每次事务提交都fsync binlog。在NVMe SSD上，这不再是磁盘瓶颈，而是组提交的等待延迟——每个事务都在等上一个事务的binlog刷盘完成。

3.1 关键参数链

# 在my.cnf的[mysqld]段添加
sync_binlog=1
binlog_group_commit_sync_delay=1000
binlog_group_commit_sync_no_delay_count=10
innodb_flush_log_at_trx_commit=1

• sync_binlog=1：保证binlog不丢，但配合grou commit参数不会导致频繁fsync。
• binlog_group_commit_sync_delay=1000：等待1000微秒（1ms）以聚合更多事务。
• binlog_group_commit_sync_no_delay_count=10：如果等待期间已经有10个事务排队，立即刷盘，不等到1ms。这个参数在NVMe SSD上效果极其显著。

3.2 压测对比

用sysbench模拟写入：

sysbench oltp_write_only --threads=64 --time=60 --mysql-host=127.0.0.1 --mysql-user=root --mysql-password=xxx --table-size=1000000 run

调优前后典型数据（美国服务器，64线程，NVMe SSD）：

• 默认：延迟P95=45ms，TPS=5200
• 调优后：延迟P95=18ms，TPS=11800

延迟降低60%以上，吞吐翻倍。注意如果binlog磁盘是SATA SSD或HDD，延迟需要适当放大（3000-5000微秒）。

4. 网卡RSS队列绑定：抢锁的隐形杀手

高并发场景下，网卡中断被分配到与MySQL不同的CPU核心，会导致严重的锁冲突和上下文切换。尤其当MySQL进程绑定在node 0，而网卡中断落在node 1时，跨NUMA抢锁会额外增加5-10%的延迟。

4.1 中断亲缘性设置

# 查看网卡中断号
cat /proc/interrupts | grep eth0
# 假设中断号是 78-85
# 将中断绑定到MySQL所在的CPU核心（0-15,32-47）
echo 00000000ffffffff > /proc/irq/78/smp_affinity
echo 00000000ffffffff > /proc/irq/79/smp_affinity
# ... 对所有相关中断重复

更好的做法是关闭irqbalance，改用脚本手动绑定：

systemctl stop irqbalance
systemctl disable irqbalance
# 绑定中断的脚本示例（放到rc.local或systemd service）

5. 验证效果：show engine innodb status抓细节

调优后不只看TPS，还要看LOG段的等待信息：

mysql> show engine innodb status\G
# 重点关注：
# ---LOG---
# Log i/o's done: ... log writes: ... pending writes: 0
# 如果pending writes频繁不为0，说明IO瓶颈。
# 看看有没有 "buf pool resize" 或 "page cleaner" 等待

同时用iostat -x 1观察磁盘：

# NVMe SSD的await应 < 0.1ms，svctm基本忽略
# 如果await > 0.5ms，说明磁盘队列深度不够或块层调度器有问题

# 调整块层队列深度（NVMe默认较高，但可以进一步放大）
echo "512" > /sys/block/nvme0n1/queue/nr_requests
# 调度器用none（NVMe推荐）
echo "none" > /sys/block/nvme0n1/queue/scheduler

6. 避坑：组提交参数与主从复制的联动

如果这台美国服务器是MySQL主库，binlog_group_commit_sync_delay会导致binlog延迟写入，进而拉长从库的复制延迟。解决方法是：

• 从库设置slave_parallel_workers=8和slave_parallel_type=LOGICAL_CLOCK。
• 主库设置binlog_transaction_dependency_tracking=WRITESET，让从库能更快并行回放。

实测在跨洋链路上，主库这个延迟参数不会额外增加从库延迟，反而因为主库TPS提升，从库整体吞吐更高。

7. 终极检查清单

# 一条命令检查所有关键点
echo "=== NUMA绑定 ===" && numactl --show $(pgrep -x mysqld | head -1) | grep -E 'policy|preferred' && echo "=== 中断亲缘 ===" && cat /proc/interrupts | head -n1 && cat /proc/interrupts | grep eth0 | awk '{print $1, $NF}' && echo "=== 块队列 ===" && for d in /sys/block/nvme*n1; do echo "$d: nr_requests=$(cat $d/queue/nr_requests) scheduler=$(cat $d/queue/scheduler)"; done && echo "=== binlog参数 ===" && mysql -e "SHOW VARIABLES LIKE 'binlog_group_commit%'; SHOW VARIABLES LIKE 'sync_binlog';"

全部调优完成后，延迟裁半不是夸张，是常态。美国服务器的高频CPU和NVMe SSD底子本来就硬，把内存跨NUMA的坑填上、把组提交的等待策略调准，写入性能直接翻倍。