内存工具-老化内存拆解指导

【1】内存工具-老化内存拆解指导

来源：飞书 wiki（obj_token: AYXTd91pEopiafxeQzGcLrqjnrb）

注：原文 18 张图片受权限限制（media_download 全部返回 403），已用图片描述占位符保留。

什么是老化内存？

指模拟用户日常高频操作、多应用常驻、长时间运行后（大概1000+用例），设备整机与各进程累积形成的内存状态，会叠加内存泄漏、资源滞留、碎片堆积等问题，还原真实长期使用后的内存现状

各进程老化内存指标数据如何采集？

采集

非root机器上老化指标数据采集（包含老化峰值内存和老化后内存）参考进程老化模型使用说明文档 文档中步骤1-3

解析和输出解读：分为老化峰值解析和老化后留存内存解析

老化留存 ：采集结束后会自动完整解析，查看GC后的留存数据

📷 图片描述：非root机器上采集老化内存数据后的结果文件夹结构。文件夹内有”memory_distribution.xlsx”等文件，其中”reference_gc”文件夹被红色箭头指向。（token FLEPbp8V6ooKl0xdlSWcAVg1nQh，下载失败）

里面有各类sheet可查看，关注进程分布表

📷 图片描述：内存工具采集数据解析后的表格界面，表格包含”开机内存""已用内存”等模块，底部有”内存拆解表""模块汇总表""进程分布表”等标签页。（token LYovbzqOkoVvzExqpJScjwdBnwc，下载失败）

进程老化内存如何进一步定位？需要root机器（注意不要remount过）

【重要】数据自动化解析

**【重要】**数据解析已支持 自动打包 → 上传内存网站 → 后台解析 → 通知用户下载，测试前记得设置以下选项

📷 图片描述：表格界面，红框突出”指定参数”标签，下方有”auto_upload_aging_log=TRUE”和”upload_aging_log_username=zhangpengming”两行参数。（token DRRpbKlXyo1LUAxvPYScXUlSnKc，下载失败）

解析完成后飞书会通知结果，

📷 图片描述：LoadTerminator功耗分析执行结果的飞书消息界面，底部”点击链接”为 https://test.loadterminator.mioffice.cn/#/projectSelect?category=内存&keyword=817cdb77080c4a45a6e1 （token KG2FbYnQeoeYHkxPLVxcVT0vnCh，下载失败）

点击飞书红框链接后跳转到网站，在网站会有解析后的数据卡片，选详情，然后点解析包下载，就可以下载解析后的数据包

📷 图片描述：解析后的数据卡片界面，右侧卡片显示”system_file_map_0416”，弹出窗口有”详情""解析包下载""删除”选项。（token ZOTKbvAp0oIrtxx1hTUcRGGenxf，下载失败）

需要分析native堆

基本思路：

同时采集showmap + memuse数据（包含未释放的malloc的调用栈和size信息），后续找到showmap中native堆峰值时刻，从memuse中裁剪出对应时间段数据

开始采集：

参考进程老化模型使用说明文档 文档中步骤1-3，在执行序列页面将测试前只执行一次的操作改为勾选”执行memuse数据获取”和”获取showmap数据间隔自定义”两项

📷 图片描述：进程老化内存定位的测试设备配置表，特定参数部分红框突出显示”获取showmap数据间隔自定义""执行memuse数据获取”等参数。（token DpC4bc6n9oBpT7xSB7ZcM8wbnJg，下载失败）

在特定参数页面的模型特定参数配置中配置mem_use和showmap相关的参数(下图中红框中的参数都需要正确配置)。

📷 图片描述：表格”特定参数”，红框突出”dumpers_meminfo_dur”参数值为30，说明为dumpers_meminfo持续时间单位30s。（token VEqcbRmiwoaRyWxpsMocnRaWn0k，下载失败）

红框中的参数配置直接参数说明即可。但是mem_use启动参数的配置需要注意一下：

mem_use_start_time：填写mem_use采集工具的启动时机。before_test即可

init_rc：在开机阶段启动mem_use采集进程（内核当前不支持。

• before_test: 在老化测试用例执行之前启动mem_use采集进程。
• init_rc_tmp：在开机阶段启动mem_use采集进程。（当前为规避内部BUG的模式，此模式需要使用特定Patch版本，请找@印闯 协调Patch版本）

检查输出是否完整

老化测试正常结束后，会采集到如下的日志。如果日志有缺失说明采集过程有异常。

📷 图片描述：进程老化测试相关日志文件目录结构，“mem_use_systemui_p1_aging”文件夹下有多个”3.maps”开头文件，以及”memuse.filename.data""memuse.info.data""memuse.log”等文件。（token BZwdbI8TNorhDrxF3wNcTRZjnkf，下载失败）

