I found our database filling up too.
In our case, the DAT update task was complaining about being unable to download jticontentdetection.mcs, filling up the ePO database with “update failed” events.
Fixed that by following the instructions in https://kc.mcafee.com/corporate/index?page=content&id=KB90127
We too were missing the event database purge tasks. Fixed that by following instructions here:
The database growth has seemed to settle down over the weekend. It quit growing about 1GB a day. If it is events then how did you find these extra client events that were causing you issues? We don't use TIE/ATP in our environment so don't think it is the same issue as you.
I did do a query looking for top event id's but didn't see anything causing issues. It there another type of SQL query that I can do?
We don't use TIE/ATP either.
However, this is what our client logs showed before my fix (in reverse time order):
When, I run the update task on a system conected to our production ePO server, I don't see any message "Framework Service 11/03/2019 08:58:04 Info Error occurred while verifying JtiContentDetection.McS.".
Is there a database query that reveals the error that you were having?
ePOProductEventsMT contains client events ... the table EPOEvents contains Threat Events. Revisit the sql command - instead of searching for threats reverse engineer for clients events ... or Best practice: Create client event summary queries : display events sent from your agents to McAfee ePO, create client event summary queries - https://docs.mcafee.com/bundle/epolicy-orchestrator-5.9.0-product-guide/page/GUID-F14501EF-EF6D-483A...
Due to the large number you may want to start small and build up - suggest running query for only 15 minutes
If you run a query on events, are they all new ones, or are they possibly older ones that the clients had backed up and finally sent with the new agent? The most frequent event ID from your screenshot was 1034, which is a scan complete client event. You can also purge by event ID or disable those events in server settings, event filtering, if you don't want to see them. To purge by event ID, create a query searching for that event (filter it for a time range if you want). The query needs to be a table type. Then you can create a server task to run that query and purge those events.
Was my reply helpful?
If this information was helpful in any way or answered your question, will you please select Accept as Solution in my reply and together we can help other members?
OK, both twenden and I have reported the sudden growth of the producteventsmt table.
Advice on how to purge events is welcome, of course, but said advice doesn't address the underlying problem, which, from a bit of drilling down into events shows, as an example, for just one machine:
Same event, generated at the same time, multiplied up thousands of times, relentlessly.
That's a bug in the agent, the agent extension, or in ePO itself.
I've configured ePO to filter out that event, so I'm now waiting to see if and when it all calms down.
Redeploying Agent to that PC as well, but it's happening all over the place in our environment.
I've redeployed Agent 220.127.116.118 to the 13 top offenders and that seems to have stopped the flood of events, which was still occurring after I'd told ePO to filter out events which were flooding the events table (2401,2402,2411,2412,and 2427).
I'll re-enable some of them later and see what happens.
So, the issue here is that a handful of Agents spammed the ePO server with repeats of the same event.
Redeploying the agent appears to have fixed it here.
To verify this cause, do a query of Events and group by host name. Affected hosts will list tens of thousands or more, up to millions of events.
Is this what happened to you too, twenden?
Hope this helps.
Yes, that is what happened in my case. It was only one system that was spamming 2422 events. This system has since then been fixed. I have created a purge tasks to eliminate these events.
In our case the SQL database grew from 4GB to almost 8GB in a few days. Purging has reduced it back down to 4GB. Thanks to all that helped as I know has a query to monitor client tasks.
Same issue here - not so much with the database size yet but the DB/Events folder on the EPO server suddenly grows to hundreds of thousands/millions of files to process all of a sudden!
Apologies for being thick but how do I identify the machines which may be causing these? For now I have turned off 2401/2402/2411/2412/2427