maintanosgr

ok sure. Done

• This reply was modified 8 months, 1 week ago by maintanosgr.

I think there’s a confusion.

checking the size in phpmyadmin and the total row count doesn’t show any increase. The row count stays the same and the size as well.

whats actually increasing is the actual disk space used by the ibdata file in MySQL.

the reason is simple

From Maria Db

Reclaiming the disk space? This is costly. (Switch to the PARTITION solution if practical.) MyISAM leaves gaps in the table (.MYD file); OPTIMIZE TABLE will reclaim the freed space after a big delete. But it may take a long time and lock the table. InnoDB is block-structured, organized in a BTree on the PRIMARY KEY. An isolated deleted row leaves a block less full. A lot of deleted rows can lead to coalescing of adjacent blocks. (Blocks are normally 16KB – see innodb_page_size.) In InnoDB, there is no practical way to reclaim the freed space from ibdata1, other than to reuse the freed blocks eventually. The only option with innodb_file_per_table = 0 is to dump ALL tables, remove ibdata*, restart, and reload. That is rarely worth the effort and time. InnoDB, even with innodb_file_per_table = 1, won’t give space back to the OS, but at least it is only one table to rebuild with. In this case, something like this should work: CREATE TABLE new LIKE main; INSERT INTO new SELECT * FROM main; — This could take a long time RENAME TABLE main TO old, new TO main; — Atomic swap DROP TABLE old; — Space freed up here You do need enough disk space for both copies. You must not write to the table during the process.

So any form of operation which keeps inserting then deleting and reinserting constantly will lead to unclaimed space that never gets released and it seems practically this happened partially from fvm

Actually the tricky part is detecting what data increases it because at the end of the transactions the actual records are minimal. I’m suspecting it’s transients that are stored there but not sure why removinh fvm mitigated the issue

The crons might be the issue possibly because I saw a lot of update queries regarding Cron tasks

Let me see if I can find out more info

In our case with a theme using the 9999px method, we ended up having a broken gallery with extremely high images and wrong aspect ratio of course. It would be great if you could give us an option to ignore the 9999px height specifically since it’s so tied to the core documentation.

Hi, unfortunately what you suggested I already tried.

The files exist and the class exists on the core folder.

I also noticed that you’re autoloading via composer and that the classmap is correctly defined.

Furthermore I tried to do a composer dump-autoload in case it would be missing something but it didn’t work either.

Finally I resorted to completely uninstalling the plugin and reinstalling but to no avail.

I’m sending you an email

The whole issue started after upgrading to the latest version.

Oh, I see.

I thought I had to only set it globally. I had to set the settings for every single type of cache and now it seems all are working well. My omission because most systems I’ve seen just use a general configuration for redis. I guess this can help if you’re using a redis cluster.

I no longer see double entries on both redis servers but only on the configured ones.

You pointed me in the right direction, so thank you very much.