Does anyone have any tips to get a better response when browsing pages in Kaseya?
We're on the latest build/patch.
I use Firefox and I find browsing between modules just seems to be so slow.
Server spec is decent too as we just migrated to a new server.
I've recently cleared logs (reduction to 14 days of logging and shrunk SQL database to 20GB)
At the moment i've disabled LAN watches and patch updates to no avail.
Can you share with me how many end points that you have and what is your current hardware setup for the VSA? do you have one server or 2 servers
A 20 GB database with 14 days of logging should work out near 2000 agents? That could certainly benefit from splitting one server into two. So, do you see any bottlenecks on your Kaseya server(s), high CPU, Memory.
And what do you consider to be slow? I've got a 2, 3 second wait, and we've had that consistently, when I switch modules in our setup and our servers are definitely not slow. It's about the same for IE and Chrome, so that's not the issue here.
We have just over 7000 agents and run a SQL server separate from our VSA server on VMWare with Nimble SAN hardware. Our SQL server has 36 GB (for a 60 GB database) and 4 CPU's. Our VSA has 16 GB and 8 CPU's. We don't run LAN watches, but do run the old Patch Management and run fairly frequent Audits, which can have some impact. If you want, Kaseya can assist in working out what is slowing you down and maybe they'll tell you it's normal.
we have 1075 agents at the moment.
The KServer is a VM on a Dell PowerEdge R430.
VM runs on a RAID1 with 2 x 2TB SAS 16Gbps HDDs.
CPU is an Intel Xeon E5-2640 v3 and i've given the VM 4 CPU and 32GB RAM.
It is just one server, Server 2016 Std with SQL 2017.
it is all about how it is configured, Check few things:
-Agent log history retention
-Network monitors, scans etc
-Event logs collection threshold
-while assigning alerts and monitors, don't select create Alarms/Create Tickets for every agent.
I've got a support ticket open with Kaseya already. Due to the time difference responses are slow.
We seem to have a mismatch of schedules here. We had audits scheduled daily and weekly.
I've cancelled all audit schedules.
Agent logs are 14 days, Procedure logs are 21 and remote control logs are 90 days.
We only have 3-6 event logs alerts set up on servers notifying on backup failures and stuff. Is that what you meant? We have 137 servers. None of the alerts are set to create alarms, just to email.
Our MSP Practice manages 3400 agents on a VSA Hyper-V Guest with 4 cores and 12GB of RAM and lopes along using about 9-12% CPU load. SQL is 8 cores and 16G RAM and typically runs < 15% CPU load. Actual memory demand on these systems are 4G and 8G respectively.
We build VSA platforms for our customers with a very specific optimization process that distributes the I/O load based on performance analysis that we did on an earlier VSA platform. Old platform had SATA SSDs, new has 7.2K RPM SAS disks - same array format, MUCH faster performance overall. (10G iSCSI storage). You can read our Best Practice Guide for VSA in the Downloads / Documents section of our website.
DON'T put everything on a large C: drive! #1 way to put performance in the toilet.
DON'T use SATA drives (even SSD) as they're a major performance bottleneck in multi-threaded apps.
DO distribute your load - Separate your SQL above 1000 or so agents; use multiple disk volumes for the high-transaction places within VSA and on your SQL server; add a separate disk for O/S Paging; and set the min/max size of all pagefiles to the same (fixed size) with a minimal pagefile on C: for core dumps and memory management only.
Poorly configuring the settings in VSA will also dramatically affect performance. Patch Scans more than weekly, Audits run daily (or more!), scheduled discoveries (any, except during onboarding!), and log retention periods (>7 days for EVT and most others, >30 days for procedures, >365 days for remote control logs) will all contribute to performance degradation without providing any benefit.
This is how we set up our MSP customers for the bulk of their agents. There may be a special situation or two, but how you define your base settings is what will set the tone for performance overall.
Thanks for this reply.
We do indeed have one large partition. Would adding a second disk and moving the SQL database and logs to this drive increase my performance?
Although we have approx 1100 agents, there are about 700 online at one time.
Out of curiousity how often do you run your patch scans, audits, network discoveries and log retension? Is it what you said above?
Regarding disk, you should read the Tech Brief - Optimum VSA Storage Layout document on our website. In a shared VSA/SQL platform, we would typically deploy 11 distinct disk volumes - C:, D: (app root), and P: (paging), plus 5 mounted volumes for VSA and 3 for SQL. These are LUNs, not partitions from a single LUN! Just adding a second large disk likely would not help much.
Our patch scans run every Monday from midnight to 6 AM for servers and between 10 AM and 4 PM for workstations. Patch scans should never be scheduled during the same times that you deploy patches. We patch workstations around 2-4 AM Thursdays. Servers are assigned very specific start times between midnight and 11 PM on the third, fourth, or first weekend each month for monthly updates. Customers manage this scheduling through an Excel spreadsheet, which defines the schedule (day/time) and controls the pre/post patch reboots.
We run "Latest" audits monthly and distribute them over 7 days. We provide MSPs with a much more efficient/effective audit that directly drives the automation. This tool takes just seconds (7 to 40-ish seconds depending on CPU) to run and update Kaseya. These run daily, collect over 150 data points, are customizable, and bring about 35-40 values back into custom fields for reporting and automation. (Some MSPs bring back additional data for reporting or custom automation, but our standard collection is 35 values.)
We NEVER recommend running scheduled discoveries except during the first few days when onboarding a new client. It's one-click if you need an update. We use KNM for server status monitoring (see my blog - Agent Offline is NOT Server Down!) and repeating scans just fills the KNM with workstations that you don't need to monitor this way.
This is the tip of the iceberg of optimizing and automating VSA. Standards for operation are essential. We lock down access to Master/System role to just one or two users, and restrict roles to very specific needs (see the Tech Brief - VSA Security Roles) to prevent admins from changing core VSA settings. We don't recommend allowing admins to create and run their own procedures. We encourage them to create procedures, but they have to follow a standard, go through a code review, and then we make the procedure available to all the techs. More info about this on my blog.
You can see more of what we do on our website in the RMM Suite section. Our user guides are published and provide good insight to effective operation. You'll see from the "Regular Maintenance Tasks" that our MSPs spend less than 90 minutes a month administering their VSA.
I'm having a read of that document which is very helpful so thank you.
im going to move to get mores drives and split it all up.
one thing I have to ask about. A new drive for each VSA folder is that really neccessary?
In our performance testing, those were the folders where we saw consistently high I/O. Having a 1:1 physical to logical relationship for storage provides a tremendous performance boost compared to using a single disk with partitions. You're allocating the same amount of total storage, you're just using several smaller volumes (and distributing the I/O load) across them. It's a one-time setup pain - especially if retro-fitting an existing VSA, but the long term gains are worth it. Also - we've needed to increase storage as profiles or Software Management library has grown, and this makes it very easy to accomplish.