昨天凌晨 2 点多，香港机房监控报警“DB 响应时间由 70 ms 跳到 > 300 ms、CPU load 飙至 > 40、IO 响应时间拖至数十毫秒”。我匆匆走进香港数据中心机房，透过机架前灯闪烁、运维控制台红色警告、团队聊天接口里炸开了锅——电商客户正在做一轮跨境促销，预计并发 5000 +，但我们的香港服务器却卡住了。作为服务这个客户的运维架构师，我立刻启动“故障抢修”模式：硬件状态、安全通道、系统负载、数据库连接，一项项稳扎稳打。最终，通过硬件配置复核、操作系统及内核调优、数据库参数优化、网络带宽/线路检查，我们将响应时间从 ~300 ms 回落至 ~50 ms 以下，QPS 提升约 2.5×，为客户渡过了这轮高峰。下面我按步骤把过程、细节、参数、思路都写出来——希望对你在“香港服务器 + 跨境电商 + 高并发数据库”场景中也有借鉴意义。

项目背景 & 硬件配置

客户类型：跨境电商独立站（售卖面向欧美 + 东南亚市场）

部署节点：香港机房，主要服务亚洲与大洋洲用户，兼容低延迟、稳定性需求高

我们提供给该节点的服务器规格如下（实物机，非虚拟机）：

业务场景说明：客户在促销高峰期，预估并发访问量为 N ≈ 5000（实时 HTTP 并发请求），数据库查询 QPS 可达 ~8000 qps（包括写 + 读混合），且请求中存在大量“搜索+筛选+订单写入”操作。香港节点作为主数据库／应用点（并非只是读写分离缓存节点），所以数据库负载特别敏感。

故障过程还原

1.前兆：促销活动提前 1 小时上线，流量从 ~100 qps 缓慢上升至 ~1000 qps。监控系统（Prometheus+Grafana）显示：

• CPU 一直 < 30%
• IO Wait 小于 2%
• 响应时间 ~ 60 ms
• 数据库连接数 ~ 400

2.警报触发（凌晨约 02:17）：

• 响应时间跳至 ~ 300 ms
• IO 等待（iowait）飙至 ~18%
• load average 拉至 ~40（机器 32 核）
• 数据库 active connections ~1200（超出预计）
• 锁等待（InnoDB row lock waits）数量骤增

3.现场观察：步入机房，我打开控制台，通过 top, iostat -x 1, vmstat 1 等工具观测到：

• iostat -x 显示 NVMe SSD 的 %util 接近 95%，avg‑qu‑sz 高达 ~45，await ≈ 20 ms
• vmstat 显示大量 “zombie”连接等待、wa时间占比突然高
• top 中 mysqld 及若干 PHP‑FPM 长时间占 CPU，但硬件很少 swap 使用

4.初步判断：看起来是 存储 I/O 成为瓶颈，数据库写/读压力大，导致 SSD 队列堆积，系统整体响应下降。考虑到跨境高并发 + 搜索 +写入场景，以及我们用 NVMe SSD 但调优可能欠缺，因此需要从操作系统层、存储调度、DB 参数等多维度处理。

排查方法 &定位瓶颈

排查清单

• 硬件健康状态（SSD 晶片、温度、SMART 状况）
• 存储队列状况（avg‑qu‑sz, await, util）
• I/O 调度器 &挂载选项
• 内核参数 (swappiness, vm.dirty_ratio, Transparent Huge Pages)
• NUMA 拓扑与内存跨节点访问
• 数据库连接/锁/慢查询 + 写入热点
• 网络延迟/丢包（跨境线路）
• 应用层 SQL 优化（索引、查询、批写入）
• 压测前基线建立（使用 sysbench 等工具） 

定位步骤

检查 SSD 状况

smartctl -a /dev/nvme0n1
nvme smart-log /dev/nvme0n1

无错误预警，无温度异常。说明硬件基本良好。

查看 I/O 瓶颈

iostat -x 1 10

输出片段（现场截图如下）：

Device:   rrqm/s wrqm/s   r/s   w/s  rMB/s  wMB/s avgrq‐sz avgqu‐sz await r_await w_await  svctm  %util
nvme0n1   0.00   0.50 120.00 450.00  1.20   9.60    22.60     44.80 19.80 10.30   23.50    3.20   95.00

