Pruning options

[Marafa]

 

The log table core_mail_error_logs within the database is 13.33 GB in size. You may wish to adjust the pruning options for these logs to keep the log table smaller in size.

 

i got this alert in ACP , so i changed the prune options to one month , but nothing happened. how to make this active?

 

 

[Mark H]

I think a more important item to check first is what the error is saying; the email error logs table is growing rapidly.

At 13 GB, that may indicate you have repeated email send failures.

Have you checked the content of one of the log entries? ACP -> Support page -> "System Log" and "Error Log" buttons. Also check ACP -> Email Settings -> Email Error Logs button, in upper right.

As to your second question, pruning is done by a system task, it's not instant.

[Marafa]

yes there was an error in one of the emails , and it is now solved

can i push this system task?

[Mark H]

Possibly. Use the Live Search for: tasks

Choose Tasks from the list then find the task(s) associated with pruning, and run manually. Note that this may take some time, and if it times out, you can run it again or wait for the system to run it.

[Marc Stridgen]

As suggested in the message, you may also wish to check your prune settings, and adjust to suit

[Marafa]

The Prune Setting is 30 Days

The Task was run siicceffuly , 

Still the ACP shows that the file size if 13.5 GB

The log table core_mail_error_logs within the database is 13.33 GB in size. You may wish to adjust the pruning options for these logs to keep the log table smaller in size.

[Marc Stridgen]

If the logs are less than 30 days old, then it will indeed stay the same size as nothing will have been pruned. You may wish to reduce that temporarily 

[Marafa]

i updated the Prune email error logs to only 2 days

and run the prune task successfully

still showing the same message in ACP

 

[Mark H]

Do you have access to phpMyAdmin?

If so, use it to view the database and in the list of tables, check the "Overhead" column.

The value there should be zero most times. (MySQL should recover that overhead automatically, but it sometimes doesn't.)

If the "Overhead"value for your table is 13 GB, that's something your Host needs to address.

You can run an "Optimize" on that table to get back the space temporarily, but long-term is something your Host needs to fix in MySQL so it recovers it automatically on a timely basis.

[Marc Stridgen]

In addition to the above, if your table is now no longer actually that size, you should dismiss the message. Only if it returns should you be concerned with whether or not it has happened