redis启动时提示错误：<jemalloc>: Unsupported system page size - 运维

这是一个比较常见的错误，通常是因为 Redis 检测到的系统页面大小（Page Size）与它编译时预期的值不兼容。jemalloc（Redis 默认的内存分配器）对页面大小有特定要求。

下面我将为您提供一套从简单到复杂的解决方案。

错误原因深度解析

现代 Linux 系统支持多种页面大小（如 4KB, 64KB）。而 Redis，尤其是通过包管理器（如 apt）安装的预编译版本，通常是在常见的 4KB 页面大小系统上编译的。如果你的系统环境（例如某些 Docker 容器、ARM 架构设备或做了特殊内核配置的系统）使用了 64KB 或其他非标准页面大小，预编译的 Redis 二进制文件就会遇到这个错误。

解决方案（按推荐顺序尝试）

方案 1：使用 `--disable-jemalloc-prefix` 参数启动（临时解决）

这是最快捷的临时解决方法，它告诉 Redis 使用系统默认的 malloc 而不是 jemalloc。

启动命令：

redis-server --disable-jemalloc-prefix

验证是否生效： 启动后，使用 redis-cli 连接，然后执行 INFO memory，查看 mem_allocator 字段。如果显示为 libc，则表示成功使用系统内存分配器。

优点： 快速简单，无需重新安装。 缺点： 可能不是性能最优的方案，因为 jemalloc 通常能更好地处理内存碎片。

方案 2：从源码编译 Redis（推荐的根本解决方法）

这是最彻底、最稳定的解决方案。通过在你的环境中编译，可以确保生成与当前系统页面大小完全兼容的二进制文件。

步骤：

安装编译依赖：

# 对于 Ubuntu/Debian
sudo apt update
sudo apt install build-essential
# 对于 CentOS/RHEL/Rocky Linux
sudo yum groupinstall "Development Tools"
# 或者（对于较新版本）
sudo dnf groupinstall "Development Tools"

下载并解压 Redis 源码： 请访问 https://redis.io/download/ 获取最新稳定版下载链接。
```
wget https://download.redis.io/releases/redis-7.2.4.tar.gz
tar -xzf redis-7.2.4.tar.gz
cd redis-7.2.4
```

编译并安装：

# 编译，-j 参数指定并行编译的作业数，通常设为 CPU 核心数，可以加快速度
make -j$(nproc)
# 安装到系统目录（默认是 /usr/local/bin）
sudo make install

验证新安装的 Redis：

# 查看新 Redis 的路径
which redis-server
# 启动 Redis，不再需要特殊参数
redis-server

现在错误应该消失了。

方案 3：检查并修改系统页面大小（高级操作，谨慎使用）

除非你明确知道自己需要改变页面大小，否则不推荐此方案，因为它可能影响整个系统的稳定性。通常这只是为了确认问题根源。

检查当前页面大小：
```
getconf PAGE_SIZE
```
或者
```
echo $(getconf PAGE_SIZE)
```
常见输出：
- 4096 (4KB): 这是标准大小，Redis 预编译版预期的大小。
- 65536 (64KB): 这通常是不兼容的根源，常见于 Docker 的 alpine 镜像或某些 ARM 设备（如 Apple Silicon Mac 的早期容器环境）。
如何改变页面大小（以 Docker 为例）： 如果你的 Redis 运行在 Docker 容器中，并且基础镜像（如 Alpine）使用 64KB 页面，最简单的办法是换一个使用 4KB 页面的基础镜像。

将 Dockerfile 中的：
```
FROM alpine:latest
```
更换为：
```
FROM debian:bookworm-slim
# 或
FROM ubuntu:22.04
```
Debian/Ubuntu 系列镜像默认使用 4KB 页面，与绝大多数预编译软件兼容性更好。

总结与最佳实践

方案	适用场景	优点	缺点
方案 1 (启动参数)	快速验证、临时测试	极其简单，无需编译	性能可能非最优，治标不治本
方案 2 (源码编译)	生产环境、长期使用	性能最佳，一劳永逸	需要安装编译工具，步骤稍多
方案 3 (修改系统)	在特定容器或嵌入式环境中	可能解决根本环境问题	风险高，可能影响其他应用

强烈建议采用方案 2（从源码编译），这是最可靠的方法，能确保 Redis 在你的特定环境中获得最佳性能和稳定性。方案 1 仅作为临时测试使用。