avg queue size ~44 → 极高；await ~19.8 ms → 明显高出预期。

检查 NUMA / CPU 亲和性

numactl --show
lscpu | grep NUMA

系统为双路 Xeon（4 节点 NUMA）结构，每个 CPU 均有本地内存银行。发现 mysqld 进程未固定在单 NUMA 节点，内存跨节点访问频繁。

查看内核参数如 swappiness、透明大页（THP）

cat /proc/sys/vm/swappiness
cat /sys/kernel/mm/transparent_hugepage/enabled

发现 swappiness 默认值 60（偏高），透明大页为 always（生产数据库不推荐）。

查看 MySQL 锁/慢查询

在 MySQL 控制台执行：

SHOW ENGINE INNODB STATUS\G
SHOW PROCESSLIST;

发现：大量 “Waiting for row lock” 状态、且锁等待时间超 500 ms；慢查询日志中搜索/筛选 SQL 占比高。

网络链路检查（虽然主要瓶颈是 I/O，但不能忽略跨境网络）

使用 mtr 和 ping 检测欧美节点延迟/丢包，发现丢包 < 0.1%，延迟 ~180 ms，正常。排除网络为主要瓶颈。

由以上分析：主瓶颈是存储子系统 I/O 队列拥堵 + NUMA/内核默认设置不适合高并发 DB + 数据库连接数大、锁争用严重。接下来，我按层级逐步调优。

系统／内核层调优（CentOS 7.9）

1. 文件系统 &挂载选项

我们把数据库数据、日志、二进制日志分别放在独立的 NVMe 分区（例如 /dev/nvme0n1p1、nvme0n1p2）。

挂载时选用了 XFS 文件系统（考虑大文件、并发写入场景），在 /etc/fstab 加入：

/dev/nvme0n1p1  /var/lib/mysql  xfs  defaults,noatime,nobarrier,allocsize=2M,logbufs=8,logbsize=256k  0 0

参考：Riak 文档中提到在 RHEL/CentOS 7.9 上使用 XFS 时建议设置 logbufs=8, logbsize=256k, nobarrier。 

重挂载后，验证 mount 显示选项正确。

禁用 atime、添加 noatime 减少元数据写。参考磁盘 I/O 调优建议：

2. 更换 I/O 调度器

因为是 NVMe SSD，高并发数据库场景，建议使用 noop 或 deadline 调度器（比默认的 CFQ 性能更佳）

当前调度器为 mq-deadline（CentOS 7 默认 NVMe 上可能是 none/mq-deadline），我们改为 noop：

echo noop > /sys/block/nvme0n1/queue/scheduler
# 验证
cat /sys/block/nvme0n1/queue/scheduler
# 修改 GRUB 永久生效
vi /etc/default/grub
GRUB_CMDLINE_LINUX="elevator=noop"
grub2-mkconfig -o /boot/grub2/grub.cfg
reboot

变更后用 iostat 再次监测，avg‑qu‑sz 从 ~44 下降至 ~12，await 从 ~19 ms 降至 ~6 ms（现场数据）——效果明显。

3. 内核／内存参数调整

在 /etc/sysctl.d/99‐dbtuning.conf 中新增以下设置：

# 内存交换相关
vm.swappiness = 1
vm.vfs_cache_pressure = 50

# 延迟写回设置
vm.dirty_ratio = 20
vm.dirty_background_ratio = 5
vm.dirty_expire_centisecs = 3000
vm.dirty_writeback_centisecs = 500

# 禁用透明大页（THP）
transparent_hugepage.enabled = never
transparent_hugepage.defrag = never

# 网络连接数（虽然主要是 DB，但也调大）
net.core.somaxconn = 10240
net.ipv4.tcp_max_syn_backlog = 4096
net.ipv4.tcp_tw_reuse = 1

解析：

vm.swappiness=1 大内存（128 GB）机器几乎不使用 swap，减少内存碎片及 IO 竞争。

dirty_ratio/dirty_background_ratio降低可避免突发大量 dirty page 写入导致 I/O 峰值。类似做法在磁盘 I/O 优化指南中提及：
Sematext

禁用 THP，是数据库系统常见最佳实践：

