1. 首页
  2. 技术文章

对 OpenSIPS 4.0 进行性能分析

mazhu • • 技术文章

运营生产系统的一个关键方面在于能够了解 OpenSIPS 的运行状况、其行为背后的原因以及其性能表现。

当然，你希望在 OpenSIPS 持续处理生产流量的同时完成这些工作，确保不影响服务运行，无需重启。

这正是 OpenSIPS 4.0 引入性能分析支持的原因，即对 OpenSIPS 作为应用程序的实时“透视”。

性能分析支持可满足以下关键需求：我的 OpenSIPS 正在做什么？为何运行缓慢？为何无法处理流量？

概况介绍

分析支持是 OpenSIPS 4.0 的内置组件，无需重新编译或重启，只需在需要了解 OpenSIPS 的运行情况时激活它即可。

分析支持功能会在某些任务（通常耗时较长）开始和结束时生成报告（以序列形式，包含所有子任务）：

Start session
⎡Enter job
⎸   ⎡Enter sub-job A
⎸   ⎣Exit sub-job A
⎸   ⎡Enter sub-job B
⎸   ⎣Exit sub-job B
⎣Exit job
End session

分析支持提供了不同的方式，可以从 OpenSIPS 外部实时访问分析数据。

分析架构

从架构上看，性能分析支持功能有两个主要类型的组件接入其内部 API：

  • 分析数据生产者（producers）：生成分析记录的实体
  • 对消费者（consumers）进行画像：负责向外界提供画像记录的实体，可能采用不同的格式。
对 OpenSIPS 4.0 进行性能分析

Producers 性能分析

OpenSIPS 4.0 目前提供了两种性能分析来源，分别从脚本和 C 代码这两个不同层面处理可观测性和性能分析。

脚本性能分析非常简单，每次执行脚本路由（或子路由）时都会生成性能分析记录。因此，你可以追踪实际的执行路径和执行时间。如果你专注于了解 OpenSIPS 脚本的性能，这将非常有用。

进程性能分析则是在 C 代码层级进行执行追踪。在每个进程内部，性能分析从 I/O 反应堆层级开始，一直深入到 SIP 协议栈的底层：

  • 读取和处理SIP数据包
  • 异步或进程间通信作业的恢复
  • 定时器作业
  • SIP 相关 API 调用（TM、Dialog、B2B）
  • 额外进程（例如 mi_fifo、mi_datagram、httpd）

Consumers 性能分析

OpenSIPS 4.0 目前提供了两种访问分析数据的方式——通过 OpenTelemetry 协议 (OTLP) 和通过 OpenSIPS 事件。

使用OpenTelemetry 模块，你可以将分析数据发送到 OpenTelemetry 服务器进行存储、分析和绘制图表。

对 OpenSIPS 4.0 进行性能分析

访问性能分析数据的一个简单、无需工具的方法是使用 OpenSIPS 事件。OpenSIPS 提供两个事件：E_PROFILING_PROC和E_PROFILING_SCRIPT。你只需通过 MI 订阅这些事件即可。事件包含：

  • 秒：UNIX 时间戳，秒
  • 微秒：秒内的微秒
  • 会话：会话 ID，用于对属于同一分析会话的所有事件进行分组
  • 动词：将操作分析为“开始”、“进入”、“退出”和“结束”
  • 名称：分析操作的描述
  • 类型：生成分析数据的进程类型
  • 深度：执行深度 “开始”为 1 级，每次“进入”增加，每次“退出”减少。
  • 文件：cfg 文件名或执行性能分析的 C 函数。
  • 行：文件中的行
  • 状态：仅适用于“退出”和“结束”操作，即“名称”操作的状态/返回码（很大程度上取决于其性质）。

以下是处理 SIP 请求生成的分析记录示例（简化版）：

{'sec': 1776767469, 'usec': 195210, 'verb': 'start', 'name': 'SIP receiver udp:127.0.0.1:5060'}
{'sec': 1776767469, 'usec': 195653, 'verb': 'enter', 'name': 'udp proto reading', 'file': 'handle_io', 'line': 317}
{'sec': 1776767469, 'usec': 196071, 'verb': 'enter', 'name': 'receive_msg', 'file': 'receive_msg', 'line': 120}
{'sec': 1776767469, 'usec': 196786, 'verb': 'enter', 'name': 'request_script', 'file': 'receive_msg', 'line': 235}
{'sec': 1776767469, 'usec': 199569, 'verb': 'exit', 'name': 'request_script', 'file': 'receive_msg', 'line': 237, 'status': 1}
{'sec': 1776767469, 'usec': 200219, 'verb': 'exit', 'name': 'receive_msg', 'file': 'receive_msg', 'line': 316, 'status': 0}
{'sec': 1776767469, 'usec': 200757, 'verb': 'exit', 'name': 'reading done', 'file': 'handle_io', 'line': 324, 'status': 0}
{'sec': 1776767469, 'usec': 201291, 'verb': 'end', 'name': 'SIP receiver udp:127.0.0.1:5060', 'status': 0}

你可以在这里看到一个完整的示例，该示例来自多个进程，执行的是完整调用。

分析控制

为了控制分析过程的详细程度，尤其是在讨论进程级分析时，计时器作业可能每秒运行 10 次。OpenSIPS 4.0 提供了一个 MI 命令，用于设置或检查每个进程的详细程度。

mi core:profiling_proc [id/pid=nn] level=2

该级别可以分为多个递增级别：

  • 0 – 已禁用用户画像分析
  • 1 – SIP 堆栈层（I/O 反应器、SIP API）
  • 2 – 额外流程级别
  • 3 – 定时器作业级别

如果缺少“level”参数，则该函数将执行列表操作，而不是设置分析级别。

如果没有指定进程（通过id或pid），则该操作适用于所有进程。

原文：https://blog.opensips.org/2026/05/08/profiling-your-opensips-4-0/

本文来自作者投稿，版权归原作者所有。如需转载，请注明出处：https://www.nxrte.com/jishu/66565.html

赞 (0)
mazhu的头像mazhu
0

相关推荐