Reference Information › User Interface Reference Guide › Infrastructure Editor › Application Configuration › Resources

Resources

You can specify the resource level for resources, such as memory, CPU, and bandwidth. The resource levels are Min, Max, and Default.

The Min and Max values specify the minimum and maximum value for the given resource that should be allowed. This means that if, for example, an entity has a min=1GB and max=4GB for memory, you can not allow specify less than 1GB or more than 4GB for that resource. The actual resource amount is determined at start time -- start of the application or of the appliance. At that time, an actual value is calculated and provided for the entity. The resource amount then does not change until the entity is stopped.

The Default value is what actual resource value will be provided to the entity, if no explicit value is provided. For example, if you have an appliance that has memory resource defined as min=1GB, max=4GB, default=2GB, and no explicit value is provided, the appliance receives the default value of 2GB.

You could also specify actual values. These can be specified in several ways – explicitly on the instance by changing its default or by inference from a higher level entity. The actual values may be defined persistently in the AppLogic ADL descriptors or ad-hoc when starting or restarting an application or appliance.

Setting Resources at the Application Level

CA AppLogic packages a connected system of appliance instances in a new entity, called the application. The application is an opaque object that contains all the instances with their connections and configuration as well as user code and data.

Among other functions, the application aggregates the resource ranges for all contained appliances. The application’s minimum value for a resource is the sum of all instance minimums, and the application’s maximum value for that resource is the sum of all instance maximums. Unsurprisingly, the application’s default value for a resource is the sum of all resource defaults.

This way, if no explicit values are defined at the application level, the values will be inherited or used from the appliance level.

If an explicit value for a resource is defined at the application level, whether it is a limit value or a default value, then this new value is used to constrain all subordinate or contained instances. The algorithm for computing the values on the subordinates is linear interpolation. Simply put, the values for instances are adjusted proportionately, based on how much the application value is adjusted from the inherited level.

For example, a simple application with two subordinates, A and B. A has mem.min=1G, mem.max=3G; B has mem.min=2G and mem.max=6G. The inherited limits for the app will be mem.min=3G (1+2=3) and mem.max=9G (3+6=9). If we now set the application’s lower memory limit to 4.5G (mem.min=4.5G), then this will adjust A’s mem.min to 1.5G and B’s mem.min to 3G.

The way this is calculated is as follows:

• For the application, the inherited range is 6GB (from 3 to 9). Setting the lower limit to 4GB, puts all appliance minimums at the 25th percentile of their ranges.
• For appliance A, the range was 2GB wide, so 25% is 0.5GB. Adding 0.5GB to the lower limit of 1GB gives us a new lower limit of 1.5GB.
• For appliance B, the range was 4GB wide, so 25% is 1GB. Adding 1GB to the lower limit of 2GB gives us a new lower limit of 3GB.

The same math works for the default and maximum values. Usually, there is no need to understand how this works. The important thing to understand is that as you set the resource values – limits or default – at the application level. The corresponding resource values will be adjusted for all appliances proportionately within their ranges.

Before reading this you would think the class and instance ranges are not that important. However, the use of the range to properly pro-rate the resource for each appliance, makes it worth careful consideration. This assumes you want to be able to scale the application resources up and down.

The application level is where the final resource values are determined. There are two ways to adjust those:

• Persistent – by modifying the default value of the resource for the application. This value then applies to all subsequent starts
• Ad-hoc – by specifying an explicit resource level on the app start command. This value applies only for this start command and will not affect the persistent default.

You can always view the actual resource values assigned to a running application. The app info command provides the actuals for the application as a whole. The comp list command provides the actuals for each appliance in the application.

The ability to specify resource limits and values at the application level allows the application operator to define the resources that you want for the application as a whole, without having to deal with the individual appliance instances. For example, a production application can be set at max (default values set to the max values); while a copy of the application that is used for functional testing can be set to the minimum values.

You will have noticed by now that there is a hierarchy of resource values and limits. As any good object hierarchy, there is inheritance. If a value has is not explicitly defined at some scope, the resource value is inherited from the parent scope.