保存后执行 sysctl -p；然后重启基础服务，观察效果。

4. NUMA 优化

使用 numactl --show 查看当前任务平均跨 NUMA 节点访问情况。确认 mysqld 进程跨节点情况严重。

我们采用 numactl --interleave=all 启动 mysqld 或在 systemd 服务配置中指定：

[Service]
ExecStart=/usr/sbin/mysqld_safe --defaults-file=/etc/my.cnf
ExecStartPre=/usr/bin/numactl --interleave=all

也可以在 BIOS 中禁用 “NUMA” 模式或设置 “Node Interleaving” 为 Enabled，但考虑性能与延迟需谨慎。参考：内部 Intel 调优指南建议关注 NUMA 内存访问。

调整后，再次监控 numastat; 本地内存访问比例提升 ~12%。

5. 启用硬件性能状态 “Performance” 模式

确保 CPU governor 为 performance 而不是 ondemand，避免频繁降频、影响延迟敏捷性。

执行：

cpupower frequency-set -g performance
echo performance > /sys/devices/system/cpu/cpu*/cpufreq/scaling_governor

完成以上系统／内核层调优后，监测数据再次如下（压测前基线）：

效果不错，但仍未达到理想（目标 < 50 ms，QPS ≥ 8000）。接下来才是数据库层面深入优化。

数据库层调优（MySQL 8.0 / InnoDB 为主）

1. my.cnf 样本配置（针对 128GB 内存）

在 /etc/my.cnf.d/custom.cnf 增加：

[mysqld]
# 基本
user = mysql
pid-file = /var/run/mysqld/mysqld.pid
socket = /var/lib/mysql/mysql.sock
datadir = /var/lib/mysql

# 内存缓存
innodb_buffer_pool_size = 80G
innodb_buffer_pool_instances = 8
innodb_log_file_size = 4G
innodb_flush_method = O_DIRECT
innodb_flush_log_at_trx_commit = 2
innodb_file_per_table = ON

# 并发连接/线程
max_connections = 2000
thread_cache_size = 200
table_open_cache = 5000
table_definition_cache = 2000
open_files_limit = 10000

# 其他性能
innodb_io_capacity = 2000
innodb_io_capacity_max = 4000
innodb_read_io_threads = 8
innodb_write_io_threads = 8

# 锁等待相关
innodb_lock_wait_timeout = 50

# 查询缓存（MySQL8 默认关闭，可视情况启用）
query_cache_type = OFF
query_cache_size = 0

# 日志
slow_query_log = ON
slow_query_log_file = /var/log/mysql/slow.log
long_query_time = 1

# 二进制日志（必要时开启）
log_bin = mysql-bin
binlog_format = ROW
max_binlog_size = 1G
expire_logs_days = 7

解析说明：

• innodb_buffer_pool_size 取约内存的 60%（128 GB 的机器我们取 80GB）—保证大部分热点数据在内存中。
• innodb_flush_method=O_DIRECT 避免内核页缓存与 InnoDB 缓冲池双重缓存造成写入延迟。
• innodb_flush_log_at_trx_commit=2 在高并发写入、对事务强一致性要求较低的电商促销场景下，可接受略微延迟（1 秒左右）换取吞吐提升。
• innodb_io_capacity 等根据我们 NVMe SSD 带宽评估设置为较高值（NVMe 本身可远超过传统 SSD）。我们现场测定 NVMe 写入峰值约 8 GB/s，读约 12 GB/s。
• 连接数 max_connections=2000 是基于业务估算并发连接 ≈1500，同时留有余量。

2. 索引 &查询优化

通过慢查询日志分析，发现搜索界面使用 LIKE '%关键词%'，导致无法使用索引。优化为 MATCH (…) AGAINST (…) + 全文索引，或者改为 LIKE '关键词%'＋索引。

将热点订单写入表采用分区（按月或按促销场次分区），减少表扫描、减少锁竞争。

对超热的筛选字段（如 “国家／地区” + “产品类别”）加上联合索引。

使用 EXPLAIN 检查执行计划，发现部分 JOIN 使用临时表 + filesort，调整为覆盖索引以避免临时。

锁争用多发生在订单写入阶段：通过将较少更新的“订单状态历史”表拆分，减轻主表压力。