解析&& 输出解读：

解析：

方法1：如果 3.1 中已经打开自动上传选项，老化测试跑完后会自动打包、上传、解析、通知用户下载，有问题可以咨询@谢升军

方法2：如果忘记打开了自动上传选项，可以使用一键上传脚本老化内存数据自动打包上传脚本，有问题可以咨询@谢升军

方法3：本地解析：请参考内存工具系列-老化场景日志解析指导，有问题请咨询@钟万勇

输出解读：

1. 老化留存请关注下面红色文件

➜  systemui_p1_aging_out tree -L 1
.
├── callstack
├── max   // 老化峰值数据（按照showmap中native堆的pss）
├── showmap_analysis
├── systemui_p1_aging_memuse.info_flamegraph.html // 同开机场景，整个老化过程未释放malloc调用栈的火焰图
├── systemui_p1_aging_memuse.info_flamegraph.json
├── systemui_p1_aging_memuse.info_merged.symbolized_anonymous_func.csv
├── systemui_p1_aging_memuse.info_merged.symbolized_anonymous_invalid_event.txt
├── systemui_p1_aging_memuse.info_merged.symbolized_anonymous_lib.csv
├── systemui_p1_aging_memuse.info_merged.symbolized_java_func.csv
├── systemui_p1_aging_memuse.info_merged.symbolized_java_invalid_event.txt
├── systemui_p1_aging_memuse.info_merged.symbolized_java_lib.csv
├── systemui_p1_aging_memuse.info_merged.symbolized_native_func.csv // 同开机场景，整个老化过程 按照函数拆分的malloc数据
├── systemui_p1_aging_memuse.info_merged.symbolized_native_invalid_event.txt
├── systemui_p1_aging_memuse.info_merged.symbolized_native_lib.csv // 同开机场景，整个老化过程 按照库拆分的malloc数据
└── systemui_p1_aging_memuse.info_merged.symbolized_raw_data.csv
 
3 directories, 12 files

2. 老化峰值：请关注max文件夹中下面的红色文件（已按照showmap中native堆PSS峰值时间戳进行了裁剪）

➜  max tree -L 1
.
├── callstack
├── max_systemui_p1_aging_memuse.info_flamegraph.html // 按照峰值时间戳裁剪后的malloc调用栈火焰图（已经去掉释放的部分）
├── max_systemui_p1_aging_memuse.info_flamegraph.json
├── max_systemui_p1_aging_memuse.info_merged.symbolized_anonymous_func.csv
├── max_systemui_p1_aging_memuse.info_merged.symbolized_anonymous_invalid_event.txt
├── max_systemui_p1_aging_memuse.info_merged.symbolized_anonymous_lib.csv
├── max_systemui_p1_aging_memuse.info_merged.symbolized_java_func.csv
├── max_systemui_p1_aging_memuse.info_merged.symbolized_java_invalid_event.txt
├── max_systemui_p1_aging_memuse.info_merged.symbolized_java_lib.csv
├── max_systemui_p1_aging_memuse.info_merged.symbolized_native_func.csv // 按照峰值时间戳裁剪后的函数粒度拆分的malloc数据（已经去掉释放的部分）
├── max_systemui_p1_aging_memuse.info_merged.symbolized_native_invalid_event.txt
├── max_systemui_p1_aging_memuse.info_merged.symbolized_native_lib.csv // 按照峰值时间戳裁剪后的库粒度拆分的malloc数据（已经去掉释放的部分）
└── systemui_p1_aging_memuse.info_merged.symbolized_raw_data.csv
└── max_systemui_p1_aging_memuse.info_merged.symbolized_raw_data.csv

需要分析文件页（包含老化留存和老化峰值）

基本思路：

老化留存：使用memsue工具采集老化过程文件页访问行为（会有访问的调用栈）

老化峰值：同时采集smaps+ memuse数据（包含文件页的访问信息），后续找到smaps中文件页峰值时刻，从memuse中裁剪出对应时间段数据

开始采集：

参考进程老化模型使用说明文档 文档中步骤1-3，在执行序列页面将测试前只执行一次的操作改为勾选”执行memuse数据获取”和”获取smaps数据间隔自定义”两项

📷 图片描述：表格界面，包含测试任务编号、名称、参数设置、执行人、执行方式、结果等列。（token YI4ubU050oCyJtxMUn0cUC9lnof，下载失败）

在特定参数页面的模型特定参数配置中配置mem_use采集事件为filemap

