Azure函数事件中心读写延迟与StorageException和SocketException峰值

我们的生产服务受到延迟延迟的困扰。在这些峰值期间，我们看到我们收到了大量的StorageExceptions和SocketExceptions

这些图像超过4个小时。

更重要的是，这只会在我们的服务的EUS实例（大约有26个事件中心触发器）上发生，而不是在WEU（7个事件中心触发器）和Canary（EUS2-2事件中心触发器）上发生。

我们看到的存储帐户异常的最内层错误是：指定了租约ID，但Blob的租约已过期。少量可以正常使用-但是4小时内24.5K感觉并不像少量，并且异常峰值和等待时间峰值之间存在直接相关性

套接字的最内层异常是：试图以其访问权限禁止的方式访问套接字。它也与延迟尖峰很好地相关。

另一方面，可以看到事件在整个4小时时间内流经服务并流向接收事件中心：

所有传出事件都写入每个云中的同一事件中心（总共3个-1 EUS，1EUS2、1WEU），每个云都相应地写入其自己的eventhub。似乎整个延迟峰值也归因于对eventhub的写操作（这是通过eventhub名称+ FQDN AAD连接完成的）：

在此问题上的任何帮助将不胜感激！

我们解决了这个问题- Azure功能是在消耗计划上设置的-对其进行了设置，因此只有一个实例可用。要增加一个以上的实例，我需要将计划从消费更改为保费。

除此之外，我发现该函数在启动时会为所有触发器创建与所有Eventhub的连接-在本例中为26个Eventhub。每个Eventhub都有32个分区，因此每个Eventhub共有32个连接。

消费计划中的Azure功能具有600个连接的硬限制。

这意味着一旦建立连接，它最终将达到600个限制，进入不正常状态并重新启动自身，这又由于启动和处理来自集线器的积压事件而造成了延迟峰值。

从消费升级到高级后，可以增加连接数上限，并添加一个额外的实例（将最小实例数从1个增加到2个），这些实例将实例之间打开的连接数分割开，因此我们没有达到下限。

希望这可以帮助其他人坚持下去。