0
代码
代码
Issues
Pull Requests
讨论
Wiki
分析
0
Ccai-weiwei1989docs:资料大模型二次检查
f4a0c8a5创建于 4月24日历史提交

MindStudio Profiler Analyze特性分析与设计说明书

所属SIG组: mstt-sig
落入版本: MindStudio 26.0.0
设计人员: chenhao
日期: 2026.01.21

Copyright © 2022 openGauss Community

您对"本文档"的复制，使用，修改及分发受知识共享（Creative Commons）署名—相同方式共享4.0国际公共许可协议（以下简称"CC BY-SA 4.0"）的约束。 为了方便用户理解，您可以通过访问https://creativecommons.org/licenses/by-sa/4.0/了解CC BY-SA 4.0的概要 （但不是替代）。 CC BY-SA 4.0的完整协议内容您可以访问如下网址获取：https://creativecommons.org/licenses/by-sa/4.0/legalcode。

改版记录

日期 修订版本 修订描述 作者 审核
2026.01.21 1.0 初稿完成 chenhao chenhao

1.特性概述

本产品主要针对性能数据的分析和处理，主要包含性能拆解比对、专家建议、集群分析等基础模块，支持识别业务性能瓶颈。

1.1范围

1.2特性需求列表

表1：特性需求列表

需求编号 需求名称 特性描述 备注
1 支持模型性能拆解比对能力 模型算子的拆解和比对能力分析报告
2 支持Host的分析能力 Host Bound性能问题的自动化识别能力

2.需求场景分析

2.1特性需求来源与价值概述

1、模型开箱性能拆解及优化方向，亟须自动化拆解比对能力，提升性能调优分析效率。

2、Host Bound问题自动化识别和分析，在大模型及集群场景能力快速定界瓶颈。

2.2特性场景分析

基于模型开箱、基线版本性能提升方向。

2.3特性影响分析

描述该特性在整个系统中的位置及周边接口。描述该特性有哪些关键约束或特性冲突。

与其他需求及特性的交互分析：只涉及数据分析，独立拆解模块

平台差异性分析：win/linux

兼容性分析：新增模块能力，无兼容性问题

约束及限制：无

2.3.1硬件限制

产品类型 支持情况
Atlas A3系列训练/推理产品 支持
Atlas A2系列训练/推理产品 支持

2.3.2技术限制

操作系统：linux

编程语言：C / Python

2.3.3对License的影响分析

NA

2.3.4对系统性能规格的影响分析

按需配比资源，无特定规格诉求。

2.3.5对系统可靠性规格的影响分析

NA

2.3.6对系统兼容性的影响分析

数据分析模块新功能特性，不涉及兼容性影响。

2.3.7与其他重大特性的交互性，冲突性的影响分析

NA

2.4同类社区/商用软件实现方案分析

NA

3.特性/功能实现原理（可分解出来多个Use Case）

3.1目标

3.2总体方案

MindStudio Profiler Analyze（msprof-analyze，MindStudio性能分析工具）是MindStudio全流程工具链推出的性能分析工具，基于采集的性能数据进行分析，识别AI作业中的性能瓶颈。

image_7

图2：msprof-analyze整体方案图

4.数据分析支持拆解比对及Host Bound自动分析识别能力

4.1设计思路

通过集群同通信域内的闲置时间识别临近任务的模式建模，定位性能瓶颈点，自动识别提升自动化效率。

4.2约束条件

NA

4.3详细实现（从用户入口的模块级别或进程级别消息序列图）

image_2.png

图3：Host Bound识别流程描述图

具体方案实现细节描述如下：

  1. 首先，计算并筛选NPU硬件的闲置时间，关注某个大块闲置时间

  2. 对于某个大块闲置时间，明确其性能瓶颈所在层级，归类为Host侧瓶颈，将设备层的问题归为Device侧瓶颈:

    1. 关注当前大块闲置时间邻近的前后两个硬件任务，及其主机侧的CANN层下发操作和Pytorch层的下发任务

    2. 基于邻近两个硬件任务的主机侧下发和硬件侧执行行为，分别计算层间的等待时间

      image_3.png

    3. 根据前后邻近任务的层间等待时间，构建当前行为模式

      image_4.png

  3. 对于主机侧瓶颈，关注前后邻近任务之间发生的所有Pytorch层和CANN层任务，给出耗时最长的Pytorch函数与CANN层函数。

  4. 对于硬件侧瓶颈，关注前后邻近任务之间执行的所有设备侧任务。对于这期间之间的任务，综合考虑这些操作的延时和操作频率，计算其综合延时，推选出综合延时最大的操作作为性能瓶颈操作。

  5. 若当前性能瓶颈被认定为通信算子任务，则对该通信任务进行多卡联动分析。

    1. 聚合该通信算子任务的通信域内所有卡的通信执行时间，找到最快卡和最慢卡，即分别找到通信任务等待时间最长和最短的卡，并对齐快慢卡的通信任务结束时间，以调整卡间的时钟漂移

      image_5.png

    2. 关注慢卡在快卡等待期间的任务，找到其与快卡间的对应任务，比对相同任务间的延时差异，推选出延时差异最大的操作任务，作为慢卡的瓶颈操作

      image_6.png

4.4子系统间接口（主要覆盖模块接口定义）

在这个章节只要说本次修改涉及哪个 .h 的哪个接口的修改，大致的修改内容简述下即可。

4.5子系统详细设计

见 4.3

4.6DFX属性设计

4.6.1性能设计

新增模块的分析能力，局部计算节点的数据对比及识别，性能影响可控。

4.6.2升级与扩容设计

NA

4.6.3异常处理设计

NA

4.6.4资源管理相关设计

NA

4.6.5小型化设计

NA

4.6.6可测性设计

NA

4.6.7 安全设计

4.6.7.1 安全设计确认

参考安全设计checklist进行确认

安全属性 检查项 检查项详细说明 是否涉及 是否满足
访问通道控制 是否新增侦听端口 新增侦听端口需刷新通信矩阵 否
访问通道控制 是否新增进程或组件间通信 新增进程或组件间通信刷新通信矩阵 否
访问通道控制 是否新增认证方式 新增认证方式需刷新通信矩阵及产品文档 否
权限控制 是否涉及创建文件或目录 创建文件或目录须显式指定文件或目录的访问权限 是 是
权限控制 账号权限是否满足“权限最小化原则” 系统中各账号应赋予最小权限 否
权限控制 是否存在用户权限提升 禁止出现用户非法权限提升 否
未公开接口 是否新增GUC参数 新增GUC参数需刷新产品文档 否
未公开接口 是否新增或修改函数、视图、系统表 新增或修改函数、视图、系统表需刷新产品文档，考虑权限控制 是 是
未公开接口 是否新增SQL语法 新增SQL语法需刷新产品文档，支持记录审计日志 否
未公开接口 是否新增内部工具 新增内部工具需刷新产品文档 是 是
未公开接口 脚本中是否存在注释代码 Shell/Python等解释性语言禁止注释代码，注释代码需要删除 否
未公开接口 是否存在隐藏命令、参数、端口等接入方式 对于现网维护期间不会使用的命令/参数、端口等接入方式（包括但不限于产品的生产、调测、维护用途），必须删除（如通过编译宏） 否
未公开接口 系统是否存在隐藏后门 禁止系统预留任何的未公开账号，所有账号必须可被系统管理，并在资料中予以说明 否
未公开接口 禁止在产品对外部用户发布的软件（包含软件包/补丁包）中提供破解类、网络嗅探类工具。 1、禁止在产品对外部用户发布的软件（包含软件包/补丁包）中提供可修改任意用户口令、具有“口令破解能力”（指口令暴力破解、利用系统/算法漏洞恶意破解口令）、对包含敏感数据的文件（如包含密钥的配置文件、数据库）进行解密的功能或工具。2、禁止在系统中保留第三方的网络嗅探工具tcpdump、gdb、strace、readelf网络、进程调试工具，cpp、gcc、dexdump、mirror、JDK开发/编译工具和仅在调测阶段使用的自研调试工具/脚本（例如：仅在调试阶段使用的加解密脚本、调测功能、可以提权的命令），由于业务需要必须保留的，需要进行严格的访问控制。同时在资料中说明保留的原因、使用的场景、风险。 否
敏感数据保护 认证凭据不允许明文存储在系统中，应该加密保护。 认证凭据（如口令/私钥等）不允许明文存储在系统中，应该加密保护。 否
敏感数据保护 用于敏感数据传输加密的密钥，不能硬编码在代码中。 禁止口令和密钥硬编码。 否
敏感数据保护 是否明文打印口令或密钥等敏感信息 禁止在系统中存储的日志、调试信息、错误提示及ps命令等信息打印明文敏感信息（口令/私钥/预共享密钥）。 否
敏感数据保护 是否明文回显口令 禁止明文回显口令。 否
敏感数据保护 是否使用第三方和开源软件的缺省口令 禁止使用第三方和开源软件的缺省口令，参考安全设计指南第1.5章节。 否
敏感数据保护 是否将密码明文存储在配置文件中 明文密码不允许写入配置文件（命令行工具安装部署及使用时必需配置密码的场景除外）。 否
敏感数据保护 是否使用不安全的加密算法 禁止使用私有的或业界已知不安全的加密算法。推荐加密算法安全设计指南6.2章节。 否
敏感数据保护 口令等敏感信息是否使用安全的传输通道 在非信任网络之间进行敏感信息传输须采用安全传输通道或者加密后传输。参考安全设计指南第10章。 否
敏感数据保护 内存中口令或密钥等敏感信息使用后是否销毁 内存中的口令或密钥等信息使用完毕后立即清0。 否
敏感数据保护 密码算法中使用到的随机数必须是密码学意义上的安全随机数。 密码算法中使用到的随机数必须是密码学意义上的安全随机数，参考安全设计指南6.3章节。 否
敏感数据保护 资料中是否存在不安全的示例 资料中的示例需要是安全的，对用户进行正确的引导，若示例中存在潜在的风险，要在资料中进行说明。 否
认证 是否提供认证机制 新系统需要提供认证机制并缺省开启。 否
认证 认证是否在服务端进行 认证处理过程需要在服务端进行。 否
认证 认证失败后服务端是否返回有效信息 认证失败后，服务端返回信息不能提供详细的、可用于判断具体错误原因的提示。 否
外部参数校验 是否对外部输入进行合法性校验 1、使用外部输入数据作为循环终止条件、数组下标、内存分配大小参数等，可能导致系统出现死循环、缓冲区溢出、内存越界、拒绝服务等一系列行为。2、文件路径等外部输入应进行合法性校验，防止注入风险 否
三方件引入 是否新引入三方组件 1.新增三方组件需要通过安全编译选项、病毒、漏洞、开源片段引用、license合规、开源组件扫描，参考版本发布网络安全质量要求。2.新增三方组件需保证来源可信。 否

