vir*_* us 30 firebase google-cloud-functions firebase-storage
我刚刚注意到我的应用程序的存储空间在过去几周内几乎达到了 5GB 的免费使用限制。更详细地检查后,似乎这是由“工件”存储桶引起的。
我看到了这个 SO question,它说“工件”存储桶与 Node 10 环境有关。
我确实在一个月前搬到了 Node 10,但在发现日志不再在 Firestore 功能控制台中构建后,几天后我又恢复到 Node 8,从那时起只使用 Node 8。
但是我可以看到“工件”存储每周增加约 800Mb,这让我至少担心(请查看下面的屏幕截图)
我认为这与 Firestore 功能部署有关(或不是?),但这真的是预期的吗?我可以安全地清理这些工件吗?
对我来说,它在短短几周内急剧增加,这对我来说很奇怪,而以前我使用函数几年,从来没有遇到过这样的问题。
感谢有关如何在这种情况下安全处理存储大小并将其消耗保持在最低限度的任何建议。
我也在使用pubsub.schedule函数以防它在这里很重要。
我还注意到“神器”的带宽出乎意料地飙升,我猜这也有成本影响,我很感激任何有关尽量减少此类峰值的可能方法的意见(22.5GB 中约有 22GB 来自“神器”存储桶):
vir*_* us 46
想出了一个解决方案 - 似乎有一种方法可以在谷歌云控制台中为那些存储混乱的图像设置自动删除规则。
转到谷歌云控制台,选择您的项目 -> 存储 -> 浏览器 https://console.cloud.google.com/storage/browser
选择“神器”存储桶
在“生命周期”选项卡下添加一个规则来自动删除旧图像(在我的情况下,我把“更新后 1 天后删除”这对我来说很好用)
现在存储是安全的!
注意:如果您稍后遇到任何部署问题,例如如果您连续部署几天并且在部署时出现错误,只需在应该解决它的工件中手动删除整个“容器”文件夹,然后再次重新部署。(确保不要删除工件桶本身!)
希望 Firebase 团队能够改进这一点 - 当前的行为看起来令人困惑,因为它很容易导致意外账单,除非您采取额外措施来防止这种情况发生。但你永远不会知道它会发生,直到它发生。
| 归档时间: |
|
| 查看次数: |
3162 次 |
| 最近记录: |