Controller System Requirements

AppDynamics strongly recommends that you install the Controller on a dedicated machine for adequate stability and performance.

This page provides guidelines for the hardware and software requirements for the Controller machine, but keep in mind that each deployment is unique. Application behavior and features such as monitoring asynchronous threads and End User Monitoring increase the number of metrics per minute flowing to the Controller and can affect the requirements. 

Controller Operating System Support

A Controller installer is also available for 64-bit Mac OS machines. However, running the Controller on Mac OS is intended for instructional, development or demonstration environments only, and not meant for production use. 

Java

The Controller host machine must be able to run the Java version that the Controller uses. The Controller runs Java 1.7 by default.  The installer also packages Java 1.8.  You can switch to Java 1.8 after you install the Controller.  For more information, see Platform Version Information.

Controller Performance Profile Definitions

The Controller performs large-scale real-time data analysis and correlation for potentially many agents at a time. For best performance, the Controller must be installed on suitable hardware.

To determine the hardware needed for your Controller, first identify the expected performance profile for your deployment based on the following table. Once you've identified a profile, match it to the hardware requirements specified in the following section. 

¹ The primary consideration in sizing a Controller deployment is the metric ingestion rate per minute, as shown in the second column. While the number of nodes and business apps in your deployment do not bear directly on system capacity, the numbers shown here are indicative of the corresponding profile sizes. The actual number of nodes or business applications the controller can handle vary depending on the node type, features used, and many other factors.  

² Deployments that exceed the Extra Large profile are possible, but you need to work closely with your AppDynamics account representative to determine hardware requirements and configuration and tuning measures needed to accommodate Extra Large or larger deployments. 

Hardware Requirements per Performance Profile

The following table shows the hardware requirements typically required for a deployment by performance profile.  

AppDynamics strongly recommends that you install the Controller on a dedicated machine. The hardware requirements described in this document assume that no other major processes are running on the machine where the Controller is installed, including no other Controllers. For the Extra Large profile and larger, the Controller must run on a dedicated machine.

Notes on the Profile Hardware Requirements:

• Large and Extra Large Controllers are not supported on virtual machines or on systems that use network attached storage. 
• For Extra Large profile deployments and larger, you will need to work closely with your AppDynamics account representative for sizing, configuration, and additional considerations. 
  For configuration information for Extra Large deployments, see Tuning for Large Scale Deployments.
• The Demo profile is for demonstration and evaluation environments only.
• An important limiting factor when considering deploying the Controller to a VM is the Disk I/O latency and throughput. For more, see additional information on I/O requirements. 
• Disk sizing reflects the estimate that each metric requires approximately 7 MB of storage. This assumes default settings for the Controller, including default data retention settings and business transaction registration limits. 
• The RAM recommendations leave room for operating system processes. However, the recommendations assume that no other memory intensive applications are running on the same machine. The actual RAM allocated by the installer per profile size for the Controller application server and database in gigabytes are 1.6, 3, 12, 24, and 48, respectively. 
• Also, see Controller Performance Profiles. The agent count requirements do not reflect additional requirements of using End-User Monitoring (EUM). See Additional Sizing Considerations for more information.
• The Controller is not supported on machines that use Power Architecture processors, including PowerPC processors.
  

To perform the installation, the Controller installer requires around 200 MB of free space to be available in the system's temporary directory. For more information, see Install the Controller. 

For information on hardware requirements for Database Monitoring, see Event Store.

Calculating Node Count for .NET Environments

The .NET Agent dynamically creates nodes depending on the monitored application's configuration in the IIS server. An IIS server can create multiple instances of each monitored IIS application. For every instance, the .NET Agent creates a node. For example, if an IIS application has five instances, the .NET Agent will create five nodes, one for each instance.

The maximum number of instances of a particular IIS application is determined by the number of worker processes configured for its application pool. Consider the following diagram:

The diagram shows three application pools: AppPool-1, AppPool-2, and AppPool-3 with the following characteristics:

• AppPool-1 and AppPool-3 can have a maximum of two worker processes (known as a web garden)
• AppPool-2 can have one worker process

If applications are assigned to application pools as follows:

AppPool-1: AppA and AppB

AppPool-2: AppC, AppD and AppE

AppPool-3: AppF

Use the following formula to estimate the number of nodes:

AppPool-1 * number of applications * max number of worker processes
+
AppPool-2 * number of applications * max number of worker processes
+
AppPool-3 * number of applications * max number of worker processes
+
Windows service or standalone application processes
= Number of Nodes

In this case, the numbers would be:

AppPool-1 nodes = 4 (2 applications * 2 worker processes)

AppPool-2 nodes = 3 (3 applications * 1 worker process)

AppPool-3 nodes = 2 (1 application * 2 worker processes)

for a total of 9 nodes.

To find the number of CLRs that will be launched for a particular .NET Application / App Pool:

1. Open the IIS manager and see the number of applications assigned to that AppPool.
2. Check if any AppPools are configured to run as a Web Garden. This would be a multiplier for the number of .NET nodes coming from this AppPool as described above.

Also see: http://technet.microsoft.com/en-us/library/cc725601(v=ws.10).aspx.

Database Monitoring Considerations

The following guidelines can help you determine additional disk and RAM required for the machine hosting the Controller that is monitoring the Database Agent. For very large installations, you should work with your AppDynamics representative for additional guidelines. 

For on-premises installations, the machine running the Controller and Event Service will require (for data retention period of 10 days):

• • 1 – 10 collectors: 2 GB RAM, Single CPU
  • 10 – 20 collectors: 4 GB RAM, 2 CPUs
  • More than 20 collectors: 8 GB RAM, 4 CPUs

