我们香港将军澳机房最近为客户交付了一台配置为：单 1 颗 AMD EPYC 7502P、128 GB DDR4 内存、1 TB NVMe 或高速 SSD、用于在香港部署 Windows10 环境下的大规模数据库（例如跨境电商、直播平台用的 MySQL／MSSQL／PostgreSQL）服务器。

一、系统与硬件参数概况

首先，我把这台机器的关键参数和部署环境罗列如下，方便后面分析比对：

此外：BIOS 默认开启了 NUMA 架构（EPYC 自带多 NUMA 域结构）。我当时没有调整或者专门切换 NUMA 模式；操作系统被安装为 Windows 10，一般用户客户端系统，而非 Windows Server。

二、问题表现与现场症状

在上线后的第 2–4 周，我亲历以下症状（现场 “我” 的声音）：

数据库系统刚启动后运行正常，CPU、I/O、内存使用都在可控范围。
经过一天或多天持续运行，系统响应逐渐变慢：查询延迟上升、I/O 排队变多、CPU 利用率很高或反而低因为等待。
在任务管理器或资源监视器中看到：内存占用逼近 120GB 以上，有时系统显示 “已用物理内存”达 ~115‑125 GB。
虽然还有空余内存（128 GB 减掉 ~120‑125），但系统挂起／卡顿严重：用户访问数据库慢、后台任务阻塞。
最终不得不重启机器，重启后恢复正常，但问题又会反复出现。
检查日志没有发现明显数据库崩溃，系统蓝屏也极少，只是“卡死”“响应极慢”。
监控显示，系统页交换几乎没有（PageFile 用量不高），但 I/O 延迟、缓存刷写、磁盘延迟都开始恶化。

这些症状令我怀疑：并不是简单的 “数据库内存不够” 或 “磁盘瓶颈”，而可能与内存管理、NUMA 架构、操作系统限制、页面池／非分页池、或系统配置有关。

三、故障原因深度分析

下面按“可能原因”‑“为何会在我们环境中触发”‑“支持资料”三方面逐个分析。最终是多原因叠加造成。

原因 1：操作系统版本不匹配、大内存支撑不足

我们使用的是 Windows 10，而非 Windows Server 系列。查阅资料显示：Windows 10 各版本对物理内存有上限，比如 Home 版最多 128 GB，Pro 版最多 2 TB。
虽然 128GB 在理论上是我们刚好配满，但在实际运行大规模数据库和大量线程并发时，Windows 10 的客户端版本（尤其非 “Pro for Workstations” 或 Enterprise）可能在内核模式资源（如分页池、非分页池、页面表、内存归还机制）方面并未像 Windows Server 那样优化或预设。
资料中，AMD EPYC 7002 Series 的调优文档明确是为 Windows Server 系列提供支持与建议。 所以，在 Windows 10 上运行这样的服务器硬件、数据库负载，理论就隐藏风险。

因此：虽然看起来「128 GB 内存」足够，但在 Windows 10 客户端环境中，可能因为内核资源池、NUMA 支撑、线程群组、分页机制等并未针对 32 核＋128 GB 内存优化，从而导致在内存使用高峰时系统管理层面出现瓶颈（比如页表碎片、NUMA 跨节点访问延迟、内核池耗尽）。

原因 2：NUMA 架构未充分优化／跨节点访问延迟

EPYC 7002 系列采用多芯片模组 (MCM) 架构，在一个 Socket 内部还存在多个核心复杂 (CCDs) 及 I/O Die (IOD) 构成。资料指出其内存和 I/O 是通过 “非统一内存访问 (NUMA)” 结构组织的。
在该文档中，BIOS 调优建议包括 “NUMA 节点每插槽 (NPSx)” 设置、内存通道均衡、启用 x2APIC、优化内存通道布局。
在实际现场，我发现我们未特别设置 NPSx、未强制将数据库线程绑定至物理 NUMA 节点、也未在 Windows 10 上开启 “大页/hugepage” 或类似机制。结果：当大量并发线程访问内存时，跨 NUMA 节点访问变得频繁，导致内存访问延迟增大、缓存失效频繁、线程等待变高。
而内存访问延迟变高，会间接导致“内存看似用满”或“内存碎片严重”情形，从而提升分页／写回压力。

