性能调优参数

性能参数需要按组调整，并以目标工作负载进行验证。下面的示例为 brewfs mount --config 使用的 YAML；基准 runner 则使用等价的 BREWFS_* 环境变量。

从安全基线开始

对于 Redis 元数据和 S3 兼容对象存储，建议从以下配置开始。它保留默认的 upload_before_commit 路径：fsync 或 close 成功后，对象数据与元数据均已持久化并可见。

data:
  backend: s3
  s3:
    bucket: brewfs-data
    endpoint: http://127.0.0.1:9000
    region: us-east-1
    force_path_style: true
    disable_payload_checksum: true
    part_size: 16777216
    max_concurrency: 32

meta:
  backend: redis
  redis:
    url: redis://127.0.0.1:6379/0
  open_file_cache_ttl_ms: 30000
  open_file_cache_capacity: 65536
  allow_write_open_cache: false

cache:
  root: /var/cache/brewfs
  writeback_mode: upload_before_commit

fuse:
  workers: 1
  max_background: 512

cache.root 应位于高速本地 SSD，而不是网络文件系统；并确保磁盘剩余空间足以容纳配置的读、写 SSD 缓存预算。

容量与并发控制

参数	默认值	适用场景	代价
`cache.read_memory_bytes`	4 GiB	热点读	增加常驻内存
`cache.read_ssd_bytes`	20 GiB	更大的工作集	占用更多本地 SSD
`cache.write_memory_bytes`	384 MiB	突发写入	提高内存压力
`cache.write_ssd_bytes`	20 GiB	写入暂存	占用更多本地 SSD
`cache.memory_budget_bytes`	1280 MiB	Reader/Writer 缓冲区	必须与缓存内存共同纳入容量规划
`data.s3.max_concurrency`	32	S3 multipart 传输	可能占满对象存储或网络
`cache.upload_concurrency`	10	单个 writer 的上传并发	过高可能恶化读取尾延迟
`fuse.workers`	1	并行处理 FUSE 请求	增加调度与 CPU 开销
`fuse.max_background`	512	FUSE in-flight 请求	过载时积压更多任务

chunk_size 默认是 64 MiB，block_size 默认是 4 MiB。两者会影响对象布局；调整后应在全新的测试数据集上评估。

读密集与混合随机 I/O

吞吐优先的读 profile 会提升缓存容量和 FUSE 并发。read_direct_io: true 可以避免大 buffered FUSE 读被拆分，但会让受影响的读句柄无法使用 mmap。

cache:
  root: /var/lib/brewfs/cache
  read_memory_bytes: 4294967296
  read_ssd_bytes: 4294967296
  write_memory_bytes: 4294967296
  write_ssd_bytes: 4294967296
  memory_budget_bytes: 12884901888
  prefetch_enabled: true
  prefetch_max_bytes: 67108864
  prefetch_concurrency: 64

fuse:
  workers: 6
  max_background: 512
  read_direct_io: true

对于低延迟随机读，也应以 cache.range_background_prefetch: false 做一轮对照。后台全块预取有利于顺序访问，但会与对象存储上的前台读竞争。请比较 p95/p99 延迟，而不只看吞吐量，再决定是否保留该开关。

大写入与 S3 writeback

高吞吐 writeback profile 会先提交元数据、再异步上传对象，只能用于 data.backend: s3，并且刻意不是安全默认值。

cache:
  writeback_mode: commit_before_upload
  writeback_persist_sync: false
  writeback_require_stage_before_commit: true
  writeback_upload_concurrency: 6
  upload_concurrency: 32
  dirty_slice_target_size: 67108864
  dirty_slice_max_age_ms: 2000
  writeback_recent_pending_soft_bytes: 2147483648
  writeback_recent_pending_hard_bytes: 3221225472
  compression: none
  verify_cache_checksum: full

fuse:
  workers: 6
  max_background: 512

