与azure功能一起使用的存储帐户上的高文件io活动

pbpqsu0x  于 2021-06-21  发布在  Kudu
关注(0)|答案(1)|浏览(535)

我有一个相当简单的azure函数应用程序w/3函数(2个http绑定的,1个心跳类型的函数,每5分钟运行一次)。
当我试图弄清楚为什么这个特殊的功能应用程序比我们的其他项目成本更高时,我发现成本几乎完全是由文件存储创建/写入事务引起的存储成本造成的。
似乎每小时都会有~5-8k文件存储事务的峰值。功能应用程序是相当低的使用率,所以我不知道什么属性的峰值在文件事务。

azure函数运行时:v2
语言:javascript
部署插槽:1(证书)
应用服务计划:消费
地区:美国西部2 azure-storage 软件包版本:2.10.3
部署方法:使用azure门户(kudu)连接到github存储库
以前我看到的是超过10000笔交易的峰值。生产插槽和辅助部署插槽都配置为使用相同的存储帐户。此后,我为“cert”部署槽创建了一个单独的存储帐户,现在它每小时都会出现类似的峰值。
我尝试过:
远离的 AzureWebJobsDashboard 应用程序设置连接字符串,因为我们正在使用应用程序见解(根据我在另一个类似问题上找到的评论)。
将“cert”部署槽更改为使用与主部署槽不同的存储帐户,这样它们就不会互相攻击。
重新启动功能应用程序。
这种用法是预期的行为吗?与我们拥有的其他功能应用程序相比,我们的存储成本要高得多——尽管其他大多数应用程序都是用c#编写的。
这并不是一大笔钱,但令人惊讶的是,azure功能只收取几便士的费用,而文件事务每月的费用却高达几美元。

fykwrbwg

fykwrbwg1#

azure功能的成本由两部分组成,一部分是功能的成本,另一部分是app insights的成本。
根据您的描述,此功能不经常使用,因此您删除了 AzureWebJobsDashboard ,那么我们就可以排除两种情况,这既不会是函数内部存储的操作成本,也不会是洞察造成的成本。
基于以上两点,我怀疑如此巨大的存储成本来自部署阶段。部署项目时,整个项目信息将传递到文件存储,并且此部署操作已执行多次。这应该是这个成本的原因。

相关问题