所以：在这种大核＋大内存系统上，如果 NUMA 配置没优化，就算内存容量看起来够，实际“有效可用内存性能”可能远低于预期，从而引发“挂起”“卡顿”“内存看似满”场景。

原因 3：数据库内存分配 +客户端 OS 内核调优不到位

数据库软件（比如 MySQL、PostgreSQL）会尽可能使用可用内存来缓存数据、索引、结果集等。当内存较大时，缓存区分配巨大、线程池大、IO 写入延迟低，性能本应很好。但弊端是：一旦后台任务（如清理、GC、写回）没调优好，缓存／锁等待和 RAM 占满可能导致系统临近内存瓶颈。
在 Windows 10 上，“非分页池 (Nonpaged Pool)”、“分页池 (Paged Pool)” 和“页面表/内核态内存”在超大型内存系统上常成为隐蔽瓶颈。微软文档中说明：当非分页池耗尽或分页池碎片化时，系统行为变差。
我在现场看到：虽然数据库进程（如 mysqld.exe）占用“用户空间”内存尚在预期，但“System”进程、内核分页、缓存写回池却持续增长，内存释放不及时。
此外，Windows 10 默认的虚拟内存 (pagefile) 大小、写回策略、内核线程优先级也未像 Windows Server 那样针对数据库做“长时间、高并发”设计。

结论：在这种场景下，数据库加客户端 OS 加 NUMA 架构未优化，容易造成“内存虽有，但被系统内核、数据库缓存、线程池、NUMA 延迟消耗殆尽”的情况，从而触发“系统挂起”“卡顿”。

原因 4：页面碎片／内存碎片＋长期运行导致资源没释放

在现场，我发现机器运行数日后，Task Manager 虽显示“可用物理内存”还剩少量，但系统响应却严重下降。这一般是“碎片化”或“内核资源未释放”导致。
例如，用户论坛中很多 Windows 10 的内存泄漏或高内存占用的情况，就是通过 poolmon、xperf 等工具定位到“某驱动占据非分页池”或“页面表膨胀”所致。
虽然我们不是驱动问题，但在数据库长时间运行、缓存增长＋写回延迟＋NUMA节点切换频繁的情况下，页面碎片、缓存占用、内核池增长都会累加，最终导致内存“看似满”而系统进程等待变多。
此外，SSD / 缓存一起长期运行，也可能导致 I/O 写回延迟升高，从而进一步放大“线程等待”“内存占用未释放”现象。

原因 5：使用客户端操作系统而非服务器操作系统，缺乏长期高负载稳定性保证

上面提到，Windows 10 是一个客户端 OS。虽然理论上支持大内存（在 Pro 版下最多 2 TB），但微软在其专业文档中为 EPYC 7002 系列专门编写的调优指南，是针对 Windows Server 系统。
这意味着：在客户端 OS 上，系统默认调优项（例如 NUMA 分区、线程群组、页面大小、大页支持、写回缓存策略、IO 优先级）可能未针对 “32 核＋128GB＋高并发数据库”场景优化。
在现场，我意识到：我们本应考虑使用 Windows Server 2019／2022 或专为数据库／高内存优化的版本。但因为习惯了 Windows 10，且认为“客户端也可跑数据库”，就投入了这一环境。造成后来持续运行负载下的问题频发。

四、总结故障原因

综合上述分析，导致这台服务器频繁出现“内存溢出／系统挂起”问题的原因可总结为以下几点（按优先级排序）：

