We've done a fair bit of checking on performance and it still looks like we have to buy a new machine which I don't like because I think a lot of this is poor programming.
- We run 2 servers in the configuration. App server is almost always idle. SQL Server runs typically between 60% and 80% and sometimes nails 100% and stays there. Yes this is certainly worse then it was on 6.2.
- If we reset SQL, the CPU will max out while it catches up on event logs and monitoring but will certainly work better after it catches up. And after 1-2 days slows down again. The slow down after a few days tells me they have something leaking.
- This happens regardless of what is happening with scripts.
- We have a report that shows the number of event log entries for the last hour for the top 30 machines. We only capture errors and warnings. If we see a machine with more then 100 entries, there is some performance issues. If we see a machine with more then 400 entries it nearly kills the SQL database.
- TEMP DB is the largest issue in SQL.
- We know KAM creates an SQL procedure that takes several minutes to run and always shows at the top of the list if you dig into the statistics of Kaseya. We leave KAM disabled fro this reason.
- @Eddy - If you are seeing only about 200 MB used for SQL, this is probably AWE. It's actually a fine way to run it normally. You need to go into Windows Performance Graphs and look at SQL Server Memory (Targetted Memory and Utilize Memory) I think they are called. This shows what SQL is actually utilizing. Task Manager shows what is available to other processes in this case assuming SQL will release that memory if required. The performance values will show you for that size of database what the targetted memory will be (typically = to the size of the database) and how much is utilized. If you have less utilized then the target, then you have a memory shortage.
- Looking at the SQL procedure execution times, we see a number of SQL processes taking sufficient amount of time to run. I wish Kaseya would put some focus on these procedures and give us a baseline on what they should be and what they do so that we could understand if we have problems in our database.
- We do see KLC connecting a little faster then 6.2 as long as everything is not overloaded.
- We regularly get messages that our KServer is overloaded.