Alpha Server SC

Resource Management System (RMS)

 

 

 

 

 

Based on Version 4.0 of the

Alpha Server SC Users Guide

 

 

 

 

Introduction

 

RMS provides a set of commands for running parallel programs and monitoring their execution. The set includes utilities that determine what resources are available and commands that request allocation of resources.

 

More on Parallel Programs

 

o      A parallel program consists of a controlling process (prun) and a set of application processes distributed over the nodes in a partition. Each application process can have multiple threads running over one or more CPUs.

 

o      RMS assigns a unique number, known as the rank to each process in a parallel program. The numbers range from 0 to n-1, where n is the number of processes in the program.

 

o      The processes in a parallel program can communicate with each other across the data network. They do this by calling routines from one of the inter-process communication libraries passing it the rank of the remote process.

 

o      RMS includes MPI and Shmem libraries that have been optimized for the Quadrics data network.

 

o      The prun command sends a request to the Partition Manager to allocate the resources (CPUs and memory) required by the parallel program.

 

o      Once the resources are available, the Partition Manager instructs the RMS per-node daemons to load an RMS process called rmsloader on each node. rmsloader forks and execs the application processes.

 

o      The rmsloader processes forward output printed on stdout and stderr to prun and hence to the terminal or output file.

 

o      The parallel program terminates when all its processes have exited. The exit status returned is formed by a global OR of the exit status of each process. The Unix convention is that an exit status of zero indicates that a program has completed successfully. A non-zero exit status indicates that a problem has occurred.

 

o      If one or more of the application processes is killed by a signal (SIGSEGV for example) then rmsloader will run the corefile analysis script /opt/rms/etc/core_analysis which will print information on why the job failed.

 

RMS User Commands

 

RMS includes the following commands:

 

o       rinfo       - tells you about the resources available on your system.

 

o       prun         - runs parallel programs.

 

o       allocate - allows you to preallocate resources for running a sequence of jobs on the same nodes.

 

o       rmsexec     - starts processes on lightly loaded nodes (for example, on a node with free memory or idle CPUs).

 

Getting Resource Information with rinfo

 

 

o      Before invoking prun to run a parallel program, you can check which resources are available for your use.

 

o      RMS enables the system administrator to configure the cluster of nodes into a number of different partitions, each with different numbers of nodes and different sets of resource quotas and priorities.

 

o      This means that there may be restrictions on which resources you can use. Moreover, the administrator can set up a number of these configurations and switch between them to suit different working patterns.

 

o      For example, during the daytime, many users may be competing to use the resources for development purposes, whereas, at night, there may be a few large production jobs that run for a long time with no user interaction.

 

o        The command rinfo shows how the machine is configured, who is using the resources and what jobs these users are running on their resources.

 

Example of rinfo

 

 

o        The following is an example of the output from rinfo:

 

user@tazmo: rinfo

 

MACHINE CONFIGURATION

tazmo day

 

PARTITION CPUS STATUS TIME TIMELIMIT NODES

root 6 tazmo[0-2]

parallel 2/4 running 01:02:29 tazmo[0-1]

 

RESOURCE CPUS STATUS TIME USERNAME NODES

parallel.996 2 allocated 00:05 user tazmo0

 

JOB CPUS STATUS TIME USERNAME NODES

parallel.1115 2 running 00:04 user tazmo0

 

 

The output is split into four sections:

 

1. Machine - This section shows the following:

o      The name of the machine

o      The name of the active configuration

 

2. Partitions - This section has an entry for each partition in the active configuration. Each entry shows the following:

o      The partition name

o      The number of processors in use and the total.

o      The status of the partition

o      The partition’s up time, in hours, minutes and seconds

o      The upper time limit imposed on jobs, in hours, minutes and seconds

o      The names of the nodes in the partition

 

3. Resources - This section has an entry for each resource that has been allocated. A resource in this context means a set of processors with their associated memory and devices. Each entry shows the following:

o      The name of the resource (generated automatically)

o      The number of processors assigned to the resource

o      The status of the resource

o      The amount of time the resource has been allocated, shown in hours, minutes and seconds

o      The name of the user who has been allocated the resource

o      The names of the nodes that provide the resource

 

4. Jobs - This section has an entry for each job running on the machine. Each entry shows the following:

o      The name of the job (generated automatically)

o      The number of processors that the job is using

o      The status of the job

o      The amount of time the job has been running, shown in hours, minutes and seconds

