如何榨干Continuwuity的每一分性能？缓存、压缩与功能裁剪调优清单-平芜编程栈

【免费下载链接】continuwuity

A community-driven Matrix homeserver

项目地址：https://gitcode.com/gh_mirrors/co/continuwuity

Continuwuity 是一款社区驱动的Matrix homeserver（Rust 编写），默认配置对大多数场景够用，但想榨干硬件的每一分性能，还需要针对性调优。本文提供一份缓存、压缩与功能裁剪的完整调优清单，帮助你降低 CPU 占用、减少磁盘 I/O，让你的 Matrix 服务器在大房间和高并发场景下依然流畅。

一、先搞懂开销在哪：Continuwuity 的存储与缓存结构

从上图可以看到，Continuwuity 的核心分层包括router→api→service→database→core，底层使用RocksDB作为存储引擎。这意味着：

内存缓存（LRU cache）命中率直接影响 CPU 与磁盘 I/O 的消耗
RocksDB 压缩策略决定了存储体积与压缩/解压的 CPU 开销
出站网络操作（联邦推送、presence、typing 等）是 CPU 和网络带宽的主要消耗者

调优思路就是围绕这三点做减法或加法。官方调优指南见 docs/guides/performance.mdx。

二、缓存调优：cache_capacity_modifier 快速上手

Continuwuity 的各类内存缓存（如auth_chain_cache_capacity）默认按CPU 核心数缩放，统一由一个乘数控制。这是最简单也最有效的调优项：

# 内存充裕：从 2.0 起步，逐步上调至内存占用满意为止 cache_capacity_modifier = 2.0

场景	建议值	效果
内存充裕（16GB+）	`2.0`起步，逐步上调	大量数据驻留热内存，状态解析等操作显著加速，CPU 和磁盘 I/O 下降
内存紧张（2GB 左右）	低于`1.0`	避免 OOM，代价是磁盘/CPU 负载升高

⚠️ 特别提醒：如果你的服务器CPU 核心很多但内存很少（例如 12 核 + 2GB 内存），务必调低该值，因为缓存容量会按核心数放大，很容易吃爆内存。

相关配置说明可参考 conduwuit-example.toml，其中还包括两个进阶项：

db_cache_capacity_mb：RocksDB 读缓存的可用内存（MB），默认128 + 64 × 核心数
db_write_buffer_capacity_mb：RocksDB 写缓存的可用内存（MB），默认48 + 4 × 核心数

这两个参数同样适合"内存换性能"的玩法，调整位置与cache_capacity_modifier相同。

三、数据库压缩调优：RocksDB 压缩算法怎么选

Continuwuity 的 RocksDB 数据库默认使用zstd压缩。压缩算法的选择本质是CPU ↔ 存储空间的权衡，推荐在首次启动前完成配置（运行中切换未经充分验证）。

1. 低配机器：改用 lz4，牺牲空间换 CPU

旧 CPU（如树莓派）或磁盘空间充裕时：

rocksdb_compression_algo = "lz4" rocksdb_wal_compression = "none"

lz4压缩/解压几乎不吃 CPU，同时彻底关闭 WAL 压缩，写入路径更轻。

2. 大数据库：开启 zstd 底层深度压缩

数据库最底层存放的多是老旧且只读的数据，适合用更激进的压缩级别来压体积：

rocksdb_compression_algo = "zstd" rocksdb_compression_level = 32767 # 默认值，等价于 zstd level 3 rocksdb_bottommost_compression = true rocksdb_bottommost_compression_level = 9 # zstd level 9，更紧凑

代价是 compaction 时 CPU 占用略升，但能长期抑制数据库膨胀。各选项的完整注释见 conduwuit-example.toml，底层引擎实现位于 src/database/engine/。

四、功能裁剪：关掉没人用的昂贵功能

Matrix 协议中有些功能在大型联邦房间下开销惊人，而很多部署用不到它们。裁剪出站类功能是提升 CPU 和网络表现最直接的手段：