You will notice that both the instance resource configuration window and the application resource configuration window distinguish between inherited values and explicit values. Explicitly defined values are shown in bold typeface while inherited ones are in normal typeface. In addition, if a value is explicitly defined, there is a small arrow button to restore to the inherited value. There is also a Reset All button that resets all explicit values to their inherited values.

Working with Resources

You can set the exact amount of resources to be used when starting the application by specifying the maximum values equal to the minimum. This ensures that:

• No freedom will be given to the scheduler
• The application will not start unless at least that amount of resources are available
• The application will take no more than that amount of resources.

In the Resource tab, you can only reduce the resource range by specifying a higher minimum or lower maximum for resources.

The Resources contains the following information and configurable fields:

• Constrain by Resources
  • CPU - Specify the portion of CPU or number of CPUs to be allocated for the application. Fractional amounts can be specified as a decimal number, such as 0.5 or 3.5). Whole CPUs are specified simply as an integer, such as 12.
  • Memory - Specify the amount of memory to be allocated for the application. The amount can be specified as an integer value in Megabytes (for example, 512M) or in Gigabytes (for example, 9G).
  • Bandwidth - Specify the amount of network bandwidth to be allocated for this application. The amount can be specified as an integer value in Megabits/sec, such as 10M or in Gigabits/sec, such as 1G.

  You can specify a range for each resource type. The range defines the normal operating parameters desired for the application in production environment.

  • Minimum - The minimum amount of a resource that the application needs to work at all. This is useful to allow running the application in functional testing environments, where the application is not expected to run under production load, and therefore can run with much less resources. Contrast this with the Default below, which is amount of resources needed for production use.
  • Maximum- The maximum amount of a resource that the application will be allowed to take. Typically this is the maximum that the application can use.For example, giving it more resources will not increase performance. The application will not be allocated more than the specified maximum amount. This ensures that it will not be able to take resources away from other applications -- think of it as a quota.
  • Default - The minimum amount of a resource that the application should be provided with for normal operation in production environments. The application will not start unless at least that much resource can be allocated. Specifying a default helps ensure that the application will work within certain guaranteed resource amount -- think of it as a service level agreement (SLA) for that resource.

  Note: You can enable the CPU oversubscription and oversubscription of network bandwidth.

  • CPU Oversubscription - The CPU resource can be over-subscribed to allow a grid to run applications whose CPU allocation exceeds the physical capacity of the grid. When CPU oversubscription is configured, the CPU meter displays shows the virtual CPU capacity of the grid and an indicator beneath the meter showing the physical CPU capacity of the grid.

    This allows tighter packing of appliances in servers. CPU oversubscription is used primarily where the appliances are not expected to be under full load all the time and can tolerate lower performance in case all appliances on the server are in use.

    Notes:

    • CPU oversubscription removes the guarantee of CPU resource allocation.
    • When using CPU oversubscription, applications should be started in round robin mode.
    • If you notice performance issues in applications on grids that use overcommit, app start does support a --no_overcommit option on a per-application basis. This allows you to start a specific application without overcommit, such as 2 CPU means 2 physical cores will be allocated. You can diagnose performance issues and rule out overcommit.

    For additional information on setting oversubscription, refer to the Grid Control section of the Command Line Shell Reference Guide.

  • CPU resource can be over-subscribed to allow a grid to run applications whose CPU allocation exceeds the grid’s physical capacity. This allows tighter packing of appliances in servers. CPU oversubscription is used primarily where the appliances are not expected to be under full load all the time and can tolerate lower performance in case all appliances on the server are in use. For additional information on setting oversubscription, refer to the Grid Control section of the Command Line Shell Reference Guide.
  • Oversubscription indicates the network bandwidth oversubscription status. Oversubscription of network bandwidth allows you to start a mix of applications whose network bandwidth requirement exceeds the network bandwidth capacity of the grid. Applications tend not to continually use full capacity of their network interfaces, allowing oversubscription to typically be safe.
• Constrain by Server Names

  You can also select the specify servers where you would like the application to run. This is an advanced option that may be useful when you want to run several applications on the same system and the results produced by the scheduler are not satisfactory. In most cases you should leave this constraint disabled.

  To locate your list of servers, execute the server list shell command.

  If the specified server does not having enough resources, the application starts on other servers, provided there are available resources. A log message displays in the dashboard.