o      The name of the user who is running the job

o      The names of the nodes across which the job is distributed

o      If no resources are in use, only the machine and partition sections are displayed.

 

Command Line Options

 

 

o      rinfo has a number of command line options that let you restrict or expand the amount of information displayed.

 

rinfo [-achjlmnpqr] [-L [partition] [statistic]] [-s daemon [hostname]][-t node|name]

 

o      Some of the more commonly used options:

 

o      You can use the -h option with all the RMS commands to get a list of the available options.

 

o      Specify the -a option to list the resources and jobs of all users.

 

o      To restrict the rinfo output to the jobs section only, specify the -j option.

 

o      Specify rinfo with both the -a option and -j option to display the jobs section for all users.

 

Checking Quotas

 

 

o      The system administrator can set limits on the way a partition is used.

 

o      Usually, these limits are set at the project level so that each user working on a project is automatically subject to the limits set for the project as a whole.

 

o      For example, there might be a limit of 20 on the number of processors available for project alpha at any one time. Therefore, if two users, working on project alpha, each had 8 processors allocated to them, only 4 processors would be available for a third project member, even though rinfo might show that the partition had 64 processors and there were no other users.

 

o      The system administrator can limit the following values.

o      The maximum number of CPUs.

o      The maximum amount of memory per process,

o      The scheduling priority,

 

o      You can check what restrictions have been set by running rinfo with the -q option.

 

duncan@gold0: rinfo -q

PARTITION CLASS NAME CPUS MEMLIMIT

parallel user duncan 0/8 256

parallel project alpha 16/20 256

parallel project default 4/16 256

 

o      The system administrator can also set limits on individual users. These are always more restrictive than those imposed at the project level.

 

o      Users can request lower values of each of these values. You can specify a per-process memory limit by setting the environment variable RMS_MEMLIMIT before using prun. This may help in getting their jobs run sooner.

 

o      Users can request that their jobs be assigned a priority lower than the default by setting the environment variable RMS_PRIORITY before using prun.

 

o      You can specify the name of the project you are working on by setting the environment variable RMS_PROJECT before using prun.

 

Viewing Configuration Details

 

 

o      The -c option displays the names of all the machine configurations:

user@tazmo: rinfo -c

day

night

 

o      You can find out the names of all the active partitions with the -p option. This also gives the number of CPUs in each partition:

user@tazmo: rinfo -p

parallel 16

root 2

login 4

 

o      The -m option displays the name of the machine:

user@tazmo: rinfo -m

tazmo

 

Running Programs With prun

 

 

o      prun is the RMS utility for running parallel programs.

 

o      prun loads multiple copies of a single application program onto a range of nodes and runs them. prun acts as the program’s interface to RMS, handling stdio and forwarding certain signals.

 

o      You specify to prun how many processes to load and on which partition. In addition, the prun options enable you to select more precisely the distribution of the processes in the partition.

 

o      Unless you have already allocated a resource for the program, prun does so on your behalf, blocking until a appropriate CPUs becomes available.

 

 

Command Line Options

 

 

The syntax of the prun command is as follows:

 

prun [-hiOstv] [-B basenode] [-c cpus] [-n procs] [-N nodes][-m block|cyclic] [-p partition] program [args ...]

 

You can use the -h option to get a list of the available options and valid arguments.

 

 

Selecting A Partition

 

 

o      With the -p option, you can select a partition for the program. If you omit this option, a default partition, nominated by the system administrator, is used.

 

o      In the following example, two copies of myprog are loaded onto the partition called parallel:

user@tazmo: prun -p parallel -n 2 myprog

Hello from myprog

Hello from myprog

 

o      You can specify your own default partition by setting the environment variable RMS_PARTITION.

 

o      If no partition has been specified and the system administrator has not set up a default, you will get an error message.

 

 

 

Specifying Processes And Nodes

 

o      You can specify how many instances of a program to run by using the -n option as shown in the previous section.

 

o      You can also specify how the processes are distributed across the nodes in the partition.

 

o         In the following example, two instances of uname are requested. All arguments after the program name are passed to each process.

 

 

user@tazmo: prun -n 2 uname -n

tazmo-4

tazmo-4

 

o      Note that both instances ran on the same node. By default, RMS allocates one process per processor, using all the processors on one node before moving on to the next.

 

o      You can override this behavior; by using the -N option, which specifies how many nodes are required for the program.

 

o      In the following example, four nodes are requested and an instance of uname is executed on each:

 

