Beruflich Dokumente
Kultur Dokumente
And
Best Practices
Guide
1|Page
Contents
Introduction .................................................................................................................................................. 5
B.0 - The Basics.............................................................................................................................................. 6
B.1 - Hot Fixes ........................................................................................................................................... 6
B.2 64 bit versus 32 bit OS and SQL Server. .............................................................................................. 6
B.3 - System Requirements ....................................................................................................................... 6
B.4 - Browsers and workstations make a difference ................................................................................ 7
B.5 – Please, distribute your scripts! ........................................................................................................ 7
B.6 – My scripts are distributed but why are they all running in the morning! ....................................... 8
B.7 – The Statistics Hidden Link ................................................................................................................ 9
M.0-Memory ............................................................................................................................................... 10
How to monitor memory ........................................................................................................................ 10
M.1-Processes ......................................................................................................................................... 10
M.2-64 Bit Operating System .................................................................................................................. 11
M.3-32 Bit /3GB in the boot.ini............................................................................................................... 11
M.4 Memory Best Practices .................................................................................................................... 11
C.0 - CPU...................................................................................................................................................... 12
C.1 - Microsoft Reporting Services ...................................................................................................... 12
C.2 - KaseyaMessageSys...................................................................................................................... 12
C.3 – w3wp .......................................................................................................................................... 13
C.4 - Kaseya Add-ons ........................................................................................................................... 13
C.5 - Larger number of files on servers and workstations .................................................................. 13
C.6 - Log Archive duration ................................................................................................................... 13
C.7 – IIS Compression .......................................................................................................................... 13
C.8 – DEP ............................................................................................................................................. 14
N.0 - Network .............................................................................................................................................. 15
N.1 – IIS Compression ............................................................................................................................. 15
N.2 – Plan Network Utilization ................................................................................................................ 16
N.3 – Network Utilization for Service Desk ............................................................................................. 17
IO.0 – Disk Performance (IO) ...................................................................................................................... 18
IO.1 – Kaseya IO Hot Spots...................................................................................................................... 18
Windows Paging.................................................................................................................................. 18
2|Page
\Kaseya ................................................................................................................................................ 18
SQL Server TempDB ............................................................................................................................ 18
SQL Server Database and Logs ............................................................................................................ 18
IO.2 – Monitor your IO ............................................................................................................................ 19
Avg. Disk Queue Length ...................................................................................................................... 19
Avg. Disk Sec/Read and Avg. Disk Sec/Write ...................................................................................... 19
V.0 - Virtualization with ESX........................................................................................................................ 20
How to monitor resources under VMWare ESX ..................................................................................... 20
V.1-VMWare ESX Memory Configuration ............................................................................................... 21
V.2-VMWare ESX CPU Configuration Reservations ................................................................................ 22
V.3-VMWare ESX CPU Configuration Limit ............................................................................................. 25
V.4-VMWare ESX VMWare tools up to date? ......................................................................................... 25
F.0 - Federation of Servers .......................................................................................................................... 26
F.1 – Single versus Dual Servers .............................................................................................................. 26
F.2 – Reporting Database Servers ....................................................................................................... 26
A.0 - Add-On Performance Tips .................................................................................................................. 27
A.1 - Service Desk .................................................................................................................................... 27
Performance and Best Practices Check List ................................................................................................ 28
B -The Basics ........................................................................................................................................... 28
M-Performance Checklist for Memory ................................................................................................... 28
C-Performance Checklist for CPU............................................................................................................ 28
N-Networking .......................................................................................................................................... 29
IO-Disk Performance (IO) ........................................................................................................................ 29
V-Performance Checklist for Virtualization with ESX .............................................................................. 29
F-Federation of Servers ........................................................................................................................... 30
A-Add-On Performance Tips ................................................................................................................... 30
Appendix A – Monitor Sets ......................................................................................................................... 31
CPU .......................................................................................................................................................... 31
CPU – Reporting Services .................................................................................................................... 31
CPU – Kaseya Messagesys................................................................................................................... 31
CPU – w3wp IIS Workpool Process ......................................................................................................... 32
CPU – SQL Server Process ....................................................................................................................... 32
3|Page
Disk IO ..................................................................................................................................................... 33
4|Page
Introduction
If you are running Kaseya Version 5.x or previous versions and are close to maximizing your CPU,
Networking and/or IO resources, don’t expect Version 6.x (K2) to run similarly on the same
infrastructure. We hope this guide will help you with your planning on upgrading or a new install of
Kaseya K2. Please remember that the Minimum Requirements on the Kaseya Support Site is based on
an average. Every customer is different and your mileage will vary.
Kaseya is an enterprise application that requires specific hardware and software requirements in order
to run effectively. These requirements include a database and IIS server(s), a network capable of
handling agent traffic and a client platform and browser to present the user interface.
In addition, it is helpful to understand that every environment that is running Kaseya is different. There
are many variables that will impact the performance of your Kaseya installation. The recommended
requirements on our web site are a general guideline based on measures taken on multiple customer
environments. The purpose of this document is to help you give your Kaseya Environment a Health
Check by looking at various areas of performance and providing a checklist of items to review to
implement best practices as it pertains to performance.
This document will go over the various areas of performance with recommendations of best practices
where appropriate. Each of the sections are labeled in a way that they can be easily be referenced from
the Performance Check List which is in the last section of this document. The sections covered in this
guide are:
The Basics
Memory
CPU
Network
IO
Virtualization
Federation of Servers
Add-On Performance Tips
o Service Desk
Performance Check List
5|Page
B.0 - The Basics
Some customers choose not to have this feature enabled. In this case, you should review this
periodically and if you are experiencing performance issues, it’s best to apply all hot fixes before
contacting support.
Keep in mind that these requirements can vary based on many variables such as:
Number of audits
Number of patch scans
Number of KES scans
User/Sample scripts
Reporting
Log History
Agent History
Script distribution
It is therefore important for you to monitor your environment at all times and preferably with a Kaseya
Agent. This way, you can monitor, track and alert when resources are constrained like CPU, Disk IO,
6|Page
Memory, SQL Server Locks, etc… Kaseya provides sample monitor sets as well as a NOC service that can
monitor these for you. Please feel free to contact our NOC services for more details on this service. As
we work with many clients, we constantly update our monitor sets to insure best practices in terms of
monitoring the Kaseya solution.
7|Page
audits start. You will see CPU, Network bandwidth and IO all spike.
With high IO, Network and CPU, agents may fail to check in. Then alerts will occur and
exasperate the situation.
With high IO, Network and CPU, your UI will slow to a crawl.
B.6 – My scripts are distributed but why are they all running in the morning!
Another issue that is seen with script scheduling is that many companies are going Green. Servers and
PC’s may be turned off
during the night. If Patch
Scans and Audits are
distributed and set to
run at night, they may
be queued until
everyone in the
company comes in to
startup their machines.
So, if you are
experiencing this, check
out your statistics in the
System->Statics tab.
Note how high your CPU
is running and then look
at the tops scripts that
have run in the last hour.
If it appears that there
are more scripts that
have run than what you
set as an hourly
distribution, you may be
running into this
scenario. Consider
increasing your CPU,
Networking and IO to
address this. Kaseya
minimum requirements
are based on an average
over 24 hours assuming
an incremental audit and
patch scan a day.
8|Page
B.7 – The Statistics Hidden Link
On very useful feature is the hidden link to view
server historical statistics. This link is located on
the System->Statistics page on the box with the
heading starting with “Statistics collected at”.
This is the hidden link. Click this to bring up the
historical statistics page. Here, you can review
historical graphs that provide very useful
information on the number of scripts run, CPU,
etc…
9|Page
M.0-Memory
M.1-Processes
You must have enough memory to
support five of the most memory dependant processes in a single physical Kaseya Server environment.
These processes are:
KaseyaMessageSys
W3wp (IIS Workpool)
Kserver
MS Sql Server
MS Sql Reporting Services
In Kaseya V6, the KaseyaMessageSys.exe is a new process that will allow Kaseya to scale with future
versions and works closely with Microsoft Message Queuing. In addition to this, Version 6 also adds
Microsoft Report Services.
KaseyaMessageSys can use 380 meg. of RAM for a small implementation of Kaseya (0-250 end points) to
more than 1.2 Gig. Of RAM for larger installations (2500 or more end points).
In addition to KaseyaMessageSys, the new Kaseya UI requires more RAM from IIS (specifically, the IIS
workpool process called w3wp). This process can use 250 Megabytes for a small implementation to 700
Megabytes or more for larger implementations.
Kaseya also utilizes Microsoft Reporting Services which will add additional memory pressure for your
instances. Small instances can use 160-200 Megabytes while larger systems can use even more. It’s not
unusual for this process to grow to 1.3 Gigabytes or more.
10 | P a g e
If you currently are running Kaseya V6, these memory requirements must be considered and addressed
when you are ready to upgrade. Especially on systems that are running low on memory resources
already. It is easy, therefore, to add another 800 Megabytes to a small system just for the new Kaseya
V6 release. For larger implementations, 2Gigabytes in additional RAM is not out of the question and
highly recommended.
Also consider that Windows 2008 uses more RAM just to run. Its requirements are even more than
previous versions of windows. Typically, you should allocate at least 2 Gigabytes of RAM for the
operating system alone.
If you are limited to 32 bit systems and 4Gig of RAM, you should consider splitting the server into an
application and database server. This will at least allow more RAM to both the database server and the
application server.
Sqlserver.exe
W3wp.exe
KaseyaMessageSys.exe
ReportingServicesService.exe
KServer.exe
11 | P a g e
C.0 - CPU
CPU utilization can vary based on many variables; however, with K2 you must plan to allocate more CPU
than previous Kaseya Version 5 implementations for the same number of end points managed. This is
due to the additional functionality of the back-end database and front-end. New processes, like Kaseya
MessageSys and Microsoft Reporting Services will require CPU resources as well.
more information, please see the Appendix section for more detailed information and the XML to
import this monitor set into your own environment.
C.2 - KaseyaMessageSys
This process will allow future versions of Kaseya to scale in terms of the number of endpoints. It works
closely with other Kaseya modules and internal processes. In terms of CPU, this process may use
between 5-10% of a core. If you install the Kaseya Service Desk, you may find this process using more
CPU. The best practice is to monitor this process as well using the monitor set described in the appendix.
12 | P a g e
C.3 – w3wp
This is the IIS work pool process. It should be monitored since it is second to SQL server in terms of CPU
resource consumption. This process will consume more resources based on the number of
administrators on your system and is also impacted by the Service Desk Add-on.
Application Server: Number of named users that will access the Service Desk * 15Mhz
Database Server: Number of named users that will access the Service Desk*35Mhz
Just add the two above if this is a single server install. For example, if you know you will have 50
users accessing the Service Desk Add-on, you should have the following additional CPU
resources added to the Kaseya Minimum requirements:
For a single Kaseya Server, just add them together. In this case, we come up with 2500Mhz. So a
good rule of thumb is about 50 named users supported by one 2.4Mhz Core of CPU.
13 | P a g e
available, it is best to create a baseline on your CPU utilization and then slowly increase compression
levels until a good balance is reached with existing CPU resources and improved page performance.
C.8 – DEP
DEP is a new feature for Windows 2008 and Windows 7. It adds logic to prevent execution of programs
in memory regions and by default is turned on for all programs in Windows 2008. This does affect CPU
and we recommend setting this to “Turn on DEP for essential Windows programs and service only”. You
can access this setting by left clicking “Computer” properties and then select advanced options. Then
select Settings from the Systems Properties window and then select the “Data Execution Prevention”
tab.
14 | P a g e
N.0 - Network
Just like CPU, networking will vary based on the number of scripts run, audit scan detail, Kaseya Add-on
products, etc… It is important to monitor this carefully since Kaseya Version 6 will require more network
bandwidth than previous versions of Kaseya. Where this is most evident is in the Kaseya UI.
The Kaseya UI now is based on Java AJAX and JSON. These technologies bring a feature rich experience
to the end user. It is very much like a windows application versus a HTML based application. These
features, however, require more networking bandwidth in order to run well.
15 | P a g e
Then check the Enable dynamic and static Content compression on the default website as well as the IIS
Home. Please note that IIS 7.0 will stop compression if the server is starving for CPU. IIS 6.0 will not. Be
sure to monitor CPU utilization on the server before and after this setting to insure the impact isn’t
excessive.
16 | P a g e
Naturally, you should plan for peaks. For example, even though a T1 can handle 5000 agents in an
average install, if you’re limited to an 8 hour windows versus 24 hours to run audits and high bandwidth
scripts, you may need the capacity to support peaks that are three times the average in the tables
above.
Number and size of managed files that may be distributed to/from your servers/workstations
Customers may send managed files of various sizes to all of their endpoints. Some even
bring files back to the Kserver. This all will require bandwidth to manage effectively.
Number of administrators that will be using Kaseya to manage and monitor their respective
environments
The number of administrators makes a difference overall on Kaseya Servers. If you have
many of them running dashboards, using the UI extensively or using Service Desk, you
should plan on acquiring more network bandwidth.
Distribution of Scripts
This is described in another section above, but does affect network bandwidth as well.
Trying to run too many scripts at a time can cause network saturation
30 Lines Per
Page
17 | P a g e
IO.0 – Disk Performance (IO)
Just like Networking and CPU, disk IO is varies widely between Kaseya installs even when the same
number of endpoints are managed by different customers. Again, this can be due to many factors such
as the number and type of audits, patch scans, number and type of scripts, etc… The recommended
minimum configurations provided on the Kaseya Web Site should be adequate for most Kaseya
installations. It is difficult to predict what your disk IO loads will be but the following best practices
should help you understand and address any IO issues.
Windows Paging
If memory is low, invariably, paging will occur and could cause quite a bit of IO to the paging file.
Almost always, this is on the root drive of a windows installation (C:\). This causes disk
contention with Kaseya and SQL Server if they too are on the same physical disk (or array) as the
paging file. Consider adding memory to reduce paging or moving the paging file to another
device. In some installs of Kaseya, the c:\ is left to just the OS and paging while another set of
drives contain the Kaseya installation thus distributing the IO more effectively.
\Kaseya
The Kaseya install directory is not static. Depending on the size of your installation, the drive
that contains the Kaseya application installation should be monitored for optimal IO; Even if you
put your database files on another set of drives. The Kaseya service receives many files from
agents and processes those files in this directory. These files mainly take the form of XML
documents with detail information from tasks such as audits and patch scans. These files are
processed before they are saved in the database. Depending on the number and size of the files,
IO to this path can become heavy.
18 | P a g e
IO.2 – Monitor your IO
One of the best practices you can do for your Kaseya environment is to monitor your IO. Fast reads and
writes to physical disk are critical for SQL Server and Kaseya performance and you should install an
agent on your Kaseya application and database server to monitor Disks. All volumes should be
monitored with the following counters:
19 | P a g e
V.0 - Virtualization with ESX
Customers who use ESX server should plan resources accordingly for Kaseya VM’s. In this section, we
will cover best practices for Memory, IO and CPU. In some cases, you may be hosted by vendors using
ESX. These recommendations should help in that situation as well.
20 | P a g e
V.1-VMWare ESX Memory Configuration
VMware allows multiple Virtual Machines to share resources such as memory and CPU. Under certain
conditions, memory can be over allocated on the ESX server, but the VM will not indicate this through its
own resource monitoring. To the VM, it may think it has plenty of memory. The issue is that the ESX
server may be paging memory to its own paging file impacting the performance of the underlying VM
running Kaseya. To keep this from happening, insure that Virtual Machines that are running Kaseya have
enough reserved memory allocated to the VM. Typically, you should reserve at a minimum 2gig of RAM
for small installations and in larger, you should do 50% or more the VM’s memory. If the servers are split
as an application server and a database server, you must still reserve memory to both for best
performance.
As shown below, the VM Memory object has a counter called “Memory Reservation in MB”. If this is set
to zero (like it is below), it is possible that the VM’s memory could be swapped to disk by the ESX host.
Adjust or request that memory be reserved for your VM. Another counter called “Memory Swapped in
MB” can indicate this condition. In any case, please allocate memory reservations to a single Kaseya VM
or to both VMs if you have split your Database and Application Servers.
21 | P a g e
V.2-VMWare ESX CPU Configuration Reservations
Just like memory, ESX allows VMs to share CPU. And just like memory, you need to insure that dedicated
CPU cycles are reserved for single or dual server implementation of Kaseya. This is critical because
inconsistent CPU will always lead to unexplained performance issues. On ESX 4.0 server VMs, use the
VM Processor object to monitor CPU Performance. Here look at the CPU “Reservation in Mhz” and see if
it’s set to zero as shown below. If it is, your VM can be starved of CPU cycles from the ESX host. Again,
you need to allocate enough CPU reservations to satisfy the load of a single or dual Kaseya VM
implementation.
22 | P a g e
How can you determine if you’re starved of CPU cycles? Use the “Effective VM Speed in Mhz” counter.
This counter will show how many cycles a VM is using in Mhz. In this example, you will see that this VM
has four virtual cores.
If you select the “Host Processor Speed in Mhz” counter, it will show that the host processor runs at
3000Mhz (or 3GHz). Technically, this VM if given unlimited CPU cycles from the ESX host, should have
4x3Ghz or 12Ghz total of “Effective VM Speed” (or 12,000Mhz). In the example below, you will notice
that there are times that the VM’s CPU is at 100%, however, this would indicate that all 12,000 Mhz was
being used to get to 100%. In reality, the VM was only getting 5077Mhz maximum as shown in the
Effective VM Speed counter below. This indicates that the VM is being starved of CPU and reservations
should be allocated to this server.
23 | P a g e
One reason that this server is being starved of CPU is it could be limited in how many CPU Mhz it
receives. This is explained in the next section.
24 | P a g e
V.3-VMWare ESX CPU Configuration Limit
Even though a VM may appear to have multiple cores, there still can a limitation on how much CPU
cycles are given to those cores in total. How can you tell if you are being limited in CPU? Just check the
“Limit in Mhz”. This should never be below the recommended total CPU Mhz based on Kaseya minimum
requirements.
25 | P a g e
F.0 - Federation of Servers
This configuration requires that you have a separate application server and two database servers.
26 | P a g e
A.0 - Add-On Performance Tips
27 | P a g e
Performance and Best Practices Check List
B -The Basics
Section Item Yes/No
B.1 Did you apply all hot fixes to your environment to ensure all
performance hot fixes have been applied?
B.2 Did you upgrade your OS and SQL Server to 64 Bit for K2?
B.3 Did you check to make sure Minimum System Requirements are met?
B.4 If browsers are slow, are you using Firefox over Internet Explorer?
Is the workstation under powered to run Java to render the Kaseya
UI?
B.5 Review your script distribution. Is it even?
B.6 Are all of your end-points powered on to make script distribution a
benefit?
B.7 Do you check the statistics page periodically to review script
distribution, CPU utilization, etc.
C.2 KaseyaMessageSys - Did you create a monitor set for this process?
Review this periodically and adjust CPU resources if needed.
C.3 W32p – Did you create a monitor set for this process? Review this
periodically and adjust CPU resources if needed.
C.4.1 Kaseya Add –ons: Are you adding KES to your install? If yes, increase
your CPU requirements 10%.
C.4.2 Kaseya Add-ons: Are you installing Service Desk to your install? If yes,
28 | P a g e
use the following formula to calculate additional CPU requirements.
Just add the two together for single Kaseya Server.
C.8 Is DEP set for just essential Windows programs and services?
N-Networking
Section Description Yes/No
N.1 IIS Compression. If you have CPU resources, try installing and setting
up compression to help with bandwidth issues. Remember, this
creates more load on the CPU based on the compression you’re
using.
N.2 Did you plan for WAN network requirements for your
Implementation?
N.3 Did you plan for additional network requirements for Service Desk?
29 | P a g e
you split them into a Database and Application Server, did you still
reserve memory in ESX for both?
V.2 Did you allocate reserved CPU to your Kaseya implementation? If you
split them into a Database and Application Server, did you still
reserve CPU in ESX for both?
V.3 Is your VM being limited in Mhz? Make sure it has enough CPU in
Mhz to run Kaseya in both a single and dual VM configuration.
V.4 Is VMWare tools up to date?
F-Federation of Servers
Section Description Yes/No
F.1 If you plan to have more than 5000 agents, are you using two physical
servers?
F.2 If your reporting needs are heavy, did you plan to have a separate
reporting database server?
30 | P a g e
Appendix A – Monitor Sets
The following monitor sets can be imported into your Kaseya Version 6.x environment by just pasting
them into your monitor set import tool. Depending on your environment, you may want to change the
parameters to “tune” them; however, they should provide a good base to develop your capacity models.
Kaseya also uses these monitor sets for its TI Management services as well.
CPU
These monitoring sets will help with CPU utilization of the major CPU consumption processes on a
Kaseya install. Depending on the number of servers in your Kaseya environment, some of this will not
apply. For example, where the database is a separate server, you would not use the SQL Server process
utilization monitor set. In addition, the CPU in these monitor sets can exceed 100%. Don’t confuse this
with total CPU utilization of a system. For example, a four core server with reporting services taking up
two cores at 100% will read 200% in these measures. If reporting services was using all cores at 100%,
you will see the measure report 400%.
These are useful in terms of trending as well as providing some feedback to support like a process that
may be taking more resources suddenly.
31 | P a g e
<Counter name='Messagesys Processor Time' description='null' counterObject='Process' counter='%
Processor Time' counterInstance='KaseyaMessageSys' counterSampleInterval='60'
collectionOperator='Over' collectionThreshold='0' trendTimeSpan='1209600' trendReArm='3600'
thresholdOperator='Over' thresholdAmount='98' thresholdDuration='5' thresholdWarning='10'
thresholdReArm='600'/>
</Counters>
<Services>
</Services>
<Processes>
</Processes>
</MonitorSet>
</monitor_set_definition>
32 | P a g e
</MonitorSet>
</monitor_set_definition>
Disk IO
This monitor set should be used on each volume that houses your OS paging file, Kaseya install
directory, database data, log and tempDB. The monitor set below assumes that everything is on the C:\.
You can import this monitor set and clone it for additional drives in your installation. You should change
the Disk Queue Length measure to reflect 2x the number of physical drives in your disk device. This also
assumes your using an agent to monitor the Kaseya server(s).
33 | P a g e