tbllog_register growing again

[Faizal1]

Hi all,

I had an issue where the tbllog_register was being filled with RunJobsQueue.executed entries in the past but have now setup a script to clean them up every so often.

Now the tbllog_register seemed to be huge again and when i checked I found the below entries every 5 mins. Don't remember that many entries before but I could be wrong.

ProcessEmailQueue.failed      108510 current entries and every 5 mins

ProcessEmailQueue.sent        108511 current entries and every 5 mins

EmailCampaigns.queued        107700 current entries and every 5 mins

 

Just wondering if this is normal and if there are any issues with removing these entries like the RunJobsQueue.executed ones?

Thanks

Edit: WHMCS version 8.7.3

Edit 2: Just checked and without these entries, the total size of the table would only be about 50000 only.

 

 

Edited January 24 by Faizal1

[joeroot6543]

On 1/25/2024 at 3:27 AM, Faizal1 said:

I had an issue where the tbllog_register was being filled with RunJobsQueue.executed entries in the past but have now setup a script to clean them up every so often.

Now the tbllog_register seemed to be huge again and when i checked I found the below entries every 5 mins. Don't remember that many entries before but I could be wrong.

ProcessEmailQueue.failed      108510 current entries and every 5 mins

ProcessEmailQueue.sent        108511 current entries and every 5 mins

EmailCampaigns.queued        107700 current entries and every 5 mins

Hi there,

I'm encountering a similar issue with the tbllog_register filling up with entries related to ProcessEmailQueue and EmailCampaigns. It seems like there's a high frequency of entries being added every 5 minutes. I'm also curious about whether this is normal behavior and if there are any potential issues with removing these entries, akin to the situation with the RunJobsQueue.executed entries.

Thanks for raising this concern! 

[WHMCS Stephen]

Hello,

The tbllog_register table holds data on the actions taken by the daily cron tasks which are available in the admin area at  Utilities > Automation Status.

It is where the results of a cron task are stored. The daily cron email report aggregates its content from these rows. These are the actions taken by the daily cron tasks which are available in the admin area at Utilities > Automation Status.

At present it is not possible to prune this log from within WHMCS. If you'd like to see this included I'd encourage you to add your vote or comments to https://requests.whmcs.com/idea/cleanup-tool-to-prune-tbllog_register-table

Ideas with the most votes and activities are reviewed by our team.

As of WHMCS 8.1 and above we have optimized the indexing for cron log data.

https://docs.whmcs.com/Changelog:WHMCS_V8.1

CORE-14970 - Optimize indexing for cron log data

In the meantime, if this is something that you would like to work with, you can do so with a SQL query. For example, the SQL query below will remove any entries in that table that predate 2023. You can modify this to suit your requirements.
 

DELETE FROM `tbllog_register` WHERE created_at < "2023-01-01";

As always, please ensure you back up your database before performing any such direct actions on the WHMCS database.

[joeroot6543]

I appreciate the clarification on the purpose of the tbllog_register table and the explanation of how the cron tasks are logged. It's helpful to understand that these entries are related to the actions taken by the daily cron tasks.

I'll definitely consider adding my vote to the feature request for a cleanup tool to prune the tbllog_register table. It seems like a useful addition for managing the database more efficiently.

Also, thank you for providing the SQL query to manually remove entries from the table. I'll keep that in mind if I need to clean up older data before the feature request is implemented. And of course, I'll make sure to take a database backup before executing any direct actions.

Thanks again for your assistance and explanation.

[mncraftmod]

On 2/7/2024 at 11:07 PM, joeroot6543 said:

I appreciate the clarification on the purpose of the tbllog_register table and the explanation of how the cron tasks are logged. It's helpful to understand that these entries are related to the actions taken by the daily cron tasks.

I'll definitely consider adding my vote to the feature request for a cleanup tool to prune the tbllog_register table. It seems like a useful addition for managing the database more efficiently.

Also, thank you for providing the SQL query to manually remove entries from the table. I'll keep that in mind if I need to clean up older data before the feature request is implemented. And of course, I'll make sure to take a database backup before executing any direct actions.

Thanks again for your assistance and explanation.

Yes of course. I appreciate  assistance in furnishing the SQL query for manually removing entries from the table. I'll certainly remember it in case I need to tidy up older data prior to the feature request being implemented. And naturally, I'll ensure to take a database backup before carrying out any direct actions.

[RadWebHosting]

You might also benefit from using this module by WHMCS Services: https://marketplace.whmcs.com/product/1334-log-prune

[mncraftmod]

On 2/7/2024 at 11:07 PM, joeroot6543 said:

I appreciate the clarification on the purpose of the tbllog_register table and the explanation of how the cron tasks are logged. It's helpful to understand that these entries are related to the actions taken by the daily cron tasks.

I'll definitely consider adding my vote to the feature request for a cleanup tool to prune the tbllog_register table. It seems like a useful addition for managing the database more efficiently.

Also, thank you for providing the SQL query to manually remove entries from the table. I'll keep that in mind if I need to clean up older data before the feature request is implemented. And of course, I'll make sure to take a database backup before executing any direct actions.

Thanks again for your assistance and explanation.

Supporting the feature request for a cleanup tool is a great idea, as it would make managing the tbllog_register table much easier. It's also smart to prioritize backups before running any manual SQL commands.