arm架构redis性能不足主因是编译未启用原生指令集与jemalloc内存分配器：必须添加-march=native -mtune=native及malloc=je，禁用过时arch参数，否则吞吐损失10%~20%。
ARM架构上Redis性能不如x86，不是硬件不行，而是默认编译没“认出”ARM的指令集和调度特性——直接套用x86的make命令或RPM包，大概率会丢掉10%~20%的吞吐能力。
编译时必须加-march=native -mtune=native，否则ARM核心跑不满
ARM芯片（比如鲲鹏920、飞腾D2000）支持ARMv8-A指令集、NEON向量单元、AES加密扩展，但GCC默认不启用。不加-march=native，编译出来的redis-server连基础的LSE（Large System Extension）原子指令都用不上，INCR、HSET这类高频命令会退化成多条普通指令模拟，延迟明显升高。
实操建议：
- 编译前先确认当前CPU支持的特性：
lscpu | grep "Architecture\|Features"，看到aarch64和fp asimd aes pmull sha1 sha2 crc32 atomics才算完整支持 - 强制指定ARM64通用优化（兼容性更强）：
make CFLAGS="-O3 -march=armv8-a+crypto+simd -mtune=generic" - 若确定是鲲鹏920，可进一步收紧：
make CFLAGS="-O3 -march=armv8-a+crypto+simd+lse -mtune=tsv110"（lse对Redis的CAS操作提升显著） - 避免用
-mcpu——它在较新GCC中已被-mtune和-march覆盖，混用反而可能触发编译器bug
MALLOC=je不是可选项，是ARM平台的刚需
x86上glibc malloc表现尚可，但在ARM多核高并发场景下，glibc的arena锁争用严重，INFO memory里常能看到mem_allocator:glibc + 高allocator_stats碎片率。Jemalloc专为多核设计，其per-CPU缓存机制能直接压降zmalloc调用开销。
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
实操建议：
- 必须显式指定：
make MALLOC=je，不能依赖make自动探测 - Jemalloc需提前安装：
yum install jemalloc-devel（麒麟v10源里有），否则编译会静默回退到glibc - 验证是否生效：启动后执行
redis-cli INFO memory | grep mem_allocator，输出必须是jemalloc-5.2.1（或类似版本） - 注意jemalloc 5.3+在ARM上偶发
assert(bin->slabcur == NULL)崩溃，生产环境建议锁定jemalloc-5.2.1
别碰ARCH=arm64，这是过时机参数
Redis 6.0+已废弃ARCH变量，硬加make ARCH=arm64不仅无效，还会干扰GCC对-march的解析，导致编译失败或生成非aarch64二进制。官方构建逻辑现在完全由GCC自身识别uname -m输出决定。
常见错误现象：
-
make ARCH=arm64后file src/redis-server显示ELF 64-bit LSB shared object, x86-64——说明根本没编译成ARM版 - 报错
error: unknown type name ‘__int128’——因为ARCH=arm64强行启用了x86专属宏定义 - 正确做法：删掉所有
ARCH=xxx，只靠CFLAGS驱动，make会自动走src/Makefile里的aarch64分支
真正卡住性能的，往往不是大配置项，而是编译那一刻选错的一个flag。ARM上Redis的“快”，藏在-march的精度里、MALLOC=je的链接里、以及彻底抛弃过时参数的决心里——这些地方错了，调再久的maxmemory-policy也补不回来。
