MindStudio Insight支持Device内存分析特性设计说明书¶
Copyright © 2026 Ascend Community
改版记录
| 日期 | 修订版本 | 修订描述 | 作者 | 审核 |
|---|---|---|---|---|
| 2026-01-15 | v1.0 | 初稿 | 刘鹏程 | 廖宴 |
目录
表目录
表X：特性场景相关性分析
表X：特性需求列表
图目录
图X：方案总体实现原理图
图X：样图：处理流程示意图
List of abbreviations 缩略语清单 ：
| Abbreviations 缩略语 | Full spelling 英文全名 | Chinese explanation 中文解释 |
|---|---|---|
| msInsight | MindStudio Insight | MindStudio Insight |
1.特性概述¶
在大模型训练或推理性能调优场景下，内存优化是一个非常重要的方向，如何在固定的Device内存条件下，运行更大参数模型或计算更大Batch数据，一直是大模型热门课题。MindStudio Insight作为昇腾平台性能分析工具，提供完整丰富的内存分析功能，来帮助开发者识别和优化内存使用。
1.1范围¶
昇腾平台Device侧内存分析。
1.2特性需求列表¶
表X：特性需求列表
| 需求编号 | 需求名称 | 特性描述 | 备注 |
|---|---|---|---|
| 1 | 支持PyTorch中snapshot内存分析 | 支持snapshot中内存Timeline展示和内存状态分析功能 | |
| 2 | 支持MindStudio Memory Scope内存分析 | 支持msMemScope内存Timeline、调用栈、内存分类拆解等功能 |
2.需求场景分析¶
2.1特性需求来源与价值概述¶
在强化学习场景下，其包含多个generate_sequence、actor_update等多个不同的阶段，其内存变化也是非常复杂的，通过snapshot或msMemScope能够深入分析各个阶段内存使用细节，为解决OOM和内存优化提供依据。
2.2特性场景分析¶
描述该特性的业务使用场景
内容包括：
1）场景触发条件及对象：什么角色/工具/接口等在什么具体情况下使用该特性，使用对象技能如何？
2）描述该特性主要有哪些用户应用场景、子场景及关键任务操作。_
2.3特性影响分析¶
描述该特性在整个系统中的位置及周边接口。描述该特性有哪些关键约束或特性冲突。
与其他需求及特性的交互分析：
平台差异性分析：包括硬件平台和操作系统
兼容性分析：
约束及限制：
2.3.1硬件限制¶
支持昇腾NPU各代际产品。
2.3.2技术限制¶
操作系统：支持Windows、Linux、MacOS三种类型操作系统。
- Windows版本10+;
- Linux版本glibc > 2.30;
- MacOS版本13.0+。
如果所使用的Linux版本glibc < 2.30，建议升级Linux版本或从源码编译msInsight代码以获得支持。
2.3.3对License的影响分析¶
NA
2.3.4对系统性能规格的影响分析¶
- 建议运行msInsight设备内存超过16GB。
- 建议内存数据文件不超过1GB。
2.3.5对系统可靠性规格的影响分析¶
特性对于可靠性指标的假设和约束，例如在预设的条件下要支持 __x__ 个 __9__ 的目标等。
2.3.6对系统兼容性的影响分析¶
是否会影响数据库的前向兼容，也就是用户在数据库旧版本使用的特性在新版本上是否依然可以使用。
2.3.7与其他重大特性的交互性，冲突性的影响分析¶
分析包括周边工具、其他内核特性的交互和影响
2.4同类社区/商用软件实现方案分析¶
该特性在同类社区 __/__ 商用软件上的实现机制，对比分析，体现优劣性对比
3.特性/功能实现原理（可分解出来多个Use Case）¶
3.1目标¶
该章节主要描述特性在什么场景下要实现什么规格、达到什么目标
3.2总体方案¶
该章节主要阐述该特性的详细设计，包括选择什么硬件、使用什么算法、架构如何布局等
从整体流程上，根据场景分析和系统分解，将特性实现分为多个关键场景（ __Use Case__ ）
定义对接的原则
方案整体架构图
例如：
图X：方案总体实现原理图
4.Use Case一实现¶
4.1设计思路¶
说明 __Use Case__ 实现的思路
4.2约束条件¶
描述前提条件，即该功能开启的限制条件，比如会导致系统 __xx__ 功能不可用，比如在 __xx__ 内存限制下才能开启等。
4.3详细实现（从用户入口的模块级别或进程级别消息序列图）¶
本章节具体描述 __Use Case__ 实现过程。使用时序图、流程图描述各模块间的交互过程。
同时用简短文字说明时序图、流程图的各个模块分配需求的变化，尽量使用结构化的语言。
4.4子系统间接口（主要覆盖模块接口定义）¶
在这个章节只要说本次修改涉及哪个 __.h__ 的哪个接口的修改，大致的修改内容简述下即可。
4.5子系统详细设计¶
详细描述各模块的修改点。
4.6DFX属性设计¶
4.6.1性能设计¶
特性是否影响已有的相关性能指标，是否会影响现有特性的性能，如何保证新特性的性能
4.6.2升级与扩容设计¶
特性是否会影响到升级和扩容
升级设计原则包括:
- _涉及系统表修改的特性，必须设计系统表升级脚本和回滚脚本，以及版本号控制
- _对于涉及修改持久化数据（如日志）的特性，必须考虑新老版本共存时的兼容性场景，必要情况下，需要增加版本号以进行控制
- _对于涉及修改执行态数据格式（如syscache结构）的特性，必须考虑新老版本共存时的兼容性场景，必要情况下，需要增加版本号以进行控制
- _涉及升级工具gs_upgradectl的修改，设计需要考虑灰度升级、回滚、再升级和升级提交等内部逻辑
- _涉及集群管理工具（例如om或cm）的公共函数修改，设计需要考虑灰度升级、回滚、再升级和升级提交等内部逻辑
4.6.3异常处理设计¶
有哪些异常场景，是否有规避方案，怎么提示用户，如何保证用户业务影响最小
4.6.4资源管理相关设计¶
是否占用额外的内存、磁盘 __I/O__ 、网络 __I/O__ 等资源，资源占用规格是什么，如果资源超出环境限制后，是否有处置措施
4.6.5小型化设计¶
请说明特性是否会影响小型化版本的规格（内存使用、安装包大小、 __CPU__ 占用等），如果影响，是否有调整优化手段或者使用宏隔离。
4.6.6可测性设计¶
特性是否具备可测试性，给出测试应该涵盖的功能、性能、安全、可靠性等方面，涵盖边界值、异常场景等。
4.6.7 安全设计¶
4.6.7.1 安全设计确认¶
参考安全设计checklist进行确认
| 安全属性 | 检查项 | 检查项详细说明 | 是否涉及 | 是否满足 |
|---|---|---|---|---|
| 访问通道控制 | 是否新增侦听端口 | 新增侦听端口需刷新通信矩阵 | NO | |
| 访问通道控制 | 是否新增进程或组件间通信 | 新增进程或组件间通信刷新通信矩阵 | NO | |
| 访问通道控制 | 是否新增认证方式 | 新增认证方式需刷新通信矩阵及产品文档 | NO | |
| 权限控制 | 是否涉及创建文件或目录 | 创建文件或目录须显式指定文件或目录的访问权限 | YES | YES |
| 权限控制 | 账号权限是否满足“权限最小化原则” | 系统中各账号应赋予最小权限 | NO | |
| 权限控制 | 是否存在用户权限提升 | 禁止出现用户非法权限提升 | NO | |
| 未公开接口 | 是否新增GUC参数 | 新增GUC参数需刷新产品文档 | NO | |
| 未公开接口 | 是否新增或修改函数、视图、系统表 | 新增或修改函数、视图、系统表需刷新产品文档，考虑权限控制 | YES | YES |
| 未公开接口 | 是否新增SQL语法 | 新增SQL语法需刷新产品文档，支持记录审计日志 | YES | YES |
| 未公开接口 | 是否新增内部工具 | 新增内部工具需刷新产品文档 | NO | |
| 未公开接口 | 脚本中是否存在注释代码 | Shell/Python等解释性语言禁止注释代码，注释代码需要删除 | NO | |
| 未公开接口 | 是否存在隐藏命令、参数、端口等接入方式 | 对于现网维护期间不会使用的命令/参数、端口等接入方式（包括但不限于产品的生产、调测、维护用途），必须删除（如通过编译宏） | NO | |
| 未公开接口 | 系统是否存在隐藏后门 | 禁止系统预留任何的未公开账号，所有账号必须可被系统管理，并在资料中予以说明 | NO | |
| 未公开接口 | 禁止在产品对外部用户发布的软件（包含软件包/补丁包）中提供破解类、网络嗅探类工具。 | 1、禁止在产品对外部用户发布的软件（包含软件包/补丁包）中提供可修改任意用户口令、具有“口令破解能力”（指口令暴力破解、利用系统/算法漏洞恶意破解口令）、对包含敏感数据的文件（如包含密钥的配置文件、数据库）进行解密的功能或工具。2、禁止在系统中保留第三方的网络嗅探工具tcpdump、gdb、strace、readelf网络、进程调试工具，cpp、gcc、dexdump、mirror、JDK开发/编译工具和仅在调测阶段使用的自研调试工具/脚本（例如：仅在调试阶段使用的加解密脚本、调测功能、可以提权的命令），由于业务需要必须保留的，需要进行严格的访问控制。同时在资料中说明保留的原因、使用的场景、风险。 | NO | |
| 敏感数据保护 | 认证凭据不允许明文存储在系统中，应该加密保护。 | 认证凭据（如口令/私钥等）不允许明文存储在系统中，应该加密保护。 | NO | |
| 敏感数据保护 | 用于敏感数据传输加密的密钥，不能硬编码在代码中。 | 禁止口令和密钥硬编码。 | NO | |
| 敏感数据保护 | 是否明文打印口令或密钥等敏感信息 | 禁止在系统中存储的日志、调试信息、错误提示及ps命令等信息打印明文敏感信息（口令/私钥/预共享密钥）。 | NO | |
| 敏感数据保护 | 是否明文回显口令 | 禁止明文回显口令。 | NO | |
| 敏感数据保护 | 是否使用第三方和开源软件的缺省口令 | 禁止使用第三方和开源软件的缺省口令，参考安全设计指南第1.5章节。 | NO | |
| 敏感数据保护 | 是否将密码明文存储在配置文件中 | 明文密码不允许写入配置文件（命令行工具安装部署及使用时必需配置密码的场景除外）。 | NO | |
| 敏感数据保护 | 是否使用不安全的加密算法 | 禁止使用私有的或业界已知不安全的加密算法。推荐加密算法安全设计指南6.2章节。 | NO | |
| 敏感数据保护 | 口令等敏感信息是否使用安全的传输通道 | 在非信任网络之间进行敏感信息传输须采用安全传输通道或者加密后传输。参考安全设计指南第10章。 | NO | |
| 敏感数据保护 | 内存中口令或密钥等敏感信息使用后是否销毁 | 内存中的口令或密钥等信息使用完毕后立即清0。 | NO | |
| 敏感数据保护 | 密码算法中使用到的随机数必须是密码学意义上的安全随机数。 | 密码算法中使用到的随机数必须是密码学意义上的安全随机数，参考安全设计指南6.3章节。 | NO | |
| 敏感数据保护 | 资料中是否存在不安全的示例 | 资料中的示例需要是安全的，对用户进行正确的引导，若示例中存在潜在的风险，要在资料中进行说明。 | NO | |
| 认证 | 是否提供认证机制 | 新系统需要提供认证机制并缺省开启。 | NO | |
| 认证 | 认证是否在服务端进行 | 认证处理过程需要在服务端进行。 | NO | |
| 认证 | 认证失败后服务端是否返回有效信息 | 认证失败后，服务端返回信息不能提供详细的、可用于判断具体错误原因的提示。 | NO | |
| 外部参数校验 | 是否对外部输入进行合法性校验 | 1、使用外部输入数据作为循环终止条件、数组下标、内存分配大小参数等，可能导致系统出现死循环、缓冲区溢出、内存越界、拒绝服务等一系列行为。2、文件路径等外部输入应进行合法性校验，防止注入风险 | YES | YES |
| 三方件引入 | 是否新引入三方组件 | 1.新增三方组件需要通过安全编译选项、病毒、漏洞、开源片段引用、license合规、开源组件扫描，参考版本发布网络安全质量要求。2.新增三方组件需保证来源可信。 | NO |
4.6.7.2 敏感数据分析¶
msInsight为本地工具，不涉及处理敏感信息。
4.6.7.3 设计实现¶
说明整体安全设计方案，以及详细实现、接口定义等
4.7系统外部接口¶
是否会影响到系统外部接口，包括 __guc__ 参数、工具使用方式、 __SQL__ 语法、网络协议、系统表视图函数、驱动（ __JDBC/ODBC__ ）等
4.8自测用例设计¶
描述自测用例是如何设计的，如何测试保证功能符合预期
5.Use Case二实现¶
同第 __4__ 章
6.可靠性&可用性设计¶
6.1冗余设计¶
特性设计考虑的冗余主要是系统采用了冗余设计，特性需要考虑镜像备份、配置参数备份和主备冗余系统之间进行数据同步等信息。
特性设计时，需要给出备份的关键配置参数清单，主备冗余系统之间进行数据同步时间 __/__ 策略和关键数据清单，主备切换时数据核查机制 __/__ 脏数据处理策略、备份恢复策略等。
对于镜像式备份，如快照 __/checkpoint__ 机制，需要给出备份周期、数据核查机制 __/__ 脏数据处理策略、恢复策略等，对系统性能有明显影响的特性，需要给出设计约束条件。
6.2故障管理¶
故障管理包括故障检测、故障隔离、故障定位、故障恢复和相互关联的设计。
特性的故障管理，主要是特性自身的故障检测、告警 __/__ 日志设计、故障恢复以及故障接口设计。
故障管理通常的设计原则包括：
- 故障全面快速检测通常考虑检测范围、备用检测、检测速度、检测影响；
- 控制失效影响范围通常考虑多平面、多粒度、隔离单位等隔离域划分；
- 故障快速恢复通常考虑自动恢复、优先恢复、分级复位、无耦合恢复、分层保护等策略。
故障管理常见的设计模式包括 __RollBack__ 模式、故障 __Bypass__ 、断路器模式、隔离仓模式等。
6.3过载控制设计¶
特性的过载控制设计需要考虑特性内处理业务的流量检测、检测位置和业务丢弃位置、业务丢弃时响应的业务消息信息，以及与统一的过载控制机制之间的调用、被调用关系、接口。
特性内部简单的过载控制机制通常采用限速的方式，需要考虑限速的位置、默认限速值、日志告警等信息。
过载控制通常的设计原则包括动态限流、弹性扩缩容、先负载均衡后流控、尽早控制、优先级保障、优雅降级设计等：
- 尽早控制：系统过载时，应尽可能在业务流程处理前端或业务处理较早的处理模块上控制业务接入，避免中间控制带来不必要的性能消耗；
- 优先级保障：系统过载时保证高优先级的业务能够优先获得资源，优先得到处理，从而保证社会效益最大化；
- 优雅降级设计：非核心业务降级、核心功能放通、体验降级等。
6.4升级不中断业务¶
特性内部的升级不中断业务，主要考虑特性在不同软件版本的消息兼容、配置数据格式兼容、接口兼容、与周边特性的相互依赖，以及升级失败时的快速回退处理过程。
6.5人因差错设计¶
特性的人因差错主要考虑特性涉及的命令、操作、配置文件 __/__ 数据等人机接口的错误防护，通常考虑如下几个方面：
- 删除、破坏性修改需要提供高危提示以及二次确认，页面焦点默认"取消"。用户可见接口（ __cli__ 以及 __web__ 页面）都需要考虑，包括开源组件提供的命令接口；
- 对重启节点操作需要提前检查是否影响客户 __VM__ 运行，给出明确提示建议操作；
- 所有高危操作需要记录审计日志；
- 预防配置错误、预防硬件误操作、操作执行前的系统检查和操作错误后的快速回退。
人因差错通常的设计原则包括：
- 角色约束：通过权限控制设计预防对不同角色的配置范围进行约束，避免越权配置导致错误；
- 配置校验：通过配置生效机制设计确保在配置生效前进行必要的校验，避免错误配置生效；
- 备份恢复：通过配置数据备份与恢复设计确保在出现配置错误时能够快速恢复到正确的配置数据状态。
6.6故障预测预防设计¶
特性应配合系统故障预测预防能力提供相关的数据采集和统计接口。比如磁盘空间检测等。
7.特性非功能性质量属性相关设计¶
7.1可测试性¶
重点从特性在测试的方向和规格上展开描述，说明在测试人员测试时应该测哪些方面，需要注意哪些边界值、异常值、异常场景。
7.2可服务性¶
对特性提供丰富的可维护可服务的措施，提供对特性的使用、维护、问题处理等的完整资料说明。
7.3可演进性¶
重点从特性架构、功能的可演进性上展开描述。
7.4开放性¶
重点描述特性的对外接口开放性，包括接口的规范性，比如符合 __SQL 2011__ 标准。
7.5兼容性¶
重点描述特性是否会影响系统的前向兼容性，即旧功能在升级新版本之后是否可使用，使用行为是否和旧版本保持一致。
7.6可伸缩性/可扩展性¶
有效满足系统容量变化的要求，包括数据库节点的扩缩容、数据库服务器本身的扩缩容。
7.7可维护性¶
重点从特性的可维护性展开描述，比如诊断视图、 __log__ 打印等。
8.数据结构设计（可选）¶
本章节完成数据库结构的设计（数据库系统表结构，可以使用 __Power Designer__ 完成），可选章节。