OSS存储卷性能调优最佳实践

客户端选型

相较于ossfs 1.0，ossfs 2.0和strmvol存储卷在顺序读写和高并发小文件读取方面均有显著的性能提升。若业务不涉及随机写，可优先选择ossfs 2.0。

若不确认业务是否有随机写入，可以在测试环境尝试挂载ossfs 2.0存储卷。若业务执行随机写操作，会返回EINVAL类型错误。

为实现性能最大化，使用ossfs 2.0客户端时，chmod和chown操作不报错但不生效。如需为挂载点下的文件或目录设置权限，可通过PV的otherOpts字段添加挂载参数来实现：chmod可使用-o file_mode=<权限码>或-o dir_mode=<权限码>；chown可使用-o gid=或-o uid=。

详细的选型建议，请参见客户端选型参考。

性能预期

OSS存储卷作为网络文件系统，其性能受网络和协议层影响。性能问题通常指与提供的Benchmark结果存在较大偏离，而非与本地文件系统的性能差异。不同客户端的基准性能参考如下。

• ossfs 1.0存储卷读写基准性能

• ossfs 2.0存储卷读写基准性能

• strmvol存储卷读写基准性能

在PV上配置了公网端点

当集群与OSS Bucket处于同一地域时，使用内网端点可大幅降低网络延迟。

• 排查方法：执行以下命令，检查PV配置的OSS端点。

  kubectl get pv <pv-name> -o jsonpath='{.spec.csi.volumeAttributes.url}'

• 解决方案：如输出为公网端点（如 http://oss-<region-id>.aliyuncs.com），请重建PV，改用内网端点（如 http://oss-<region-id>-internal.aliyuncs.com）。

OSS服务端限流

OSS对单个Bucket有总带宽和QPS（每秒请求数）的使用限制。对于部分地域的业务，及工作流等大并发访问OSS场景，可能出现带宽和QPS限流。

• 排查方法：在OSS管理控制台查看OSS Bucket的监控指标数据，确认使用带宽、请求次数等指标是否已接近或超过限制。

• 解决方案：

  • 更换地域：OSS支持的单Bucket带宽和QPS限制与地域相关，如果业务仍处于测试阶段，可评估更换至其他地域。

  • 带宽出现瓶颈：

    • 若数据没有重复读需求：为Pod动态挂载云盘用作临时存储，对临时数据建议使用弹性临时盘（EED）。具体操作请参见使用云盘动态存储卷，不同云盘类型性能指标请参见块存储性能。

    • 若数据会在副本间或业务批次间重复读取：使用分布式缓存（如Fluid结合JindoFS），将OSS的数据提前预取至集群的缓存系统中，避免后续重复向OSS请求数据。具体操作，请参见JindoFS加速OSS文件访问。

  • QPS（或IOPS）出现瓶颈： 对于大部分业务，在并发较大时带宽会比QPS更早触发限流。若仅触发QPS瓶颈，可能是由于频繁的元信息获取（如ls, stat）或频繁的文件打开和关闭，需排查客户端的配置与业务的读写方式。请参见下文的优化业务读写逻辑与客户端参数进行优化。

业务所在节点内网带宽到达瓶颈

客户端与业务Pod运行在同一节点上，共享该节点的网络资源（Serverless算力场景下则共用一个ACS实例资源）因此，节点的网络带宽上限会约束OSS存储卷的性能上限。

• 排查方法： 查看节点监控信息或ECS实例监控信息，确认是否出现带宽瓶颈。

• 解决方案：

  • 优先考虑将业务Pod调度在可用网络带宽更高的节点上。

  • 升降配节点资源，获取更高的带宽。

  • 以上方案不可行且任务为I/O密集型时，评估切换至云盘存储卷。

ossfs 1.0存储卷落盘受云盘最大吞吐限制

ossfs 1.0客户端为了支持完整的POSIX写操作并保证单客户端的数据一致性，在访问文件时会默认将部分数据落盘。此落盘操作默认发生在ossfs Pod的/tmp下，该空间实际对应节点上用于存放容器运行时数据的云盘。因此，ossfs 1.0的性能会直接受限于这块云盘的IOPS和吞吐量上限。

• 排查方法：

  以下方式不适用于ContainerOS节点。

  1. 执行以下指令，确认业务Pod运行所在节点的容器运行时数据盘ID。

     kubectl get node <node-name> -o yaml | grep alibabacloud.com/data-disk-serial-id

     根据输出中的data-disk-serial-id，临时空间实际位于云盘实例d-uf69tilfftjoa3qb****上。

     alibabacloud.com/data-disk-serial-id: uf69tilfftjoa3qb****

     若输出中ID为空，可访问ECS控制台-块存储-云盘，根据挂载实例定位云盘并查询其监控信息。

  2. 根据获取到的实例ID，查看云盘监控信息，判断该磁盘是否出现IOPS或吞吐瓶颈。

