If you are using s3fs to mount an S3 bucket to your server and have noticed a huge increase in ListBucket and HeadObject calls in your Billing. The calls will increase you AWS bill and depending on how many objects you have in your bucket, it could be significant.
Day over day I saw "Requests-Tier2" - The number of GET and all other non-Tier1 requests - go from 399 thousand to 9 million. That's a 2155% increase and my bill went from 17 cents per day to 4 dollars per day.
Requests-Tier1 - The number of PUT, COPY, POST, or LIST requests for STANDARD, RRS, and tags - also increased, but not as much. 90 thousand per day to 325 thousand per day.
$ lsof | grep S3_DROP_ZONE
which gave the following output
[root@ip-999-99-9-999 ec2-user]# lsof | head -1 && lsof | grep S3_DROP_ZONE
COMMAND PID TID USER FD TYPE DEVICE SIZE/OFF NODE NAME
updatedb 4211 root cwd DIR 0,36 0 5078268 /S3_DROP_ZONE/redacted/redacted/redacted/81089
updatedb 4211 root 8r DIR 0,36 0 1 /S3_DROP_ZONE
updatedb 4211 root 9r DIR 0,36 0 14 /S3_DROP_ZONE/redacted
updatedb 4211 root 10r DIR 0,36 0 405726 /S3_DROP_ZONE/redacted/redacted
updatedb 4211 root 11r DIR 0,36 0 5078257 /S3_DROP_ZONE/redacted/redacted/redacted
updatedb 4211 root 12r DIR 0,36 0 5078268 /S3_DROP_ZONE/redacted/redacted/redacted/81089
Solution: Add your mount point (in my case /S3_DROP_ZONE) to PRUNEPATHS in /etc/updatedb.conf so updatedb does not include this when it scans. Locate and kill the PID associated with the "updatedb" process. Shown above, my PID was 4211. Then you can either let the updatedb process start on it own via cron.daily or you can start it manually.
You can monitor the lsof output on your server to verify that its not scanning you S3 mount again. You can also monitor your billing to ensure that it goes down and you can enable request logging on your S3 bucket if you want, to make sure that the requests coming from the server that has S3 mounted on it, is not sending an unusual amount of requests.
Comments
Post a Comment