user@tazmo: prun -N 4 uname -n

tazmo-4

tazmo-5

tazmo-6

tazmo-7

 

o      The -n and -N options can be used in combination to place more than one process on each node. In the following example, four processes are executed, two per node:

 

user@tazmo: prun -n 4 -N 2 uname -n

tazmo-4

tazmo-4

tazmo-5

tazmo-5

 

o      Additionally, with the -c option you can select how many processors you want on each node for each process. This is for use in multi-threaded applications.

 

o      The following example runs four myprog processes on two nodes, allocating two CPUs per process — 8 CPUs in total:

 

user@tazmo: prun -c 2 -n 4 -N 2 myprog

 

 

 

Input And Output

 

 

o      Each process in a user’s application has three standard input/output (I/O) streams:

 

o      stdin or unit 5 in Fortran

o      stdout or unit 6 in Fortran

o      stderr or unit 0 in Fortran

 

o      The use of these streams by parallel programs is different from that of sequential programs (that is, standard Unix applications that execute independently of all other processes).

 

o      When the parallel processes start executing, stdout and stderr are routed to prun.

 

o      Normal write operations to these file descriptors have the expected effect, as do calls to the isatty(3c) function. Other ioctl functions are not reliable.

 

o      In a parallel program the three I/O streams should be used as follows:

o      stdin This must be redirected to come from a file.

o      stdout This is used for line buffered output from all processes.

o      stderr This is used for unbuffered output from all processes.

 

 

Getting Input

 

o      Processes executed by prun cannot read from stdin. This is because repeatable behavior cannot be guaranteed when unsynchronized processes read at the same time.

 

o      You can work around this by running a shell script that executes the program with stdin redirected from a file.

 

o      In the following example, with the first command all processes read from the same file; with the second, the processes have a file each:

 

user@tazmo: prun sh -c ’myprog < myfile’

user@tazmo: prun sh -c ’myprog < tmp.$RMS_RANK’

 

o      The -c option to the shell (the Bourne Shell, in this example) tells it that the next string represents a command to execute. Single quotes are used to delimit the string, not double quotes.

 

o      This method of quoting prevents the shell from trying to expand $RMS_RANK before the command is executed. RMS_RANK is set by prun to the rank of the process.

 

o      Similarly, each process can direct its output to a unique file:

 

user@tazmo: prun sh -c ’uname -n > host.$RMS_RANK’

 

o      The following simple shell script runs the first process in an xterm window with stdin, stdout and stderr for that process redirected to the new window:

 

#!/bin/sh~

if [ $RMS_RANK -eq 0 ] ; then

xterm -e myprog

else

myprog

fi

 

Line Buffered Output

 

o      In a parallel program, when processes print simultaneously to stdout, the output comes out on separate lines but in an arbitrary order.

 

o        In fact, the ordering may be different each time the program runs. The -t option of prun tags the output of each process with the rank of the process.

 

o        This makes it easy to identify the source of messages output by the program, as shown in the following example:

 

user@tazmo: prun -n 4- t pwd

2 /home/user

0 /home/user

3 /home/user

1 /home/user

 

Environment Variables

 

o      The following environment variables may be used to identify resource requirements and modes of operation to prun. These environment variables will be used where no specific command line options are specified.

 

o      RMS_IMMEDIATE  - Controls whether to exit rather than block if resources are not immediately available. By default, prun blocks until resources become available. Root resource requests are always met.

 

o      RMS_MEMLIMIT  - The maximum amount of memory required. This must be less than or equal to the limit set by the system administrator.

 

o      RMS_PARTITION - Specifies the name of a partition. This is the same as using the –p option.

 

o      RMS_PRIORITY - The priority level for scheduling this job. This must be less than or equal to the priority level assigned in either the users table or the projects table

 

o      RMS_PROJECT  - The name of the project with which the job should be associated for accounting purposes.

 

o      RMS_TIMELIMIT - Specifies the execution time limit in seconds. The program will be signalled either after this time has elapsed or after any time limit imposed by the system has elapsed. The shorter of the two time limits is used.

 

o      RMS_VERBOSE - Whether to execute in verbose mode and display diagnostic messages. This is the same as using the  v option. Setting a value of 1 or more will generate.

 

o      Information on the current priority level, project name and memory limit is accessible through the command rinfo using the -l option. prun passes all existing environment variables through to the processes that it executes. In addition, it sets the following environment variables.

 

