amazon-s3 - 追踪S3成本(S3FS)

在过渡期间，由于ListBucket和HeadObject的调用，我们的S3成本大幅上涨。我们正在尝试找出如何解决S3成本突然增加的问题。我们做了一些本不应该影响的更改，但是主要的更改似乎是

HeadObject调用

增加10-20倍

ListBucket调用

的突然出现

我已附上图表，显示了2018年4月10日至2018年4月14日之间的跃迁。在这两个日期之间，我们进行了以下更改

从(debian 8)S3FS v1.61(从2012年开始，甚至在Github中都非常老)更改为v1.84(最新)

从弗吉尼亚北部移至加利福尼亚北部(成本增加10％)

巨大的黄色横条显示了使用Amazon CLI的文件移动(4月11日至13日)

为了使这种情况平静下来，我们在/ etc / fstab中的mount命令中添加了以下内容:noatime,stat_cache_expire=3600,enable_noobj_cache

从4月14日开始看似不平衡的小条现在稳定在$ 25 /天左右

自开始以来已经存在的选项(无更改)_netdev,allow_other,use_cache=/tmp,umask=0000,use_path_request_style,ensure_diskfree=10240
我们已经做了以下尝试来调试它

启用S3记录

将日志转储到Athena中，然后将CSV导出到MySQL中

这些日志仅值

1天

屏幕快照“查询1”显示路径中有480万次命中...基本上，我们认为它正在遍历整个目录树(最多包含约10万个文件)，以查找文件是否存在
屏幕快照“查询2”显示了沿着

路径执行的相同操作(类型)

不十分确定该怎么办，但我们通常每天约5美元(包括其他服务)的账单现在约为25美元/天(增加了5倍)..随着/ etc / fstab的更改，它已降至每天13美元如果我们可以回到零ListBucket调用和20％的HeadObject调用，尝试将其提高到每天5美元。

任何尝试尝试的想法都非常感谢。

最佳答案

已对ListBucket和HeadObject API进行了调用updatedb(和located)。

解决方案:将挂载点(在我的情况下为/ mnt / s3fs)添加到/etc/updatedb.conf中的PRUNEPATHS中，以便updatedb扫描时不包括此挂载点