H10 介绍了存储层次：越接近处理器的存储通常越快，容量也越有限。本课把视线放在主存，建立 DRAM、内存条、通道、带宽、延迟和 ECC 的基本直觉。读完后，应能解释常见内存规格，估算通道带来的理论带宽，并把容量、性能和可靠性要求写进方案。这里只讨论概念与基础判断，不展开 DDR 时序参数，也不讨论 HBM 的实现。
主存扮演什么：工作集的家
程序运行时，处理器需要不断取得指令和数据。寄存器与缓存容纳其中很小而活跃的部分，主存承接规模更大的运行现场：程序代码、正在处理的请求、数据库缓存、排序过程中的数组，以及操作系统自己的数据结构。可以把主存看作工作集的家，但这不表示工作集的每个字节每时每刻都只待在 DRAM 中；其中更热的副本可能已经进入处理器缓存。
工作集强调某段时间内实际需要访问的数据。例如，数据库文件总计 2 TB，并不自动意味着必须准备 2 TB 内存。如果大多数请求只涉及其中较小的热点集合，主存可以优先容纳这些内容。反过来，磁盘上的文件只有 20 GB，也不保证 32 GB 内存够用：解压、索引、对象管理和多份中间结果都可能扩大运行时占用。容量估算应围绕运行状态，而不是照搬文件大小。
主存通常由 DRAM 构成，断电后不能可靠保留数据。程序将结果写入内存，只能说明运行现场发生了变化，不能据此认定业务结果已经持久化。数据库日志、文件系统写回以及存储设备的完成语义仍然决定数据何时真正落盘。这个边界把“运行得快”和“故障后能恢复”分开，也解释了为什么增加内存不能代替备份。
容量不足时，操作系统可能回收缓存，或把部分内存页换出到存储设备。后续访问这些页需要额外等待，服务响应时间可能突然拉长。在某些配置中，系统还可能终止进程。增加容量可以缓解这类问题；但如果工作集已经装得下，任务仍在连续扫描大量数据，继续增加容量未必提高速度，此时更应检查带宽与访问方式。
还应区分程序声明的地址空间、当前驻留的内存和实际访问的工作集。它们描述的是不同层面，不能看到程序申请了某个容量，就断定对应数量的 DRAM 已经被持续使用。初步分析可以先记录业务规模、并发数和峰值驻留量，再观察吞吐与响应时间如何随负载变化。这样得到的证据更接近真实容量需求。
DRAM 直觉：电容存位，行列组织
DRAM 的全称是动态随机存取存储器。常见存储单元可以用“受控开关加小电容”建立直觉：电容中电荷的状态代表信息，开关决定何时让它与读写线路相连。这是理解原理的简化模型，不表示软件可以直接测量每个电容，或者所有器件都用相同的电压规则表示 0 和 1。
电容很小，电荷会逐渐泄漏，因此 DRAM 需要周期性刷新。刷新相当于在信息变得不可靠之前，重新确认并补充存储状态。只要通电也不能完全取消这项工作。“动态”强调需要维护电荷状态；“随机存取”强调可以按地址访问不同位置，并不保证任意位置在任意时刻都有完全相同的等待时间。
大量存储单元排成行与列。内存控制器接到请求后，会把地址映射到相应通道、rank、bank 以及行列等位置。这里的 bank 可以先理解为器件内部具有独立行状态的阵列分区。实际映射由平台决定，程序中的相邻地址不能简单地画成某根内存条上相邻的 2 个电容。
读取时，器件先选中某行，通过感应放大器识别微弱的电荷差异，并把该行内容暂存在行缓冲区，同时恢复单元中的电荷。随后再依据列位置，选择需要传出的数据。这个过程说明，DRAM 不是每次都只独立打开目标字节，而是先让较大范围的数据处于可访问状态，再取其中的部分内容。
如果后续请求访问已经打开的同一行，通常可以少做部分准备工作；如果需要切换到另一个行，则可能先关闭当前行，再打开目标行。这使访问顺序影响有效延迟。连续遍历数组往往比沿着分散指针逐个寻找对象更容易形成高效访问，但具体效果还取决于缓存命中、请求并行和控制器安排，不能仅凭“连续”就断言每次都命中行缓冲区。
写入则把新的数据状态送回选中的位置。刷新也需要占用内部资源，可能与正常访问产生竞争。控制器会协调这些操作，因此主存性能既来自电路速度，也来自大量请求如何被组织。对本课而言，记住“电容会漏电、访问有行列准备、内部存在并行资源”就足以解释许多现象，无须把具体时序名称背成性能排名表。
DRAM 单元存储的是位，处理器与内存之间的实际传输通常按更大的块组织。软件读取 1 个字节，并不意味着总线上只运输 1 个字节。若取来的其他数据很快也被使用，传输成本就得到分摊；若每次只使用极少部分，其余内容不断被丢弃，标称带宽很高也可能没有转化为有效业务吞吐。
内存条、通道与 rank：并行能力从哪里来
内存条是承载 DRAM 颗粒、连接触点以及相关组件的模块。常见 DIMM 可以插入主板内存槽。内存槽提供物理位置，通道则是处理器内存控制器连接内存的数据通路。它们不是同义词：某个平台有 8 个槽位，可能对应 4 个通道，每个通道连接 2 个槽位。必须结合平台说明理解槽位归属。
增加内存条可能增加容量，也可能启用更多通道，但不能只按条数推断带宽。如果 2 根内存条插在同一通道，它们仍要共享该通道的传输资源；如果按平台要求分别插入 2 个通道，就有机会让不同请求并行传输。正确插槽位置通常由主板或服务器的安装规则指定，不能凭槽位距离判断。
rank 是模块组织中的另一个概念，可以先理解为在选择信号控制下、共同组成规定数据位宽的颗粒集合。rank 与内存条的正反面并无必然对应关系，也不等于通道。标记为单 rank 或双 rank，说明模块内部的组织方式；它不意味着系统分别拥有 1 条或 2 条独立的内存通道。
同一通道上的多个 rank 可以让控制器交错安排请求，例如某个 rank 在准备数据时，另一个 rank 有机会进行其他操作。这可能提升资源利用率，却不会把共享数据总线变成额外的独立通道。每通道装入更多模块还可能增加电气负担，平台可能因此降低支持的传输速率。容量、组织和速率必须放在同一张配置表里核对。
规格中的 DDR 表示双倍数据速率，即在时钟的 2 个边沿传输数据。标注为 DDR5-4800 时，4800 通常表示每秒 4800 百万次传输，单位应读作 MT/s，而不是把它直接理解为 4800 MHz 时钟。采购页面有时把传输速率笼统称作“频率”，读规格时应先辨认单位。已经使用 MT/s 计算带宽后，不应再因 DDR 额外乘以 2。
内存条标称支持的速率，也不保证装入任意机器后都能以该速率运行。处理器、主板、固件、模块类型、每通道模块数量及混插规则都可能限制实际配置。比较方案时，应记录整机实际运行速率，而不是只记录包装上最高的数字。不同 DDR 代际的接口与平台要求也不能只靠容量相同来互换。
DDR5 DIMM 通常把数据通路进一步分成 2 个可独立调度的子通道。为避免混淆，本课后面的估算统一把 1 个平台通道按合计 64 位的用户数据宽度计算。查看资料时要先确认“通道”是指平台通道还是子通道；如果资料按 32 位子通道计数，就应使用相应宽度，不能同时把数量和宽度都翻倍。
带宽与延迟：每秒运多少，单次等多久
带宽描述单位时间内能够传输多少数据，常用 GB/s；延迟描述某次请求从发出到数据可用所需的时间，常用 ns。运输类比中，带宽像每秒通过道路的货物量，延迟像某批货物从出发到到达的时间。增加并行道路可以提高总运输量，但不必然缩短某批货物的行程。类比用于区分指标，不能替代对真实内存请求的分析。
对于 64 位用户数据宽度，单次传输对应 8 B。若实际传输速率为 4800 MT/s，单通道理论峰值带宽可估算为 4800 × 10⁶ × 8 B/s，即 38.4 GB/s。若有 2 个相同且可并行工作的通道，合计理论值为 76.8 GB/s；有 4 个则为 153.6 GB/s。这里 GB 使用十进制单位，不能不加说明地与 GiB 混写。
通用估算式为：理论峰值带宽 = 传输速率 × 用户数据位宽 ÷ 8 × 通道数。它表示理想的数据传输上限，没有扣除刷新、命令安排、读写切换、访问冲突等开销，也没有保证程序能持续发出足够多的请求。ECC 的校验位不计入这里的用户数据量。比较测试值时，还要核对测试统计的是有效读写字节还是其他流量口径。
滑块中提高通道数，理论带宽会按比例增加；提高 MT/s，计算结果也会增加。这个模型不输出延迟，更不能直接输出应用加速比。真实平台可用的通道数和速率组合受到硬件限制，图中参数组合只是帮助理解公式。若某次访问必须等上次返回后才知道目标地址，多余的传输能力可能暂时无法使用。
例如，顺序扫描大型数组时，处理器可以提前组织多个访问，持续搬运数据，较容易受到带宽限制。沿着链表查找时，下个节点的地址可能藏在当前节点中，等待过程串行相接，延迟就可能成为主要约束。实际程序往往同时包含这 2 类访问，不能给整个业务永久贴上“只看带宽”或“只看延迟”的标签。
还可以用在途数据量建立直觉：要在约 100 ns 的往返时间下维持 40 GB/s 的传输，系统平均需要大约 4000 B 数据处于请求尚未完成的状态。这里仅用带宽乘以时间做数量级说明，不代表每个平台的实际延迟，也不要求所有访问由同一个线程发出。并发请求不足时，再宽的通路也可能没有被用满。
提高速率与降低延迟并非同一件事。某些操作以时钟周期表示，周期数和每个周期的长度会共同影响时间；不同配置还涉及控制器、拓扑和排队。更高传输速率可能提高连续传输能力，但不能据此断定所有随机访问都更快。深入时序比较属于后续内容，本课选型以工作负载测量和整机支持条件为依据。
ECC：让部分硬件错误可被发现和纠正
内存中的位可能发生非预期变化，原因包括器件缺陷、信号问题和外部扰动等。错误如果没有被发现，程序可能继续使用错误数值，产生静默数据损坏。对数据库、财务计算或长期运行的服务来说，错误结果有时比明显报错更难处理，因为它可能在经过多步计算后才表现出来。
ECC 是错误纠正码的简称。基本思路是保存数据时同时保存按规则计算的冗余信息，读取时重新检查数据与冗余信息是否一致。冗余关系安排得合适，就能在规定范围内判断错误是否发生，并定位某些错误。它不是给每个数据位简单复制一份，也不是看到任何差异都能自动恢复原始内容。
常见入门模型是 SECDED，即单比特纠错、双比特检错。这里的单与双指同一个受保护编码字中的错误位数。在该模型的保证范围内，出现 1 位错误可以纠正，出现 2 位错误能够检测但不能据此纠正。更多位错误的结果取决于编码与错误形态，不能把“带 ECC”解释成任何损坏都可识别和恢复。
ECC 是否生效需要处理器内存控制器、主板、固件和内存模块配合。某根内存条宣称支持 ECC，并不等于插入任意平台后系统就获得了完整保护。不同服务器还可能提供更强的纠错、巡检或隔离机制，能力边界应查看整机说明。DDR5 颗粒内部的 on-die ECC 主要保护颗粒内部存储过程，不能等同于平台级 ECC 对相应内存数据路径提供的保护。
服务器常用 ECC，是因为较大的内存规模、较长的运行时间和对结果正确性的要求，使硬件错误成为必须管理的风险。这是风险管理上的理由，不表示没有 ECC 的机器必然出错，也不表示采用 ECC 后可以取消其他可靠性措施。应用程序写错地址、软件计算逻辑错误或持久化系统故障，并不自动落在内存 ECC 的纠正范围内。
可纠正错误同样值得记录。偶发事件与同一位置持续出现的错误，其运维含义可能不同，应结合平台日志、厂商建议和维护制度判断。不可纠正错误可能触发告警、进程退出或系统停机，具体行为由平台与系统策略决定。采购时只写“支持 ECC”还不够，方案还需要写清如何确认启用、如何接收事件以及由谁处理。
观察内存：先识别证据来自哪一层
操作系统看到的可用内存、固件上报的模块信息和业务测得的性能，分别回答不同问题。观察时先明确自己要确认容量压力、物理配置还是访问性能，再选择工具。这里给出常用入口与解释边界，重点是读懂信息，而不是要求执行固定实验。
在 Linux 上，free -h 可快速查看总量、已用量、缓存和可用量等概况。读取列名时，要注意 free 与 available 的区别：前者更接近当前完全空闲的部分，后者估计在不依赖交换的情况下还可供新应用使用的内存。系统会使用暂时不用的内存缓存文件，因此空闲值较小不一定意味着容量告急。判断压力还应结合可用量变化、换页活动和业务响应。
dmidecode --type memory 可查看固件提供的内存设备信息，通常需要相应读取权限。可能出现模块容量、槽位标识、标称速率、已配置速率以及宽度等字段。固件数据可能缺失或不准确，字段名称也可能随版本变化。看到某个槽位有模块，仍应对照平台资料确认它属于哪个通道；不要仅凭模块数量推断通道已经均衡使用。
某些记录会区分数据宽度与总宽度，例如以额外位承载校验信息。这可以作为理解模块组织的线索，却不能单凭某个宽度数值证明运行中的 ECC 已启用。确认保护状态与错误事件，还需要结合平台管理界面、系统支持的错误报告机制及整机文档。桌面系统的系统信息或任务管理器也可提供容量、速度等线索，但显示口径同样需要核对。
在虚拟机中，客户机看到的通常是虚拟硬件或经宿主机处理后的信息。即使能够读取内存设备字段，也未必能据此还原宿主机的物理插槽、通道或 ECC 状态。云实例配置中标出的内存容量，主要描述租户获得的资源规格；物理布局与性能保障应查服务说明，不能把客户机工具输出当作宿主机硬件清单。
真正比较内存性能时，还需要说明读写模式、数据规模、线程数和测试口径。测试数据过小，主要测到的可能是缓存；线程数不足，可能没有形成足够请求；不同工具对复制操作的读写字节统计也可能不同。把测试名称之外的条件写出来，结果才有可比性。业务最终关心的仍是目标负载下的吞吐、响应时间与结果正确性。
常见误判：容量之外还有访问方式
第 1 类误判是只看容量。2 台机器都配备 128 GB，并不能说明它们拥有相同带宽。通道占用、实际速率和平台结构都可能不同。反过来，通道更多也不保证业务更快：如果任务主要受计算限制，或数据大多命中缓存，主存带宽提升的收益可能较小。判断顺序应从真实瓶颈出发，再核对硬件原因。
第 2 类误判是把所有等待都归为内存不够。容量压力、带宽饱和与单次访问延迟过高，可能都表现为处理器等待数据，但解决路径不同。增加容量主要改善工作集容纳情况；均衡启用通道有助于增加并行传输能力；改善数据布局、减少依赖访问则可能减少等待。没有证据时直接购买更大内存，容易只增加成本。
第 3 类误判是忽略内存的远近。多插槽服务器可能采用 NUMA，即非一致内存访问结构。处理器访问靠近自己的内存，与访问另一处理器关联的内存，成本可能不同。容量在操作系统中可以呈现为可用总量，但访问代价并不因此统一。此处只记住“总量相同不等于访问距离相同”，具体拓扑与放置策略留给 H25。
第 4 类误判出现在云环境。内存超卖可能借助统计复用、回收等机制提高宿主机利用率，但是否采用、采用何种方式以及是否影响实例，取决于服务类型和资源保障。客户机性能下降不能直接证明超卖，因为自身换页、其他资源竞争和访问模式变化也会产生相似表现。应记录实例规格、可用内存、压力事件与时间相关性，再结合平台指标定位。
对于关键业务，云上容量余量与性能保障仍需写入方案。可以通过代表性负载观测峰值、长尾响应和扩容效果，但不要为了观察而推断自己看不到的宿主机细节。如果迁移到另一规格后问题缓解，这说明资源条件发生了有效变化，却还不足以单独证明原来的故障根因。把事实、推测和已确认结论分开，才能形成可复用的运维记录。
案例：通道未插满与未被发现的错误
某分析服务采用支持 4 个内存通道的平台，配置 4 根 32 GB 模块，目标容量为 128 GB。该平台每通道提供 2 个槽位，但安装时只使用了其中 2 个通道，每通道放置 2 根模块。容量检查全部通过，然而大型扫描任务无法达到预期吞吐。问题的关键是模块总量充足，独立传输通路却没有全部启用。
假设调整前后都实际运行在 4800 MT/s，且各通道用户数据宽度合计为 64 位，那么原配置的理论峰值为 2 × 38.4 = 76.8 GB/s，均衡启用 4 个通道后为 153.6 GB/s。在这个明确前提下，原配置的理论峰值只有完整配置的 50%，可以称为通道未插满导致带宽腰斩。这里的比例针对理论上限，不能直接写成服务速度提升 100%。
处理过程应先核对槽位与通道映射、实际速率及平台安装规则，再在维护窗口调整模块位置。调整后既确认容量和通道状态，也在相同数据规模、并发和统计口径下复测业务。若吞吐没有按比例提高，应继续检查计算、存储输入以及请求并行程度等约束。配置修复与性能归因是相互关联的工作，但需要分别留下证据。
另一个案例是长期运行的报表服务。假设某次内存位错误把中间金额改成了另一个合法数值，程序没有崩溃，结果也顺利写入数据库。常规可用性监控可能只看到“服务正常”，后续复制甚至可能把错误结果继续传播。这个案例展示的是无保护且错误未被其他机制发现时的风险，并非每次内存错误都会以同样方式发生。
如果系统具备且已启用相应 ECC，在该错误属于可纠正范围时，硬件可以在数据交付前纠正并记录事件；超出保护能力时，则需要检测、隔离和恢复机制接续处理。业务仍需保留数据校验、审计或重算能力，因为硬件保护无法覆盖所有错误来源。容量案例提醒我们验证通道，可靠性案例提醒我们验证保护范围与处置闭环。
放进方案里
带宽部分写明处理器支持的通道数、计划启用的通道数、模块分布和实际目标传输速率。按照速率、数据宽度与通道数估算理论峰值，同时标注它只是上限。验收采用固定的数据规模、访问模式和并发条件，以业务吞吐及响应时间作为判断依据。对连续扫描任务重点观察持续传输，对依赖访问较多的任务同时关注等待时间，避免仅用标称速率排列方案。
可靠性部分把是否需要 ECC 写进非功能需求，即 NFR。对数据库、关键计算和长期运行服务，应说明错误结果的业务影响，再据此选择平台保护能力。需求应包含兼容性确认、启用状态验证、错误日志获取、告警责任人与不可纠正错误的恢复办法。预算讨论也应覆盖排障和错误结果扩散的成本，不能只比较模块单价。
方案还要交代部署约束。物理服务器应按平台规则均衡安装模块，并检查扩容后是否降速；云实例应核对可获得的性能保障和可观测指标，避免承诺无法确认的物理布局。若存在 NUMA，注明需要后续评估访问距离。验收记录应保留配置、测试条件和测量结果，使下一次扩容能够沿用同一判断口径，而不是只留下“内存已加大”的结论。
小结：从内存规格走向系统判断
主存承接程序运行中的工作集；DRAM 借助电荷状态存位，并依靠刷新维持信息。行列组织、行缓冲区和内部并行资源解释了为什么访问顺序会影响效率。内存条是模块，通道是独立数据通路，rank 是模块组织；增加条数、增加容量和增加通道带宽之间没有可以跳过条件的等号。
阅读规格时，先区分 MT/s 与 MHz，再核对通道计数和数据宽度，最后计算理论带宽。带宽回答单位时间能运多少，延迟回答请求需要等多久；应用是否受益，还取决于访问方式和在途请求数量。ECC 在规定范围内检测或纠正错误，只有配套平台支持、确认启用并接入运维，才能形成实际的可靠性能力。
后续进入 H12 时，可以继续沿用“容量、传输能力、单次等待、可靠性”这组观察维度，比较其他硬件规格。在 S4 的内存管理内容中，地址空间、内存页与回收机制会把本课的物理资源同程序视角连接起来。理解硬件供给与系统管理的边界，有助于把“内存慢”或“内存不够”转化为可以验证的具体判断。
本课概念依据为公开 DRAM 与 JEDEC 相关基础概念，以及《深入理解计算机系统》（CSAPP）的存储器层次内容。具体模块兼容性、可用速率、通道布局和纠错能力，仍应以目标平台的公开技术说明为准。
下一课转向 H12 硬盘与固态盘：把本章验收过的结论带进后续主题，写成可检查的方案约束。