Answers to Chapter Review Questions

     
A1:

Glance has an associated data-collection daemon process ( midaemon ) that runs at an HP-UX real-time priority of 20. This means that when midaemon needs to collect data, it has a better opportunity of gathering the most up-to-date information from the kernel. The midaemon has direct access to performance metrics within the HP-UX kernel that other traditional UNIX performance tools do not have direct access to (traditional UNIX performance tools interface with the kernel simply via the /dev/kmem device file). Traditional UNIX performance utilities, like top , will have a process priority similar to other process in the system. As such, they will need to wait to be scheduled along with other processes. This delay in gathering information can cause utilities like top to give a slightly out-of-date picture of the current system performance. We could use nice/renice on commands like top to try to improve the chances of regaining the CPU quicker; we could even use real-time priorities, although we need to be careful that the performance measuring tools do not swamp the system blocking real application processes from running.

A2:

Understanding the distance between processors has a direct impact on the scheduling of threads. As far as HP-UX is concerned , this introduces the concept of locality domains into the scheduling algorithm (known as multiple scheduling allocation domains), whereby the scheduling algorithm will ensure that the processors within the given locality domain are chosen as the next best processor to execute a given thread. This policy is trying to eliminate the inherent latency involved in loading the data/code for a given thread into the cache for a processor in another locality domain. Even with an architecture such as Superdome where a non-blocking high-speed inter- cell crossbar connector is used, a latency in the order of +20 percent can be observed when accessing a memory location located in another locality domain. (This is the minimum latency observed. Even higher latencies can be observed when accessing cells located in a different cabinet in the system complex.)

A3:

Yes, variable page size can improve the overall performance of individual applications because an individual application can have encoded in the program header a hint as to the suggested page size for that individual application. When used, the hint will tell the operating system the size of an individual data/code page. This can result in a single page being larger than the default 4KB. When a process is executing, the operating system must translate the Virtual page addresses referenced by the process into Physical page addresses used by the operating system. While performing this translation, the process may be in a sleeping state. The fewer times the operating system needs to perform this translation, the fewer times the process will be asleep and will spend more time executing. This hint used in the program header may not be adhered to if system memory usage is such that the hint cannot be satisfied. For individual programs, we use the chatr command to set the hint. For the operating system itself (known as transparent selection), we use the kernel parameter vps_ceiling (if vps_ceiling is mentioned as the way we set control vps usage for individual processes, then the answer is technically wrong). The maximum size of the hint is controlled by the kernel parameter vps_chatr_ceiling .

A4:

Application isolation relates to the fact that within a Processor Set only specified processes/threads are allowed to execute. A group of users needs to have the PSET privilege in order to execute commands such as psrset . If a user does not have this privilege, only superusers can set up and control the use of Processor Sets. In this way, we can set up a group of processors dedicated to a given application. Not only does this ( potentially ) cut down the number of context switches between all other runnable processes on the system, Processor Sets mean that the processes/threads running on the specified processors have a greater chance of finding their code/data within the cache of the associated processors. Not having to unload/reload the data/code cache of a processor continuously can have a dramatic impact on application performance.

If we have PRM installed in our system, using PRM to manage Processor Sets is administratively simpler because the configuration of Processor Sets is contained within the PRM configuration file. The default Processor Set software does not come with a configuration file; the defined Processor Sets do not survive a reboot, which means that we need to set up a configuration file and/or a startup script manually.

A5:

The symptoms would seem to indicate that a potential memory bottleneck is causing additional pressure on the IO subsystem. The fact that system CPU utilization is above 50 percent would indicate that operating system code is being executed more than user code. Which system processes are executing: vhand , swapper , syncer ? Are any page-outs occurring? If so, this is a direct indication of memory pressure. This will also add additional pressure to the IO subsystem, accentuating any IO bottleneck. The fact that the operators seem to think the majority of disks are constantly being accessed is the only indication that may point to an IO problem. This needs further investigation. Are many processes "blocked on IO"? What is the buffer cache hit rate? Are processes performing physical or logical IO? If they are performing physical IO while the buffer cache hit rate is high, we need to try to establish why processes are performing physical IO. Most of the time, processes should be performing logical IO (through the filesystem) with the buffer cache offering processes a "staging post" for data that is currently active. Some applications may need to write directly to disk (synchronous IO) because the data in question is critical and they perform their own internal buffering. If we can establish that applications are operating in this way, we can use techniques such as disabling the use of the buffer cache for particular VxFS filesystems (micache=direct mount option). This may mean that we can reduce the size of the overall dynamic buffer cache requirement. This in turn will release memory back to user processes, which may in turn reduce the overall memory pressure.



HP-UX CSE(c) Official Study Guide and Desk Reference
HP-UX CSE(c) Official Study Guide and Desk Reference
ISBN: N/A
EAN: N/A
Year: 2006
Pages: 434

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net