async-profiler中nativemem未捕获所有内存分配的问题分析
问题背景
在Rust应用程序的性能分析过程中,开发者发现async-profiler的nativemem功能未能捕获所有的内存分配调用。与jemalloc/jeprof工具相比,async-profiler的结果中缺失了部分调用栈信息。这些缺失的调用栈包括通过__GI___libc_malloc和_int_malloc等底层分配函数的路径。
技术分析
经过深入调查,发现async-profiler在内存分配拦截机制上存在两个关键问题:
-
特定分配函数未被拦截:async-profiler原本没有拦截像
posix_memalign这样的特殊内存分配函数。这些函数在Rust的标准库中被广泛使用,特别是在处理对齐内存分配时。 -
函数入口点修补不完整:当函数引用同时存在于
.rela.plt和.rela.dyn节区时,async-profiler只修补了其中一个节区的引用,导致部分调用路径未被正确捕获。
解决方案
开发团队针对这两个问题进行了修复:
-
扩展了拦截范围,现在能够正确捕获
posix_memalign等特殊分配函数。 -
改进了函数入口点修补机制,确保无论函数引用出现在哪个节区都能被正确拦截。
实际影响
这个问题特别影响Rust应用程序的分析,因为Rust的内存分配器会使用多种底层分配策略。修复后,async-profiler能够提供更完整的内存分配分析结果,与jemalloc等工具的结果更加一致。
技术细节
在Linux系统中,内存分配通常通过以下路径进行:
- 应用程序调用标准库分配函数
- 这些函数最终调用底层的内存管理实现
- 性能分析工具通过拦截这些调用点来收集数据
async-profiler通过动态修补这些调用点来实现无侵入式的分析。之前的实现遗漏了一些特殊情况,现在已得到完善。
结论
这个修复使得async-profiler在内存分配分析方面更加可靠,特别是对于使用Rust等现代语言开发的应用程序。开发者现在可以更有信心地使用async-profiler来进行全面的内存性能分析。
Kimi-K2.5Kimi K2.5 是一款开源的原生多模态智能体模型,它在 Kimi-K2-Base 的基础上,通过对约 15 万亿混合视觉和文本 tokens 进行持续预训练构建而成。该模型将视觉与语言理解、高级智能体能力、即时模式与思考模式,以及对话式与智能体范式无缝融合。Python00
GLM-4.7-FlashGLM-4.7-Flash 是一款 30B-A3B MoE 模型。作为 30B 级别中的佼佼者,GLM-4.7-Flash 为追求性能与效率平衡的轻量化部署提供了全新选择。Jinja00
VLOOKVLOOK™ 是优雅好用的 Typora/Markdown 主题包和增强插件。 VLOOK™ is an elegant and practical THEME PACKAGE × ENHANCEMENT PLUGIN for Typora/Markdown.Less00
PaddleOCR-VL-1.5PaddleOCR-VL-1.5 是 PaddleOCR-VL 的新一代进阶模型,在 OmniDocBench v1.5 上实现了 94.5% 的全新 state-of-the-art 准确率。 为了严格评估模型在真实物理畸变下的鲁棒性——包括扫描伪影、倾斜、扭曲、屏幕拍摄和光照变化——我们提出了 Real5-OmniDocBench 基准测试集。实验结果表明,该增强模型在新构建的基准测试集上达到了 SOTA 性能。此外,我们通过整合印章识别和文本检测识别(text spotting)任务扩展了模型的能力,同时保持 0.9B 的超紧凑 VLM 规模,具备高效率特性。Python00
KuiklyUI基于KMP技术的高性能、全平台开发框架,具备统一代码库、极致易用性和动态灵活性。 Provide a high-performance, full-platform development framework with unified codebase, ultimate ease of use, and dynamic flexibility. 注意:本仓库为Github仓库镜像,PR或Issue请移步至Github发起,感谢支持!Kotlin07
compass-metrics-modelMetrics model project for the OSS CompassPython00