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.

You have posted to a forum that requires a moderator to approve posts before they are publicly available.

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.

Basics?

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.

Glenn

You have posted to a forum that requires a moderator to approve posts before they are publicly available.

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.

Glenn

You have posted to a forum that requires a moderator to approve posts before they are publicly available.

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.

Glenn

You have posted to a forum that requires a moderator to approve posts before they are publicly available.