Kaseya Community

General Kaseya server performance best practices

  • All. 
    I did a bit of a search around but couldn't find a decent answer. 

    I have found the performance of our Kaseya server to have degraded over time.  Some times it really goes on major go-slows whilst other times its fine.  Its always pretty slow.  Watching performance monitors haven't really shown any avenues worth looking at.  The CPU and disks dont appear to being overloaded at the time. 

    Most of my issues appear to be with database reads.  For example, in "agent status" if I choose a particular machine group and view (say "all servers"), data appears quite fast.  However, if I choose "all groups" with the same view I will wait for a couple of minutes and then get a 'time-out' page. I have DB maintenance task that cleans up the indexes etc each night.  As far as I can see there arent any significant issues but performance says otherwise.

    Does anyone know of a quality document or article on where to start on setting up the server for the best performance?  What are common bottle-necks?   What do others do here?

    Thanks

  • Have you seen the Kaseya best practices guide? For some reason i can't attach PDF's here, so i uploaded it to SCRIBD

    (Don't shoot me Kaseya, i will remove this post if you tell me where to get this document on your website)

    http://www.scribd.com/doc/60390760

    This document helped us with performance stuff - other than that, there isn't a huge amount we have been able to do. 

    Kaseya support have done work for us in the past to clean / speed things up a bit.

    Hope it helps.  

  • I have noticed the same on our server, where resource monitor is showing significant disk activity reading the database.  Were you able to get an answer to this?

  • yeah, I logged a support call.  the guy who helped was very good.

    the long story short is that I messed the DB up.  A loooooong time ago I was trying to work around an old restriction so I setup some indexes in the db.  Unfortunately I forgot about them.  basically over many months this index got massive and slowed the DB down.  I removed all the indexes and all is well now.

    But one thing to note, make sure you don't keep lots of Procedure logs (or any other logs).  I had 60 days worth which was 18 million records in one table!!!  apparently it starts to have issues when it reaches around 2 million.  So cleaned that out and set it to 15 days.  

    All ok now.  just look for tables with massive amounts of data in them.

    J

  • You are right JD for future readers of this post.

    We keep logs for 7 days for some, 14 - or 30 at the most for others - if you don't review them any way other than instantly or over the course of a few days retention for that amount of time is pointless.

    That best practice guide is really good, but support is also a good option.

    In the new year i am due to decommission our Kaseya server in our data center. Going from a 12Gb RAM S2k3 box with a 32 bit OS to (initially) a 64gig RAM Dual processor S2K8 box and see what more we can push through the box

    I'd be interested to know if anyone here has clustered their Kaseya server with Microsoft Clustering services? I can see some serious performance benefits in doing it, with it Network load balanced it'd be an awesome setup. Don't want to hijack this thread so if anyone wants to pm me feel free.

  • No NLB support on the frontend yet, but SQL failover is possible.  We run our frontend/backend on a Hyper-V cluster.  The current limitation is Hyper-VR2's limit of 4 core dedication.  Other than that, things run fine.

  • A rule of thumb here is DISKS! Seen plenty of servers running K with lots of cores and a stack of RAM, but running on SATA disks and an old raid card or software raid (or no RAID!), it's not good enough, especially with a reasonable (1000 +) number of agents. Get some 15k SAS disks and good RAID if this looks like your server, and it will help. If you want confirmation then of course monitoring your disk I/O and queues will give an indicator if they are being overly stressed.

  • Along similar lines of the few previous threads disk performance is critical, as is the memory allocation. We are running a split front/back end on a clustered VMWare platform using a SAN. Our performance is great, but we did have some issues at first due to memory on the SQL server. We ended up allocating enough RAM to run the entire DB in memory and have not had an issue since.

    Also, here is the link to the 6.1 System Requirements:  help.kaseya.com/.../K2-System-Requirements61.htm