mysql启用large-pages失败主因是内核未预分配大页、mysql用户无memlock权限或systemd服务缺失cap_ipc_lock能力；配置large-pages须为独立布尔项，验证需查@@large_pages值及innodb状态中的“large pages used”。

MySQL 启动时提示 Failed to set up huge pages 或 Cannot allocate memory for huge pages

这说明 MySQL 进程根本没拿到大页内存，不是配置写错了，而是底层条件全没满足。常见原因有三个：内核没预分配 vm.nr_hugepages、MySQL 用户没被允许锁定内存（memlock 限制未解除）、或 mysqld 启动时没获得 CAP_IPC_LOCK 权限（systemd 服务默认不给）。

必须按顺序处理：

• 先用 sysctl -w vm.nr_hugepages=2048 分配足够页数（按 InnoDB buffer pool + 10% 算，每页默认 2MB）
• 再在 /etc/security/limits.conf 加两行：mysql soft memlock unlimited 和 mysql hard memlock unlimited（假设 MySQL 运行用户是 mysql）
• 最后检查 systemd service 文件（如 /usr/lib/systemd/system/mysqld.service），确保包含 LimitMEMLOCK=infinity 和 CapabilityBoundingSet=CAP_IPC_LOCK，否则 ulimit 设置会被覆盖

my.cnf 里写 large-pages=1 却不生效

MySQL 的 large-pages 是个布尔开关，**不能带等号和值**，也不能加引号。写成 large-pages=1 或 large-pages="ON" 都会被忽略，启动日志里也不会报错，只会静默 fallback 到普通页。

正确写法只有一行，放在 [mysqld] 段内：

large-pages

验证是否真正启用，别信配置文件，执行 SQL：

SELECT @@large_pages; —— 返回 1 才算成功；

Zynq Linux Hardware Debug

Zynq‑7000 / Zynq UltraScale+ 硬件调试技能。适用于 Xilinx Zynq（Cortex‑A9/A53 + FPGA）Linux 环境，调试 I2C、I2S、UART、GPIO 等外设。包括设备树配置、内核驱动、用户空间调试工具、交叉编译和常见问题排查，支持 PetaLinux 开发。

下载

SHOW ENGINE INNODB STATUS\G —— 搜索输出里是否有 Large pages used 字样。

启用后性能反而下降或触发 OOM

大页不是银弹。在以下场景容易出问题：

• 物理内存小（比如
• NUMA 架构服务器上未绑定 CPU 和内存节点：InnoDB 分配的大页可能跨 NUMA node，延迟反升
• buffer pool 设置远小于总物理内存，却分配了过多 hugepages：空闲大页占着内存不释放，挤压其他进程

建议初始分配页数按公式算：ceil((innodb_buffer_pool_size * 1.1) / 2 / 1024 / 1024)（单位 MB → 转为 2MB 页数），之后压测观察 HugePages_Free 和 HugePages_Rsvd 是否稳定。

如何确认系统已支持并启用 HugePages

别只看 Hugepagesize 有值就以为万事大吉。关键要看实际分配状态：

运行 cat /proc/meminfo | grep -i huge，关注四列：

• HugePages_Total > 0：内核已分配页数
• HugePages_Free ≈ HugePages_Total：还没被进程用，正常
• HugePages_Rsvd > 0：表示已有进程预留（MySQL 启动后这里应上升）
• HugePages_Surp == 0：没超限，否则说明 vm.nr_overcommit_hugepages 不够或内存不足

如果 HugePages_Total 是 0，echo 2048 > /proc/sys/vm/nr_hugepages 会失败，必须先确保系统内存足够且未被锁死——这是最容易卡住的第一步。