• Versions: WordPress: 6.7.2, W3TC plugin: 2.8.6.

    Relevant plugin settings: Memcache backend, object cache enabled, option “Store transients in database” enabled.

    After the recent plugin update, I was facing php out of memory expections (up to 1.6GB per php fpm process) in combination with a tremendous slow down of php request processing at increased CPU load. I figured out that 200M+ of autoload transients were present in some WordPress instances, which explains the peak of memory consumption and slow php processing. I had suspected the plugin wp-typography as its cache stored as transient was one of the largest ones (please refer here to the topic). After deleting all outdated transients (expect the newest one) from this plugin, I recognized another 175 new ones (61MB) after just 9hrs.

    List of recent transient options from the same plugin (all of them autoload!!!):

    _transient_typo_1740565127_php_hyphenator_cache +476 secs.
    _transient_typo_1740564651_php_hyphenator_cache +195 secs.
    _transient_typo_1740564456_php_hyphenator_cache +189 secs.
    _transient_typo_1740564267_php_hyphenator_cache +216 secs. 
    _transient_typo_1740564051_php_hyphenator_cache +256 secs.
    _transient_typo_1740563795_php_hyphenator_cache

    I suspect the transients are automatically stored by W3TC as backup due to enabled option “Store transients in database”. However, I cannot see why outdated transients are not automatically removed. Even issuing wp w3tc flush object does not change the list of transients in the database.

    Expected behaviour: Once the object cache is updated (for whatever reason), outdated transients in the database are removed either directly or async. via WP cron. When adding new transients to database, older versions should not marked as autoload.

    Thanks for your help!

Viewing 3 replies - 1 through 3 (of 3 total)
  • Plugin Contributor Marko Vasiljevic

    (@vmarko)

    Hello @theschappy

    Thank you for reaching out and I am happy to help!
    Let me make some tests and check this with the team so I can give you a clear answer on this

    Thank you for bringing this to our attention and thank you for your patience

    Thanks!

    Thread Starter Matthieu-P. Schapranow

    (@theschappy)

    Thank @vmarko for the prompt reply. For the time being, I tested to disable the option “Store transients in database” to see if this is a work around. I expect to have no new transients added to the database now (I would consider this as the default option if not already, because I do not see any benefits from duplicating transients in memcache and the database at the same time).

    For further investigation, here are some further settings:

    • Default lifetime of cache objects: 180s
    • Garbage collection interval: 600s
    • Purge via WP Cron: off

    Is garbage collection also running for transients stored in the database or only on disk as noted in the explanation? If the “Purge via WP Cron” task is scheduled, would this purge also the transients copies stored in the database; i.e. a be kind of regular cleanup task?

    Thread Starter Matthieu-P. Schapranow

    (@theschappy)

    The author of the wp-typography plugin pointed out here that outdated transients are removed from the database by the plugin iff wp_using_ext_object_cache is false. I suspect that W3TC with configured object cache will alter this WP setting to true. As the plugin does not know how the specific object cache works, it cannot run removal operations. As a result, expired transients will be present in the object cache as well as in the database if the Store transients in database setting is enabled. Thus, disabling this options removes the redundant storage from database and reduces load on the database. Furthermore, I have now configured W3TC’s Purge via WP cron setting for the object cache to cleanup outdated transients from it as well; otherwise it might grow in a similar way like the database.

Viewing 3 replies - 1 through 3 (of 3 total)
  • You must be logged in to reply to this topic.