Kaseya Performance And Best Practices Guide

Transcription

Kaseya PerformanceAndBest PracticesGuideAuthors:Date:1 PageJacques Eagle Thursday, April 29, 2010

ContentsIntroduction . 5B.0 - The Basics. 6B.1 - Hot Fixes . 6B.2 64 bit versus 32 bit OS and SQL Server. . 6B.3 - System Requirements . 6B.4 - Browsers and workstations make a difference . 7B.5 – Please, distribute your scripts! . 7B.6 – My scripts are distributed but why are they all running in the morning! . 8B.7 – The Statistics Hidden Link . 9M.0-Memory . 10How to monitor memory . 10M.1-Processes . 10M.2-64 Bit Operating System . 11M.3-32 Bit /3GB in the boot.ini. 11M.4 Memory Best Practices . 11C.0 - CPU. 12C.1 - Microsoft Reporting Services . 12C.2 - KaseyaMessageSys. 12C.3 – w3wp . 13C.4 - Kaseya Add-ons . 13C.5 - Larger number of files on servers and workstations . 13C.6 - Log Archive duration . 13C.7 – IIS Compression . 13C.8 – DEP . 14N.0 - Network . 15N.1 – IIS Compression . 15N.2 – Plan Network Utilization . 16N.3 – Network Utilization for Service Desk . 17IO.0 – Disk Performance (IO) . 18IO.1 – Kaseya IO Hot Spots. 18Windows Paging. 182 Page

\Kaseya . 18SQL Server TempDB . 18SQL Server Database and Logs . 18IO.2 – Monitor your IO . 19Avg. Disk Queue Length . 19Avg. Disk Sec/Read and Avg. Disk Sec/Write . 19V.0 - Virtualization with ESX. 20How to monitor resources under VMWare ESX . 20V.1-VMWare ESX Memory Configuration . 21V.2-VMWare ESX CPU Configuration Reservations . 22V.3-VMWare ESX CPU Configuration Limit . 25V.4-VMWare ESX VMWare tools up to date? . 25F.0 - Federation of Servers . 26F.1 – Single versus Dual Servers . 26F.2 – Reporting Database Servers . 26A.0 - Add-On Performance Tips . 27A.1 - Service Desk . 27Performance and Best Practices Check List . 28B -The Basics . 28M-Performance Checklist for Memory . 28C-Performance Checklist for CPU. 28N-Networking . 29IO-Disk Performance (IO) . 29V-Performance Checklist for Virtualization with ESX . 29F-Federation of Servers . 30A-Add-On Performance Tips . 30Appendix A – Monitor Sets . 31CPU . 31CPU – Reporting Services . 31CPU – Kaseya Messagesys. 31CPU – w3wp IIS Workpool Process . 32CPU – SQL Server Process . 323 Page

Disk IO . 334 Page

IntroductionIf 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 sameinfrastructure. We hope this guide will help you with your planning on upgrading or a new install ofKaseya K2. Please remember that the Minimum Requirements on the Kaseya Support Site is based onan average. Every customer is different and your mileage will vary.Kaseya is an enterprise application that requires specific hardware and software requirements in orderto run effectively. These requirements include a database and IIS server(s), a network capable ofhandling 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. Thereare many variables that will impact the performance of your Kaseya installation. The recommendedrequirements on our web site are a general guideline based on measures taken on multiple customerenvironments. The purpose of this document is to help you give your Kaseya Environment a HealthCheck by looking at various areas of performance and providing a checklist of items to review toimplement best practices as it pertains to performance.This document will go over the various areas of performance with recommendations of best practiceswhere appropriate. Each of the sections are labeled in a way that they can be easily be referenced fromthe Performance Check List which is in the last section of this document. The sections covered in thisguide are: The BasicsMemoryCPUNetworkIOVirtualizationFederation of ServersAdd-On Performance Tipso Service DeskPerformance Check List5 Page