4.6.7.2 敏感数据分析

1. 敏感数据清单

敏感数据的具体范围取决于系统具体的应用场景，设计者应根据风险进行分析和判断。典型的敏感数据包括认证凭据（如口令）、密钥等内容。

数据字段 备注/说明 数据字段敏感度 关联处理模块 强制的操作 禁止的操作
管理员账号/密码 系统管理员的账号和密码 高 登陆/认证 加密传输/加密存储/匿名化等 回显/日志等
... ... ... ... ... ...
2. 敏感操作检查

1）生命周期维度 对于识别出的敏感数据，我们需要完整的识别出数据的生命周期，识别“产生、使用、传输、持久化和销毁”的过程，以避免后续风险识别过程中无意的疏漏。 2）高风险处理过程 识别对敏感数据的处理过程中，是否有高风险的处理。典型的高风险处理包括：“打印”，“回显”，“存储”，“硬编码”，以及“不安全算法”。从信息处理的角度出发，这些高风险的处理过程在处理敏感数据时，容易产生安全漏洞，需要详细检查，对于识别到的多个敏感数据均需要进行检查，敏感数据检查矩阵如下：

例如，在典型的Web系统中，识别到的敏感数据（管理员账号/密码）在其生命周期的检查结果如下：

  • 产生：由管理员首次登陆系统设置密码
  • 使用：管理员登陆系统时使用密码进行认证
  • 传输：管理员在客户端输入登陆密码后，密码通过网络传输至服务端
  • 持久化：管理员首次设置密码后，服务端将密码持久化在后端数据库中
  • 销毁：超过一定周期后，强制管理员修改密码，将旧密码删除
产生 使用 传输 持久化 销毁
打印 不涉及 使用过程中不会将密码进行任何形式的打印 安全传输通道下不需要加密；非安全传输通道下加密传输 不涉及 销毁过程不打印密码，但需记录操作日志
回显 在客户端密文回显，口令显示为********* 不涉及 不涉及 不涉及 不涉及
存储 用户输入设置密码后，会通过安全加密算法将密码加密保存至后端数据库 同【产生】 不涉及 后端数据库加密存储 从后端数据库 表中删除对应密码
硬编码 不涉及 不涉及 不涉及 不涉及 不涉及
不安全算法 使用安全算法（AES256）加密 使用时内存中解密 非安全传输通道使用安全加密算法 同【产生】 不涉及

4.6.7.3 设计实现

说明整体安全设计方案，以及详细实现、接口定义等

4.7系统外部接口

NA

4.8自测用例设计

NA

5.可靠性&可用性设计

5.1冗余设计

特性设计考虑的冗余主要是系统采用了冗余设计，特性需要考虑镜像备份、配置参数备份和主备冗余系统之间进行数据同步等信息。

特性设计时，需要给出备份的关键配置参数清单，主备冗余系统之间进行数据同步时间 / 策略和关键数据清单，主备切换时数据核查机制 / 脏数据处理策略、备份恢复策略等。

对于镜像式备份，如快照 /checkpoint 机制，需要给出备份周期、数据核查机制 / 脏数据处理策略、恢复策略等，对系统性能有明显影响的特性，需要给出设计约束条件。

