What JuiceFS settings/configurations are helpful for reducing the amount of PUT calls made to an object storage service?

[aeblyve]

Hello,

Which JuiceFS mountpoint or other settings would be most helpful for reducing the amount of PUT requests made to Amazon S3? In our setup, we are seeing a rather high amount of PUT requests that result in significant expense. Our workload is mostly random writing, with a mix of large files and small files.

The PUT request load seems related to periods of high load on the Redis database. Is it possible that if Redis database performance is bottlenecking, that the number of PUT requests would be increased?

If JuiceFS necessarily needs to make very many PUT requests to S3 in this situation, would it be better instead to use something like MinIO or Ceph on EC2/EBS as object storage?

Current mountpoint settings are:

rw,allow_other,writeback_cache,max-uploads=40,buffer-size=1024,backup-meta=0,_netdev

(Backup-meta is handled by a special mountpoint client)

Would --writeback be helpful for this as well as writeback_cache?

Thanks!

[frostwind]

I am a juicefs user. We had a scenario to test SQLiite random write, which shows FUSE writeback_cache help to improve 4-5 times of speed of SQLite random write. I didn't benchmark if it can save number of PUTs , but my best guess is it can save PUT request too. When using writeback_cache , you may need to keep in mind that it may convert sequential I/O to random I/O and cause I/O amplification.
https://juicefs.com/docs/community/guide/cache/#fuse-writeback-cache
Also you may need to use main branch to avoid below bug #5315
If you use Minio or ceph on top of EC2 which would be costly , at least $0.12 / GB/ month , and extra cost of compute VM. I don't think that is a good way you want to try.
I am not familiar with redis, but usually if you have tons of random write, probably PUT will be bottleneck. Also if you use AWS memoryDB as meta engine , you may check this bottleneck may related to your case.
#3929 (comment)

--writeback option may not help here. It just use local disk as staging area and delay upload , the number of upload should be the same. Also other clients may not be able to see the update in a timely manner since it try to first update meta DB then upload to object storage.