Repeatedly reading files can‘t hit the page cache.

[ddrid]

What happened:
When repeatedly reading some files in the same directory, which is expected to benefit from page cache established by the kernel, leading to performance improvements. However no speed-up is observed. The performance of repeated reads remains similar to that when the kernel cache is cleared.
When using juicefs profile tool to analyze, it shows that the average time spent per read operation remains approximately 4000 us, I think it is far from achieving the performance of in-memory page cache."

What you expected to happen:
Repeatedly reading files can hit the page cache.

Environment:

• JuiceFS version (use juicefs --version) or Hadoop Java SDK version: 1.2.0+2024-06-18.873c47b

[jiefenghuang]

It do hit page cache, you can check the access log when read.

[ddrid]

It do hit page cache, you can check the access log when read.

Hi @jiefenghuang , thanks for the reply.
There are many read request logs in the access log, such as:
2024.08.29 20:38:33.286865 [uid:0,gid:0,pid:7938] read (80031,110592,0): (106731) - OK <0.001008>
2024.08.29 20:38:33.286912 [uid:0,gid:0,pid:2316] read (46908,110592,0): (106731) - OK <0.001064>

How can I determine if these requests hit the page cache? As I understand it, requests that hit the page cache should bypass the user-space JuiceFS and be read directly from the kernel space, right?

[jiefenghuang]

yes, maybe you can add a log in fuse.go:Read(...).
then create a file /[mount_point]/f1, execute cat /[mount_point]/f1.

you could potentially introduce a deliberate delay (using a sleep function) right at the start of the vSlice.Read(...) method. By doing this, you might be able to observe and compare the differences in performance when the method is executed repeatedly. Performance is roughly the same because it hit read cache.

[ddrid]

yes, maybe you can add a log in fuse.go:Read(...). then create a file /[mount_point]/f1, execute cat /[mount_point]/f1.

you could potentially introduce a deliberate delay (using a sleep function) right at the start of the vSlice.Read(...) method. By doing this, you might be able to observe and compare the differences in performance when the method is executed repeatedly. Performance is roughly the same because it hit read cache.

Hi @jiefenghuang,

I found the cause of the issue. It was because I was reading a dataset with a large number of images, exceeding 10,000. I discovered in the official documentation that there is a parameter --open-cache-limit value: max number of open files to cache (soft limit, 0 means unlimited) (default: 10000) (https://juicefs.com/docs/community/command_reference/#mount-metadata-cache-options) When I set this parameter to 0, reading the dataset hits the page cache successfully.

I have two things I'm unclear about:

1. Are there any risk to set this value to 0? Could it cause excessive memory usage? Why is the default set to 10,000?
2. I did not set the --open-cache parameter, which should mean open cache is disabled by default. Why does the --open-cache-limit parameter take effect? What is the relationship between parameter --open-cache-limit and --open-cache?

[jiefenghuang]

yes, maybe you can add a log in fuse.go:Read(...). then create a file /[mount_point]/f1, execute cat /[mount_point]/f1.
you could potentially introduce a deliberate delay (using a sleep function) right at the start of the vSlice.Read(...) method. By doing this, you might be able to observe and compare the differences in performance when the method is executed repeatedly. Performance is roughly the same because it hit read cache.

Hi @jiefenghuang,

I found the cause of the issue. It was because I was reading a dataset with a large number of images, exceeding 10,000. I discovered in the official documentation that there is a parameter --open-cache-limit value: max number of open files to cache (soft limit, 0 means unlimited) (default: 10000) (https://juicefs.com/docs/community/command_reference/#mount-metadata-cache-options) When I set this parameter to 0, reading the dataset hits the page cache successfully.

I have two things I'm unclear about:

1. Are there any risk to set this value to 0? Could it cause excessive memory usage? Why is the default set to 10,000?
2. I did not set the --open-cache parameter, which should mean open cache is disabled by default. Why does the --open-cache-limit parameter take effect? What is the relationship between parameter --open-cache-limit and --open-cache?

I think this is another issue, please use tools for more detailed debugging.
For the part of the meta cache, you can take a look at pkg/meta/openfile.go.