Kaseya Community

Post Your Kaseya Performance Graphs Here

  • The information is for comparative purposes 

     

    Agents Currently online 3097

    Total Licenses Used 4897

    Kaseya Version 6.1.0.0

    The VSA and SQL are on separate servers 

     

    Notes: The server was rebooted around the 9th

     

     

    * All times reference the ending time of each data bin.

     SQL Server Configurations 
     Physical Memory (Bytes)  17,179,402,240
     AWE Memory (Bytes)  0
     CPU Count  4
     Hyperthreaded Ratio  1
     Buffer Cache Hit Ratio (should be > 95)  99.99%
     Current Tasks waiting for CPU (Runnable Tasks Count Should Be Always Zero) 
     Scheduler ID   Current Tasks Counts   Runnable Tasks Count 
    0 5 0
    1 7 1
    2 5 0
    3 5 0
     Current Pending IOs (There should be none, if there are results, we have an IO issue) 
     Database ID   File ID   IO Stall   IO Pending (ms) 
    No records Found
     Current Lock/Blocks (Waiting more than 1 second; which is bad!) 
     Session ID   Wait Duration (ms)   Wait Type   Blocking Session ID   Resource Description 
    No records Found
     Database IO Distribution (for all databases on this instance) 
     Database Name   Total IO (MB) 
    ksubscribers 1,097,845
    tempdb 97,320
    mms 12,669
    ReportServerTempDB 61
    msdb 60
    ReportServer 23
    master 22
    model 5

     

  • Ours is very similar to yours, within 10% in most cases.

    What if your server configuration?  Are these physical or virtual servers?

  • They are virtual machines. could you post yours PLEASE .. you can just copy and paste the stats here.

  • We're running a much smaller system:

    Agents Currently Online: 803
    Total Licenses Used: 1,118
    Kaseya Version: 6.2.0.0

    The VSA and the SQL are on separate servers, with the VSA being a virtual machine.  Both were IPL'd on the 11th.

     SQL Server Configurations 
     Physical Memory (Bytes)  549,745,152,000
     AWE Memory (Bytes)  260,810
     CPU Count  64
     Hyperthreaded Ratio  16
     Buffer Cache Hit Ratio (should be > 95)  99.87%
     Current Tasks waiting for CPU (Runnable Tasks Count Should Be Always Zero) 
     Scheduler ID   Current Tasks Counts   Runnable Tasks Count 
    0 2 0
    1 4 0
    2 1 0
    3 1 0
    4 1 0
    5 1 0
    6 1 0
    7 1 0
    8 1 0
    9 3 0
    10 1 0
    11 1 0
    12 1 0
    13 1 0
    14 2 0
    15 3 0
    16 2 0
    17 3 0
    18 1 0
    19 1 0
    20 1 0
    21 1 0
    22 1 0
    23 2 0
    24 1 0
    25 1 0
    26 1 0
    27 1 0
    28 1 0
    29 1 0
    30 2 0
    31 3 0
    32 3 0
    33 3 0
    34 1 0
    35 1 0
    36 1 0
    37 1 0
    38 2 0
    39 1 0
    40 1 0
    41 1 0
    42 2 0
    43 1 0
    44 1 0
    45 1 0
    46 1 0
    47 3 0
    48 2 0
    49 2 0
    50 1 0
    51 1 0
    52 1 0
    53 1 0
    54 1 0
    55 1 0
    56 1 0
    57 1 0
    58 2 0
    59 1 0
    60 1 0
    61 1 0
    62 1 0
    63 3 0
     Current Pending IOs (There should be none, if there are results, we have an IO issue) 
     Database ID   File ID   IO Stall   IO Pending (ms) 
    No records Found
     Current Lock/Blocks (Waiting more than 1 second; which is bad!) 
     Session ID   Wait Duration (ms)   Wait Type   Blocking Session ID   Resource Description 
    No records Found


    [edited by: Bill Curnow at 4:11 PM (GMT -7) on 9-15-2011] Fixed grammer
  • That was VERY interesting

    2 points of interest

    1 our connections keep going up until a restart

    2 you also saw a massive increase in Locks at the same time as us. For us this brought the server to a stand still and we had to reboot. So it must have been a Kaseya update or something.

    Any one else want to share there performance  

  • ;) we tracking the lock issue very closely before we upgraded to K2, but honestly I haven't looked those numbers in over a year.  Back then the Kaseya maintenance process involved blasting and rebuilding the database schema every night.  The ksubscribers database also accounted for more active connections to the database than nearly all of our other systems combined (Kaseya is one of about 20 systems that use that database server).  I believe they've gotten a bit smarter with their nightly maintenance, but not much.  Database connections continue to be a problem.

    I obviously left out a couple of the tables (the Current Tasks waiting for CPU and Database IO Distribution tables were too long) but one thing I should have mentioned is that we're not using Kaseya's internal database backup system.

  • Dose anyone else want to join the fun and post their stats please

    Also this info can't be right ?

    SQL Server Configurations

    Physical Memory (Bytes) 549,745,152,000

    AWE Memory (Bytes) 260,810

    CPU Count 64

    Hyperthreaded Ratio 16

    Buffer Cache Hit Ratio (should be > 95) 99.87%

  • Yes, those are accurate numbers.  It's a Dell PowerEdge R910 with 8 quad-core CPUs.  We like to joke that it only has 1/2TB of RAM because our boss is cheap and didn't want to go for a full TB.

  • You are Dead to me

    Right so can some one  with realistic hardware post now ! lol

    oh and can i come work with you Bill

     

     

     

     

     



    [edited by: Michael Dixon at 2:39 PM (GMT -7) on 9-22-2011] l
  • Michael Dixon

    You are Dead to me

    Right so can some one  with realistic hardware post now ! lol

    oh and can i come work with you Bill

    This probably isn't the year to join the cotton industry.  Cotton production in TX is projected to be just 3M bales due to the drought, compared to 8M bales last year.  Sadly, that server is going to loaf this year... but there's always next year!

  • But everyone is missing the big question.  If you implement a Kaseya server with such staggeringly good hardware, is Kaseya still slow as heck to use at the browser????  or is it awesome?

  • jdvuyk can you post your stats please. You can simply copy and paste that page into the forum when using the rich formatting option.

  • I am literally in the middle of moving to a new server environment today/tomorrow.  So not a lot of point.  But I have found over the last couple of years that:

    1) It doesn't seem to matter how good your hardware is, in some situations the Kaseya is just slow at the browser.  This has been well documented by many.

    2) When I get periods of slowness the server appears to be doing very little.

    Im not too worried about going into an in-depth, I'm just curious.  Does a awesome server = awesome experience.  

  • he probably would know what we suffer so couldn't comment

  • Interesting stats guys.  I'd add mine but there's little point at the moment as most of our clients are still on one our 5.1 servers.  We have a 6.1 server but it's only got a few hundred agents on it at the moment.  Our biggest 5.1 has just shy of 11k agents on it and on a busy auditing day it slows down.

    What we did do was throw as many disks at the SAN as we possibly could and this improved things quite dramatically.

    Once we've got a few more sites installed I'll post our stats here too.