📷 图片描述：memuse工具采集数据后的输出界面，红色箭头指向”模型特定参数”，突出显示filemap关键配置项。（token MZsrb9kOUoYS6mxPiqJcTtGInyc，下载失败）

检查输出是否完整：

老化测试正常结束后，会采集到如下的日志。如果日志有缺失说明采集过程有异常。

📷 图片描述：Linux系统终端界面，红框突出显示”mem_use”和”smaps_all”两个文件，文件大小分别为15和27K。（token XOhsb8z5EoAPOQxqtvVcbCDtnqe，下载失败）

📷 图片描述：内存老化测试生成的多个smaps_all文件列表，文件名以”systemui_dijun”开头。（token OPerbgKnooixvPxGL4fcscAxnof，下载失败）

📷 图片描述：root机器执行”ll mem_use”后的文件列表，含1.smaps、2.smaps、memuse.filename.data等文件。（token P3vlbZ2jDoPPpQxpcEOcS6WNnhf，下载失败）

解析&& 输出解读：

1. 解析：
   • 方法1：参考3.1中打开自动上传选项，老化测试跑完后会自动打包、上传、解析、通知用户下载，有问题可以咨询@谢升军
   • 方法2：如果忘记打开了自动上传选项，可以使用一键上传脚本老化内存数据自动打包上传脚本，有问题可以咨询@谢升军
   • 方法3：本地解析：请参考内存工具-文件页内存拆解指导 有问题请咨询 @印闯
2. 老化留存和峰值输出可参考内存工具-文件页内存拆解指导

需要分析java堆、匿名页（包含老化留存和老化峰值）

1）基本思路：

需要分析java：采集showmap + hprof，后续找到showmap中java堆最大时刻，匹配临近的hprof分析

2）采集：参考进程老化模型使用说明文档 文档中步骤1-3，在执行序列页面将测试前只执行一次的操作改为勾选”获取hprof数据间隔自定义”和”获取showmap数据间隔自定义”两项

📷 图片描述：采集相关参数配置界面，勾选了”获取hprof数据间隔自定义”和”获取showmap数据间隔自定义”两项。（token Jk57bwbt5o5CExxpPbIcylv3nAe，下载失败）

• 在特定参数页面的模型特定参数配置中配置dumpsys，showmap和hprof相关的参数(下图中红框中的参数都需要正确配置)。

📷 图片描述：表格”模型特定参数”，红框突出”dumpsys_meminfo_dur=30”、“is_get_hprof=TRUE”、“mtb_hprof_process_name=com.android.systemui”等参数。（token MynnbaPxKoCDHKxaMYjcx4PonSb，下载失败）

3）检查输出是否完整：关注showmap_all和hprof_all下面均有大量输出文件

📷 图片描述：进程老化测试数据目录结构，红框突出显示”gfx_info""hprof_all""showmap_all”三个文件夹。（token CmUlboSfCoXDBUxzPGbcCNvJneg，下载失败）

4）解析：参考内存工具系列-老化场景日志解析指导，有问题可咨询@钟万勇

5）输出解读：

老化留存

1）java堆：hprof_all文件夹中找到最后一个hprof进行分析 或者 在2.2 章节非root机器上老化结束也会采集hprof

📷 图片描述：“老化后剩余内存”文件夹下名为”meminfo_mediaserver64.hprof.zip”的压缩文件。（token DdvfbGdjVowRNNxM4yccsiGMnwc，下载失败）

2）匿名页：showmap_all找到最后一个showmap进行分析

📷 图片描述：DataDisk文件夹下的showmap_all文件夹内容，含多组以数字命名的.txt文件。（token IyjcbM600oERAlxET30cS0gZnid，下载失败）

老化峰值：关注aging_showmap_max_result.txt中的

java堆：找到下面字段，查看峰值对应的hprof文件

[PSS Java Heap (匿名页-Java) 峰值]
  文件: systemui_dijun_294750000000_iter1_showmap_9.txt
  文件编号: 9
  测试场景: systemui  设备: dijun  轮次: iter1
  起始时间戳: 250910000000 (9921-01-09 06:13:20)
  峰值时间戳: 294750000000 (未知)
  峰值: 52453 KB
  最近的hprof文件: systemui_dijun_291120000000_iter1_hprof_5.hprof

匿名页：关注峰值对应的showmap

[PSS 匿名页-其他 峰值]
  文件: systemui_dijun_294750000000_iter1_showmap_9.txt
  文件编号: 9
  测试场景: systemui  设备: dijun  轮次: iter1
  起始时间戳: 250910000000 (9921-01-09 06:13:20)
  峰值时间戳: 294750000000 (未知)
  峰值: 17795 KB