Kaseya Community

Massive Kaseya Database

  • I'm showing an obscenely large Kaseya Database.

    Database Location: Same machine as KServer Database Size: 2843.75 MB Size per machine:8.18MB Database File Path: C:\Program Files\Microsoft SQL Server\MSSQL\data\ksubscribers_dat.mdf Kaseya File Path: C:\Kaseya\
    I've tried defragging the database but it hasn't shrunk. We only have around 400 Machines under management.

    Any ideas?

    Cheers, Jason


    Legacy Forum Name: Massive Kaseya Database,
    Legacy Posted By Username: jasonjordan
  • How long are you keeping log files?

    Also do depending on how long you have had Kaseya and how many machines that not too big. Our database is at around 1.9gig.

    God Bless,

    Marty


    Legacy Forum Name: Server,
    Legacy Posted By Username: MissingLink
  • As the link states... your database is not that big.

    you probably have a lot of un-necessary information being stored for a long period of time.
    You can lower your data retention from whatever days you have to something less than 30 days.
    You can also stop logging every single thing that Kaseya does, and only log the stuff you need to know.
    Since this is a business process decision, you will need to make the choice of what you keep.
    If you are using the MSDE and not full blown SQL, then that would certainly explain your system being sluggish. You should also regularly defrag, and clean your database out.

    You should see a marked improvement.


    Of course here is the disclaimer....

    Many things factor into a database running slow, or a system running slow...
    It is up to you to determine if you have followed the recommended requirements, and are following the standard procedures.... things such as ram, hard drive speed, OS, bus speed, processor, blah blah blah....data retention, "excessive check-ins" a big one in my opinion, and other stuff... all factor into the performance of your system.

    I would change my check in times to be the following at a minimum.

    Workstations -5 min
    Servers -3 min.

    This step alone will siginificantly improve performance.... now do remember that using Kaseya is a philosophy, so you will have to NOT get into a HUGE hurry when you customer calls with " The Sky is falling, the SKY is falling", and take is slow and not get excited...

    your connections times using remote control will slow down a little bit as a result of this change, but your performance overall as a system will improve.

    Its all a balancing act.

    Gamer-X



    OF course... Gamer-X should read the post that says Massive Database, and DOES NOT say performance issues.......

    Maybe I should stick to the discussion.....
    I assumed that you were having performance issues since you were worried about your database getting so massive....
    I'm an idiot.




    Legacy Forum Name: Server,
    Legacy Posted By Username: Gamer-X
  • Jason,

    Just FYI, our db is at 10.9G for about 1400 agents. (7.74MB per machine) As SQL databases go, this really isn't massive, but we do have plans to separate our KServer from the SQL Server in the near future. And we have better plans for how to configure that SQL Server box to ensure maximum db performance.

    Can't wait for Kaseya to come out with their fault tolerant/redundant site functionality.

    Vince


    Legacy Forum Name: Server,
    Legacy Posted By Username: vplaza
  • Jason,

    Here's what we have:

    20018.75MB

    4590 agents

    4.46MB per agent






    Legacy Forum Name: Server,
    Legacy Posted By Username: bpenland
  • bpenland wrote:
    Jason,

    Here's what we have:

    20018.75MB

    4590 agents

    4.46MB per agent





    The Force is stong in this one. Smile

    Legacy Forum Name: Server,
    Legacy Posted By Username: vplaza
  • Smile

    Legacy Forum Name: Server,
    Legacy Posted By Username: bpenland
  • That is impressive indeed bpenland. Do you mind sharing what your KServer hardware setup is like for this beast?

    Thanx

    -Ed


    Legacy Forum Name: Server,
    Legacy Posted By Username: bellcpa
  • Front End Server:

    HP DL360

    Dual 3.4Ghz Xeon

    4GB RAM

    Mirrored 72GB 15k U320



    Back End Server:

    HP DL380 G4

    Dual 3.4Ghz Xeon

    6GB RAM

    Mirrored 72GB 15k U320 (System)

    Mirrored 146GB 15k U320 (Data)



    Front End and Back End servers are linked via cross over cable and all database calls go over that link.

    IO throughput is the most important performance characteristic. If you're building your environment for the future, my recommendation would be to invest inthe bestdisk controller you can buyand a large number of smaller/ faster drives.

    Hang ten,

    Bob


    Legacy Forum Name: Server,
    Legacy Posted By Username: bpenland
  • Does it make sense to goto something faster like Raid 10 for the data array setup or should a mirror be fine?

    bpenland wrote:
    Front End Server:

    HP DL360

    Dual 3.4Ghz Xeon

    4GB RAM

    Mirrored 72GB 15k U320



    Back End Server:

    HP DL380 G4

    Dual 3.4Ghz Xeon

    6GB RAM

    Mirrored 72GB 15k U320 (System)

    Mirrored 146GB 15k U320 (Data)



    Front End and Back End servers are linked via cross over cable and all database calls go over that link.

    IO throughput is the most important performance characteristic. If you're building your environment for the future, my recommendation would be to invest inthe bestdisk controller you can buyand a large number of smaller/ faster drives.

    Hang ten,

    Bob



    Legacy Forum Name: Server,
    Legacy Posted By Username: Coldfirex
  • When we moved our SQL DB from RAID5 to a RAID10 we noticed our disk access time was cut in half.

    -Ed


    Legacy Forum Name: Server,
    Legacy Posted By Username: bellcpa
  • This is what we had in mind when we separate SQL from our KServer.

    I am interested, however, in the idea of connecting the KServer to the SQL Server box via a crossover cable rather than going through the network switch. How do you force the KServer to make database calls only through that link? Do you specifiy the IP address of the SQL Server in the Kaseya configuration so you know all traffic is going through that NIC? It sounds like it could potentially be a faster connection to the SQL box than going through the switch.


    Legacy Forum Name: Server,
    Legacy Posted By Username: vplaza
  • We pointed the DB to the IP address assigned on the cross over link. So for the cross over we use bogus IP addresses 1.1.1.1 and 1.1.1.2.

    It wasn't really for performance reasons; it was to prevent that traffic from causing switch utilization issues. When we split the servers, we weren't sure how much data would be transmitted between those servers so we isolated it on a cross over.

    Coldfirex

    As far as the raid goes, there won't be a noticeable performance difference from RAID 0+1 to RAID 10. Try to avoid RAID 5 though (as bellcpa has pointed out).


    Legacy Forum Name: Server,
    Legacy Posted By Username: bpenland
  • bpenland wrote:
    We pointed the DB to the IP address assigned on the cross over link. So for the cross over we use bogus IP addresses 1.1.1.1 and 1.1.1.2.

    It wasn't really for performance reasons; it was to prevent that traffic from causing switch utilization issues. When we split the servers, we weren't sure how much data would be transmitted between those servers so we isolated it on a cross over.

    Coldfirex

    As far as the raid goes, there won't be a noticeable performance difference from RAID 0+1 to RAID 10. Try to avoid RAID 5 though (as bellcpa has pointed out).

    Great! Thanks for the info.

    Legacy Forum Name: Server,
    Legacy Posted By Username: vplaza
  • Also on the cross over cable idea you can also use VLANs and place those ports into a VLAN of there own so you limit broadcast packets. Not quite as good as NIC-NIC put can accomplish many of the same functions.

    God Bless,

    Marty

    vplaza wrote:
    bpenland wrote:
    We pointed the DB to the IP address assigned on the cross over link. So for the cross over we use bogus IP addresses 1.1.1.1 and 1.1.1.2.

    It wasn't really for performance reasons; it was to prevent that traffic from causing switch utilization issues. When we split the servers, we weren't sure how much data would be transmitted between those servers so we isolated it on a cross over.

    Coldfirex

    As far as the raid goes, there won't be a noticeable performance difference from RAID 0+1 to RAID 10. Try to avoid RAID 5 though (as bellcpa has pointed out).

    Great! Thanks for the info.



    Legacy Forum Name: Server,
    Legacy Posted By Username: MissingLink