由 Tom McDonald 于 2024 年 2 月 20 日撰写，文章来源高级(300)，Amazon FSx forLustre存储，技术如何做永久链接 分享
使用内存映射 (MMAP) 的一个主要好处是可以节省客户端的内存，同时在多个线程和进程间共享数据，并减少文件系统对应用程序的影响。用户始终在寻找提高应用性能的方法，而这通常意味着需要深入分析工作负载的存储特征，以了解工作负载的执行目标。当应用程序利用内存映射 (MMAP) 时，理解 IO 特性会变得更加困难。在这种情况下，应用程序直接从内存读取，绕过系统级的跟踪。存储性能分析变得更加复杂，因为大多数 IO 操作都是在客户端内存中进行的。
Amazon FSx for Lustre 的默认配置已能够满足大多数用户的工作负载需求。然而，对于 MMAP 应用程序而言，在了解工作负载特征后，客户端的调整可以显著提升性能。借助这些客户端的更改，我们示范了性能提升可高达 27。
在本文中，我们探讨了如何提升 FSx for Lustre 对于 MMAP 负载的吞吐性能能力。该分析利用了 Linux 操作系统内置的性能分析工具，识别 Lustre 中提高工作负载性能的机会。这种调优无需进行服务端更改，有效减少了结果时间，并通过 Amazon EC2 和 FSx for Lustre 的运行时间减少节省了工作负载成本。
MMAP 在传统工作负载如数据库和高性能计算应用中被广泛使用，也在现代工作负载如 Apache Arrow 和科学计算语言如 Julia 中得到了应用。在以下情境中，用户的应用程序将介于 1GiB 至 30GiB 的大文件映射到内存中，随后在内存中对数据进行分析，并继续处理下一文件。用户希望最大化性能，以最佳方式满足行业内的快速上市需求。在生产环境中，如 图 1 所示，数千个 c6i8xlarge 的 EC2 实例对数据存储执行大块、高吞吐量且 100 的读取操作，推动了性能的极限。
图 1 Amazon FSx for Lustre 架构
要理解 mmap 如何与 FSx for Lustre 文件系统配合工作，我们需要深入研究 FSxL 客户端与服务器的关系以及 mmap 调用。FSxL 的设计原则与 NFS 等协议有所不同，这一差异使其在扩展性上具有优势，有助于理解其在 mmap 方面的高效操作。
从存储客户端的角度来看，“逻辑元数据卷”模块是元数据客户端 (MDC) 模块的抽象层，而逻辑对象卷 (LOV) 模块则是对象存储客户端 (OSC) 模块的抽象层。此外，还有一个 Lustre 网络 (LNET) 模块对于成功通信至关重要，但超出了本文讨论的范围。
文件的 MMAP 过程从对元数据服务器 (MDS) 的远程过程调用 (RPC) 开始。MDS 会返回文件请求和文件对象结构的元数据信息给 MDC。需要注意的是，这些不是 Amazon 简单存储服务 (Amazon S3) 对象，而是 FSxL 对象，存放于 OST 服务器上。然后，OSC 会请求将文件的数据结构返回给客户端，基于已实施的任何 FSxL 分条。
让我们看看 图 2 中的核心组件。首先，有两个对象存储服务器 (OSS)，它们与 FSx for Lustre 的扩展架构中的存储服务器相连接。每个 OSS 连接了两个对象存储目标 (OST)，即用户数据所存储的设备。在此示例中，用户数据存储在两个 OSS 和四个 OST 中的四个 FSxL 对象中。这些对象依次以轮询方式读取，分别为 stripe 0、stripe 1、stripe 2 和 stripe 3。此外，还存在称为“Lustre 分布式锁管理器” (LDLMs) 的元数据和对象服务器锁定服务，以确保文件的一致性。
在大数据传输期间，这额外的开销通常不会产生影响，因为它在网络通信中是微不足道的。原本为较大文件设计的常见带条大小为 1MB 和 4MB，对于某些较小的文件和文件操作可能会导致不利影响。
图 2 一般 Lustre 客户端通信
要最佳了解工作负载，常见的做法是从存储向应用程序反向推导。如 图 3 所示，我们分析 Amazon CloudWatch 中的使用指标：DataReadBytes、DataWriteBytes、DataReadOperations、DataWriteOperations 和 MetadataOperations。这个例子显示了默认工作负载的吞吐量为 67GB/sec，并且每秒有 6500 次 IOPS。
图 3 CloudWatch 图表 FSx for Lustre
从应用程序的角度来看，一种方法是使用 Linux 工具 strace 在正在运行的进程上进行分析，以了解 Linux 操作系统在单次测试中请求了什么。以下是示例 strace 命令：
strace fff p ltPIDgt o /path/to/output/directory
如 图 4 中所示，strace 输出显示大文件正在使用 Linux 的 MMAP 函数调用映射到内存中。映射内存中的 IO 不足以了解应用程序的特征，因为这些 IO 请求绕过了 Linux 内核 IO 子系统，直接从内存地址读取。要查看这些结果，执行以下命令，其中 是正在运行的进程：
user strace f p ltPIDgt
图 4 strace 示例输出
确认应用程序调用 mmap 后，分析转向了 OST RPC 页面信息。这对于理解 IO 的大小是小 IO 还是大 IO (gt1MiB)非常重要。从 212 版本的 Lustre 开始，操作系统的页面大小报告“每个 RPC 的页面数”。Linux 内核中的 BUFSIZ 被确定为 8KiB。
OSC 为每个访问的 OST 提供直方图报告，称为 rpcstats。在当前版本的 Lustre 客户端中，可以在 /sys/fs/lustre 下访问这些数据。
图 5 显示了“每个 RPC 的页面数”，即 RPC 调用中操作系统页面的数量。这是了解发生情况的重要线索。根据以下直方图，我们可以看到 93 的读 RPC 请求小于或等于 16KiB，79 甚至更小于 8KiB，并且小读取的延迟影响对读取性能产生了负面影响。
图 5 RPC 统计直方图
为了深入了解访问类型，分析 Slabtop 的输出是必要的，因为这需要了解 Linux 内核的操作。Slabtop 是一个 Linux 工具，它显示实时内核缓存信息，帮助用户更好地 entender 到具体的事情。有关 slabtop(1) 的更多信息，请参见主页面。
Linux 中用于内存管理的两个常见函数为 kmalloc() 和 vmalloc()。 图 6 的 Slabtop 输出清楚地表明应用程序使用的是 kmalloc()。这是一种为小于 Linux 内核页面大小的对象分配内存的标准方法，进一步验证了之前的直方图分析。这些信息帮助形成了初步的假设：增加客户端的提前读取大小将减少对 Lustre 文件系统的整体 IO 调用。
图 6 slabtop 输出示例
在确定了 IO 特征后，我们深入研究了 Lustre 操作手册。显而易见，应用程序对加载到内存的大文件执行了小 IO。此外，应用程序在单台主机上运行 16 个独立的进程读取相同的文件。这提供了预加载待映射文件是否能通过缓存数据提高多进程的读取效率的深入洞察。
我们深入探讨了以下三个客户端参数：
maxreadaheadmb 控制所有文件上的提前读取数据量，但仅在检测到顺序读取时触发。maxreadaheadperfilemb 控制在检测到顺序读取时客户端或进程应该预取的数据量。maxreadaheadwholemb 控制在访问时完整读取一个 MiB 文件的最大值，无论读取调用的大小如何。鉴于该应用程序使用了 kmalloc，我们推测这是发生的顺序读取，maxreadaheadmb 对性能产生了积极影响。下一步是运行一些命令，以了解当前的默认配置设置：
user echo “Getting the maxreadahead values”user sudo lctl getparam llitemaxreadaheadmbuser sudo lctl getparam llitemaxreadaheadperfilembuser sudo lctl getparam llitemaxreadaheadwholemb
上述命令返回的默认值为 64MB 的提前读取。由于用户有一个大文件且多个进程在读取文件，我们假设将客户端的提前读取缓冲区增加到 1024MB 将提供性能提升。我们通过以下命令调优 Lustre 文件系统的提前读取缓冲区。请注意，这些设置在重启后不会持久化，因此建议在重启时有一个可执行的启动脚本来实施这些更改。
user echo “Setting the maxreadahead values”user sudo lctl setparam llitemaxreadaheadmb=1024user sudo lctl setparam llitemaxreadaheadperfilemb=64user sudo lctl setparam llitemaxreadaheadwholemb=64
如 图 7 所示，这些客户端更改导致性能提升了 27，从默认设置下的 1201 秒降低到将 maxreadaheadmb 设置为 1024MiB 后的 877 秒。如果用户在使用 FSx for Lustre 的应用程序中进行 MMAO 处理大型文件，则应考虑增加此客户端设置。该性能提升没有额外成本，从而缩短了结果时间并提供了可扩展解决方案。
图 7 性能变化
要撤销这些更改，运行以下命令将其恢复到默认的 64MB：
user echo “Reverting the maxreadahead values back to default of 64MB”user sudo lctl setparam llitemaxreadaheadmb=64user sudo lctl setparam llitemaxreadaheadperfilemb=64user sudo lctl setparam llitemaxreadaheadwholemb=64重启 Linux EC2 实例也会恢复到默认设置，因为这些设置不会在客户端重启中保持。
在本文中，我们展示了如何识别由于 MMAP IO 导致的性能瓶颈，并如何改善性能以充分优化计算资源。这种针对 Amazon FSx for Lustre 和 Amazon EC2 的无成本性能调优技术使得这些应用在大规模上得以实现。有关提升性能的其他技术可以参考 Amazon FSx for Lustre 性能文档，这些技术与工作负载相关。
小熊加速器永久免费
通过使用标准的操作系统工具，例如 strace 和 slabtop，您可以深入分析应用程序的特征，并根据数据作出决策以优化服务并提高工作负载性能。
Amazon FSx for Lustre 是一种面向高性能计算 (HPC) 的高扩展性解决方案，全球多数 AWS 区域 都可用。如果您有任何意见或问题，请随时联系我或在评论区留言。
标签 Amazon Elastic Compute Cloud (Amazon EC2)、Amazon FSx for Lustre、AWS 云存储
Tom McDonald 是 AWS 的高级工作负载存储专家。从 Atari 400 开始，Tom 开始编写程序，长期关注于提高任何存储服务的性能。在上游能源领域有 20 年的经验，专注于文件系统和高性能计算，Tom 热衷于通过社区和指导帮助他人。
施耐德电气数据泄露事件关键要点施耐德电气拒绝支付 125000 的赎金，导致 4 GB 的被盗数据在暗网被曝光。数据泄露源于其 Atlassian Jira 系统遭到 Hellcat 勒索软件集团的入侵，泄露了超过 400000 条用户详情。此次数据泄露是在其此前承认的 Cactus 勒索软件攻击后...
使用亚马逊转录和亚马逊基础平台的实时会议助手重点摘要本文介绍了一个名为实时会议助手LMA的解决方案，利用亚马逊转录、亚马逊基础平台和相关知识库如亚马逊 Q 业务提升会议体验。用户可以实时录制会议、自动生成会议摘要，并提取有价值的见解。该解决方案支持多种会议平台，并通过浏览器扩展程序进行操作。解决方案...