alloc-track

此项目允许对每个线程和每个回溯进行实时内存分析。

用例

• 诊断内存碎片（以可变分配的形式）
• 诊断内存泄漏
• 分析单个组件的内存消耗

用法

1. 将以下依赖项添加到您的项目中： alloc-track = "0.2.3"

2. 设置由 alloc_track::AllocTrack 包装的全局分配器

   默认Rust分配器

   
   use alloc_track::{AllocTrack, BacktraceMode};
   use std::alloc::System;
   
   #[global_allocator]
   static GLOBAL_ALLOC: AllocTrack<System> = AllocTrack::new(System, BacktraceMode::Short);
   

   Jemallocator分配器

   
   use alloc_track::{AllocTrack, BacktraceMode};
   use jemallocator::Jemalloc;
   
   #[global_allocator]
   static GLOBAL_ALLOC: AllocTrack<Jemalloc> = AllocTrack::new(Jemalloc, BacktraceMode::Short);
   

3. 调用 alloc_track::thread_report() 或 alloc_track::backtrace_report() 生成报告。注意，backtrace_report 需要启用 backtrace 特性，并将 BacktraceMode::Short 或 BacktraceMode::Full 标志传递给 AllocTrack::new。

性能

在 BacktraceMode::None 或未启用 backtrace 特性时，线程内存分析的性能相当合理。但这并不是您希望在生产环境中运行的内容，因此功能开关是个好主意。

当启用回溯日志记录时，性能将大幅下降，具体取决于分配的数量和堆栈深度。符号解析是延迟的，但许多分配意味着许多回溯。backtrace_report 只接受一个参数，即单个回溯记录的过滤器。过滤掉不感兴趣的回溯不仅更容易阅读，而且在生成报告时也更快，因为可以跳过符号解析。请参见 examples/example.rs 以获取示例。

真实世界示例

在LeakSignal，我们在一个高带宽/高并发的gRPC服务中遇到了极端的内存分割问题。我们怀疑这是一个已知的高并发超线程问题，但需要确认原因并尽快修复问题。现有的工具（bpftrace，valgrind）无法给出具体原因。我在2019年左右创建了这个项目的原型，现在是时候让它大放异彩了。在一个测试环境中，我添加了一个HTTP端点来生成线程和回溯报告。我能够确定一个位置，那里一个大的多分配对象被频繁克隆和丢弃。这里的快速修复解决了我们的内存分割问题。