Massive size of cache folder

[Lakjin]

Is it normal for `apps/common/runtime/cache` to be 50GB+? How do I stop it from being this large?

 

[twisted1919]

It depends on how busy your system is.
Try: https://www.mailwizz.com/kb/clear-cache-command/ when you're not sending campagns.

 

[Lakjin]

That's quite excessive. I don't think my system is that busy. Less than 1m emails a day. I will try clearing the cache, but if this continues, is there any way to disable the cache?

 

[Lakjin]

So in the hour that I ran the clear cache command, ~2GB of cache came back after clearing. We don't even have any active campaigns running right now. Only webhooks from our email service provider. Surely this cannot be expected behavior?

 

[twisted1919]

I don't see this as a problem, there is a price to pay for performance in multithreaded environments, and in this case, this is one of these things.
You can switch to redis caching, allow it to store like X GB then use an eviction policy to remove old data, this way you'll always have at most x GB of data in cache.

 

[Lakjin]

I just setup a cron to clear cache every hour. I am all for performance, but the cache MailWizz uses seems excessive.

 

[Loïc31]

Same problem with the cache.
I'm just setting up Mailwizz, and it's just being tested. So it is almost empty.

I had +150 thousands of files in the cache which was beginning to be a problem with my host, relating to the number of inodes.
I emptied the cache, but files are coming again, second after second.
Again, with no activity at all in Mailwizz.

It seems to me there is a bug.
There was no problem up to now.

 

[twisted1919]

There's no bug, MailWizz does a lot of cache to improve performance.
You can use Redis instead of file cache, but you need redis installed on your host, see https://www.mailwizz.com/kb/using-redis-cache-mutexes/

 

[Loïc31]

The files in apps/common/runtime/cache, have a last modified date in 2024 (see screenshot attached).
Does that seem right to you?

 

[twisted1919]

Nope, that seems wrong. Are you sure the date/time on the server is properly set?

 

[Loïc31]

Yes it is.
This is the reply from Fastcomet specialist on that matter:

----

I can confirm that the date that you are seeing is there indeed; however, cPanel does not cause it in any way, it is something with the application itself or the way the application is modifying the files because all other values are normal:

-> https://prnt.sc/awCL1OWt6D_D

The date in cPanel is completely normal, as displayed in the picture below:

-> https://prnt.sc/p5ekUYOPk-Hp

Concerning this, you can turn to the application developers for more information on what is causing it or why it is happening.

Regarding the issue itself, we can fix it by creating a cronjob that will remove files that are becoming older than a specific date.

-----

 

[Loïc31]

And this is the cronjob they implemented on my server in order to remove old files, so that I stop having too many inodes after a while:
0 0 * * * find /home/parleran/Mailwizz/apps/common/runtime/cache -type f -ctime +30 -exec rm {} \;

 

[twisted1919]

@Loïc31 - I took a look at the issue, and found out the cache library we're using does this, it is its way to signal the cache is still valid, from its source code:

/**
     * @var boolean whether cache entry expiration time should be embedded into a physical file.
     * Defaults to false meaning that the file modification time will be used to store expire value.
     * True value means that first ten bytes of the file would be reserved and used to store expiration time.
     * On some systems PHP is not allowed to change file modification time to be in future even with 777
     * permissions, so this property could be useful in this case.
     * @since 1.1.14
     */
    public $embedExpiry=false;

And looking in the method that sets the cache:

protected function setValue($key,$value,$expire)
    {
        if(!$this->_gced && mt_rand(0,1000000)<$this->_gcProbability)
        {
            $this->gc();
            $this->_gced=true;
        }

        if($expire<=0)
            $expire=31536000; // 1 year
        $expire+=time();

        $cacheFile=$this->getCacheFile($key);
        if($this->directoryLevel>0)
        {
            $cacheDir=dirname($cacheFile);
            @mkdir($cacheDir,$this->cachePathMode,true);
            @chmod($cacheDir,$this->cachePathMode);
        }
        if(@file_put_contents($cacheFile,$this->embedExpiry ? $expire.$value : $value,LOCK_EX)!==false)
        {
            @chmod($cacheFile,$this->cacheFileMode);
            return $this->embedExpiry ? true : @touch($cacheFile,$expire); // <- HERE it sets the date in future
        }
        else
            return false;
    }

So it seems this is the way it suppose to work, sorry for sending you to your hosting for nothing.

And this is the cronjob they implemented on my server in order to remove old files, so that I stop having too many inodes after a while:
0 0 * * * find /home/parleran/Mailwizz/apps/common/runtime/cache -type f -ctime +30 -exec rm {} \;

I see this uses ctime, which is creation time, so you delete files older than 30 days, which seems legit.

 

[Loïc31]

No problem, now everything is clear at least : )
Fastcomet specialists didn't see any real problem as such.

I just wanted to make sure there was no bug.
And possibly that could have been linked to the large number of cache files created without activity of Mailwizz (+1000 in 24h).

Thank you for your research!
That's much appreciated!