commit_before_upload 将本地暂存缓存作为立即的写回目标，因此能够提高写入吞吐。如果异步对象尚未上传到 S3 时进程异常退出或缓存盘损坏，已经发布到元数据的数据可能缺失，其他客户端也可能暂时读到缺失对象。只有接受这一持久性窗口、且会监控待上传队列时才使用它；常规生产持久性契约应保留 upload_before_commit。

compression: none 去除了大写入基准中的压缩 CPU 开销，以更多网络流量和对象存储空间换取 CPU 吞吐。lz4 仍是通用默认值；zstd 更偏向节约存储而非 CPU 吞吐。

元数据密集型负载

open-file cache 可避免反复读取属性与 slice。保守配置只缓存读句柄：

meta:
  open_file_cache_ttl_ms: 30000
  open_file_cache_capacity: 65536
  allow_write_open_cache: false

单客户端基准，或明确接受跨客户端 close-to-open 新鲜度下降的工作负载，可以使用较短 TTL 的 profile：

meta:
  open_file_cache_ttl_ms: 1000
  open_file_cache_capacity: 65536
  allow_write_open_cache: true

不要把 allow_write_open_cache: true 当作多客户端生产环境的通用优化。它允许非 append 写句柄复用缓存属性，因而可能延迟观察到其他客户端的变更。

预读、缓存校验与带宽

参数	建议
`cache.prefetch_enabled`	顺序负载可保持开启；随机 I/O 应进行 A/B 对照。
`cache.prefetch_max_bytes`	默认最大预读 64 MiB；确认缓存余量后再上调。
`cache.prefetch_concurrency`	默认 64；若后台 I/O 影响前台延迟，应降低。
`cache.range_background_prefetch`	小范围读有局部性时有帮助；评估随机读尾延迟时可关闭。
`cache.populate_write_cache_after_upload`	上传后让新写入 block 继续服务读取。
`cache.persist_write_cache_after_upload`	将这些 block 持久化到读缓存盘，代价是额外本地写 I/O。
`cache.verify_cache_checksum`	`full` 提供缓存完整性保护；`none` 仅适合基准取舍。
`cache.bandwidth.upload_limit_mibps` / `download_limit_mibps`	用 MiB/s 限制共享网络或对象存储的上传、下载带宽。

验证每个 profile

使用全新的基准数据集；冷读前清空本地缓存并等待 writeback 排空；记录完整配置和测试结果。通过 BrewFS 统计数据观察缓存命中、后台预取、待上传字节数，以及元数据 open-cache 命中率。已发布数字所使用的 fio profile 与复现规则，请参阅基准测试方法。

性能参数需要按组调整，并以目标工作负载进行验证。下面的示例为 brewfs mount --config 使用的 YAML；基准 runner 则使用等价的 BREWFS_* 环境变量。

从安全基线开始

data:
  backend: s3
  s3:
    bucket: brewfs-data
    endpoint: http://127.0.0.1:9000
    region: us-east-1
    force_path_style: true
    disable_payload_checksum: true
    part_size: 16777216
    max_concurrency: 32

meta:
  backend: redis
  redis:
    url: redis://127.0.0.1:6379/0
  open_file_cache_ttl_ms: 30000
  open_file_cache_capacity: 65536
  allow_write_open_cache: false

cache:
  root: /var/cache/brewfs
  writeback_mode: upload_before_commit

fuse:
  workers: 1
  max_background: 512

cache.root 应位于高速本地 SSD，而不是网络文件系统；并确保磁盘剩余空间足以容纳配置的读、写 SSD 缓存预算。

容量与并发控制

参数	默认值	适用场景	代价
`cache.read_memory_bytes`	4 GiB	热点读	增加常驻内存
`cache.read_ssd_bytes`	20 GiB	更大的工作集	占用更多本地 SSD
`cache.write_memory_bytes`	384 MiB	突发写入	提高内存压力
`cache.write_ssd_bytes`	20 GiB	写入暂存	占用更多本地 SSD
`cache.memory_budget_bytes`	1280 MiB	Reader/Writer 缓冲区	必须与缓存内存共同纳入容量规划
`data.s3.max_concurrency`	32	S3 multipart 传输	可能占满对象存储或网络
`cache.upload_concurrency`	10	单个 writer 的上传并发	过高可能恶化读取尾延迟
`fuse.workers`	1	并行处理 FUSE 请求	增加调度与 CPU 开销
`fuse.max_background`	512	FUSE in-flight 请求	过载时积压更多任务

