如何采集SAP Function Module执行的详细堆栈追踪以排查间歇性性能问题

一、SAP侧详细性能追踪实现方法 #

• 使用ST12（ABAP跟踪分析工具）：可针对指定Function Module、调用账号、客户端开启跟踪，支持设置耗时阈值触发捕获，仅记录执行时长超过阈值的调用，自动拆分总耗时为ABAP执行时间、数据库调用时间、子模块调用时间三类，可按调用层级展开每个下游FM、每段逻辑的耗时占比，具备和JVM堆栈追踪类似的分析能力。
• 使用SAT（ABAP运行时分析工具）：可实现更细粒度的代码级耗时统计，支持过滤指定FM名称的调用，自动记录完整调用栈，包括锁等待、RFC交互、事务提交各阶段的具体耗时，可定位到单条ABAP语句的执行时长。
• 使用ST05（性能追踪工具）：专门拆分数据库SQL访问、锁操作、RFC调用的耗时占比，开启后可捕获慢调用过程中所有执行的SQL语句、执行计划、扫描行数，排查是否存在异常数据库访问。
• 实时进程排查：遇到正在发生的慢调用时，可通过SM66（全局进程监控）找到对应RFC工作进程，直接查看当前执行堆栈、等待原因，无需提前开启追踪。

二、同类间歇性慢调用常见根因 #

• 数据库执行计划抖动：价格查询类FM通常涉及动态查询条件，当传入的商品参数组合未命中缓存的最优执行计划时，数据库会重新生成执行计划或走全表扫描，这类情况不会导致服务器整体指标异常，但单条查询耗时会突增。
• 锁等待冲突：多线程并行调用时，不同FM执行过程可能申请同一个业务锁（如商品主数据锁、价格配置表锁），偶发的排队等待时间不会计入服务器CPU/IO指标，仅会拉长单次调用总耗时。
• 应用服务器缓存失效：SAP内置的表缓存、FM结果缓存偶发过期/刷新时，单次调用会触发全量数据加载，耗时陡增，后续调用恢复正常，无固定复现规律。
• RFC工作进程队列阻塞：服务器整体资源正常的情况下，RFC工作进程组偶尔满负荷，请求进入队列等待的时间会计入总调用耗时。
• 内存缓存未命中：当查询的商品关联数据刚好被从应用服务器内存缓存中淘汰时，单次调用需要从数据库加载全量关联数据，首次加载耗时远高于缓存访问，之后调用恢复正常。

内容的提问来源于stack exchange，提问作者sdas