Redis主线程跨NUMA节点调度会显著放大内存访问延迟：本地访问约100ns，远端访问超250ns，导致P99延迟抖动；网卡中断与Redis不在同一节点时，数据路径绕远并挤占互连带宽；THP在Redis场景下引发毫秒级延迟尖刺，关闭后P99标准差降60%以上。

Redis主线程频繁跨NUMA节点调度会放大内存访问延迟

Redis是单线程事件循环模型，主线程处理命令、网络IO和定时任务。在默认调度下，Linux内核可能把Redis进程从Socket 0迁移到Socket 1运行，而它之前缓存的热点数据（如键值对元信息、客户端连接结构体）仍留在Socket 0的本地内存中。此时Redis读取这些数据就会触发远端内存访问——延迟从约100ns跳到250ns以上，P99延迟直接抖动。这不是Redis代码问题，而是硬件拓扑与OS调度策略错配导致的。

网卡中断和Redis不在同一NUMA节点时，网络数据路径绕远

当网卡（比如eth0）物理上连在Socket 0，但其中断被分配到Socket 1的CPU上处理时，内核会把接收到的数据包写入Socket 1的内存缓冲区。Redis主线程若运行在Socket 0，每次epoll_wait返回后调用read()，都要跨总线去Socket 1拿数据。这个过程不仅延迟高，还挤占QPI/UPI互连带宽，影响其他服务。

• 查网卡所属NUMA节点：cat /sys/class/net/eth0/device/numa_node
• 查当前中断分布：cat /proc/interrupts | grep eth0
• 强制绑定中断到目标节点核心：echo "0-7" > /proc/irq//smp_affinity_list（需先停掉irqbalance）

THP（Transparent Huge Page）在Redis场景下会引发周期性延迟尖刺

THP试图自动合并4KB页为2MB大页以减少TLB miss，但Redis大量随机小对象分配+频繁fork子进程（RDB/AOF rewrite），会导致内核在copy-on-write时阻塞主线程长达毫秒级。实测关闭THP后，P99延迟标准差下降60%以上。

redis-tools

按类别查找Redis命令、检测服务器连接、监控键数量和内存占用，支持离线速查表。

下载

• 临时关闭：echo never > /sys/kernel/mm/transparent_hugepage/enabled
• 永久关闭（openEuler等发行版需防tuned覆盖）：echo 'echo never > /sys/kernel/mm/transparent_hugepage/enabled' >> /etc/rc.local，并检查GRUB_CMDLINE_LINUX中是否含transparent_hugepage=never

server_cpulist比taskset更可靠，但必须配合I/O线程隔离

taskset -c 0,2,4,6 redis-server只作用于启动瞬间；一旦Redis因OOM或信号重启，亲和性就丢失。Redis 6.0+的server_cpulist参数写进redis.conf才是持久化方案。但要注意：如果启用了io-threads（Redis 7.0+），这些线程默认会抢占主线程绑定的核，必须显式配置io-threads-cpulist错开物理核。

• 正确配置示例：
  server_cpulist 0,2,4,6
io-threads 4
io-threads-cpulist 1,3,5,7
• 修改后必须执行redis-cli shutdown再redis-server redis.conf重载，CONFIG REWRITE不生效
• 别忘了客户端压测工具也要绑核：taskset -c 1,3,5,7 redis-benchmark -t set,get -n 1000000

实际效果取决于你是否把Redis主线程、网络中断、I/O线程、客户端连接四者全部锁在同一NUMA节点内。脱离拓扑谈“绑核”，只是把性能问题从“随机抖动”变成“稳定低效”。