# 关闭出站已读回执 allow_outgoing_read_receipts = false # 关闭出站 typing 通知 allow_outgoing_typing = false

裁剪 presence（在线状态）

出站 presence 更新被官方评价为"非常昂贵"，且默认已关闭。如果你的场景完全不需要在线状态，可以彻底关掉整个 presence 处理链路：

allow_local_presence = false allow_incoming_presence = false allow_outgoing_presence = false

各开关的详细语义见 conduwuit-example.toml。

推送通知：按需评估

移动端推送通知会让 Continuwuity 持续向外部 push 服务发起请求，是重要的出站流量来源。若你的用户群不需要服务器端推送（例如纯 Web 端使用），可评估是否启用相关能力；推送机制的完整说明见 docs/guides/push.mdx。

五、网络层优化：DNS、Unix Socket 与 HTTP/3

DNS 调优（官方强烈推荐）

联邦场景下服务器每分钟可能产生数千次 DNS 查询，普通解析器根本扛不住。正确姿势：

自托管高性能缓存解析器（官方推荐Unbound），与 Continuwuity 同机部署
在 Continuwuity 中设置dns_cache_entries = 0，完全依赖外部解析器
IPv4-only 网络：设置ip_lookup_strategy = 1，省掉无意义的 IPv6 查询

⚠️ 避免使用systemd-resolved和 Docker 默认解析器，二者在高负载下表现不佳。详细步骤（含 Docker 部署示例）见 docs/guides/dns.mdx。

同机部署用 Unix Socket

反向代理与 Continuwuity 同机时，改用 Unix socket 可去除 TCP 开销：

# 先注释掉 address 和 port unix_socket_path = "/run/continuwuity/continuwuity.sock"

信任服务器排序

trusted_servers按顺序查询，把响应快的服务器放前面，并避免把matrix.org放在第一顺位（通常较慢）。超大房间加入慢时，可尝试把trusted_server_batch_size提升到2048。

反向代理开启 HTTP/3

在 Caddy 等反向代理上启用HTTP/3（放行:443/udp），可显著改善弱网环境下的客户端连接体验，减少 TCP 队头阻塞带来的延迟。

六、用指标验证调优效果

调优不是"调完就完"，Continuwuity 内置 Prometheus 指标端点，方便量化效果：

allow_prometheus_metrics = true prometheus_metrics_token = "a-long-random-secret"

重点关注这些指标（完整列表见 docs/guides/metrics.mdx）：

指标	说明
`continuwuity_sender_queue_depth`	等待发送的消息队列深度，反映出站拥塞
`continuwuity_cache_entries`	auth chain / 状态缓存条目数，验证缓存是否生效
`continuwuity_database_size_bytes`	RocksDB 数据库体积，验证压缩策略收益
`continuwuity_database_memory_bytes`	数据库内存占用，防止缓存调过头
`process_cpu_time_seconds_total`	进程 CPU 时间，对比调优前后变化

项目还附带了现成的 Grafana 仪表盘：docs/public/guides/grafana-dashboard.json，指标采集代码位于 src/core/metrics/。

调优速查清单

#	操作	收益	适用场景
1	`cache_capacity_modifier = 2.0`	状态解析加速、CPU/IO 下降	内存充裕
2	调低`cache_capacity_modifier`	避免内存耗尽	低内存 / 高核数
3	`rocksdb_compression_algo = "lz4"`+ 关闭 WAL 压缩	大幅降低 CPU 占用	老 CPU、树莓派
4	开启 bottommost 深度压缩	数据库长期不膨胀	数据量大、空间紧张
5	关闭出站 read receipts / typing / presence	降低 CPU 与网络压力	大房间、联邦繁忙
6	自托管 Unbound +`dns_cache_entries = 0`	消除 DNS 瓶颈	所有联邦部署
7	Unix Socket + HTTP/3	降低请求延迟	同机代理 / 弱网用户
8	信任服务器排序 + 增大 batch size	大房间加入更快	联邦活跃服务器