Advanced Open Workflow logging is choking up database.

šŸ’¬ General Discussion
1

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. :angry:

2

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.

3

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:

4

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.

5

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**
6

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

7

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.

8

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: