Jump to content

Eset console runs very slow


Recommended Posts

Hey, Im using ESET Remote admin console and in our corporate environment the console runs VERY VERY slow. takes 5-15 minutes for basic tasks. Deploying a scan or ever a few minutes to have clicks register. in RPD's the resources are never over 50% and at the hyper visor level resources aren't over 50% Memory Disk and CPU. The console serves 1500~ clients, would this have to do with the lag we see? If so is there any way to improve the performance?

Link to comment
Share on other sites

Where is the database stored? (same machine or separate server?)

 

What OS does your server have?

 

How frequently are the agents set to 'phone home' to ERA?

Link to comment
Share on other sites

We're running far less clients - approx 160 - but everything in our console takes 1-2 seconds, so it may be the number of clients.

Our clients phone home every 60 seconds (at present) and we are running sql2014 in a VM on the same server as our eset VM. SQL is using virtual disks and we have 16gb ram assigned to it. The eset VM has 4gb assigned.

Out of interest, it's not perchance a Dell box with Broadcom network interfaces is it? If so, there are bugs in the dell drivers and you need to disable virtual machine queuing on the nic.

Jim

Link to comment
Share on other sites

  • Administrators

Its dynamic, the disk can grow as needed

 

That caused a performance issue for one of our largest clients. After moving the database to a virtual disk with static size, performance improved a lot.

Link to comment
Share on other sites

  • 1 month later...

While testing I discovered Microsoft SQL 2012 express ran significantly faster than Microsoft SQL 2008 express if it has adequate RAM.

 

 SQL version 2008 and older need fast storage to perform well.  2012 and newer tend to scale very well by just feeding them more RAM.  Another thing to note is just because the database engine itself is limited to 1GB of RAM does not mean that SQL 2012 can only consume 1 GB of RAM.   In reality it can consume/use 1.73GB of RAM between the engine and the other caching mechanisms.  

 

If you are stuck with SQL 2008 you can migrate the VMDK file to another lun and choose thick provisioning. Or if you are VMware Enterprise plus licensed you can add SSD cache to your host and have your database cached on SSDs.   

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