📚 课程目录第3章硬件环境评估

硬件环境评估：检查物理内存、虚拟内存、交换分区及系统架构的限制

内存不够，第一步别去琢磨算法优化。

先看看你手头这台机器到底给了你多少资源。

我遇到过不少组，管理员说“服务器128G内存够用了”，结果一查，操作系统跑在32位上，MaxQuant根本用不了超过2G。这种事其实挺常见的。

物理内存：你的第一道防线

MaxQuant对内存的胃口有多大？

说白了，跟你跑的样本数、TMT通道数、还有是不是加了“Match between runs”功能直接挂钩。

我个人习惯，上来先看总物理内存：

# Linux 下查看物理内存
free -h

# 输出示例
              total        used        free      shared  buff/cache   available
Mem:           125G        1.2G        120G        2.1G        3.8G        120G

这里重点看的是 available 这一列。不是 free。

为什么？因为系统会把一部分内存拿去做缓存，但应用需要的时候可以让出来。available 才是真正能分配给 MaxQuest 的“净可用量”。

我建议的最低配置门槛，按数据规模分成三档：

数据规模	样本数	推荐物理内存	说明
小型	1-6	16-32 GB	标蛋（Label-free）可跑，TMT 勉强
中型	6-18	64-128 GB	开启“Match between runs”后压力明显
大型	18+	256 GB 以上	TMTpro 16-plex 或超大 DIA 数据集必备

注意： 如果系统物理内存只有 8G，即便 MaxQuant 启动后没报错，跑着跑着就会被 OOM Killer 杀掉。别指望它能自己优雅退出，日志里通常只有一句话——“Killed process (MaxQuant)” ，没有任何报错信息。

虚拟内存与交换分区（Swap）：你以为的避难所

物理内存不够，系统会用交换分区来救急。但我得说句实话——

Swap 对于 MaxQuest 来说，是个假希望。

我曾经手头有台 64G 的机器，管理员配了 128G 的 Swap，觉得肯定够了。结果呢？MaxQuest 一跑起来，内存吃满，开始疯狂往 Swap 里写。磁盘 I/O 直接打满，一天只跑出两道流程。最后一看进程状态，全是 D（Uninterruptible Sleep），卡在 I/O 等待上。

所以，检查 Swap 是必要的，但别指望用它救命：

# Linux 查看 Swap
swapon --show

# 输出示例
NAME      TYPE      SIZE   USED PRIO
/dev/sda3 partition   8G   2.1G   -1

这里你得注意两点：

Swap 总量：别超过物理内存的 50%。太大的 Swap 只会让系统慢到让你怀疑人生。
Swap 使用率：如果 MaxQuest 运行期间 Swap 持续上涨，那说明物理内存已经严重不足。此时效率还不如去加物理内存条。

一个小技巧： 你可以在 MaxQuest 运行前、跑 10 分钟后、跑完时各抓一次 free -h 的输出。对比 Swap 的 used 列，如果每次都在涨，那几乎可以断定物理内存不够。

系统架构限制：32位 vs 64位 —— 天壤之别

这是一个被忽视很多次的坑。

MaxQuest 是一个 .NET 应用，它的内存模型受操作系统架构限制。这里有个硬性数字，你一定要记住：

32位 Windows / Linux： 单个进程最多 2-4 GB 内存（取决于是否启用 PAE）。
64位系统： 理论上限是 2^64，实际上受物理内存限制，但跑几百 GB 都没问题。

我见过有实验室在 32 位 Windows 7 上装 MaxQuest，结果不管给多少样本都报“OutOfMemoryException”。怀疑插件冲突、怀疑参数配错，搞了三天才发现是系统架构的问题。嗯，这种事你想想看，数据都裂开了还继续分析，能不崩吗？

确认你的系统是 64 位的：

# Windows 下
# 打开 "系统信息" → "系统类型" 会显示 "x64-based PC"

# Linux 下
uname -m

# 输出示例
x86_64              # 64位
# 如果是 "i686" 或 "i386"，那就是 32 位，必须重装系统

另外，MaxQuest 本身也有 32 位和 64 位版本。 千万别装错了。

我记得 1.x 版本还有单独的 32 位安装包，从 1.6.x 之后就只提供 64 位版了。所以如果你还在用老版本，务必确认下载的是 MaxQuant_64bit.msi 而不是 MaxQuant_32bit.msi。

内存带宽和 NUMA 架构：容易被忽略的性能瓶颈

物理内存够用了，架构也对了，MaxQuest 还是跑得慢？

那你得看看内存带宽和 NUMA 节点了。

现代服务器通常有多个 CPU，每个 CPU 有自己的内存控制器。这叫 NUMA（非均匀内存访问架构）。如果你把 MaxQuest 的任务绑定在 CPU 0 上，但给它分配的内存却挂在 CPU 1 上，那么每次内存访问都要多走一层 QPI/UPI 总线，性能下降 10%-20% 是很正常的。

怎么检查？

# Linux 下查看 NUMA 拓扑
numactl --hardware

# 输出示例（简化）
available: 2 nodes (0-1)
node 0 cpus: 0 1 2 3 4 5 6 7
node 0 size: 65536 MB
node 1 cpus: 8 9 10 11 12 13 14 15
node 1 size: 65536 MB
node distances:
node   0   1
  0:  10  20
  1:  20  10

看 node distances：10 表示近，20 表示远。如果 MaxQuest 进程报内存不足而系统总内存又没满，有可能是它被调度到了一个节点上，只用了该节点的本地内存。这时你可以用 numactl --membind=0 把进程绑定在某个 NUMA 节点上运行。

  经验之谈： 在双路服务器上跑大型 MaxQuest 任务时，我习惯先用 numactl --show 看一下默认策略。如果策略是 preferred 或 all，那可以试试显式绑定到一个节点上。不过如果数据集真的很大（比如 256 GB 以上），NUMA 跨节点访问反而是必要的，这时候就别绑了。

总结一下今天的检查清单

把这些信息收集齐了，你就能回答自己一个问题——我的硬件环境到底卡不卡。后续分析参数怎么配，能不能用那些吃内存的功能，全部基于这个评估。

好，把这个清单存下来