2 个版本
0.0.2 | 2023 年 9 月 17 日 |
---|---|
0.0.1 | 2023 年 8 月 2 日 |
#131 in 性能分析
2,470 次每月下载
在 6 个 crate 中使用 (通过 kaspa-perf-monitor)
68KB
1.5K SLoC
perf-monitor-rs
此 crate 是基于 workflow-rs
的项目使用的 https://github.com/larksuite/perf-monitor-rs 的更新分支。
# Cargo.toml
[dependencies]
perf_monitor = "0.2"
一款旨在作为应用程序性能监控基础的工具包。它是
- 跨平台: perf-monitor 支持 Windows、macOS、Linux、iOS 和 Android。
- 安全包装器: perf-monitor 在内部使用许多系统 C 接口,但对外暴露安全的包装器 API。
- 高效: perf-monitor 是围绕底层 API 的薄包装器,注意不引入不必要的开销,在众多同质 API 中选择最轻量级的方法。
功能
- CPU
- 当前进程的使用情况
- 其他进程的使用情况(即将推出)
- 当前进程中的任何线程的使用情况
- 逻辑核心数量
- 内存
- 跟踪 Rust 分配的全局分配器
- Windows 和 MacOS(Linux 即将推出)中当前进程的进程内存信息。
- IO
- 磁盘 IO
- 网络 IO(即将推出)
- FD
- FD 数量
示例
一个简单的活动监视器
use perf_monitor::cpu::{ThreadStat, ProcessStat, processor_numbers};
use perf_monitor::fd::fd_count_cur;
use perf_monitor::io::get_process_io_stats;
use perf_monitor::mem::get_process_memory_info;
// cpu
let core_num = processor_numbers().unwrap();
let mut stat_p = ProcessStat::cur().unwrap();
let mut stat_t = ThreadStat::cur().unwrap();
let _ = (0..1_000).into_iter().sum::<i128>();
let usage_p = stat_p.cpu().unwrap() * 100f64;
let usage_t = stat_t.cpu().unwrap() * 100f64;
println!("[CPU] core Number: {}, process usage: {:.2}%, current thread usage: {:.2}%", core_num, usage_p, usage_t);
// mem
let mem_info = get_process_memory_info().unwrap();
println!("[Memory] memory used: {} bytes, virtural memory used: {} bytes ", mem_info.resident_set_size, mem_info.virtual_memory_size);
// fd
let fd_num = fd_count_cur().unwrap();
println!("[FD] fd number: {}", fd_num);
// io
let io_stat = get_process_io_stats().unwrap();
println!("[IO] io-in: {} bytes, io-out: {} bytes", io_stat.read_bytes, io_stat.write_bytes);
上述代码应该有如下输出
[CPU] core Number: 12, process usage: 502.16%, current thread usage: 2.91%
[Memory] memory used: 1073152 bytes, virtural memory used: 4405747712 bytes
[FD] fd number: 7
[IO] io-in: 0 bytes, io-out: 32768 bytes
详细信息请见 examples
性能
我们关注与获取性能信息相关的开销。我们尝试使用最有效的方法,同时确保 API 的可用性。
例如,这些设备上的CPU使用率和FD数量成本有以下结果
- MacOS: MacBookPro15,1; 6核心Intel Core i7; 2.6GHz; 16GB
- Windows: Windows10; Intel Core i3-2310M; 2.10GHz; 64位; 4GB
- Android: Pixel 2; android 10
性能分析 | Windows | MacOS | Android |
---|---|---|---|
线程CPU使用率(ms) | 3 | 0.45 | 16 |
FD数量(ms) | 0.15 | 0.07 | 10 |
支持平台
性能分析 | Windows | MacOS | iOS | Android | Linux |
---|---|---|---|---|---|
CPU | ✅ | ✅ | ✅ | ✅ | ✅ |
内存 | ✅ | ✅ | ✅ | ✅ | ✅ |
FD计数 | ✅ | ✅ | ❌ | ✅ | ✅ |
IO | ✅ | ✅ | ✅ | ✅ | ✅ |
请参阅每个模块的文档以获取用法和更多详细信息。
Rust版本
编译文档需要使用nightly版本,其他版本在稳定和nightly版本下均应正常工作。
cargo build
cargo +nightly doc
cargo +nightly test
cargo test --lib
贡献
欢迎贡献!
打开一个issue或创建一个PR来报告bug,添加新功能或改进文档和测试。如果您是新的贡献者,请参阅此页面以获取帮助。
为什么是perf-monitor-rs?
有一些crate可以完成类似的事情,例如spork、procfs和sysinfo。
我们的应用程序需要在运行时自我监控以帮助我们找出性能问题。例如,当CPU使用率异常升高时,我们希望找出是哪个线程引起的。
然而,上述crate中没有一个是满足我们需求的。
spork
除了调用线程之外,无法获取其他线程信息。只能处理内存和CPU信息。而且它已经停止更新多年。procfs
看起来足够好,但现在只支持Linux平台。在我们开发perf_monitor_rs的早期阶段,无法获取线程信息。sysinfo
支持我们需要的所有平台,但我们认为它的接口不够优雅,因为每个调用之前都需要显式刷新,否则会获取旧值,并且无法从返回值中区分。更重要的是,它缺少一些功能,如FD、CPU使用率。
如果您正在构建跨平台应用程序并面临相同的问题,我们希望perf_monitor_rs可以成为您的首选。
许可证
perf-monitor在MIT许可证下提供。请参阅LICENSE。
依赖项
~0.3–14MB
~122K SLoC