• 解决方案：

  • 对于只读或顺序写场景：ossfs 1.0无法预知一个已打开的文件是否会被随机写入，因此即使是只读操作也可能会触发落盘行为。建议将这类业务切换到更合适的客户端（如ossfs 2.0），或对业务进行读写分离。

  • 对于随机写场景：通过FUSE客户端（如ossfs 1.0）执行随机写的性能通常较差。建议从应用层面进行改造，直接通过OSS SDK访问OSS，或者将存储切换为更适合该场景的NAS存储卷。

存放ossfs 1.0存储卷临时数据的盘水位过高

若云盘监控显示ossfs 1.0的落盘云盘使用率始终处于高水位（尤其是Serverless算力场景下），临时数据的频繁淘汰和轮转也会导致访问性能的进一步下降。

• 排查方法：

  1. 参见此前的ossfs 1.0存储卷落盘受云盘最大吞吐限制中的解决方案，确认容器运行时数据所在的云盘。

  2. 通过云盘监控查询该盘的资源使用情况。如果使用率一直维持在稳定的高水位，而业务本身对该盘的写入量较少，则可能是ossfs 1.0客户端的临时数据轮转导致的性能问题。

• 解决方案：

  1. 检查业务逻辑：确认业务代码中是否存在长期占用文件描述符（即打开文件后长期不关闭）的行为。在文件描述符被持有期间，其相关的临时数据无法被释放，会异常占用大量本地盘空间。

  2. 扩容本地盘：如果业务逻辑无问题，且当前云盘的最大吞吐量已满足要求，则需评估扩容云盘容量。

鉴权TTL过短导致大量RAM请求

ossfs客户端（1.0和2.0）在使用RAM角色鉴权时，会在初次访问OSS时获取Token并记录其过期时间。为了保证会话的连续性，客户端会在Token过期时间的20分钟前，提前获取新的Token并刷新过期时间。

因此，RAM角色的最大会话时间（max_session_duration）必须超过20分钟。

例如，若会话时间为30分钟，客户端将在Token使用10分钟后（30 - 20 = 10）进行一次刷新，不影响正常吞吐。若会话时间短于20分钟，客户端会认为Token“永远”处于即将过期的状态，从而在每次对OSS发起请求前都尝试获取新Token，引发大量的RAM请求，影响性能。

• 排查方法： 默认的客户端日志等级可能不会记录频繁的Token刷新行为。需确认业务所使用的RAM角色配置正常。

• 解决方案： 参见设置RAM角色最大会话时间，查询并修改RAM角色的最大会话时间，确保配置正常。

优化元信息缓存（并避免禁用）

元信息缓存是提升ls、stat等高频操作性能的核心机制，可以大幅减少耗时的网络请求。错误禁用或配置不当会导致客户端为保证数据一致性而频繁请求OSS，造成性能瓶颈。

• 排查方法：
  执行以下命令，确认PV配置的客户端参数中是否包含了禁用缓存的选项。

  kubectl get pv <pv-name> -o jsonpath='{.spec.csi.volumeAttributes.otherOpts}'

• 解决方案：

  • 避免禁用缓存：若上述命令的输出包含max_stat_cache_size=0 (ossfs 1.0) 或close_to_open=true (ossfs 2.0)，且业务场景不属于必须保证强一致性，建议重建存储卷并删除这些参数。

  • 优化缓存配置：如果业务读取的数据更新频率较低，可主动增大元信息缓存的数量和失效时间，以进一步提升性能。

    • ossfs 1.0存储卷：请参见元数据缓存。

    • ossfs2.0存储卷：请参见减少OSS请求并提升挂载点性能。

    • strmvol存储卷：默认缓存挂载点下的所有元信息且不失效，通常无需额外配置。

避免维护对象扩展信息（仅适用于ossfs 1.0）

文件系统的mode、gid、uid等元信息在OSS中属于对象的扩展信息，ossfs 1.0需要通过额外的HTTP请求获取。虽然客户端默认会缓存这些元信息（包括基本属性和扩展属性）以提升数据访问性能，但频繁的元信息获取，特别是包含扩展属性的获取，仍然是性能瓶颈之一。

因此，对此类场景的性能优化主要关注两点：

1. 尽可能减少获取元信息的次数，请参见优化元信息缓存（并避免禁用）。

2. 避免请求开销较大的扩展属性，以降低单次获取的时间成本。

解决方案：

• 业务不依赖文件系统元信息：建议配置readdir_optimize参数关闭扩展信息维护，其chmod、chown、stat等行为将等同于ossfs 2.0。

• 业务仅需全局配置权限：对于非root容器需要权限等场景，建议配置readdir_optimize参数，同时通过gid、uid、file_mode/dir_mode参数全局修改文件系统的默认用户或权限。