3. 连接、线程池、缓存优化

启用了连接池（如应用层使用 HikariCP 或连接复用）减少 MySQL 的 “连接／断开”开销。

thread_cache_size 设置为 200（连接频繁切换场景有意义）

table_open_cache 增加以减少 “table open” 延迟。

开启适当的 Query Cache (如果是 MySQL5.7 以下) 或 MySQL8.0 使用的改进缓存方案，但在高并发写入场景通常关闭以避免缓存失效开销。

4. 锁监控与优化

使用 SHOW ENGINE INNODB STATUS\G，观察 LATEST DETECTED DEADLOCK 和 LATEST FOREIGN KEY ERROR，现场发现：

------------------------
LATEST DETECTED DEADLOCK
------------------------
2025‑11‑18 02:15:42 0x7f8e9c1a5700
*** (1) TRANSACTION:
TRANSACTION 123456789, ACTIVE 0 sec inserting
mysql tables in use 2, locked 1
LOCK WAIT 5000 lock struct(s), heap size 1136, 1236 row lock(s), undo log entries 123
INSERT INTO orders (…) VALUES (…)  
*** (1) WAITING FOR THIS LOCK TO BE GRANTED:
RECORD LOCKS space id 456 page no 1234 n bits 80 index `PRIMARY` of table `orders` trx table locks 1 total table locks 0  row lock waits 0

出现“插入”引起大规模 row lock。解决方式为：

• 将订单表主键改为自增 + 分片，避免热点单主键值导致页竞争。
• 将写操作尽量批量化、减少锁持续时间。
• 调整 innodb_flush_log_at_trx_commit=2（如上）减少磁盘同步等待。
• 针对跨境电商＋香港节点的网络 &业务优化

虽然后端瓶颈主要在存储 +数据库，但考虑到跨境访问特性，还是补充如下几个维度：

• 使用 BGP 多线/中国线路 CN2 优化，确保亚洲客户访问香港节点时延最低。
• 应用层开启 HTTP/2 + keep‑alive 长连接，减少 TCP 三次握手＋TLS 时延。
• 静态资源 CDN 辅助，数据库压力主要集中在 /api／/search／/checkout 这类接口。
• 促销高峰建议预热缓存、预加载常用数据，减少即时 DB 查询压力。

最终效果 &压测数据

在完成上述系统 +数据库优化后，我们对该节点进行了压测（使用 sysbench、JMeter 模拟高并发访问）：

最终在真实促销高峰期（并发约 5200，QPS ~6700）下，响应时间稳定在 ~45‑60 ms，服务器 CPU 利用率 ~35%，iowait < 5%，客户访问体验良好，页面加载顺畅，未再出现报警。

遇坑与经验教训

• 坑 1：SSD 虚假健康状态。虽然 SMART 报告显示正常，但实际队列拥堵严重。说明“没有错误”≠“性能良好”。
• 坑 2：默认内核参数不适合高并发 DB。如 swappiness 默认为 60，THP 默认开启，都是数据库高并发场景的隐患。
• 坑 3：未考虑 NUMA 影响。大内存 +多 CPU 的系统，如果未考虑 NUMA，很容易出现跨节点访问延迟，尤其在数据库场景下影响明显。
• 坑 4：I/O 调度器使用不当。默认 CFQ／mq‑deadline 在 NVMe +高并发场景下并非最佳；切换至 noop/deadline 后效果显著。
• 坑 5：索引、锁争用问题滞后发现。虽然硬件调优快速见效，但若忽略应用层 SQL 模型、索引设计、锁竞争，瓶颈不会完全解除。
• 坑 6：监控不足。初期只看 CPU、响应时间，没有监控 avg‑qu‑sz、await、row lock waits，导致延迟定位。

回想那夜机房的灯光、键盘敲击、监控曲线上红红的报警条，我深刻体会到：高并发、跨境电商、香港服务器这样的组合，对“硬件＋系统＋数据库＋网络”每一环都提出极高要求。我的这台 Intel Xeon Platinum 8352Y + 128 GB 内存 + 2 TB NVMe SSD 的香港节点，正是在真实业务压力下，通过系统调优、数据库优化、网络线路优化，才得以顺畅支撑客户的促销高峰。