You are viewing an old version of this page. View the current version.

Compare with Current View Page History

Version 1 Next »

\n

\n \n \n \n \n \n \n \n \n \n \n \n \n
Related DocumentationVersion of up.time affectedAffected Platforms
Working with Novell NRM SystemsAllNovell NRM
\n

\n \n

up.time captures the following Novell NRM system (version 6.5) statistics:

\n \n \n \n

Each statistic returns one of the following status options:

\n \n
    \n
  • Good \n

    The statistic is well within the threshold suspect value.

    \n
  • \n
  • Suspect \n

    The statistic is between the threshold good and critical values.

    \n
  • \n
  • Bad \n

    The statistic is greater than the threshold critical value.

    \n
  • \n
\n \n

Work To Do Response Time

\n \n

This statistic enables you to view how processes share the CPU. The \nresponse time is the amount of time that a Work To Do process requires \nto run.

\n \n

If this statistic returns a value of Suspect, you can check the \nrunning threads to determine why there is a delay in the Work To Do \nthreads. If the value is Bad, thread is probably running more than it \nshould or it is hung. You should identify the parent NetWare Loadable \nModule and then unload and reload it if possible.

\n \n

Allocated Service Processes

\n \n

This statistic enables you to view, as a graph, how the service processes are allocated on your server.

\n \n

If the service processes are approaching the maximum, increase the \nvalue of the Maximum Server Processes Set parameter. If you have only a \nfew available server processes, increase the Minimum Server Processes \nSet parameter.

\n \n

If the status is Bad, examine your server by doing the following:

\n \n
    \n
  1. In Novell NRM, click Profiling / Debugging.
  2. \n
  3. Check the information for server process functions.
  4. \n
  5. Change the Maximum Server Processes and the Minimum Server Process Set parameters.
  6. \n
\n \n

Available Server Processes

\n \n

This statistic enables you to view the number of available processes \non your server as a graph. The graph charts the processes that are \navailable every five seconds over a 50 second period.

\n \n

If the status is Suspect or Bad, increase the Set \nparameters for Maximum Server Processes and the Minimum Server \nProcesses settings. If the number of available server processes has not \nreached the maximum and is not increasing, add memory to \nyour server.

\n \n

Abended Thread Count

\n \n

This statistic enables you to view the threads that have ended abnormally (abended) and are suspended.

\n \n

If the status is Suspect or a Bad, your server has abended and has \nrecovered automatically by suspending the offending thread while \nleaving the rest of the server processes running. As a result, some of \nthe server's functions were compromised. You must determine which \nmodule, driver, or hardware the abended threads belong to, and then \ntake the appropriate action.

\n \n

CPU Utilization

\n \n

This statistic enables you view, as a graph, how busy any given CPU \nis. up.time tracks usage on a per CPU basis, collecting data every 30 \nseconds. The graph displays a 10 second history.

\n \n

If the status is Suspect or Bad, determine which thread or module is \ncausing the most CPU cycles and take appropriate action, including:

\n \n
    \n
  • Unloading and reloading the module.
  • \n
  • Reporting problems to the vendor of the module.
  • \n
  • Loading an updated module.
  • \n
\n \n

To determine which thread or module is using the most CPU cycles:

\n \n
    \n
  1. In Novell NRM, click Profile / Debug.
  2. \n
  3. Do one of the following: \n
      \n
    • View the Execution Profile Data by Thread data.
    • \n
    • Click Profile CPU Execution by NLM.
    • \n
    \n
  4. \n
\n \n

Connection Usage

\n \n

up.time monitors connections on a per-server basis. NRM displays only the following metrics:

\n \n
    \n
  • The number of connections that are being used.
  • \n
  • The peak number of connections used on this server.
  • \n
\n \n

Available Memory

\n \n

This statistic enables you to view the amount of memory that is not \nallocated to any service. Most, if not all, of this memory is used by \nthe file system cache. When available memory gets too low, modules \nmight not be able to load or file system access might become sluggish.

\n \n

DS Thread Usage

\n \n

This statistic enables you view the number of server threads that \nNovell eDirectory uses. The server thread limit ensures that threads \nare available for other functions as needed – for example, when large \nnumber of users log in at the same time.

\n \n

eDirectory uses multiple server threads. However, its thread \nrequirements should not cause poor performance because eDirectory \ncannot use more than its allocated maximum number of threads.

\n \n

If this statistic returns a Good status, eDirectory is using less \nthan 25% of the available server threads. If it returns a Suspect \nstatus, eDirectory is using between 25% and 50% of the available server \nthreads. If the status is Bad, eDirectory is using more than 50% of the \navailable server threads.

\n \n

Packet Receive Buffers

\n \n

This statistic enables you to view the status of Packet Receive \nBuffers for the server. Packet Receive Buffers transmit and receive \npackets. You can set the maximum or minimum number of buffers to \nallocate using the Maximum Packet Receive Buffers or Minimum Packet \nReceive Buffers SET parameters. The minimum number of buffers is the \nnumber of packets that are allocated at when the system is initialized.

\n \n

If the number of Packet Receive Buffers is increasing, the system \nwill be sluggish. If the number of Packet Receive Buffers reaches the \nmaximum, and no Event Control Blocks (ECBs) are available, the server \nwill become very sluggish and will not recover.

\n \n

Available Event Control Blocks (ECBs)

\n \n

This statistic enables you to view the status of available Event \nControl Blocks (ECBs). Available ECBs are Packet Receive Buffers that \nhave been created but which are not currently being used.

\n \n

If the available ECB count is zero, the server will become sluggish \nuntil enough ECBs are created to fill the demand. The server will \nrecover as long as the number of Packet Receive Buffers does not \nincrease to the maximum that can be allocated.

\n \n

LAN Traffic

\n \n

This statistic shows whether or not your server can transmit and \nreceive packets. If this statistic returns a Good status, the server is \nable to accept or transmit packets through the network board. If the \nstatus is Bad, the network board is not transmitting or receiving \npackets.

\n \n

All servers should be able to transmit or receive packets. If your \nserver is not transmitting, your LAN is not functioning properly. Check \nthe drivers and protocol bindings for the network board on the server. \nIf the drivers and protocol bindings are functioning properly, then the \nnetwork board is probably faulty. If the network board is functioning, \nyou should perform a diagnostic on your LAN.

\n \n

Available Disk Space

\n \n

This statistic enables you to view the status of the available disk \nspace on all mounted volumes on a server. This statistic returns the \nfollowing statuses:

\n \n

Disk Throughput

\n \n

This statistic enables you to view the status of amount of the data \nthat is being read from and written to the storage media on this server.

\n \n

If this statistic returns a Good status, then the storage system is \nexperiencing reads or writes, and there are no pending disk I/Os. If \nthe status is Suspect, the storage system has disk I/Os pending, no \nreads or writes have occurred, and less than four samples have been \ntaken. If the status is Bad, the storage system has disk I/Os pending, \nno reads or writes have occurred, and four or more samples have been \ntaken.

  • No labels