Posted July 27, 20222 yr 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?
July 27, 20222 yr 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.
July 27, 20222 yr Author yes there was an error in one of the emails , and it is now solved can i push this system task?
July 27, 20222 yr 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.
July 28, 20222 yr Community Expert As suggested in the message, you may also wish to check your prune settings, and adjust to suit
July 28, 20222 yr Author 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.
July 28, 20222 yr Community Expert 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
July 28, 20222 yr Author i updated the Prune email error logs to only 2 days and run the prune task successfully still showing the same message in ACP
July 28, 20222 yr 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.
July 29, 20222 yr Community Expert 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