5.2故障管理

故障管理包括故障检测、故障隔离、故障定位、故障恢复和相互关联的设计。

特性的故障管理，主要是特性自身的故障检测、告警 / 日志设计、故障恢复以及故障接口设计。

故障管理通常的设计原则包括：

  1. 故障全面快速检测通常考虑检测范围、备用检测、检测速度、检测影响；
  2. 控制失效影响范围通常考虑多平面、多粒度、隔离单位等隔离域划分；
  3. 故障快速恢复通常考虑自动恢复、优先恢复、分级复位、无耦合恢复、分层保护等策略。

故障管理常见的设计模式包括 RollBack 模式、故障 Bypass 、断路器模式、隔离仓模式等。

5.3过载控制设计

特性的过载控制设计需要考虑特性内处理业务的流量检测、检测位置和业务丢弃位置、业务丢弃时响应的业务消息信息，以及与统一的过载控制机制之间的调用、被调用关系、接口。

特性内部简单的过载控制机制通常采用限速的方式，需要考虑限速的位置、默认限速值、日志告警等信息。

过载控制通常的设计原则包括动态限流、弹性扩缩容、先负载均衡后流控、尽早控制、优先级保障、优雅降级设计等：

  1. 尽早控制：系统过载时，应尽可能在业务流程处理前端或业务处理较早的处理模块上控制业务接入，避免中间控制带来不必要的性能消耗；
  2. 优先级保障：系统过载时保证高优先级的业务能够优先获得资源，优先得到处理，从而保证社会效益最大化；
  3. 优雅降级设计：非核心业务降级、核心功能放通、体验降级等。

5.4升级不中断业务

离线python处理模块脚本，不参与业务进程运行，不涉及升级终端业务场景。

5.5人因差错设计

特性的人因差错主要考虑特性涉及的命令、操作、配置文件 / 数据等人机接口的错误防护，通常考虑如下几个方面：

  1. 删除、破坏性修改需要提供高危提示以及二次确认，页面焦点默认"取消"。用户可见接口（ cli 以及 web 页面）都需要考虑，包括开源组件提供的命令接口；
  2. 对重启节点操作需要提前检查是否影响客户 VM 运行，给出明确提示建议操作；
  3. 所有高危操作需要记录审计日志；
  4. 预防配置错误、预防硬件误操作、操作执行前的系统检查和操作错误后的快速回退。

人因差错通常的设计原则包括：

  1. 角色约束：通过权限控制设计预防对不同角色的配置范围进行约束，避免越权配置导致错误；
  2. 配置校验：通过配置生效机制设计确保在配置生效前进行必要的校验，避免错误配置生效；
  3. 备份恢复：通过配置数据备份与恢复设计确保在出现配置错误时能够快速恢复到正确的配置数据状态。

5.6故障预测预防设计

特性应配合系统故障预测预防能力提供相关的数据采集和统计接口。比如磁盘空间检测等。

6.特性非功能性质量属性相关设计

6.1可测试性

重点从特性在测试的方向和规格上展开描述，说明在测试人员测试时应该测哪些方面，需要注意哪些边界值、异常值、异常场景。

6.2可服务性

对特性提供丰富的可维护可服务的措施，提供对特性的使用、维护、问题处理等的完整资料说明。

6.3可演进性

重点从特性架构、功能的可演进性上展开描述。

6.4开放性

重点描述特性的对外接口开放性，包括接口的规范性，比如符合 SQL 2011 标准。

6.5兼容性

重点描述特性是否会影响系统的前向兼容性，即旧功能在升级新版本之后是否可使用，使用行为是否和旧版本保持一致。

6.6可伸缩性/可扩展性

有效满足系统容量变化的要求，包括数据库节点的扩缩容、数据库服务器本身的扩缩容。

6.7可维护性

重点从特性的可维护性展开描述，比如诊断视图、 log 打印等。

6.8资料

参考下表，评估特性会涉及到的各类资料的修改点，并说明具体修改点。

类别 手册名称 是否涉及（Y/N） 具体修改或新增内容简述
白皮书 技术白皮书 N XX章节新增XX技术
产品文档 产品描述 Y 技术指标刷新为XX
特性描述 Y 新增XX特性
编译指导书 Y XXX
安装指南 Y 安装集群章节需刷新XX场景
管理员指南 N XXX
开发者指南 （包括开发教程、SQL参考、系统表和系统视图、GUC参数说明、错误码说明、API参考等） Y 在XX章节增加XXX功能
工具参考 Y 新增XX工具
术语表 Y 新增术语XX
入门 简易教程 N XXX

7.数据结构设计（可选）

本章节完成数据库结构的设计（数据库系统表结构，可以使用 Power Designer 完成），可选章节。