FD leak

Rust FD泄漏问题的排查与解决

王圆圆

王圆圆

— 6 min read
Rust FD泄漏问题的排查与解决
Photo by Arian Darvishi / Unsplash

问题背景

在生产环境中运行的 Rust Web 服务出现了文件描述符（FD）持续增长的现象。服务使用 actix-web 框架，配合 SQLite 数据库（通过 sqlx）、Redis 缓存、以及 Tantivy 全文检索引擎。

初始监控数据显示：

  • 同一个数据库文件 data.db 被打开了多次（FD: 9, 10, 49, 52, 61）
  • 文件描述符总数在运行一段时间后持续增长
  • 服务内存占用从 71.81 MB 增长到 305.30 MB

排查过程

1. 文件描述符分析

通过 Linux 系统工具进行详细排查：

# 查看进程打开的文件描述符
ls -l /proc/<PID>/fd

# 持续监控 FD 数量变化
watch -n 5 'ls -l /proc/<PID>/fd | wc -l'

# 详细查看 FD 类型分布
lsof -p <PID>

发现进程中存在：

  • 多个数据库文件句柄
  • 大量 eventpoll、eventfd（异步 I/O 相关）
  • Socket 连接（Redis、HTTP）

2. 代码层面审查

重点检查了可能导致 FD 泄漏的常见模式：

✅ 已排除的风险点：

  • 未使用 into_raw_fd/from_raw_fd 等底层 API
  • 未使用 mem::forget 阻止资源释放
  • 没有频繁创建不可回收的客户端对象
  • HTTP 客户端（reqwest::Client）在 AppState 中单例复用
  • Redis 连接惰性初始化后复用

⚠️ 发现的潜在问题：

  1. SQLite WAL 模式未优化
    • 默认配置下 WAL 文件可能持续增长
    • 未配置连接空闲超时

Tantivy IndexReader 频繁创建

// 每次搜索都创建新 Reader
pub fn search(&self, query: &str) -> Result<Vec<Item>> {
    let reader = self.index.reader()?;  // ❌ 频繁创建
    // ...
}

SQLite 连接池配置不当

// 原配置
SqlitePoolOptions::new()
    .max_connections(5)  // 连接数过多
    .connect(...)

优化方案

1. 限制 SQLite 连接池并设置超时

let db_pool = SqlitePoolOptions::new()
    .max_connections(3)  // 从 5 降低到 3
    .idle_timeout(Duration::from_secs(30))  // 空闲连接 30 秒后释放
    .connect(&database_url)
    .await?;

优化原理：

  • 减少同时打开的数据库文件句柄数量
  • 空闲连接自动回收，避免长期占用 FD

2. 配置 SQLite WAL 模式与 Checkpoint

// 启动时执行一次
sqlx::query("PRAGMA journal_mode=WAL;")
    .execute(&db_pool)
    .await?;

sqlx::query("PRAGMA wal_checkpoint(TRUNCATE);")
    .execute(&db_pool)
    .await?;

关于 WAL 相关文件：

  • data.db-wal（Write-Ahead Log）：事务日志文件，记录未提交到主数据库的写操作
  • data.db-shm（Shared Memory）：共享内存索引文件，协调多个进程/连接对 WAL 的访问

这两个文件是 SQLite WAL 模式的标配，不是"泄漏"，而是正常机制。通过定期执行 wal_checkpoint(TRUNCATE) 可以：

  • 将 WAL 中的数据刷入主数据库
  • 截断 WAL 文件，释放磁盘空间
  • 减少相关文件句柄的长期占用

3. 缓存 Tantivy IndexReader

pub struct Searcher {
    index: Index,
    reader: IndexReader,  // ✅ 缓存 Reader
    query_parser: QueryParser,
}

impl Searcher {
    pub fn new(index_path: &Path) -> Result<Self> {
        let index = Index::open_in_dir(index_path)?;
        let reader = index.reader()?;  // 启动时创建一次
        let query_parser = /* ... */;
        
        Ok(Self {
            index,
            reader,
            query_parser,
        })
    }
    
    pub fn search(&self, query: &str) -> Result<Vec<Item>> {
        let searcher = self.reader.searcher();  // ✅ 复用 Reader
        // ...
    }
    
    // 索引更新后调用
    pub fn reload_reader(&mut self) -> Result<()> {
        self.reader.reload()?;
        Ok(())
    }
}

优化原理：

  • IndexReader 在创建时会打开索引的 segment 文件
  • 每次请求都创建新 Reader 会导致 FD 频繁打开/关闭
  • 缓存 Reader 后，FD 数量稳定在索引分段数量上

优化效果

优化前

  • FD 数量：52+ 并持续增长
  • 数据库文件被打开 5 次
  • 内存占用：71.81 MB → 305.30 MB（持续增长）

优化后

  • FD 数量：46 并保持稳定
  • 数据库相关文件：4 个（主库 + WAL + SHM + 备用连接）
  • 内存占用稳定，无明显增长趋势
  • Socket 连接数稳定在合理范围

监控建议

生产环境监控脚本

#!/bin/bash
# monitor_fd.sh

APP_NAME="your-service"
THRESHOLD=800  # 根据 ulimit -n 设置阈值（建议 60-80%）

