wp_options increasing in size on every request

Hi, it would require inspection on what is being stored there, but no, normally that shouldn’t happen.

The plugin settings itself is stored on wp_options, but that is similar to other plugins and takes a few Kb at most.
The wp_options is also used to store transient admin notices after manually purging the cache. It would not cause that to happen, as it only happens on manual interaction.

To store the minified css and js files, it uses it’s own table, wp_fvm_cache so those should not be on wp_options.

Please ensure you are running the latest version, and not some old or edited version.

A few years ago, there was a version that had a bug and was creating too many cronjobs. You can install a plugin like wp cron control and take a look at the cronjobs. It’s safe to delete anything fvm related.

If after installing the plugin, you see the database increasing in size, check if it’s really the wp_options or the cache table.

If it’s the wp_options you need to inspect and see what kind of data is being stored there, by looking at the name and content.

If the cache table increases too much, you likely are minifying a dynamic css or js file. If the name of the file changes on every pageview (check without fvm) then every pageview would trigger a minification for that file.
In that case, exclude it, as there is no point minifying a dynamic file.

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

I would export the wp_options table (or take a look via phpmyyadmin), then look for the last rows added and see if they are related and what’s inside.

Cron jobs are stored?in the wp_options table of the WordPress database where the option_name is cron. Check it’s size.

You need to see if it’s increasing because of the cron field, or because more rows are added to wp_options.

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

The actual disk space used by the ibdata file in MySQL is going to depend on how you set the server, however, I can tell you that FVM shouldn’t be adding and then deleting data under normal circunstances.

It periodically deletes some data, but it’s to prevent growing the table beyond a reasonable limit.

For wp_fvm_cache the limit is 20k rows, and for the wp_fvm_logs the limit is 500 rows. The plugin will delete rows above this count.

The wp_fvm_logs are only created when you do a manual cache purge, mostly, so they increase but not so frequently.
The wp_fvm_cache increases whenever it sees a different css or js file, so as I said earlier, if there is a dynamic css or js url (the query string changes on each pageview for example)… it’s going to keep increasing.

If the wp_fvm_cache table is increasing the row count for every pageview, then you need to exclude that file, else it’s not efficient.

You can convert wp_fvm_logs and wp_fvm_cache to MySAM too, though it will affect performance when inserting data, because it will block the table instead of the row.

Removing FVM might mitigate the database storage issue, but check if indeed the two tables are increasing rapidly to those limits. If they are not, then data would not be deleted.

It would be more likely some transients used somewhere else (theme, plugins, code…) since those are meant to be created and deleted frequently.

If the issue is with regular wordpress transients, then adding a Redis Object Cache plugin will help you move them out of MySQL (transients will not write to wp_options anymore).

—

For MariaDB, you could try to switch to Percona DB and see if it makes a difference. It’s not the first time I’ve seen performance issues on MariaDB that don’t happen with Percona… but it’s still going to depend on the settings.

Take a look at these settings and see what you can do:

innodb_file_per_table:

• When set to 1, this option stores each InnoDB table’s data and indexes in its own file (.ibd file) instead of the shared ibdata1 file. This makes it easier to reclaim space at the table level. It’s typically recommended for most use cases.

innodb_page_size:

• This setting determines the page size for InnoDB tablespaces. The default is 16KB, but it can be set to 4KB, 8KB, or 64KB depending on your workload and hardware. Smaller page sizes can reduce waste when dealing with lots of small rows but can increase overhead.

innodb_buffer_pool_size:

• This setting controls the size of the buffer pool, where InnoDB caches data and indexes. A larger buffer pool can reduce I/O by keeping more data in memory, but it won’t directly affect disk space usage.

innodb_autoextend_increment:

• This variable sets the increment size (in MB) for extending the size of an InnoDB data file when it’s full. A larger increment can reduce the frequency of file extensions but might lead to more unused space.

innodb_optimize_fulltext_only:

• When set to 1, OPTIMIZE TABLE statements only optimize InnoDB full-text search indexes. This is relevant if you’re using full-text search and want to optimize those indexes without fully rebuilding the table.

innodb_file_format:

• This setting determines the file format for InnoDB tables. In MariaDB 10.3 and later, the default and recommended value is Barracuda, which supports features like table compression.

innodb_flush_method:

• This setting affects how InnoDB flushes data to disk. While it doesn’t directly impact space reclaiming, it can influence I/O performance and efficiency.

innodb_log_file_size and innodb_log_files_in_group:

• These settings control the size and number of log files in the InnoDB redo log. Proper sizing is important for performance but doesn’t directly impact space usage.

These are generic recommendations though, so good luck investigating that.