Kaseya Community

Kserver hard drives / performance

  • Hi,

    I am currently running a kserver (MSP Edition) with about 500 agents. Our old server kept killing hard drives as they were SATA 3 server grade drives. Now we replaced our server with a new one that has SAS 15k5 drives all in mirrors. Mirror1 for the OS, Mirror2 for the SQL database, Mirror3 for the SQL log files. We have all our MSP agents check in every 30 seconds.

    Our average transactions are about 15 per second.

    My questions: What kind of hard drives/check in configs are other kservers using. Any recommendations/real world experiences for kservers between 500 and 2000 agents.

    We would like to keep our 30 second check in, but we could change that if it is really needed.

    Thanks,
    Daniel

    Legacy Forum Name: Kserver hard drives / performance,
    Legacy Posted By Username: ddenhoed
  • Why do you need workstations to check in so often? It's a little overkill, but thats my own opinion.

    Currently, we have all servers to check in every 60 seconds and workstations check in every 2 minutes and I believe 2 minutes is fairly quickly compared to some other forum users.

    Legacy Forum Name: General Discussion,
    Legacy Posted By Username: LANWorx
  • we have our servers checking in every 10 seconds

    if i want to run a script i dont want to be sitting there for 2 mins waiting for something to happen...i want it done now

    in my mind, cost of hardware is a lot less than the cost of lost time/efficiency

    Legacy Forum Name: General Discussion,
    Legacy Posted By Username: tbone2345
  • I do like the 30 second check-in. Especially if I am waiting for a Remote Control session to establish.
    I would look more at what happens when Agents do check-in. Are agents pushing unfiltered Event Log entries to your kserver. Are the agents pulling software directly from your server or from a File Source on their local site. Is your server a repository for BUDR backups?? - How much load have you placed on your own server.

    Our kserver is a fairly ordinary P4 with mirrored 15k SCSI drives The System and SQL are all on the C: partition with 450 agents. As you can see, our config is NOT performance optimized but we don't really load it up and it performs well.

    Compared to your 15 we are averaging around 20 transactions, but I always look at this in relation to our performance baseline.
    If you suspect you are flogging your disks... I would pay attention to PhysicalDisk Average Queue Lengths.

    Legacy Forum Name: General Discussion,
    Legacy Posted By Username: garry
  • Garry,

    Our avg. disk queue length is around 0.1 to 0.2. Which is very decent. A few maximums going to 1.2. Which is very good. I think our system is keeping up fine, but what are the requirements when I hit 2000 agents. Do we have to look at HP c-class servers then? I don't know if $150K for a kserver is going to pay off.

    Legacy Forum Name: General Discussion,
    Legacy Posted By Username: ddenhoed
  • ddenhoed
    Garry,

    Our avg. disk queue length is around 0.1 to 0.2. Which is very decent. A few maximums going to 1.2. Which is very good. I think our system is keeping up fine, but what are the requirements when I hit 2000 agents. Do we have to look at HP c-class servers then? I don't know if $150K for a kserver is going to pay off.


    What scale are you using in Performance monitor for avg. disk queue length? The default is 100.00 but I know alot of people change this.

    Legacy Forum Name: General Discussion,
    Legacy Posted By Username: Coldfirex
  • It's my understanding that the checkin control no longer effects how quickly an agent will respond. I think it was the 4.8 update which included persistant connections from the kserver to the agent. This means that scripts should run immeditaly and not have to wait 30 sec or 1 minutes for the next quick checkin. We have all devices set at 1 minute.

    From the Kaseya Help:

    "Check-In Period
    Best Practices: The agent maintains a persistent connection to the KServer. As a result, quick check-in times do not effect response times from the agent. The quick check-in time sets the maximum time before re-establishing a dropped connection. Setting all your machine's quick check-in time to 30 seconds guarantees each agent recovers from a dropped connection within 30 seconds, assuming connectivity is successful."


    The performance of the kaseya server is really dependant on how much and how often you utilize the different features such as scripts, monitoring, alerts and logs. For example, How many monitoring sets are assigned to each machine? How many events and event logs are being monitored and/or processed? How long are you keeping logs? Are logs being archived? How often are patches scanned and processed? How many system checks are you running on how many servers? How often is lan watch run on how many machines? How many different SNMP monitor sets are being run on how many machines?


    To us, the kserver is one of, if not the, most important server we run so we want it to always be more powerful than necessary for our purposes. In my experience, I have found that the suggested server configuration by Kaseya supports about half their indicated machines. So their suggested configuration for 1000 is good for 500 machines and so on. We run a lot of scripts/monitoring/alerts so we split our kserver and sql server at about 1500 machines and got a huge performance boost.. We also saw increased performance when we switched from raid5 to raid10 for the data volumes.

    Legacy Forum Name: General Discussion,
    Legacy Posted By Username: cbnny