o      RMS_JOBID - The identifier for the job.

 

o      RMS_NNODES - The number of nodes used by the application.

 

o      RMS_NODEID - The network ID of the host node.

 

o      RMS_NPROCS - The total number of processes in the application.

 

o      RMS_RANK - The rank of the process in the application. The rank ranges from 0 to n-1, where n is the number of processes in the program.

 

o      RMS_RESOURCEID - The ID of the allocated resource.

 

 

Memory Limits

 

o      RMS imposes memory limits on the processes in a parallel application. The default limits ensure that each process has a fair share of the memory available.

 

o      The system administrator can raise or lower the limits on a per user or per project basis.

 

o      Use rinfo with the -q or prun with the -v option to see the limits that apply to you.

 

duncan@cfs1: rinfo -q

PARTITION CLASS NAME CPUS MEMLIMIT

parallel project default 0/22 96

duncan@cfs1: prun -v -n2 dping

prun: starting 2 processes on 2 cpus memlimit 96 MB no timelimit

0: 0 bytes 2.43 uSec 0.00 MB/s

 

o      Exceeding these limits will cause brk(), malloc(), mmap() and sbrk() system calls to fail with ENOMEM. Programs with static arrays larger than the memory limit will fail immediately.

 

o      For example if you run a process like this with too small a memory limit it will exit before entering main and prun will exit immediately.

 

#include <stdio.h>

int array[50 * 1024 * 1024];

main (int argc, char **argv)

{

printf("hello world\n");

exit(0);

}

 

o      If you use prun with -v it will print a warning if all processes exit this way

 

duncan@cfs1: prun -v -n2 myprog

prun: starting 2 processes on 2 cpus memlimit 10 MB no timelimit

prun: Warning: exit 1 on all nodes. Data segment size may exceed memory limit.

 

o      You can check on the size of your application processes with the command size

 

duncan@cfs1: size myprog

text data bss dec hex

8192 8192 209707392 209723776 c802180

 

o      In this case you will need 200 MBytes per process.

 

Program Termination

 

o      A parallel program terminates when all its processes have exited. The exit status returned is formed by a global OR of the exit status of each process.

 

o      On Unix systems, an exit status of 0 generally implies success. If the exit status is not 0, you can set prun to output an error message that indicates which processes failed.

 

o      To do this, enable verbose operation either by using the -v option, as shown in the following, example, or by setting RMS_VERBOSE:

 

user@tazmo: prun -v myprog

myprog: process 0 exited with status 1

 

o      If one or more of the application processes is killed (for example by the signal SIGSEGV) RMS will run a corefile analysis script. This script looks for core files created by your program and prints out a backtrace showing you where the process failed.

 

o      Where possible RMS arranges for core files to be written to fast local temporary storage (the I/O implications of a parallel program dumping core to your homedirectory can be severe).

 

o      On Compaq AlphaServer SC systems core files are written to /local/core/rms/resource/ where resource is the id of the resource allocated. This directory is removed when the resource is deallocated to prevent the disk from filling up.

 

o      If you wish to preserve a core file you should run the failing command under allocate and copy the core file to permanent storage before freeing the resources.

 

user@tazmo: allocate -N4

user@tazmo: prun myprog

myprog: process 0 killed by signal 11

...

...

user@tazmo: rinfo -r

parallel.397

user@tazmo: prun -B0 -N1 cp ’/local/core/rms/397/core*’ .

user@tazmo: exit

 

Common Problems

 

There are some common problems and error messages that you may encounter when running applications. This section suggests some solutions.

 

o      The Program Hangs - The program may hang if prun cannot allocate the resources required for the program and has blocked, waiting until they become available. Resource requests made by allocate will behave in the same way.

 

If you enable verbose reporting with the -v option or by setting RMS_VERBOSE, prun will output a message as your jobs starts

 

duncan@gold0: prun -v -N2 uname -a

prun: starting 2 processes on 2 cpus memlimit 96

OSF1 gold0.quadrics.com T5.0 861.3 alpha

OSF1 gold1.quadrics.com T5.0 861.3 alpha

 

It the job is blocked waiting for resources you will get a warning message. Some time later you will get the start message and then the output from your program.

 

duncan@gold0: prun -v -n2 uname -a

prun: Warning: waiting for free cpus

prun: starting 2 processes on 2 cpus memlimit 96

OSF1 gold0.quadrics.com T5.0 861.3 alpha

