juicedata / juicefs

JuiceFS is a distributed POSIX file system built on top of Redis and S3.
https://juicefs.com
Apache License 2.0
10.67k stars 930 forks source link

try to use otter inside juicefs #4294

Open osevan opened 9 months ago

osevan commented 9 months ago

Hi dear devs,

otter is fastest go build cache system.

https://github.com/maypok86/otter

It could be improve cache hits :-)

If possible, everyone should be set the config with right settings like ram usage. And fine grained flush to disk after every sec or msec will be cool too. And fsync simulating like fsync off will be cool, because applications could receive faster simulated sync signals and can work further.

Here is new hash system outperforming Blake and siphash 5-10 times.

https://medium.com/@frankwessels_nl/highwayhash-fast-hashing-at-over-10-gb-s-per-core-in-golang-fee938b5218a

https://pkg.go.dev/go.shabbyrobe.org/fxhash

Fxhash and gxhash further faster than highwayhash.

You can follow some hash systems here:

https://www.reddit.com/r/rust/comments/17xgn0t/gxhash_a_new_extremely_fast_and_robust_hashing/

Thanks and

Best regards

davies commented 9 months ago

JuiceFS only has disk cache, and the index of disk cache is not the bottleneck, so we will not expect much performance improvements from otter.

The S3-FIFO could be better than 2-random (similar to LRU), we need to dig more into that.

1a1a11a commented 8 months ago

@davies Hi there, happy to learn about your experience (and help) if juicyfs decides to use S3-FIFO. In my opinion, if cache hit ratio is important, moving from two random to S3-FIFO would 1. provide a non-trivial hit ratio improvement (it will be workload-dependent though); 2. be more SSD-friendly due to sequential writes and therefore better tail latency; 3. be more scalable when scaling to multiple cores. :)