B.0 - The BasicsB.1 - Hot FixesMake sure your up to date on hot fixes since performance related issues are addressed through thismechanism. Go to system, configure and make sure you have “Enable automatic check” checked. Alsoverify that you are current on hot fixes by looking at the “Last Hotfix” field. If not, click the “Get LastestHotfix” button. It is also a good idea to run the “Reapply Schema” link after hot fixes are applied sincethis may create any missing indexes on the database helping performance.Some customers choose not to have this feature enabled. In this case, you should review thisperiodically and if you are experiencing performance issues, it’s best to apply all hot fixes beforecontacting support.B.2 64 bit versus 32 bit OS and SQL Server.Don’t use 32 bit OS’s or SQL Server. It’s okay for test environments, but will not scale to support Kaseya.B.3 - System RequirementsDid you review the minimum system requirements at the Kaseya support ents.aspxKeep in mind that these requirements can vary based on many variables such as: Number of auditsNumber of patch scansNumber of KES scansUser/Sample scriptsReportingLog HistoryAgent HistoryScript distributionIt is therefore important for you to monitor your environment at all times and preferably with a KaseyaAgent. 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 canmonitor these for you. Please feel free to contact our NOC services for more details on this service. Aswe work with many clients, we constantly update our monitor sets to insure best practices in terms ofmonitoring the Kaseya solution.B.4 - Browsers and workstations make a differenceThe new features and functionality of the new Kaseya UI does require more resources in terms ofNetworking bandwidth and CPU on the clients workstation running the UI. The reason is that we arenow using Java AJAX and JSON in order to render our pages. We have found that using Firefox overInternet Explorer provides better response times on the Kaseya UI and is highly recommended. Chromeappears to be the fastest; however,this browser is not supported atthis time.If you notice that the UI is slow,check to see how much CPU yourworkstation is utilizing duringscreen refreshes. If the CPUconsistently hits 100%, yourworkstation may be underpowered to render the pages. Alsocompare the CPU utilizationbetween Firefox and InternetExplorer.B.5 – Please, distribute your scripts!You probably keep hearing thisfrom us as a Kaseya Customer,but it is very important that youdistribute your scripts. On theright, the scripts for the “LatestAudit” are all scheduled at once.And before that, all of the PatchScans are scheduled in a smalltime frame as well. If you don’thave enough resources on theserver, many things can happen.For example: The patch scans maynot be finished before7 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 andexasperate the situation.With high IO, Network and CPU, your UI will slow to a crawl.Keep an eye on your script distribution, it is important!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 andPC’s may be turned offduring the night. If PatchScans and Audits aredistributed and set torun at night, they maybe queued untileveryone in thecompany comes in tostartup their machines.So, if you areexperiencing this, checkout your statistics in theSystem- Statics tab.Note how high your CPUis running and then lookat the tops scripts thathave run in the last hour.If it appears that thereare more scripts thathave run than what youset as an hourlydistribution, you may berunning into thisscenario. Considerincreasing your CPU,Networking and IO toaddress this. Kaseyaminimum requirementsare based on an averageover 24 hours assumingan incremental audit andpatch scan a day.8 Page

B.7 – The Statistics Hidden LinkOn very useful feature is the hidden link to viewserver historical statistics. This link is located onthe System- Statistics page on the box with theheading starting with “Statistics collected at”.This is the hidden link. Click this to bring up thehistorical statistics page. Here, you can reviewhistorical graphs that provide very usefulinformation on the number of scripts run, CPU,etc Again, one of the biggest resource issues isscripts. If they don’t appear distributed, butspiking as shown, then you may experiencetimes of slowness in your environment. Reviewthe CPU graph too and see if your environment has historically high CPU utilization or spikes as well. If itdoes, try to distribute your scripts to run more evenly.9 Page

M.0-MemoryHow to monitor memoryMemory can be monitored by using the resource monitor in Windows 2008. There are two keyindicators that are important tomemory and this is why they showon this panel. You should not seeexcessive Hard Faults/sec. Ideally,this number should be very low oreven zero. If you see values in thedouble digits or more, you arerunning low on memory and diskswapping is occurring. This is bad.Also, make sure you are not above85% on your Used Physical Memory.If you are, you should consideradding more RAM to your system.M.1-ProcessesYou must have enough memory tosupport five of the most memory dependant processes in a single physical Kaseya Server environment.These processes are: KaseyaMessageSysW3wp (IIS Workpool)KserverMS Sql ServerMS Sql Reporting ServicesIn Kaseya V6, the KaseyaMessageSys.exe is a new process that will allow Kaseya to scale with futureversions and works closely with Microsoft Message Queuing. In addition to this, Version 6 also addsMicrosoft Report Services.KaseyaMessageSys can use 380 meg. of RAM for a small implementation of Kaseya (0-250 end points) tomore 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 IISworkpool process called w3wp). This process can use 250 Megabytes for a small implementation to 700Megabytes or more for larger implementations.Kaseya also utilizes Microsoft Reporting Services which will add additional memory pressure for yourinstances. Small instances can use 160-200 Megabytes while larger systems can use even more. It’s notunusual 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 addressedwhen you are ready to upgrade. Especially on systems that are running low on memory resourcesalready. It is easy, therefore, to add another 800 Megabytes to a small system just for the new KaseyaV6 release. For larger implementations, 2Gigabytes in additional RAM is not out of the question andhighly recommended.Also consider that Windows 2008 uses more RAM just to run. Its requirements are even more thanprevious versions of windows. Typically, you should allocate at least 2 Gigabytes of RAM for theoperating system alone.M.2-64 Bit Operating SystemCurrently, it is highly recommended that even small installations of Kaseya Version 6 use 64bit Windowsto address RAM over the 32 Bit limit of 4Gig. As shown above in section M.1, even a small installation ofKaseya can be impacted by new Kaseya and Windows 2008 requirements. In addition to the OS, SQLServer should be 64 Bit as well.M.3-32 Bit /3GB in the boot.iniKaseya has seen that the /3GB switch in the boot.ini of 32 bit Windows causes excessive paging simplybecause more RAM is being allocated to applications and not to the Operating system. This switch is setin the boot.ini file and should be taken out. In its place, you should upgrade your Windows operatingsystem to 64 bit or add additional memory to your existing 32 Bit environment and using the /PAEswitch in its place. PAE is used by SQL Server (by enabling AWE) and can use the additional memoryabove the 32 Bit limit of 4GB. This feature does not work on 32 Bit Windows Standard Edition.If you are limited to 32 bit systems and 4Gig of RAM, you should consider splitting the server into anapplication and database server. This will at least allow more RAM to both the database server and theapplication server.M.4 Memory Best PracticesMake sure to monitor memory usage on the following processes to develop usage history and assessMemory requirements specific to your environment: ServicesService.exeKServer.exe11 P a g e

C.0 - CPUCPU utilizat

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.