while true; do
    PID=$(pgrep -f "$APP_NAME" | head -1)
    if [ -n "$PID" ]; then
        FD_COUNT=$(ls -l /proc/$PID/fd 2>/dev/null | wc -l)
        echo "$(date '+%Y-%m-%d %H:%M:%S') - PID: $PID, FD Count: $FD_COUNT"
        
        if [ "$FD_COUNT" -gt "$THRESHOLD" ]; then
            echo "⚠️ WARNING: FD count exceeds threshold!"
            # 可以触发告警或详细日志
            lsof -p $PID > "/tmp/fd_detail_$(date +%s).log"
        fi
    fi
    sleep 300  # 每 5 分钟检查一次
done

关键指标

# 查看进程 FD 限制
ulimit -n

# 实时监控 FD 变化
watch -n 5 'ls -l /proc/<PID>/fd | wc -l'

# 按类型统计 FD
lsof -p <PID> | awk '{print $5}' | sort | uniq -c

# 查看 TCP 连接状态
ss -anpt | grep <PID>

经验总结

文件描述符泄漏的常见原因

  1. 数据库连接池配置不当
    • 连接数设置过大
    • 缺少空闲超时机制
    • 未正确关闭连接
  2. 文件系统资源频繁创建
    • 日志文件轮转不当
    • 临时文件未清理
    • 索引/缓存文件重复打开
  3. 网络连接管理问题
    • HTTP 客户端重复创建
    • WebSocket 连接未正确关闭
    • 长连接无超时设置
  4. 异步资源生命周期管理
    • Tokio/async-std 任务未正确清理
    • Channel 未关闭
    • Stream 未消费完毕

最佳实践

  1. 资源池化：数据库连接、HTTP 客户端等复用
  2. 设置超时：idle_timeout、connect_timeout、request_timeout
  3. 及时释放：明确资源生命周期，避免跨作用域持有
  4. 监控告警：生产环境持续监控 FD 数量
  5. 压力测试：上线前进行长时间并发测试，观察资源使用趋势

Rust 特定建议

  • 利用 RAII（Resource Acquisition Is Initialization）自动管理资源
  • 避免使用 mem::forget 和底层 FD 操作
  • 使用 Drop trait 确保资源清理
  • 异步代码注意 Future 的生命周期
  • 善用 Arc<Mutex<T>> 等模式共享资源

总结

文件描述符泄漏是生产环境中常见但容易被忽视的问题。通过系统化的排查方法、合理的资源配置、以及持续的监控，可以有效避免和解决此类问题。本次优化不仅解决了 FD 泄漏问题，还提升了服务的整体性能和稳定性。

对于 Rust 开发者来说，虽然语言本身的内存安全保证减少了很多低级错误，但在系统资源管理层面仍需要深入理解底层机制，合理配置第三方库，才能构建真正可靠的生产级服务。

Read more

城乡差距背后的高墙

城乡差距背后的高墙

2024年的官方数据显示，中国城镇化率已达67%，城乡收入比缩小至2.34。这些数字看起来令人鼓舞——我们似乎正稳步迈向城乡融合的理想图景。 但真相往往藏在数字的褶皱里。 当我深入阅读这份城乡差距研究报告时,一个令人不安的发现浮出水面：表面上缩小的"硬差距"背后,是愈发固化的"软差距",以及不断涌现的新型鸿沟。更关键的是,我们需要对这些官方数据保持必要的审慎——毕竟,统计口径的选择、样本的代表性、以及数据采集的真实性,都可能影响我们对现实的判断。 一、收入的悖论：相对缩小与绝对扩大 表象：城乡收入比在下降 报告显示,2024年农村居民收入增速(6.6%)快于城镇(4.6%),推动城乡收入比从2.39降至2.34。这符合"共同富裕"的政策叙事。 真相：绝对差距突破3万元 但如果我们看绝对金额,会发现城镇居民人均可支配收入54,

By 王圆圆
闭源的中医

闭源的中医

当我们谈论中医和西医的差异时，很容易陷入"传统与现代"、"整体与局部"这类老生常谈的对比。但如果换一个角度——会发现一个反直觉的真相：看似神秘、强调个人经验的中医，实际上更像一个"闭源系统"；而标准化、机械化的西医，反而是真正的"开源"。 这不仅仅是个有趣的比喻。这种知识传承方式的根本差异，决定了两套医学体系的进化路径，也解释了为什么当代中国出现了一个吊诡的现象：政府越保护中医，民众（尤其是知识阶层）对它的信心反而越低。 知识的黑箱与门槛 不透明的核心机制 西医的"开源"特征首先体现在其底层逻辑的可验证性。一个药物从分子结构、作用靶点、代谢途径到临床疗效，每一步都要发表论文、接受全球同行评审。任何人都可以按照论文中的方法重复实验，验证结果。这就像开源软件的源代码——完全公开，接受任何人的检验和改进。 反观中医，核心理论建立在阴阳五行、

By 王圆圆
隐形的路

隐形的路

亚当和夏娃真的有可能不吃那个禁果吗？ 这个争论了几千年的问题，也许本身就问错了方向。真正的问题不是"能不能不吃"，而是"为什么我们要假装他们能不吃"。 一个注定失败的考验 让我们诚实地看待伊甸园的设置： 一对还不具备"分辨善恶知识"的存在，被要求判断"违背命令是恶的"。这就像要求一个尚不懂对错的孩子为道德过失承担完全责任。 一棵"悦人眼目"、"能使人有智慧"的树，被种在园子中央。一个会提出质疑的声音，被允许进入。一道禁令，本身就是最好的指路牌。 如果上帝是全知的，那么在创造他们、种下那棵树、允许蛇进入的那一刻，祂就完全知道结果。这很难不让人觉得，整个设置从一开始就不是为了让他们"通过"，而是为了让他们"经历"

By 王圆圆