• 业务需要精细的权限策略：建议不通过文件系统权限进行访问控制。改为通过OSS服务端的鉴权体系实现路径隔离，例如为不同业务创建不同的RAM用户或角色，并使用Bucket Policy或RAM Policy限制其能访问的子路径。同时，仍应配置readdir_optimize参数以优化性能。

优化文件写入模式

OSS对象的默认写操作为覆盖写（Overwrite），客户端在处理文件修改时，需要遵循“先读后写”的模式：先从OSS将完整的对象读取到本地，然后在文件关闭后将整个文件重新上传至服务端。因此，在频繁打开、写入、关闭文件的极端情况下，业务实际上是在重复地、完整地下载和上传数据。

解决方案：

• 批量写入而非多次写入：尽可能避免无意义的多次写入。一次性将内容在内存中准备好，然后调用一次写操作完成。需要特别注意，一些封装好的写函数（例如Java的FileUtils.write），其内部已经包含了open、write、close的完整流程，在循环中反复调用此类函数会造成性能问题。

• 使用临时文件实现频繁修改：若某个文件在一次数据处理任务中确实需要被多次打开和修改，建议先将它从OSS挂载点拷贝到容器内的临时路径（如/tmp），在本地临时文件上完成所有修改操作，最后再将最终版本一次性拷贝至OSS挂载点以实现上传。

• 针对追加写场景启用Appendable特性：若业务场景仅为频繁、小量的数据追加写（例如日志写入），可评估使用ossfs 2.0，并开启enable_appendable_object=true参数配置。开启后，客户端将使用OSS的Appendable类型对象，追加数据时无需每次都下载并完整上传整个文件。但需注意：

  • 如果目标文件已经存在但不是Appendable类型对象，不支持使用该方案对其进行追加写。

  • enable_appendable_object是针对整个存储卷的全局参数。开启后，该存储卷上所有的写操作都会通过AppendObject接口实现，影响大文件覆盖写的性能（不影响读）。建议为该类追加写业务创建专用的存储卷。

优化并发读模式（尤其适用于模型加载场景）

当多个进程并发地从单个大文件内部的不同位置读取数据时，其访问模式接近随机读，容易引发客户端冗余地读取数据，造成异常的多倍带宽占用。例如，AI模型加载场景下，主流模型框架通常由多个并发进程同时读取同一个模型参数文件，从而触发性能瓶颈。

如果使用ossfs 2.0时，发现类似场景下的性能差于ossfs 1.0，或其表现与ossfs 2.0客户端压测性能有显著差异，则可确认为此问题。

解决方案：

• 数据预热（推荐）：在业务Pod启动前，通过脚本实现数据预热。其核心原理是，通过高带宽的并发顺序读，提前将模型文件完整地加载并缓存至节点的内存（Page Cache）中。预热完成后，业务进程的“随机读”将直接从内存中命中，从而绕过性能瓶颈。

  可参考以下可独立运行的预热脚本，并发地将文件内容读取到/dev/null：

  #!/bin/bash
  # 设置最大并发数
  MAX_JOBS=4
  
  # 检查是否提供了目录作为参数
  if [ -z "$1" ]; then
      echo "用法: $0 <目录路径>"
      exit 1
  fi
  
  DIR="$1"
  
  # 检查目录是否存在
  if [ ! -d "$DIR" ]; then
      echo "错误：'$DIR' 不是一个有效的目录。"
      exit 1
  fi
  
  # 使用 find 找出所有普通文件，并通过 xargs 并发执行 cat 到 /dev/null
  find "$DIR" -type f -print0 | xargs -0 -I {} -P "$MAX_JOBS" sh -c 'cat "{}" > /dev/null'
  
  echo "已完成所有文件的读取。"

  可将此脚本的核心逻辑简化，在Pod的lifecycle.postStart中执行。

  # ...
  spec:
    containers:
    - image: your-image
      env:
      # 定义模型文件所在的目录路径。若未配置或目录不存在，脚本将跳过数据预热
      - name: MODEL_DIR
        value: /where/is/your/model/
      # 定义预热脚本的并发数，默认为 4
      - name: PRELOADER_CONC
        value: "8"
      lifecycle:
        postStart:
          exec:
            command: ["/bin/sh", "-c", "CONC=${PRELOADER_CONC:-4}; if [ -d \"$MODEL_DIR\" ]; then find \"$MODEL_DIR\" -type f -print0 | xargs -0 -I {} -P \"$CONC\" sh -c 'cat \"{}\" > /dev/null'; fi"]
  # ...

• 改造业务逻辑：评估并改造业务逻辑，将“文件内的多进程并发读”切换为“对多个不同文件的并发读”，以发挥OSS高吞吐的优势。