OSF1 gold0.quadrics.com T5.0 861.3 alpha

 

 

If prun hangs between the two messages, you can suspend it by pressing Ctrl/Z and use rinfo to find out what is going on. You should see that your resource request is queued or blocked.

 

If the request is blocked it must wait for the completion of other jobs that you or your project have submitted. If the request is queued it must wait for the completion of jobs submitted by other users or projects.

 

You can prevent your job from blocking with the -i option to prun or by setting the environment variable RMS_IMMEDIATE. This will cause the job to fail if resources are not available.

 

Error Messages

 

The error messages you may encounter are as follows:

 

o      prun: can’t find program - The problem here is be that the specified program cannot be located using your current search path. The solution is to add the program’s directory to your PATH environment variable.

 

o      prun: Error: Partition manager for partition is down - The problem in this case is that the partition you specified with the -p option (or the default partition, if you did not specify one) is unavailable. The solution is to specify an alternative partition or ask the system administrator to restart the partition. rinfo will tell you the status of the various partitions.

 

o      prun: Error: no such partition as name -  The problem is that the specified partition does not exist. The most likely cause of this error is an incorrectly entered partition name. rinfo will show you the names of the partitions.

 

o      prun: failed to start loader - The per node daemon, rmsd, starts an rmsloader process on each node. These loaders connect back to prun. They find out from prun what they should run and then exec(3) the user’s program and forward its I/O.

 

This should all happen quickly. Things can go wrong, however, so a timeout is built into prun. This is the message that appears when the timeout expires.

 

 

The

Allocating Resources With allocate

 

o      RMS makes a distinction between allocating a resource (CPUs and memory) and running jobs on it.

 

o      prun combines both tasks: allocating resources and running jobs. allocate simply allocates resources. You may find it useful to use allocate before prun if you want to run a sequence of jobs with the same resource requirements.

 

o      This means you only have to wait once for the CPUs to be allocated. It is also useful if you want to run several jobs concurrently.

 

o      There are two ways to use allocate. These are described in the next two sections. Basically, allocate has an optional and final argument which is the name of a shell script.

 

o      If you do not specify a script, allocate spawns an interactive shell that has the resource until you exit the shell. If you do specify a shell script, the resource is allocated to this script until it exits.

 

 

The

allocate Command Line Options

 

o      allocate has four options that have the same option letter and meaning as their prun counterparts

 

allocate [-hiv] [-Bbase] [-Ccpus] [-Nnodes] [-ppartition] [script [args ...]]

 

o      The most frequently used options to allocate are -N which allows you to specify the number of nodes and -C the number of CPUs per node.

 

o      The -N option takes either a numeric argument specifying the number of nodes of the letter a meaning use whatever is available.

 

o      You can use the -h option to get a list of the available options and valid arguments.

 

Allocating Resources To An Interactive Shell

 

o      When allocate is run without specifying a shell script as the final argument, it spawns an interactive shell that has the resources allocated to it. These resources are freed when you exit the shell or when a time limit, imposed by the system administrator on parallel jobs, expires; whichever comes first.

 

o      In the following example, both the prun commands execute concurrently on the partition called

 

parallel:

user@tazmo: allocate -N 4 -p parallel

user@tazmo: prun -n 2 myprog &

user@tazmo: prun -n 2 test

user@tazmo: exit

 

o      The & following the program name and associated options tells the shell to run the program in the background and return to the command prompt.

 

o      In the next example the two prun commands are executed sequentially, both on the same two nodes in the parallel partition:

 

user@tazmo: allocate -N 2 -p parallel

user@tazmo: prun uname -n

tazmo-32

tazmo-33

user@tazmo: prun uname -n

tazmo-32

tazmo-33

user@tazmo: exit

 

o      If this example was run without allocating resources to the shell, you could not guarantee that the second use of prun would start immediately after the first completed; nor could you guarantee that both runs would use the same two nodes in the partition.

 

 

The

Verifying Resource Allocation To A Shell

 

o      When you allocate a resource to an interactive command shell, you can check that the resource has been successfully allocated by using rinfo as shown in the following example:

 

user@tazmo: rinfo

MACHINE CONFIGURATION

tazmo day

PARTITION CPUS STATUS TIME TIMELIMIT NODES

root 6 tazmo[0-2]

parallel 2/4 running 01:02:29 tazmo[0-1]

RESOURCE CPUS STATUS TIME USERNAME NODES

parallel.996 2 allocated 00:05 user tazmo0