Additional Sizing Considerations

Event Service

The Event Service is a file-based storage facility used by EUM, Database Monitoring, and Analytics. Database Monitoring uses the Events Service instance embedded in the Controller by default. The disk space required will vary depending upon how active the databases are and how many are being monitored. 

For redundancy and optimum performance, the Events Service should run on a separate machine. For details on sizing considerations, see Events Service Sizing and Capacity Planning.

AppDynamics for Databases Requirements for Demo and Small Profile Environments

AppDynamics for Databases is an on-premise solution and can be installed on the same server as the AppDynamics Pro Controller, or on a different server.  In either case, it requires 1 CPU and 2GB of RAM to monitor a single database instance. If you install it on the Controller server, these resources are in addition to the Controller resources. 

Asynchronous Call Monitoring and End User Monitoring (EUM)

Monitoring asynchronous calls and using End User Monitoring (EUM) typically increases the number of metrics collected.  As a result:

• The Small profile is not supported for installations with extensive async monitoring and/or use of EUM.
• A Medium profile running 40+ agents may need to upgrade to a configuration closer to a Large profile if extensive async monitoring and/or EUM are added.

Specifically, the features affect the workload of the system as follows: 

• Monitoring asynchronous calls increases the number of metrics per minute to a maximum number of 23000 per minute. 
• EUM
  • Web RUM can increase the number of individual metric data points per minute by up to 22000

  • Mobile RUM can increase the number of individual metric data points per minute by as much as 15 to 25K per instrumented application if your applications are heavily accessed. The actual number depends on how many network requests your applications receive.

    The number of separate EUM metric names saved in the Controller database can be larger than the kinds of individual data points saved.  For example, a metric name for a metric for iOS 5 might still be in the database even if all your users have migrated away from iOS 5.  So the metric name would no longer have an impact on resource utilization, but it would count against the default limit in the Controller for metric names per application.  The default limit for names is 200,000 for Browser RUM and 100,000 for Mobile RUM.

Running the Controller on Virtual Machines

Medium and smaller profile Controllers can run on virtual machines, but with a few additional considerations: 

• The memory allocation for the Controller's virtual machine must be fully reserved RAM. Reserve as much as possible of the total memory allocation. The following page describes how to configure reserved memory on VMWare: Set Memory Reservation on a Virtual Machine.  
• The Controller license is bound to the MAC address of the host machine. To run the Controller on a virtual machine, you must ensure that the host virtual machine uses a fixed MAC address. 
• The virtual machine that hosts the Controller must meet hardware resource requirements that are equivalent to physical machines, including I/O performance. 
• Running a large or extra large profile Controller on a virtual machine is not supported, without prior approval by AppDynamics. These deployments require you to work closely with your AppDynamics account representative throughout the planning and installation process. For more information, contact your AppDynamics account representative.  

To test whether your virtualized storage subsystem is providing the required I/O capacity, see information on disk I/O rate tests.

Understanding Disk I/O Requirements

One of the most important indicators of a machine's ability to support the performance requirements of a Controller is the machine's disk I/O performance.

The average write latency for the disk that hosts the Controller should not exceed 3 milliseconds while the Controller is under sustained load. Be sure to test I/O latency on the machine for the Controller under load to best understand the hardware needed for your deployment. 

The AppDynamics Controller always writes and reads using the following block sizes:

• Read block size: 16 K
• Write block size: 64 K

When considering I/O performance, keep in mind that while onboard disks typically satisfy I/O performance requirements, in a SAN environment the bottleneck in terms of I/O write and read speed becomes the latency between the CPU and the SAN-based storage. 

AppDynamics strongly recommends that you avoid installing the Controller or putting the Controller's data directory, db/data, on an NFS-mounted filesystem. NFS adds latency and throughput constraints that can affect Controller performance and even lead to data corruption.

Similarly, you should avoid iSCSI or other SAN technologies that are subject to the quality of service issues from the underlying network.

For best performance, if not using onboard disk storage, consider using a robust Fiber Channel, FCoE, or iSCSI over 10Gbit Ethernet SAN. In all cases, be sure to thoroughly load test the deployment with real-world traffic load before putting the Controller into a live environment.  

Measure Disk I/O

To measure the disk I/O performance, AppDynamics recommends using the free fio tool. For information on fio, see the documentation for fio.

Linux file descriptor limit

For Linux environments, it is important to set the file descriptor limit to at least 65535. See information on limiting file descriptors on Linux in Configure Linux for the Controller.

Virtual Memory Space

The virtual memory size (swap space on Linux or Pagefile space on Windows) should be at least 10 GB on the target system, and ideally 20 GB.

Be sure to verify the size of virtual memory on your system and modify it if it is less than 10 GB. Refer to the documentation for your operating system for instructions on modifying the swap space or Pagefile size. 

Network Bandwidth Requirements

See Install and Administer Agents for information on bandwidth usage in an AppDynamics deployment.

Internationalization Support

The Controller and App Agents provide full internationalization support, with support for double- and triple-byte characters. This support provides the following abilities:

• Controller UI users can enter double- or triple-byte characters into text fields in the UI
• The Controller can accept data that contains double- or triple-byte characters from instrumented applications

Reporting Service System Requirements

The Reporting Service is a standalone Controller process responsible for generating and transmitting reports. 

The Reporting Service relies on certain system libraries and resource that are usually included in standard Linux distributions. However, certain lightweight flavors of Linux may be lacking the requirements, primarily font libraries. In this case, errors in the reporting server log will indicate missing components, such as a missing libfontconfig.so file.

The operating systems in which this type of error has been observed and the steps for resolving the issue by installing the missing component include: