My SuiteCRM instance stopped because the disk got full. When investigated, I had dev/vda1 was 100% full. Further, the highest usage was coming from
/var/lib/mysql/suitecrm (Suitecrm Database)
aow_processed_aow_actions.ibd 54GB
aow_processed.ibd 18GB
Seems like the Advanced Open Workflow logging is choking up database. How do I fix it. 
I have a post about some of these things in my blog
https://pgorod.github.io/Database-tables-size/
The AOW processed tracks Workflows that have āRepeated Runsā unchecked, so they need to track which records it was run on, to prevent from running again on the same record.
so you have to be careful when deleting rows form there. Itās likely that millions of rows can be deleted safely, BUT only you can know the meaning of your Workflows and whether it is a bad thing that they will be run again for some record.
So review the logic of your Workflows and then try to clean up stuff related to deleted records, for example, or cases where the āNo Repeated runsā condition wasnāt really necessary.
Just stumbled into this ā we have over 31M records in this thing AND we do NOT have ANY workflows defined!!
It took mysql 21 minutes to return that result from:
MariaDB [suitecrm]> select count(*) from aow_processed;
+----------+
| count(*) |
+----------+
| 31340634 |
+----------+
**1 row in set (21 min 11.17 sec)**
What gives?
Following this advice now:
Thatās weird, if you donāt have workflows definedā¦
If I were you I would try to understand better why that data is getting added to the table. For this, it would help to have some notion of that data, before you delete itā¦ dates, which records it references, etc.
Itās very weird ā and check this out since 4/1 there are 2.7M records in there !!
MariaDB [suitecrm]> INSERT aow_processed_new SELECT * FROM aow_processed WHERE date_entered >= '2021-04-01 12:00:00';
**Query OK, 2730931 rows affected (2 hours 10 min 41.13 sec)**
**Records: 2730931 Duplicates: 0 Warnings: 0**Okay update: looks like we did setup some baby ones last fall but forgot about them ā not even sure what they are doing for us atm other than taking up a lot of diskspace
Just went from 86% disk usage to 9% !
I basically doubled the volume size last fall because I thought it legit needed it.
Now to figure out what it was doing and why as well as how to make sure it doesnāt happen again.
If your workflows allow ārepeated runsā, they donāt have those aow_processed space problems.
If they are not running on āall recordsā, they also generate less rows there.
Finally, this is all a function of the number of records on the module table (the module on which the Workflow runs), so maybe a clean-up there is in order.
Some of these caveats are explained here: