TOCPREVNEXTINDEX

Lund Performance Solutions


Environment Variables and Workload Groups

Environment Variables

Each of the SOS/SOLARIS environment variables are outlined in Table 3.1. Instructions to set the environment variables are provided in the next section, "Setting the Environment Variables."
Table 3.1 SOS Performance Advisor environment variables
Variable Name
Default Value
Accepted Value
PATH
$PATH:/opt/lps/bin
$PATH:/<custom directory name>/bin
TERM
N/A
N/A
LPS_OPT_PATH
/opt/lps
An existing, fully-qualified directory
LPS_ETC_PATH
/etc/opt/lps
LPS_VAR_PATH
/var/opt/lps
LPS_TIME_SEP
: (colon)
Any single alpha-numeric character
LPS_DATE_SEP
/ (forward slash)
LPS_DECIMAL_INDICATOR
. (period)
LPS_DATE_FMT
MDY (month day year)
MDY, DMY, or YMD

Setting the Environment Variables

Prior to running the SOS Performance Advisor programs, set the appropriate environment variables:
  • PATH
  • TERM
  • LPS_OPT_PATH
  • Set only if the host-independent application files were placed in a custom directory during installation.
  • LPS_ETC_PATH
  • Set only if the host-specific configuration files were placed in a custom directory.
  • LPS_VAR_PATH
  • Set only if the host-specific dynamic files were placed in a custom directory.
  • Localization environment variables (optional).
  • Setting the PATH Environment Variable

    Prior to running SOS Performance Advisor, it is necessary to set the PATH environment variable:
  • If the SOS Performance Advisor application files were placed in the default directory (/opt/lps) during installation, add the following line to your .profile:
  • PATH=$PATH:/opt/lps/bin
  • If the SOS Performance Advisor application files were placed in a custom directory, add the following line to your .profile:
  • PATH=$PATH:/<custom directory name>/bin
    If you are not sure how to set the PATH environment variable for the shell used when running SOS Performance Advisor, please ask your system administrator for assistance.

    Setting the TERM Environment Variable

    Prior to running SOS Performance Advisor, it might be necessary to set the TERM environment variable equal to the appropriate device name of your terminal. For example:

    TERM=vt100

    For more information about the TERM environment variable, please refer to your system documentation.

    Setting LPS_OPT_PATH, LPS_ETC_PATH, and LPS_VAR_PATH

    In the past, all Lund Performance Solutions files (lps files) associated with the SOS Performance Advisor application could be found in one directory (/opt/lps). In accordance with the OSF/1 standard, Lund Performance Solutions files are now located in three different directories, which are listed in Table 3.2.

    If the SOS Performance Advisor application files were placed in a custom directory during installation, it will be necessary to set the corresponding environment variable equal to the custom directory destination prior to running the application.
    Table 3.2 SOS Performance Advisor custom directory PATH environment variables
    Variable Name
    Accepted Value
    Default Value
    LPS_OPT_PATH
    An existing, fully-qualified directory
    /opt/lps
    LPS_ETC_PATH
    /etc/opt/lps
    LPS_VAR_PATH
    /var/opt/lps

    Setting the Localization Environment Variables

    Four specific environment variables are available in SOS Performance Advisor to customize certain date, time, and numerical characteristics of the application for use in different countries or languages. These environment variables, including their acceptable ranges and default values, are outlined in the next table.
    Table 3.3 SOS Performance Advisor localization environment variables
    Variable Name
    Accepted Value
    Default Value
    LPS_TIME_SEP
    Any single alpha-numeric character
    : (colon)
    LPS_DATE_SEP
    / (forward slash)
    LPS_DECIMAL_INDICATOR
    . (period)
    LPS_DATE_FMT
    MDY, DMY, or YMD
    MDY (month day year)

    Workload Groups

    A workload is a group of similar, identifiable transactions on the host system performed by individual users and programs. Workloads can be grouped by:
  • Applications
  • User login
  • Departmental processes
  • A workload may be as simple as one user running one program, or as complex as entire departments running many programs.

    Identifying and Characterizing Workloads

    Make sure workloads are homogeneous. A homogeneous workload consists of processes of a similar type, function, and priority.

    Averaging is meaningless for workloads made up of dissimilar transactions. For example, if an average accounts receivable transaction takes 200 milliseconds of the CPU’s time, while general ledger transactions average 500 milliseconds, taking an average of the two does not provide a meaningful average for either transaction.

    Identifying Workloads

    Input from management and system users is essential in identifying and defining workloads. Interview managers and users to determine how the system is used and to identify distinct functions, such as order entry, telemarketing, or accounting. Break down the various departmental functions into essential components, based on your desired result. Identify groupings that will provide you with the needed information. These grouped components make up your workloads.

    Characterizing Workloads

    Once you have identified your workloads, use the following guidelines to further refine your workload definitions:
  • Limit the components of any workload to users or transactions with service demands of comparable magnitude and similar balance across the system. Do not mix heavy-CPU/low-I/O transactions with light-CPU/heavy-I/O transactions.
  • Do not mix interactive processes and batch processes in the same workload. System resources, priorities, and think times are different for interactive and batch processes.
  • Use separate workloads for specific divisions, branches, or departments as needed.
  • Identify workloads by user logon, if possible.
  • Creating a Workload Definition File

    Once you have identified and refined you workloads, enter the data in a workload definition file.

    Workload Definition File

    User-defined workloads are created in /etc/opt/lps/cfg/workdefs.

    Workload Groups

    Four workload groups are defined by default (see Table 3.4). These four workloads should always exist.
    Table 3.4 SOS Performance Advisor default workload groups
    Workload
    Description
    INTERACT
    The INTERACT workload contains any processes attached to a terminal (interactive processes).
    The INTERACT workload group should be configured by the user.
    DAEMON
    The DAEMON workload contains any daemon processes. By default, this workload group is configured to include any process not attached to a terminal and owned by the root user.
    The DAEMON workload group should be configured by the user to reflect the system.
    BATCH
    The BATCH workload contains any batch job processes. By default, this is configured to include any process outside of the DAEMON workload group that is not attached to a terminal.
    The BATCH workload group should be configured by the user to reflect the system.
    DEFAULT
    The DEFAULT workload contains any process that does not match any other workload definition. Note that initially, this will be an empty workgroup (no processes will match), because at least one of the other defaults will include any possible process. However, since those workload groups are configurable, this workload group must exist.
    The DEFAULT workload cannot be modified. It guarantees a process will fall into at least one workgroup by matching any process that does not fall into any other workgroup definition.

    Response Time Calculations

    Response time calculations are performed for processes, workload groups, and on a system- wide basis. They include:
  • Transactions
  • Response time
  • Average response time per transaction
  • The definitions of transaction and response time are dependent upon the type of workload group to which the process belongs. The response time calculations are described below.
    INTERACT Response Time Calculations
  • Transactions = Terminal reads + Process deaths
  • Response time = Process live time - Think time
  • Process live time is the amount of time a process is alive during the interval. If the process was created before the interval and doesn’t die until after the interval, process live time will equal the interval time.
    Think time is defined as the amount of time a process is waiting for user input.
    DAEMON Response Time Calculations
  • Transactions = Voluntary context switches + Process deaths
  • Response time = Process live time - Process resource wait time
  • Process resource wait time is the amount of time a process is waiting on resources (such as CPU) verses waiting on an event (such as a terminal input).
    BATCH Response Time Calculations
  • Transactions = Process deaths
  • Response time = Process live time
  • Mix Response Time Calculations
    The mix response times vary, based on whether the process is attached to a terminal or not.
  • If the process is attached to a terminal, the INTERACT response time calculations are used.
  • If the process is not attached to a terminal and it has a high Nice value, the BATCH response time calculations are used.
  • If the process is not attached to a terminal and it has a default or low Nice value, the DAEMON response time calculation is used.
  • Workload Definition Requirements
    The workdefs file requires the following information for each workload:
  • The name of the workload, up to ten characters.
  • The type of process or processes included in the workload, such as INTERACT, DAEMON or BATCH.
  • The user or program specification, including one or more of the following:
  • USER (your user ID or logon ID)
  • PROG (the name of the executable program file)
  • TTY (the device name of your terminal)
  • GROUP (the user group identification)
  • Workload Definition File Configuration Guidelines

    Use the following guidelines to create or edit workload definition files:
  • Separate workloads by one or more blank lines.
  • Include comments on any line, if desired, preceded by an exclamation character (!).
  • A workload type specification is needed to indicate the types of processes to include or exclude from the workload definition. This makes it possible to create two workloads for processes that run in both interactive and batch modes. (Refer to Table 3.4.)
  • Program and user specifications are specified by:
  • PROG=program name
  • USER=user name/group name
  • System group names are valid specifications. Check the /etc/group file for a list of existing group names.
    For more information about group names, refer to your system documentation or the manpage for regexp (Regular Expressions).
  • Device file specifications, such as TTY=tty0p2, are also valid. You can capture activity on a terminal-by-terminal basis, or for multiple terminals.
  • There is no limit to the number of user, program, and tty specifications allowed for each workload.
  • Name and type specification lines are required. All other lines are optional.
  • To be included in a workload group, a process must satisfy the program, user, and tty specifications, if all three are present.
  • If one or more program specification lines are included, a program needs to satisfy only one of these to be included in the group.
  • If no program specifications are entered, all process programs are included in the group, unless the process is somehow disqualified by the user or tty specifications.
  • A process can belong to only one workload group. If it fits the criteria for two or more groups, it is assigned to the first workload in the file for which it qualifies.
  • Four workloads appear by default: INTERACT, DAEMON, BATCH, and DEFAULT. Processes that do not fit into user-defined workloads will be included in one of these pre-defined workloads.

  • Lund Performance Solutions
    www.lund.com
    Voice: (541) 812-7600
    Fax: (541) 81207611
    info@lund.com
    TOCPREVNEXTINDEX