About three weeks ago I upgraded my ePO server from 4.5.4 HF1 to 4.6.4. Now in the Server Task Log I see that the Purge Audit Log Server task that I had been running on ePO 4.5.4 HF1 with no issue is now taking 4+ hours tom complete. I run this task every night to get rid of audit logs older than 90 days old. I noticed that everyday when I looked that the task took 4+ hours to complete. I did disable that task and create a new task that do the same function it also was taking several hours to complete. Has anyone seen this before? What are some things I can look at to get this working again? Thanks in advance.
Solved! Go to Solution.
I have managed to resolved this issue by using SQL command to delete rows out of the OrionAuditLog table manually. Although this may be frowned upon it did do the trick and now my Automated ePO server task to Purge the Audit log now runs successfully every night. Thanks for all the responses.
Hi kink 80
Would you check in this location, how many folders are there and whats their size?
C:\Program Files\McAfee\ePolicy Orchestrator\DB\Events
Remove Debug folder, it is temporay location from where Event Parser services takes events and store them in DB, after it make sure a new folder with same name is created automatically, Restart Event parser server service, and run that task again and post resuilts, I mean time that it takes to purge events.
alexn ....... wrote:
Remove Debug folder, it is temporay location from where Event Parser services takes events and store them in DB
Hi... this is not correct, I'm afraid. The Events folder is the working folder that the event parser uses to process events into the database: the Debug folder is used to store events that the event parser cannot process, so that they can be investigated later. (If you don't want these events to be stored and are happy to simply lose them, you can configure ePO to simply remove events that cannot be processed.)
Neither of these folders and their contents really have any bearing on how long it takes to purge events from the database, which happens completely inside SQL. (The only case where this might be relevant is if the folder was filling up at rapidly while the purge task was running, which might indicate a problem processing events, but it would not necessarily impact the purge task.)
It's more likely to be a possible indexing problem in the DB: before anything else, please make sure that you have reindexed the database, and then try the purge task again.
I would like to add when event parsing and Purging runs simultenoulsy, this dely takes place.So once we will remove all these gathered events, there will be no event parsing and event purging will take lees time. May JOE would explain this process a bit more.
alexn ....... wrote:
I would like to add when event parsing and Purging runs simultenoulsy, this dely takes place.
Yes, that's what I was referring to when I said "The only case where this might be relevant is if the folder was filling up at rapidly while the purge task was running, which might indicate a problem processing events". Generally this doesn't impact the purge task though.
So once we will remove all these gathered events, there will be no event parsing and event purging will take lees time.
This is possible, but it assumes that no new events arrive while the purge is running, which is unlikely. If you're finding that event processing is affecting the speed of the purge task, the best way to prevent this is to stop either the event parser service, which will cause events to pile up in the Events folder, or by stopping the ePO server service which will stop any new events from arriving and cause them to pile up on the client machines. Once the purge has completed you can re-enable the service(s) and ePO will start processing the backlog again.
However, this is all irrelevant
Having re-read the original question, I notice the original poster is talking about the Audit log, not the Threat Event log - so we're talking about something that is completely internal to ePO. In this case, DB index fragmentation is definitely the first place to look. I would also examine the audit log and see if there are (for example) a large number of entries being logged that were not being logged under 4.5 - it might be as simple as that.
Thanks for the replies. I re-indexed my ePO SQL database last night and then re-enabled the Purge Audit Log task again. When it ran this morning I still got the same result it just hangs and then prevents other ePO server tasks from running efficiently. Usually every one of my ePO Server tasks takes less than a minute to complete but after the Purge Audit Log task hangs all of the rest of my tasks take much longer as well. I have attached a screen shot. I am purging event logs older than 90 days. I did look in the Audit log and saw that it is logging every time we assign a policy to a machine. But i assume this has not changed when moving from ePO 4.5 to ePO 4.6. When I look at the Audit log fo rthe last day it says there are 311126 items. Is that a high number?
I just did a row count on my OrionAuditLog SQL table and it is reporting 29,064,047 rows is that a normal number for ~17,000 machines?
I can't speak for everyone, but but that seems high for the audit log. Perhaps you could do a count, group by on the task names or something to get an idea why there are so many things occurring.
Maybe also trend it the count by month. If you have 29 million lines now, you should technically have around 10 million lines for the month of february. See if something has caused a spike in the logs.