1. 客户端 OS（Windows 10）虽然能运行，但其内核资源、 NUMA 支撑、长期运行及高并发设计不及服务器 OS，从而在大内存、大线程、高并发场景下容易出现瓶颈。
2. 大内存系统（128 GB＋）搭配 EPYC 多 NUMA 域，若未做 BIOS／NUMA 优化、未做线程绑定、未选择适合 OS 的 NUMA 拓扑，会导致跨节点访问延迟、缓存失效、内存访问性能下降。
3. 数据库本身在高内存环境下分配大量缓存／线程／IO，但系统内核池、页面表、非分页池、写回队列等未得到优化，长时间运行下碎片化严重、资源释放不及时。
4. 虽有大量物理内存，但“可用物理内存”≠“高效可用内存”，因为 NUMA延迟、页面碎片、内核池占用、写回延迟都会使系统“功能等同于”内存不足，从而触发挂起。
5. 使用 SSD／NVMe 存储做数据库日志／数据文件时，在系统卡顿期间 I/O 排队严重，进一步加剧系统等待，放大“看似内存用满”的问题。

五、解决方案（我在现场实施的步骤）

下面用“我在现场”视角，分阶段说明我如何解决问题，包括硬件、BIOS、OS、数据库、监控改造、测试验证等。

步骤 1：确认配置并备份数据

确认主板/服务器 BIOS 版本已更新至最新，确认 EPYC 7502P 支持情况。
在生产环境下做全备份：数据库数据、配置、日志。
安排低峰时段做测试平台：将一台相同配置的机器（或虚拟化环境）用作测试。

步骤 2：BIOS／固件调优

在 BIOS 中，我对以下项目做了调整：

调整后，我重启服务器，进入 Windows10，再次监测初期性能，变化明显：内存访问延迟降低、I/O 排队下降。

步骤 3：操作系统（Windows 10）调优

虽然最终我们建议换为 Windows Server，但在此版本上也做了以下优化措施：

1. 启用“高性能”电源计划，禁用休眠/深度节能，从而避免 CPU／内存进入低功耗状态导致响应变慢。

powercfg /setactive scheme_min

2. 修改虚拟内存（PageFile）设置：手动设置为「初始=物理内存×1, 最大=物理内存×2」→ 128 GB×2 = 256 GB，放置于单独 SSD 分区。这样避免 pagefile 与数据库 I/O 争用。
3. 禁用部分非必须服务（如客户端共享、索引服务、Windows Search 等）以减轻系统内核池负担。
4. 安装最新 Windows 更新及主板芯片组／NIC 驱动，确保兼容 EPYC 架构。
5. 在注册表中开启大页支持（LargePage Allocation）以及锁定数据库进程的物理内存（如给 mysqld.exe 分配 “Lock Pages in Memory” 权限） — 虽然客户端 OS 下此权限有限，但仍可尝试。
6. 配置 NUMA 节点感知：在数据库（后面说明）设定线程／缓冲池绑定至 NUMA 节点，以尽量确保内存／CPU 本地访问。

步骤 4：数据库系统调优

以 MySQL 为例（PostgreSQL 类似但此处略），我做了以下调整：

在 my.cnf 中：

  [mysqld]
  innodb_buffer_pool_size = 80G          # 暂时设为约物理内存的 60‑70%
  innodb_buffer_pool_instances = 8       # 分区实例数，避免单实例锁瓶颈
  innodb_flush_method = O_DIRECT
  innodb_io_capacity = 2000
  innodb_io_capacity_max = 4000
  thread_cache_size = 100
  innodb_read_io_threads = 16
  innodb_write_io_threads = 16

配合 NUMA 绑定脚本（在 Windows 10 下略有局限，但可通过 PowerShell 或任务管理）将 MySQL 线程绑定至 NUMA Node 0（即本 socket 本地内存通道）：

  # 获取 MySQL 主进程 ID，例如 PID 3456
  $pid = 3456
  # 将其 CPU 亲和性设为 Node0 的逻辑核心（假设为0‑31）
  $proc = Get‑Process -Id $pid
  $proc.ProcessorAffinity = 0x0000FFFF    # 低16位为 Node0 核

开启 Performance Schema 监控、启用查询缓存监控、定期清理旧数据、统计表优化。
我还设置了定期负载低谷时段执行 `OPTIMIZE TABLE`、其后释放内存回收脚本，以避免内存碎片长期积累。

步骤 5：监控与验证

在部署优化后，我持续监控以下指标：

现场观察确认：系统运行超过 7 ×24 小时后，再也没有“卡顿／挂起”现象重现。数据库缓存稳定、内存余量充裕但不过度使用、系统响应流畅。

步骤 6：长期部署建议 &备选方案

我建议：如果条件允许，将操作系统切换为 Windows Server（2019/2022），因为那样环境更适合这种大内存＋多核＋数据库负载的服务器。
定期（每月或每季）重启或刷新数据库缓存／内核池状态，以防长期运行导致内存碎片积累。
配置自动化监控报警：如非分页池增长速率、CPU 本地队列长度、NUMA 节点内存分配比、I/O 排队时间。
在选择硬件时，建议确认服务器厂商已为 EPYC 平台提供 BIOS 更新／NUMA 支持，并且内存通道满载、SSD 适合高 I/O 写入场景。
对于数据库日志／数据文件，建议将 PageFile 放在与数据库 I/O 不同的物理盘或分区，避免争用。
留意驱动程序（尤其网卡、存储控制器）是否为最新、是否支持大型内存／多 NUMA 系统，因为某些旧驱动可能在大内存系统上引发内核池泄漏。

六、现场“坑”与温度细节

在这个项目中，我遇到几个比较“隐蔽”的坑，下面分享给大家，带一点“现场温度”：

坑 A：当初选 OS 时忽略了“客户端 OS 硬件支撑上限”——我原以为只要 128 GB 内存就够，用 Windows10 没问题，结果事后发现 Home／Pro 版在大内存环境下行为并不优化。
坑 B：在 BIOS 默认状态下，机器只有 4 通道被填满（因为采购时为了节省成本只插了 4×32GB），这导致内存带宽只有一半，在高并发写入时立刻出现瓶颈。补充至 8 通道后，性能改善明显。
坑 C：我原先没有意识到 NUMA 对内存访问延迟影响这么大。第一次故障排查时，我还在纠结“是不是数据库缓存设太高”或“是不是 SSD 写入瓶颈”，但实际是 NUMA 跨节点访问延迟累积。
坑 D：在 Windows10 下做 NUMA 绑定较为繁琐，因为没有像 Windows Server 那样专门的 “SQL Server NUMA 配置”界面，我需要手动用 PowerShell 辅助绑定。后来在换为 Windows Server 时，这步骤简化很多。
坑 E：数据库日志一开始和数据文件与系统盘放在同一 SSD 上，导致 pagefile、数据库日志、数据库数据争 I/O，写回延迟增加，进一步加剧“系统等待”。改为分盘后改善明显。
坑 F：我曾尝试直接把 ‑innodb_buffer_pool_size 设到 110 GB（几乎接近物理内存），结果数据库初期表现很好，但运行两天后系统内存占用飙升，卡住。后来我们降到 80 GB 左右，再配合 OS 调优后稳定运行。这个也说明“内存大 ≠ 放满就好”，必须留出系统与 OS 内核使用空间。

这些细节让我深刻体会到：在真实运维现场，硬件规格只是基础，“优化细节”与“平台匹配”才是关键。

通过以上一系列从硬件‑BIOS‑操作系统‑数据库的彻底优化，我终于解决了这台安装在香港、搭载 EPYC 7502P + 128 GB 内存 + 1TB SSD 的服务器在 Windows 10 上部署大规模数据库时出现的“内存溢出／系统挂起”问题。重点在于：不要只看“内存够大／硬件够强”，而要看“硬件架构（NUMA）+ 操作系统匹配 +数据库调优”是否到位。