随机数算法 RandomX 作为门罗币（Monero）的 PoW 共识机制，其设计初衷即是通过内存密集型工作负载实现抗 ASIC 挖矿。与传统 SHA 系列算法不同，RandomX 的性能瓶颈不在算术逻辑单元，而在内存子系统的访问效率。本文聚焦内存带宽优化与 CPU 缓存交互的工程实现细节，为运维与开发人员提供可落地的参数配置清单。
内存访问模式与带宽瓶颈本质
RandomX 核心运行机制是执行随机生成的程序，每秒数千次地访问一个约 2 GB 的只读数据集（Dataset）。该数据集按块（block）组织，每个块 64 字节，程序执行过程中通过伪随机索引进行寻址。这种访问模式呈现两个显著特征：第一，访问地址的局部性极差，几乎无法利用 CPU 预取机制；第二，每次哈希计算需要遍历整个数据集的相当比例，导致内存带宽成为决定性瓶颈。
从硬件层面观察，RandomX 的理论算力上限直接受限于内存通道带宽。实测数据表明，DDR3 内存单通道只能支撑约 1500 至 2000 H/s 的哈希率，而 DDR4 内存单通道可提升至 4000 至 6000 H/s，这一数值取决于频率与时序参数的组合。这意味着增加内存通道数量（双通道、四通道）是最直接的带宽扩容方式，而非单纯提升 CPU 主频。XMRig 官方文档明确指出，多通道内存架构是发挥 RandomX 性能的前提条件。
L3 缓存层级与线程分配策略
CPU 三级缓存（L3）在 RandomX 挖矿中扮演着数据暂存与访问加速的关键角色。XMRig 的优化指南给出了精确的缓存需求量化指标：每启动一个挖矿线程，需要预留 256 KB 的 L2 缓存与 2 MB 的 L3 缓存。这一配比源于程序执行时中间状态与数据集片段的缓存需求 ——L2 缓存承载单线程的指令操作数，L3 缓存则缓存频繁访问的数据集块。
在实际部署中，缓存需求直接限制了可用线程数。以一颗典型的 8 核 16 线程 CPU 为例，假设其 L3 缓存为 16 MB，理论最大可用线程数为 16 MB 除以 2 MB 等于 8 个线程；若强制开启 16 线程，则每个线程平均只能分配到 1 MB L3 缓存，导致缓存命中率急剧下降，算力反而可能低于 8 线程配置。这一现象解释了为何许多矿工发现线程数并非越多越好 —— 超过缓存容量的线程竞争会引发缓存抖动（cache thrashing），反而拖累整体吞吐。
进一步而言，L3 缓存的物理分布与 CPU 核心拓扑紧密相关。在非一致内存访问（NUMA）架构的服务器平台上，每个 CPU 插槽对应独立的内存控制器与缓存层级。RandomX 数据集通常按 NUMA 节点分配，每个节点需约 2080 MB 用于存储 Dataset，另需 256 MB 用于缓存。如果在多节点系统上忽视 NUMA 亲和性，跨节点的数据访问将引入显著延迟，因为数据需要通过 QPI/UPI 互联在节点间传输。XMRig 提供了自动 NUMA 感知功能，在启动时会报告节点数量并自动将数据集分配至各节点本地内存。
Huge Pages 与内存虚拟化优化
操作系统默认的页面大小为 4 KB，这对于 RandomX 这类大规模内存访问模式而言会产生额外的页表查询开销。每一次内存访问都需经过虚拟地址到物理地址的转换，若页表条目不在 TLB（Translation Lookaside Buffer）中，则需遍历多级页表，严重时甚至导致流水线停顿。启用 Huge Pages（巨页）将页面大小提升至 2 MB（标准 Huge Pages）或 1 GB（1GB Huge Pages，仅 Linux 支持），可显著减少页表层级与 TLB 未命中概率。
实测数据显示，启用标准 Huge Pages 可将 RandomX 性能提升 40% 至 50%，这一收益主要来源于 TLB 未命中率的下降与页面换入换出频率的降低。在此基础上，进一步启用 1GB Huge Pages 可再获得 1% 至 3% 的额外提升，原因在于 1GB 页面进一步减少了元数据开销。在 Linux 系统中，启用 1GB Huge Pages 需要在启动参数中预留 3 GB 以上的连续物理内存（三个 1GB 页面），这意味着系统总内存需要相应增加。XMRig 配置文件中的 "huge_pages": true 与 "1gb_pages": true 两个开关分别控制这两级优化。
需要注意的是，Windows 平台对 Huge Pages 的支持相对有限，且 1GB Huge Pages 功能仅在 Linux 生产环境中可用。对于 Windows 用户，标准的 2 MB Huge Pages 仍是最佳选择，但提升幅度通常低于 Linux 系统。
硬件预取器禁用与 Cache QoS 机制
现代 CPU 通常集成硬件预取器（Hardware Prefetcher），其设计目的是基于历史访问模式预测即将访问的内存地址并提前将数据加载至缓存。然而，RandomX 的伪随机访问模式完全无法被预取器识别 —— 预取器基于空间局部性与时间局部性工作，而 RandomX 的地址序列近似均匀分布，错误的预取反而会污染缓存空间，浪费本已稀缺的缓存容量。
XMRig 官方优化指南将禁用硬件预取器列为必选项目。通过修改 CPU 型号特定寄存器（MSR），可关闭各核心的预取功能。这一操作通常需要管理员权限与特定的工具脚本，在生产环境中应谨慎测试以确保系统稳定性。部分高端主板提供的 BIOS 选项中也可直接关闭预取器，虽然效果可能不如 MSR 调节精细，但更为安全。
在多租户或混合负载场景下，非挖矿进程可能干扰挖矿线程的缓存访问。XMRig 引入了一项实验性功能 ——Cache QoS（缓存服务质量），通过限制非挖矿核心对 L3 缓存的访问权限，降低缓存争用。该功能利用 CPU 的 Cache QoS 机制（如 Intel CAT 或 AMD L3 缓存控制），为挖矿线程保留更大的有效缓存空间。启用方式为在配置中设置 "cache_qos": true，但需确认 CPU 架构支持相应指令。
工程化配置参数清单
基于上述机制分析，以下给出生产环境的推荐配置参数框架，适用于双路服务器或高端桌面平台：
内存与 NUMA 配置：确保每个 NUMA 节点（即每个 CPU 插槽）配备至少 4 GB DDR4 内存，推荐双通道或四通道配置以满足 4000 至 6000 H/s 的单通道带宽上限。系统启动后通过 numactl --hardware 确认节点数量与内存分布，XMRig 启动时会自动报告检测到的 NUMA 节点数。
线程数计算：以可用 L3 缓存总量除以 2 MB 并向下取整，作为初始线程数基准。例如 32 MB L3 缓存建议配置 16 线程。随后通过实际算力测试微调，若增加线程后算力提升不足 5%，则退回至前一配置。
Huge Pages 启用：Linux 系统建议加载 transparent_hugepage=always 内核参数，并通过 sysctl vm.nr_hugepages=1536 预留 3 GB（1536 × 2 MB）页面；若需 1GB 页面，则配置 vm.nr_hugepages=3 并在 XMRig 中开启 "1gb_pages": true。Windows 系统仅需在 XMRig 配置中启用 "huge_pages": true。
CPU 亲和性：使用 taskset 或 numactl --cpunodebind 将挖矿线程绑定至对应 NUMA 节点的 CPU 核心，避免跨节点调度。对于单节点系统，可通过 cpulist 参数指定挖矿核心范围，排除用于系统管理的基础核心。
缓存隔离：若 CPU 支持且系统无其他关键业务，可尝试启用 "cache_qos": true；否则通过 BIOS 或操作系统将非挖矿进程限制在特定核心集合，留出完整缓存供挖矿使用。
监控与持续调优
调优并非一次性工作，温度、功耗与长期负载下的缓存行为均会随时间变化。关键监控指标包括：算力波动幅度（超过 5% 需排查）、L3 缓存命中率（可通过硬件计数器读取）、内存带宽利用率（通过 ipmctl 或主板监控工具获取）。当发现算力随时间衰减时，首先排查是否因散热导致 CPU 降频，其次检查是否存在后台进程抢占缓存资源。
综合而言，RandomX 的性能优化本质是在内存带宽、缓存容量与线程并行度之间寻求平衡。理解 L3 缓存的物理限制、NUMA 拓扑的数据局部性以及 Huge Pages 的虚拟化收益，是实现高效挖矿的核心认知基础。
资料来源：XMRig 官方 RandomX 优化指南（https://xmrig.com/docs/miner/randomx-optimization-guide）