Hi. Please would you consider adding a limit to the number of log entries, e.g. a dropdown for 30 days, 90 days, 1yr etc. and then it deletes anything older than that.
]]>Hi,
In the log I see the entry “Done wp-cron.php ????“. I’m not sure what this means. Does it mean that it is uncertain if the wp-cron job completed successfully or something else. Can you clarify?
Thanks,
-Norm
]]>Hi,
After running the logger, how do I clean out the log data after I’m finished with it? I tried deactivating and deleting the plugin, but the log data still seems to be retained.
]]>In the log is the integer field “executed” (eg: 1674060358). I assume that is a timestamp. How do I convert that into a date/time?
THNX
]]>Does this work with the latest version of WordPress? As of this support ticket, that is WordPress 6.1.1 (which recommends PHP 7.4 or greater and MySQL 5.7 or MariaDB version 10.3 or greater).
]]>According to New Relic, the regular cron job that checks if logs should be cleaned up from the database is really inefficient. We can see that here:
MySQL [bitnami_wordpress]> EXPLAIN ANALYZE
-> SELECT
-> *
-> FROM
-> wp_cron_logs
-> WHERE
-> parent_id IN (
-> SELECT
-> id
-> FROM
-> (
-> SELECT
-> id
-> FROM
-> wp_cron_logs
-> WHERE
-> parent_id IS NULL
-> AND executed < UNIX_TIMESTAMP(DATE_SUB(NOW(), INTERVAL 30 day))
-> ) as parent_id
-> );
+----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
| EXPLAIN |
+----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
| -> Nested loop inner join (cost=87254.10 rows=9616) (actual time=0.046..686.448 rows=5723 loops=1)
-> Filter: (wp_cron_logs.parent_id is not null) (cost=19944.55 rows=192313) (actual time=0.027..245.707 rows=169347 loops=1)
-> Table scan on wp_cron_logs (cost=19944.55 rows=192313) (actual time=0.021..169.521 rows=191038 loops=1)
-> Filter: ((wp_cron_logs.parent_id is null) and (wp_cron_logs.executed < <cache>(unix_timestamp((now() - interval 30 day))))) (cost=0.25 rows=0) (actual time=0.002..0.002 rows=0 loops=169347)
-> Single-row index lookup on wp_cron_logs using PRIMARY (id=wp_cron_logs.parent_id) (cost=0.25 rows=1) (actual time=0.001..0.001 rows=1 loops=169347)
|
+----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
1 row in set (0.690 sec)
MySQL [bitnami_wordpress]>When I look at the indexes that already exist I see this:
MySQL [bitnami_wordpress]> show indexes from wp_cron_logs;
+--------------+------------+----------+--------------+-------------+-----------+-------------+----------+--------+------+------------+---------+---------------+---------+------------+
| Table | Non_unique | Key_name | Seq_in_index | Column_name | Collation | Cardinality | Sub_part | Packed | Null | Index_type | Comment | Index_comment | Visible | Expression |
+--------------+------------+----------+--------------+-------------+-----------+-------------+----------+--------+------+------------+---------+---------------+---------+------------+
| wp_cron_logs | 0 | PRIMARY | 1 | id | A | 180782 | NULL | NULL | | BTREE | | | YES | NULL |
| wp_cron_logs | 1 | executed | 1 | executed | A | 53150 | NULL | NULL | YES | BTREE | | | YES | NULL |
| wp_cron_logs | 1 | duration | 1 | duration | A | 54 | NULL | NULL | YES | BTREE | | | YES | NULL |
+--------------+------------+----------+--------------+-------------+-----------+-------------+----------+--------+------+------------+---------+---------------+---------+------------+
3 rows in set (0.067 sec)
MySQL [bitnami_wordpress]>Since there is an index on executed already, the problem is obviously a missing index on parent_id. I created one manually in my database like this:
CREATE INDEX effecient_log_delete on wp_cron_logs(parent_id);
And now we can see that the query is much much more performant:
+------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
| EXPLAIN |
+------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
| -> Nested loop inner join (cost=7283.07 rows=12434) (actual time=0.244..31.770 rows=5723 loops=1)
-> Filter: (wp_cron_logs.parent_id is null) (cost=2931.11 rows=1416) (actual time=0.226..13.515 rows=790 loops=1)
-> Index range scan on wp_cron_logs using executed, with index condition: (wp_cron_logs.executed < <cache>(unix_timestamp((now() - interval 30 day)))) (cost=2931.11 rows=6513) (actual time=0.224..11.970 rows=6513 loops=1)
-> Index lookup on wp_cron_logs using effecient_log_delete (parent_id=wp_cron_logs.id) (cost=2.20 rows=9) (actual time=0.004..0.019 rows=7 loops=790)
|
+------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+Is it possible to include this update to the plugin itself to prevent performance issues in the DB? Creating this index costs very little and means that it’s one less database query that takes a long time to run.
]]>Function wp_timezone_string() now used in version 1.0.4 of this plugin was introduced in WP 5.3. Perhaps the required WordPress version could be adjusted with the next plugin update.
]]>Hi, the plugins seems doing exactly what I was looking for, many thanks!
Two questions please (also to others) if I may:
1) Does the plugin itself store the logs somewhere? In database or in some file? Or plugin itself doesnt store the logs (but just generates the history ‘on demand’ from other WP tables/sources)?
2) If the plugin stores the logs (in db, or in some file), please is there any cleaning mechanism (eg. keeps logs only for xx days, or some hardcoded cleaning mechanism)?
As I saw some entries concerning log cleaning in plugin changelog.
Many thanks for sharing your knowledge
Best regards
Vaclav
Hi,
Thanks for the great plugin! It has been really helpful.
I discovered that the plugin did not create the log tables on multisite network activation. I added a few lines to your activation script to make it do so.
You can find them here: https://gist.github.com/jason-cleaveland/3c31646ee22b266628d81d5176c6ba16
In the event of a single site activation, the code reverts to the original table creation function.
Feel free to add it to the plugin. Let me know if you find this helpful.
Thanks again!
]]>My (local) site uses gmt_offset instead of timezone_string. So, my local site gets the warning “Missing ?timezone_string? entry in options table. Please fix! Otherwise execution times could be wrong.” There may be other sites who use gmt_offset too. Rarst provided a nice solution to overcome such situations. Hope you’d consider this in the future. Thanks.