Skip navigation
McAfee Secure sites help keep you safe from identity theft, credit card fraud, spyware, spam, viruses and online scams
This discussion is archived
3507 Views 12 Replies Latest reply: Mar 19, 2013 3:34 PM by kink80 RSS 1 2 Previous Next
kink80 Champion 472 posts since
Apr 6, 2009
Currently Being Moderated

Mar 8, 2013 1:25 PM

ePO 4.6.4 Purge Audit Logs Server task taking hours to complete

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.

  • alexn Veteran 722 posts since
    Aug 9, 2012

    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

     

    Regds


    Post Timings: 6.00 AM to 3.00PM PDT
  • alexn Veteran 722 posts since
    Aug 9, 2012

    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.

     

    Regds,

     

    Alex


    Post Timings: 6.00 AM to 3.00PM PDT
  • JoeBidgood McAfee SME 2,868 posts since
    Sep 11, 2009

    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.

     

    HTH -

     

    Joe




    (Please post questions to the forum, as I am unable to respond to private messages. Thanks!)



  • alexn Veteran 722 posts since
    Aug 9, 2012

    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.


    Post Timings: 6.00 AM to 3.00PM PDT
  • JoeBidgood McAfee SME 2,868 posts since
    Sep 11, 2009

    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.

     

    HTH -

     

    Joe




    (Please post questions to the forum, as I am unable to respond to private messages. Thanks!)



  • jenkinski Newcomer 27 posts since
    Mar 4, 2013

    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.

     

    -KJ

1 2 Previous Next

More Like This

  • Retrieving data ...

Bookmarked By (0)

Legend

  • Correct Answers - 5 points
  • Helpful Answers - 3 points