OPC UA 客户端/服务器通信可能会暂时出现连接资源瓶颈,但只有 CPU 的通信请求负载很高时才会出现这种情况。
以下是理解临时连接资源瓶颈的要求:
即使在连接关闭(断开)之后,基于 TCP 的通信(例如 OPC UA)的连接终止也会临时占用一些资源。
OPC UA 的连接设置基本上分为 2 个阶段:首先,客户端为发现过程建立连接,然后再建立高效连接。
可能的 OPC UA 连接数由 2 个限值确定。连接设置期间的行为取决于首先达到的限值:
- OPC UA 客户端/服务器连接的较大可能数量
- “连接池”资源的较大可能数量,允许使用不同数量的资源
下图显示了已终止连接如何在一段时间内继续占用资源。
① | 断开:客户端启动连接终止 |
② | 根据 RFC 793(传输控制协议)“有序”关闭连接:客户端(更确切地说,是终止连接的伙伴)的资源仍然被占用(大约 60 秒),服务器(更确切地说,是收到连接断开通知的伙伴)的资源立即释放;连接在客户端中显示为“已断开”。即使“OPC_UA_Disconnect”指令以“完成”终止,资源也会在等待时间内保持占用状态。 |
③ | 连接终止并且已经过确认伙伴所需的等待时间;资源也会在客户端释放。 |
OPC UA 连接的建立分 2 个阶段,具体取决于系统:首先,为发现过程建立连接,然后在接收到所请求的信息后再次关闭。只有这样才能建立高效连接。
与上述连接终止过程一起,这会导致在客户端临时分配 2 个资源。
① | 发现过程的连接:占用客户端和服务器上的资源 |
② | 高效连接:占用客户端和服务器上的资源 |
③ | 并行发现和高效连接:仅为客户端临时保留两个资源。 |
在 CPU 中,所有连接类型共用一个连接资源池。
约束条件:
针对某些连接类型(编程设备和 HMI)预留的资源占用了可自由使用的资源。
对于 OPC UA 客户端/服务器连接,每个 CPU 性能等级都有一个“单独的”上限,类似于其它连接类型:示例:对于 OPC UA 服务器较大为 64,对于含 CPU 1518 的 OPC UA 客户端较大为 40。
可以使用 CPU 参数“OPC UA 会话较大数”(Max. number of OPC UA sessions) 在“OPC UA > 服务器 > 设置”(OPC UA > Server > Settings) 区域中减少与服务器的可能连接限值。例如,CPU 1518 预设为值 20。
其它特定连接类型的自定义上限示例,可避免不受限制地使用连接池:
与较多 80 个连接的 Web 通信。
其它限制可能由各接口的组态限值导致。
下图简单显示了如何在减少其它连接的同时增加开放式用户通信连接的需求。在这种情况下,OPC UA 客户端/服务器通信“受影响”。这也表明,与 OPC UA 建立两级连接将暂时导致资源需求增加。
图片: 原理:临时资源消耗
用户将在此处再次找到概要说明中的提示和规则。
如果处于所需连接数的限值内,则应在客户端侧依次建立 OPC UA 客户端/服务器连接,并随着时间的推移进行“扩展”。如果以较短的间隔建立 OPC UA 客户端/服务器连接,则存在资源瓶颈危险(请参见上述关于 TIME_WAIT 的说明)。
由于 OPC UA 客户端/服务器连接分两个阶段建立,并且仅临时使用其它连接,因此应首先建立 OPC UA 客户端/服务器连接,然后再建立其它连接类型(HMI、OUC 等)。然后,可以首先从资源池中使用 OPC UA 客户端/服务器连接以顺利建立连接。
规划连接资源时,至少应有一个资源未使用。背景:如果所有连接资源都已占用且 OPC UA 连接中断,则无法重新建立连接。原因:暂时需要两个连接资源来重新建立此连接。
产品推荐
友情链接