Setting Administrator-Defined Resource Limits for SDK Applications

The JUNOS SDK has four policy levels that ensure SDK applications have minimal impact on the native JUNOS operating system and system operations.

These policies files impose limits on the system resources the application uses. Each succeeding policy level overrides the previous settings, provided the constraints are within the previous level's settings.

Level I policy is the default global policy generated by Juniper Networks. Level II is a per-provider level policy that enables different resource limits per provider.

A Level III policy is implemented in the policy file that SDK developers write for each SDK package. In building an application package, the SDK provider creates a manifest and specifies roles. The manifest file specifies the contents of the application package, and the provider specifies a role name for each entry in the package manifest. Before packaging the application, the provider has the option to create a policy file that describes the constraints to be applied to the roles. For example, the Provider_Daemon role, which is one of six possible roles, can be defined in either Level II or a Level III policy as specified in the manifest. This policy file limits the system resources the application uses in addition to the limits imposed in the default policy generated by Juniper Networks (Level I policy).

Level IV policies are set by the administrative user using the resource-limits statement at the [edit system extensions] hierarchy level. These limits can be set either by package or by individual processes in the package.

[edit system extensions]
resource-limits {
   package package-name {
      resources {
         cpu {
            priority number;
            time seconds;
         }
         file {
            core-size bytes;
            open number;
            size bytes;
         }
         memory {
            data-size bytes;
            locked-in bytes;
            resident-set-size bytes;
            socket-buffers bytes;
            stack-size bytes;
         }
      }
   }
   process process-ui-name {
      resources {
         cpu {
            priority number;
            time seconds;
         }
         file {
            core-size bytes;
            open number;
            size bytes;
         }
         memory {
            data-size bytes;
            locked-in bytes;
            resident-set-size bytes;
            socket-buffers bytes;
            stack-size bytes;
         }
      }
   }
}

Limits defined for individual processes override the limits defined for an entire package. Any limits not set as a Level IV limits inherit the limits from Level III if they exist or from Level II.

Level IV policies can be more restrictive than previous policy levels, but they cannot raise the limits set by the other levels.

If an SDK application exceeds any of the imposed limits, the router logs it. For example, if a process tries to exceed its stack size, the process will get killed and the system will generate a core file.

Level IV policies can be applied either during runtime of the application or before the application gets started by init(). However, if the SDK application was already running, it must be restarted manually in order to allow for the new limits to take effect.

If you try to commit a resource limit that is higher (less stringent) than the inherited value, the commit will fail with the following error message:

[edit system extensions resource-limits]
  'process jnx-example-service'
    Limit validation failed for program 'jnx-example-service', resource 'file' limit 'open': raising limits defined in role 'Provider_Daemon' is not allowed.
commit complete

[edit system extensions resource-limits]

If you delete a resource configuration, the setting goes back to the limits from the assigned role in the manifest file (Level II or Level III).

Operational Command to Display Resource Limits

To display the applied policies, use the show system processes resource-limits process-name process-ui-name operational command.

The next example configuration when committed applies resource limits for an SDK package jnx-example and overrides it with process-level settings for the process jnx-example-service.

[edit system extensions]
user@router# 
resource-limits {
    package jnx-example {
        resources {
            memory {
                stack-size 4m;
            }
        }
    }
    process jnx-example-service {
        resources {
            file {
                size 4m;
            }
        }
    }
}

The output for jnx-example-foo-binary, part of package jnx-example, looks like the following because the package-level settings are applied on it:

user@router> show system processes resource-limits process-name jnx-example-foo-binary
Resource Limits:
  Area                       Max. allowed     Max. configurable
  memory/stack-size                   4MB                   8MB
  memory/data-size                   32MB                  32MB
  memory/resident-set-size           24MB                  24MB
  memory/locked-in                   16MB                  16MB
  cpu/priority                         10                    10
  file/open                            64                    64

The output for jnx-example-service looks like this:

user@router> show system processes resource-limits process-name jnx-example-service
Resource Limits:
  Area                       Max. allowed     Max. configurable
  file/size                           4MB             unlimited
  file/open                            64                    64
  cpu/priority                         10                    10
  memory/stack-size                   8MB                   8MB
  memory/data-size                   32MB                  32MB
  memory/resident-set-size           24MB                  24MB
  memory/locked-in                   16MB                  16MB

For more detail on the show system processes resource-limits process-name process-ui-name operational command, see show system processes resource-limits process-name.

Example: Configuring Separate Resource Limits for a Process

In this example there are ten processes in the SDK application package, and the administative user wants to limit the number of open files and the stack size but does not want to apply the same limits to the jnx-example-service process. To do this, the user must specify limits for the jnx-example package and for the jnx-example-service process. Any limits not set inherit the Level III limits (if any) or Level II limits (if no Level III limits exist).

[edit system extensions]
user@router# show
resource-limits {
   package jnx-example {
      resources {
         file {
            open 8;
         }
         memory {
            stack-size 4m;
         }
      }
   }
   process jnx-example-service {
      resources {
         memory {
            resident-set-size 8m;
         }
      }
   }
}

[edit]
user@router# commit

Note:
The show system processes resource-limits process-name process-ui-name command output shows a maximum configurable column, which has been omitted in this example to allow for exemplification of where the maximum allowed values come from.
user@router> show system processes resource-limits process-name jnx-foo-service

Resource Limits  
   Area                     Max. allowed 
   cpu/priority                       10  <-- inherited from Level II
   file/open                           8  <-- defined in config
   memory/data-size                 32MB  <-- inherited from Level II
   memory/locked-in                 16MB  <-- inherited from Level II
   memory/resident-set-size         24MB  <-- inherited from Level II
   memory/stack-size                 4MB  <-- defined in config

The above output will be the same for all other programs in the jnx-example package except the jnx-example-service process for which there is a special configuration. The process-level configuration overrides its package-level configuration.

user@router> show system processes resource-limits process-name jnx-example-service

Resource Limits  
   Area                     Max. allowed 
   cpu/priority                       10  <-- inherited from Level II
   file/open                          64  <-- inherited from Level II
   memory/data-size                 32MB  <-- inherited from Level II
   memory/locked-in                 16MB  <-- inherited from Level II
   memory/resident-set-size          8MB  <-- defined in config
   memory/stack-size                 8MB  <-- inherited from Level II

Other Configuration Guidelines:
Guidelines for Configuring SDK Applications

See also:
Statement Summary

Configuration Command Summary

Operational Command Reference

SDK CLI Configuration


2007-2009 Juniper Networks, Inc. All rights reserved. The information contained herein is confidential information of Juniper Networks, Inc., and may not be used, disclosed, distributed, modified, or copied without the prior written consent of Juniper Networks, Inc. in an express license. This information is subject to change by Juniper Networks, Inc. Juniper Networks, the Juniper Networks logo, and JUNOS are registered trademarks of Juniper Networks, Inc. in the United States and other countries. All other trademarks, service marks, registered trademarks, or registered service marks are the property of their respective owners.
Generated on Sun May 30 20:26:48 2010 for Juniper Networks Partner Solution Development Platform JUNOS SDK 10.2R1 by Doxygen 1.4.5