chunk_size 默认是 64 MiB，block_size 默认是 4 MiB。两者会影响对象布局；调整后应在全新的测试数据集上评估。

读密集与混合随机 I/O

吞吐优先的读 profile 会提升缓存容量和 FUSE 并发。read_direct_io: true 可以避免大 buffered FUSE 读被拆分，但会让受影响的读句柄无法使用 mmap。

cache:
  root: /var/lib/brewfs/cache
  read_memory_bytes: 4294967296
  read_ssd_bytes: 4294967296
  write_memory_bytes: 4294967296
  write_ssd_bytes: 4294967296
  memory_budget_bytes: 12884901888
  prefetch_enabled: true
  prefetch_max_bytes: 67108864
  prefetch_concurrency: 64

fuse:
  workers: 6
  max_background: 512
  read_direct_io: true

大写入与 S3 writeback

高吞吐 writeback profile 会先提交元数据、再异步上传对象，只能用于 data.backend: s3，并且刻意不是安全默认值。

cache:
  writeback_mode: commit_before_upload
  writeback_persist_sync: false
  writeback_require_stage_before_commit: true
  writeback_upload_concurrency: 6
  upload_concurrency: 32
  dirty_slice_target_size: 67108864
  dirty_slice_max_age_ms: 2000
  writeback_recent_pending_soft_bytes: 2147483648
  writeback_recent_pending_hard_bytes: 3221225472
  compression: none
  verify_cache_checksum: full

fuse:
  workers: 6
  max_background: 512

元数据密集型负载

open-file cache 可避免反复读取属性与 slice。保守配置只缓存读句柄：

meta:
  open_file_cache_ttl_ms: 30000
  open_file_cache_capacity: 65536
  allow_write_open_cache: false

单客户端基准，或明确接受跨客户端 close-to-open 新鲜度下降的工作负载，可以使用较短 TTL 的 profile：

meta:
  open_file_cache_ttl_ms: 1000
  open_file_cache_capacity: 65536
  allow_write_open_cache: true

不要把 allow_write_open_cache: true 当作多客户端生产环境的通用优化。它允许非 append 写句柄复用缓存属性，因而可能延迟观察到其他客户端的变更。

预读、缓存校验与带宽

参数	建议
`cache.prefetch_enabled`	顺序负载可保持开启；随机 I/O 应进行 A/B 对照。
`cache.prefetch_max_bytes`	默认最大预读 64 MiB；确认缓存余量后再上调。
`cache.prefetch_concurrency`	默认 64；若后台 I/O 影响前台延迟，应降低。
`cache.range_background_prefetch`	小范围读有局部性时有帮助；评估随机读尾延迟时可关闭。
`cache.populate_write_cache_after_upload`	上传后让新写入 block 继续服务读取。
`cache.persist_write_cache_after_upload`	将这些 block 持久化到读缓存盘，代价是额外本地写 I/O。
`cache.verify_cache_checksum`	`full` 提供缓存完整性保护；`none` 仅适合基准取舍。
`cache.bandwidth.upload_limit_mibps` / `download_limit_mibps`	用 MiB/s 限制共享网络或对象存储的上传、下载带宽。

性能调优参数

从安全基线开始

容量与并发控制

读密集与混合随机 I/O

大写入与 S3 writeback

元数据密集型负载

预读、缓存校验与带宽

验证每个 profile

On this page

性能调优参数

从安全基线开始

容量与并发控制

读密集与混合随机 I/O

大写入与 S3 writeback

元数据密集型负载

预读、缓存校验与带宽

验证每个 profile

On this page