Cache stop caching after some hours... Works again after openlitespeed restart

[capvar]

I face a strange problem. I have a CentOS - openlitespeed host with 3-4 wordpress virtualhosts.
Everything is working good (caching, etc) at the beginning. After some time (hours) cache stop hitting (it works perfectly before). It's like no caching is enabled.
I go to admin panel, restart litespeed and everything works fine for some hours. Problem occures repeatevly.
Any suggestions?

 

[lsfoo]

Hi @capvar

Could you run df -h and df -i in the terminal?

It's possible that you're running out of disk space.

 

[capvar]

[root@s6 ~]# df -i
Filesystem Inodes IUsed IFree IUse% Mounted on
/dev/mapper/cl_s6-root 18669568 90353 18579215 1% /
devtmpfs 996611 407 996204 1% /dev
tmpfs 999288 2 999286 1% /dev/shm
tmpfs 999288 507 998781 1% /run
tmpfs 999288 16 999272 1% /sys/fs/cgroup
/dev/mapper/cl_s6-home 9115648 107585 9008063 2% /home
/dev/sda1 524288 344 523944 1% /boot
tmpfs 999288 1 999287 1% /run/user/0

[root@s6 ~]# df -h
Filesystem Size Used Avail Use% Mounted on
/dev/mapper/cl_s6-root 36G 7.7G 28G 22% /
devtmpfs 3.9G 0 3.9G 0% /dev
tmpfs 3.9G 0 3.9G 0% /dev/shm
tmpfs 3.9G 8.6M 3.9G 1% /run
tmpfs 3.9G 0 3.9G 0% /sys/fs/cgroup
/dev/mapper/cl_s6-home 18G 6.1G 12G 35% /home
/dev/sda1 1014M 229M 786M 23% /boot
tmpfs 781M 0 781M 0% /run/user/0

Doesn't seem as free space problem

 

[capvar]

I post the response headers below
1. Before restarting openlitespeed (after several hours before service start)

• Cache-Control:no-store, no-cache, must-revalidate
• Connection:Keep-Alive
• Content-Encoding:gzip
• Content-Length:125469
• Content-Type:text/html; charset=UTF-8
• Date:Wed, 26 Apr 2017 19:06:20 GMT
• Expires:Thu, 19 Nov 1981 08:52:00 GMT
• Link:<http://...../wp-json/>; rel="https://api.w.org/"
• Link:<http:/...../>; rel=shortlink
• Pragma:no-cache
• Server:LiteSpeed
• Transfer-Encoding:chunked
• Vary:Accept-Encoding
• X-Litespeed-Cache-Controlublic,max-age=1800
• X-Litespeed-Tag:B1_URL.6666cd76f96956469e7be39d750cc7d9,B1_F,B1_Po.30,B1_PGS,B1_

2. After restarting openlitespeed (working as expected)

• Cache-Control:no-store, no-cache, must-revalidate
• Connection:Keep-Alive
• Content-Encoding:gzip
• Content-Length:125469
• Content-Type:text/html; charset=UTF-8
• Date:Wed, 26 Apr 2017 19:09:49 GMT
• Expires:Thu, 19 Nov 1981 08:52:00 GMT
• Link:<http://....../>; rel=shortlink
• Pragma:no-cache
• Server:LiteSpeed
• Transfer-Encoding:chunked
• Vary:Accept-Encoding
• X-Litespeed-Cache:hit
• X-Litespeed-Cache-Controlublic,max-age=1800
• X-Litespeed-Tag:B1_URL.6666cd76f96956469e7be39d750cc7d9,B1_F,B1_Po.30,B1_PGS,B1_

 

[lsfoo]

Could you pm me the error log?

Also, is it repeated cache not working after a few hours? The cache is meant to invalidate (according to your settings, at 1800 seconds), so the first request after it is invalidated will be a cache miss. The following ones should be a hit.

 

[capvar]

Its not an invalidation thing, I hit F5 several times on the same page to ensure it's cached (or should be cached in our case), or navigate between two pages several times and wait for the response time to reduce (never does before restarting openlitespeed service).

Same procedure after restart is working perfectly.

Do you think increasing 1800 seconds to 3 hours is a good practice?

 

[lsfoo]

I see. I have a comment about the log, but I will just reply to you in the conversation about it.

Regarding the invalidation time, it is entirely dependent on how your site is set up. If you are using the wordpress cache plugin (response headers indicate that you are), our plugin knows when to invalidate pages (e.g. blog edits, new posts, etc.), so really there's no reason for it to be set to less than a day once everything is working correctly. In the plugin version 1.0.15, we actually increased the default TTL to 1 week.