Jump to content

Server Log Queue and Database Size HUGE


Recommended Posts

We recently upgraded our ERA instance (and half of our end user agents) to version 6.4, and about a month later to version 6.5. Most agents are on currently on 6.5, but there are still some lingering 6.4 and 6.1 end user agents.

We used to use the “Remote Administrator Agent – Application Reporting – Report all installed” policy in ESET Remote Administrator to report all applications on our endpoints (see first screenshot) in version 6.1. This policy is no longer being applied to any computers (see second screenshot) in version 6.5.

1.thumb.png.d393e05052d31000f4f21af3a554519d.png

2.thumb.png.e15a9b6ff297c8b331576bd419b867dc.png

 

 

 

While we upgraded to ERA 6.4, we left this policy in place and ALSO created a custom Agent policy that ALSO enabled reporting of applications (see third screenshot).

3.thumb.png.f7a66dd0786ae9cffb65fbb0f5ef53f4.png

 

 

Both of these policies were in place reporting applications for about 2 weeks. During this time period, our era_db database grew about 500% in size until it was realized that having both policies enabled to report applications may be causing this. Sure enough, after eliminating the redundant policy (we now exclusively use our custom agent policy), that database stopped growing.

 

We have now upgraded our ERA instance to 6.5 and everything runs smoothly, but we would like to clean up our mistake if possible.

The two lingering issues are:

  1. The database size (we would like to shrink from ~20GB back down to ~3GB, but how?).
  2. How to clear the server log queue that appears to hit our database server hard at midnight every night.

4.thumb.png.5ccd57ce0784a33613a47876b1172ece.png

 

Here is a snapshot of our top tables by disk usage for our era_db database in MSSQL:

5.thumb.png.53e604308f25790cce155a9a8f85c932.png

 

Do you have any suggestions on how to resolve the two issues (database size and clearing server log queue)?

 

Link to comment
Share on other sites

  • 1 month later...
  • ESET Staff

First of all, I am not sure whether tou correctly disabled reporting of non-ESET applications. Just to be sure, unassigning configuration policy is not enouth -> it is required to assigne policy that explicitly disabled reporting of non-ESET applications: otherwise AGENTs will be useing last cofiguration value, which was "enabled" in this case.

As you can see from DB size report, most of database size (~2GB) is taken by exported configurations. Are you using this task, or those logs are renmants of older ERA release, that procuded this type of log automatically for problematic computers? I would recommend to check whether this table grows and if so, disable task that could possibly request configuation export automatically (i.e. task assigned todynamic group).

What is really suspicious is amount of "Agent deployment task" logs. These are produced during remote installation of AGENT. Have you extensivelly used this type of task? Please verify there is no task running regurarly. I would also recommend to remove remote deployment task if no longer used, as it may help during database cleanup.

Regarding peaks during midnight - they are caused by database cleanups, during which are received logs not processed, and that is why mentioned queue grows. Seems DB cleanups are extremely slow, which may be caused by size of database or perfomance problems. What could possibly help is increasing RAM of machine - as you pointed out on screenshoot, there is no free ram during cleanup. I would also recommend to check other possible performance bottlenecks.

Regardless of previous, there is definitelly not as much data as is database size. To decrease size of database file, you need to shring database. I would recommend to consult this with manual for specific version of SQL Server you are using. In most cases, simple restart of DB may result in automatic shrink of database size.

 

 

Link to comment
Share on other sites

Guest
This topic is now closed to further replies.
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...