JOB CPUS STATUS TIME USERNAME NODES

parallel.1115 2 running 00:04 user tazmo0

 

o      This shows that a resource named parallel.996 has been allocated to user and has been in use for 5 seconds.

 

o      Another way of verifying that the resource has been allocated to the shell is to change the shell prompt so that it shows the name of the resource.

 

o      You can do this by editing the setup file that the shell reads in when you login. As mentioned in the name and syntax of the setup file varies according to the shell you use.

 

o        The edits for a C shell and Bourne shell setup file are as follows.

 

 

 

The

Changing The Prompt With C Shell

 

o      Add the following commands to your .cshrc file to make the shell prompt change whenever you have been allocated resources:

 

# additions to .cshrc

if ($RMS_RESOURCEID) then

set prompt="${RMS_RESOURCEID}:"

else

set prompt="$user@‘uname -n‘:"

endif

 

o      When you next login and run allocate to get an interactive shell with a resource allocated to it, the prompt will be the name of the resource (as shown by rinfo):

 

user@tazmo: allocate -p parallel -n 6

parallel.4: exit

user@tazmo:

 

 

The

Changing The Prompt With The Bourne Shell

 

o        Add these lines to your .profile file to make the shell prompt change whenever you have been allocated resources:

 

# additions to .profile

if [ $RMS_RESOURCEID ] ; then

PS1="$RMS_RESOURCEID:"

else

PS1="$user@‘uname -n‘:" "

Fi

 

o      When you next login and run allocate to get an interactive shell with a resource allocated to it, the prompt will be the name of the resource (as shown by rinfo):

 

user@tazmo: allocate -p parallel -n 6

parallel.5: exit

user@tazmo:

 

 

The

Allocating Resources To A Shell Script

 

o      Rather than allocate a resource to an interactive shell, as just described, you can allocate it to a shell script. Calls to prun  within this shell script result in the execution of parallel programs on the allocated resource.

 

o      In the following example, the shell script called script uses prun to run four user jobs, one after the other:

 

user@tazmo: cat script

#!/bin/sh

# script to run

prun preprocess

prun iterate -f12000

prun iterate -f24000

prun postprocess

 

o      allocate is used to get a resource, which comprises 8 nodes on the parallel partition, to give that resource to the shell script and to run the script:

 

user@tazmo: allocate -N 8 -p parallel script

 

 

 

The

Running A Sequential Program With rmsexec

 

o      rmsexec provides a mechanism for running sequential processes on lightly loaded nodes — nodes, for example, with free memory or low CPU usage.

 

o      Note that this load balancing service may not be available on all partitions. It is a configuration option, selected by the system administrator.

 

o      rmsexec has a number of options that enable you to influence the choice of node.

 

rmsexec [-hv] [-p partition] [-s stat] [hostname] program [args ...]

 

o      You can use the -h option to get a list of the available options and valid arguments.

 

 

 

The

Rmsexec – Defining A Node

 

o        rmsexec restricts its search to the partitions you are entitled to use (as defined by the system administrator).

 

o      You can restrict the search still further by specifying a particular partition with the -p option, as shown in the following example:

 

user@tazmo: rmsexec -p parallel myseqprog

 

o        You can also request a processor on a specific node. The following example requests the node tazmo2:

 

user@tazmo: rmsexec tazmo2 myseqprog

 

 

The

rmsexec – Defining A Load

 

o      You can specify the criterion for judging load with the -s option. There are four statistics that can be applied.

 

o      usercpu - The percentage CPU time spent in the user state.

 

o      syscpu  - The percentage CPU time spent in the system state - a measure of the I/O load on a node.

 

o      idlecpu - The percentage CPU time spent in the idle state.

 

o      freemem - The free memory in MBytes.

 

o      users - Number of users.

 

o      By default, the usercpu statistic is used. Statistics can be used on their own in which case a node is chosen that is lightly loaded according to this statistic or you can specify a threshold.

 

o      Some examples follow:

 

user@tazmo: rmsexec -s usercpu myseqprog

user@tazmo: rmsexec -s"usercpu < 50" myseqprog

user@tazmo: rmsexec -s"freemem > 256" myseqprog

 

 

The

References and Revisions

 

 

© Copyright 2000, Compaq, All Rights Reserved

 

For more information on Compaq’s RMS contact Frank.Pietryka@Compaq.com

 

011100 – Pietryka – Created from Version 4.0 of the Alpha Server SC Users Manual