The way how OptimumCache does its job can be explained with an example of how WordPress single static file index.php pops up in ‘optimumcache dump’ output.
After ‘occtl –mark-dir…’ is over, try to locate WP’s index.php via ‘optimumcache dump –resolve-filenames’. The command will list that file just a few times. But you are sure that the file is spread over shared server as /home/*/public_html/index.php at least 500 times… What is happening?
Let us take in-depth look at what OptimumCache does with ‘marked’ files:
- OptimumCache periodically requests the kernel for inode list being hold in FS cache at the moment.
- For those inodes have csum pre-set (affected once by ‘occtl –mark-dir…’) OptimumCache looks a matching file in /var/cache/optimumcache/
- Whether cached file copy is not found, it is created with file csum as the key, like /var/cache/optimumcache/68/f14b3bab817862e46cb7ff4bdfa85068004e79
- The inode cache pages are (re)mapped to file /var/cache/optimumcache/68/f14b3bab817862e46cb7ff4bdfa85068004e79, instead of original file content
This way, multiple inode instanced of the same file FS cache pages get remapped to a single instance of that file in /var/cache/optimumcache68/f14b3bab817862e46cb7ff4bdfa85068004e79
Try this command then:
# tar cf – /home/*/public_html/index.php | pv > /dev/null
and list FS cache again:
# optimumcache dump –resolve-filenames | grep 68f14b3bab817862e46cb7ff4bdfa85068004e79
68f14b3bab817862e46cb7ff4bdfa85068004e79 index.php will appear
in FS cache multiple times due to side effect from being accessed by ‘tar…’ command above.
Some time after, FS cache inode list less recently used inodes may get evicted. The count of index.php will drop relatively. That is how ‘optimumcache dump’ cached items list has to be interpreted.