| The first source of information is always the documentation for your system. Hardware vendors such as Hewlett-Packard provide copious amounts of information in paper form, on CD-ROM/DVD, or on online. An invaluable and free source of information is the HP documentation Web site: http://docs.hp.com. Next , we look at some utilities available on your systems themselves . I assume that you are familiar with commands like ioscan , diskinfo , and dmesg . In Chapter 6, "Monitoring System Resources," we discussed the STM Diagnostic suite of programs. These are exceptionally useful for finding information relating to processor speed, memory bank configuration, and disk drive errors, as well as diagnostic information logged by the diagnostic daemons. Another way to gather information from your system is to extract values directly from the kernel. This is a problem because you must know the kernel variables that you are looking for in order to extract their values. Here are some examples: To get the speed of your processor:
root@hpeos003[] echo "itick_per_usec/D" adb /stand/vmunix /dev/kmem itick_per_usec: itick_per_usec: 750 root@hpeos003[]
To establish how much memory is configured ( expressed in number of pages; 1 page = 4KB):
root@hpeos003[] echo "phys_mem_pages/D" adb /stand/vmunix /dev/kmem phys_mem_pages: phys_mem_pages: 262144 root@hpeos003[]
This equates to 262,144 pages at 4KB per page, which is 1GB of physical RAM. The amount of free memory that we currently have (again, expressed in pages) is:
root@hpeos003[] echo "freemem/D" adb /stand/vmunix /dev/kmem freemem: freemem: 196867 root@hpeos003[]
The next example explores what happens when we get to a situation where we are trying to diagnose a significant memory shortage. Trying to run any performance- related commands is difficult. There is a kernel parameter that can send diagnostic information to the console. The parameter is vhandinfoticks . If we set this to a value representing a time period , every time period we will get info from the kernel regarding the virtual memory system usage. This information is useful only to a Response Center Engineer if you are having serious virtual memory problems. Below I have set the time period to 10 seconds; 1 tick = 10 milliseconds , 1000 ticks = 10 seconds:
root@hpeos003[] echo "vhandinfoticks/D" adb /stand/vmunix /dev/kmem vhandinfoticks: vhandinfoticks: 0 root@hpeos003[] root@hpeos003[] echo "vhandinfoticks/D" adb /stand/vmunix /dev/kmem vhandinfoticks: vhandinfoticks: 0 root@hpeos003[] echo "vhandinfoticks/W3E8" adb -w /stand/vmunix /dev/kmem vhandinfoticks: 0 = 3E8 root@hpeos003[] root@hpeos003[] echo "vhandinfoticks/D" adb /stand/vmunix /dev/kmem vhandinfoticks: vhandinfoticks: 1000 root@hpeos003[]
The last of these examples is a kernel variable that I think is quite useful. The kernel variable is called boot_string . The kernel maintains it at boot time, and it shows the ISL command used to boot the system. This kernel variable also shows us the hardware path of the disk we booted from; this is sometimes useful in a mirrored disk configuration:
root@hpeos003[] echo "boot_string/S" adb /stand/vmunix /dev/kmem boot_string: boot_string: disk(0/0/1/1.15.0.0.0.0.0;0)/stand/vmunix root@hpeos003[]
I have also included the source code for two C programs, one called infocache32 the other called infocache64 (see Appendix B for the source code for both programs). The reason for two is that there are two separate but similar system calls used in both programs: nlist() and nlist64() . nlist() is for a 32-bit architecture, while nlist64() is for a 64-bit architecture. PA-RISC 2.0 supports 64-bit or 32-bit HP-UX, while PA-RISC 1.X supports only 32-bit HP-UX. To check whether your system is 32-bit or 64-bit capable, run this command:
root@hpeos002[] # getconf HW_CPU_SUPP_BITS 32 root@hpeos002[] #
If we see the value 32 , this means that we only support 32-bit HP-UX. A value of 32/64 means that we can support either 32-bit or 64-bit HP-UX, while a value of 64 means that we support only 64-bit PH-UX. There is also a kernel parameter that details which architecture we are running with:
root@hpeos002[] # nm /stand/vmunix grep cpu_arch cpu_arch_is_1_0 9959824externdata $SHORTDATA$ cpu_arch_is_1_1 9959760externdata $SHORTDATA$ cpu_arch_is_2_0 9959996externdata $SHORTDATA$ root@hpeos002[] # root@hpeos002[] # echo "cpu_arch_is_2_0/D" adb /stand/vmunix /dev/kmem cpu_arch_is_2_0: cpu_arch_is_2_0: 0 root@hpeos002[] #
We also need to be sure that we are actually running 32-bit HP-UX because a 64-bit machine could have been running HP-UX version 10.20 and upgraded to 11.X. This would mean that the operating system was still 32-bit. We can check the bit- size of the kernel by using getconf again:
root@hpeos003[] getconf KERNEL_BITS 64 root@hpeos003[]
This has a direct impact on which version of infocache we use and how to compile it: I have seen many incarnations of this program over time. Recently, I saw a version on Hewlett-Packard's IT Resource Center (http://itrc.hp.com). Below, you can see the output from building and running infocache on an HP 715 running HP-UX 11i as well as an A500 server.
root@hpeos002[] # getconf KERNEL_BITS 32 root@hpeos002[] # model 9000/715/G root@hpeos002[] # ll infocache32.c -rw-r----- 1 root sys 2336 Aug 10 18:46 infocache32.c root@hpeos002[] # cc +DD32 -lelf -o infocache32 infocache32.c root@hpeos002[] # ./infocache32 Kernel = /stand/vmunix HW page size is 4096 bytes HW TLB walker present TLB is unified TLB size is 64 entries Cache is separate I cache size is 131072 bytes (room for 32 pages) D cache size is 131072 bytes (room for 32 pages) One cache line is 32 bytes Cache lines per chunk: 1 root@hpeos002[] #
This is the same program, but it was compiled and run on a 64-bit machine (an A500 server):
root@hpeos003[] model 9000/800/A500-7X root@hpeos003[] root@hpeos003[] getconf KERNEL_BITS 64 root@hpeos003[] root@hpeos003[] echo "cpu_arch_is_2_0/D" adb /stand/vmunix /dev/kmem cpu_arch_is_2_0: cpu_arch_is_2_0: 1 root@hpeos003[] ll infocache64.c -rw-r----- 1 root sys 2344 Nov 22 12:48 infocache64.c root@hpeos003[] cc +DD64 -lelf -o infocache64 infocache64.c root@hpeos003[] ./infocache64 Kernel = /stand/vmunix HW page size is 4096 bytes NO HW TLB walker TLB is unified TLB size is 240 entries Cache is separate I cache size is 786432 bytes (room for 192 pages) D cache size is 1572864 bytes (room for 384 pages) One cache line is 64 bytes Cache lines per chunk: 1 root@hpeos003[]
| 