Kernel Parameters

1. bufpages
   Bufpages specifies how many 4096-byte memory pages are allocated for the file system buffer cache. These buffers are used for all file system I/O operations, as well as all other block I/O operations. Bufpages meant much more prior to having dynamic buffer cache (9.X on workstations, 10.X on servers). dbc_min_pct and dbc_max_pct are the appropriate parameters to use now.

   Back to the Top

   In HP-UX 10.X, it is recommended this kernel parameter be set to 0. This will enable dynamic buffer cache.

2. create_fastlinks
   When equal to '1', this tells the kernel to store the path name of the "linked-to" file in the inode, rather than in a data block. This reduces disk space usage and eliminates a disk I/O to retrieve the name. By default, this feature is disabled for backward compatibility. We recommend all systems have create_fastlinks enabled by setting this kernel parameter to 1.

   Back to the Top

3. dbc_max_pct
   This parameter determines the percentage of main memory to which buffer cache is allowed to grow. When performing a large amount of block I/O, the system will "grow" the buffer cache to this maximum size. If the system begins to feel pressure due to process space memory requirements, the kernel will shrink buffer cache. The problem arises when there is stress due to process space requirements, and, there is block I/O pressure. The system tries to reclaim buffer cache pages to allocate them to running processes. But the system is also trying to allocate as much buffer cache as it can, causing a vicious cycle of allocating and deallocating memory between buffer cache and process memory space, creating a large amount of overhead. There is a good chance that your system is paging at this point, which is causing even more overhead.

   The idea then, is to keep this number reasonably low, allowing you to have cache space but also keep the application space large enough to avoid high levels of conflict between them. The default value is 50%, but we recommend 25% to start. We have seen systems that need buffer cache to have a max of as little as 5%, with a min at 2%. We have also seen systems that require 80 to 90% buffer cache. You need to determine if your system is going to be used for applications performing large amounts of block I/O, or very little I/O but large (or many) processes, or both. If the answer is "both", you will need an enormous amount of physical memory.

   Back to the Top

4. fs_async
   This kernel parameter controls the manner in which writes of file system meta structures are performed. Asynchronous writes to disk can improve file system I/O performance significantly. However, synchronous writes to disk make it easier to restore file system integrity if a system crash occurs while file system meta structures are being updated. Depending on the application, you will need to decide which is more important.You may value file system integrity more than I/O speed. If so, fs_async should be set to 0.

   Back to the Top

5. hpux_aes_override
   This value is part of the OSF/AES compliance. It controls directory creation on automounted disk drives. We recommend hpux_aes_override be set to 1. If this value is not set, you may see the following error message:

   mkdir: cannot create /design/ram: Read-only file system.

   This system parameter cannot be set using SAM. The kernel must be manually created. It is best to modify the other parameters with SAM first and then change this parameter second, otherwise SAM will override your 'unsupported' value with the default.

   NOTE: Apply patch PHCO_11647 if you use this parameter on HP-UX 10.X. Failure to do so can cause some "apparent" corruption in parts of the file system where trasnition links occur.

   Back to the Top

6. maxdsiz
   Maxdsiz defines the maximum size of the data segment of a process. The default value of 64 MB is too small for most applications. We recommend this value be set to the maximum value of 1.9Gb. If maxdsiz is exceeded, the process will be terminated, usually with a SIGSEGV (segmentation violation) and you will probably see the following message:

   Memory fault(coredump)

   In this case, review the values of maxdsiz, maxssiz and maxtsiz. For more information on these parameters, please see the on-line Help section within SAM's Kernel Configuration. If you need to exceed the specified maximum of 1.9Gb, there are a couple of ways (yet to be supported) to do so. Contact your Hewlett Packard technical consultant for the details. It is important to note that the maxdsiz parameter must be modified in order for these procedures to work. Maxdsiz will need to be set to 2.75Gb or 3.6Gb depending on the method chosen and/or size required. It will also require a manual creation of a new kernel.

   Back to the Top

7. maxfiles
   This sets the soft limit for the number of files a process is allowed to have open. We recommend this value be set to 200.

   Back to the Top

8. maxfiles_lim
   This sets the hard limit for number of files a process is allowed to have open. The default for this kernel parameter, and our recommendation, is 2048.

   Back to the Top

9. maxssiz
   Maxssiz defines the maximum size of the stack of a process. The default value is 8Mb. We recommend this value be set to a value of 79 Mb.

   Back to the Top

10. maxswapchunks
    This (in conjunction with some other parameters) sets the maximum amount of swap space configurable on the system. Maxswapchunks should be set to support sufficient swap space to accommodate all swap anticipated. Also remember, swap space, once configured, is made available for paging (at boot) by specifying it in the file /etc/fstab (/etc/checklist on 9.X). The maximum swap space limit calculated in bytes is: (maxswapchunks * swchunk * DEV_BSIZE). We recommend this parameter be set to 4096.

    NOTE: Never modify the kernel parameter, swchunk.

    Back to the Top

11. maxtsiz
    Maxtsiz defines the maximum size of the text segment of a process. We recommend 1024 MB.

    Back to the Top

12. maxuprc
    This determines the number of concurrent processes that a user can run. A user is identified by the user ID number. Maxuprc is used to keep a single user from monopolizing system resources. If maxuprc is too low, the system issues the following error message to the user when attempting to invoke too many processes:

    no more processes

    We recommend maxuprc be set to 200.

    Back to the Top

13. maxusers
    This kernel parameter is used in various algorithms and formulae throughout the kernel. It is used to limit system resource allocation and not the actual number of users on the system. It is also used to define some system table sizes. The default values of nproc, ncallout, ninode and nfile are defined in terms of maxusers. We are recommend fixed values for nproc, ninode and nfile. Set maxusers to 124.

    Back to the Top

14. netmemmax
    This specifies how much memory can be used for holding partial internet-protocol(IP) messages in memory. They are typically held in memory for up to 30 seconds. The default of 0 allows up to 10% of total memory to be used for IP level reassembly of packet fragments. Values for netmemmax are specified as follows:

    Value	Description
    -1	No limit, 100% of memory is available for IP packet reassembly.
    0	netmemmax limit is 10% of real memory.
    >0	Specifies that X bytes of memory can be be used for IP packet reassembly. The minimum is 200 Kb and the value is rounded up to the next multiple of pages (4096 bytes).

    If system network performance is poor, it might be because the system is dropping fragments due to insufficient memory for the fragmentation queue. Setting this parameter to -1 will improve network performance, but, at the risk of leaving less memory available for processes. We recommend it be set to -1 for systems acting as data servers only. For all other systems, we recommend a setting of 0.

    Back to the Top

15. nfile
    Nfile sizes the system file table. It contains entries in it for each instance of an open of a file. Therefore, it restricts the total number of concurrent "opens" on your system. We suggest that you set this at 2800. This parameter defaults to ((16 * (nproc + 16 + maxusers) / 10 ) + 32 + 2 * npty). If a process attempts to open one more (than nfile) file, the following message will appear on the console:

    file: table is full

    When this happens, running processes may fail because they cannot open files, and no new processes can be started.

    Back to the Top

16. ninode
    Ninode sizes the in-core inode table, also called the inode cache. For performance, the most recently accessed inodes are kept in memory. Each open file has an inode in the table. An entry is made in the table for each "login directory", each "current directory", each mount point directory, etc. It is recommended that ninode be set to 15,000.

    NOTE: On a multi-processor system running HP-UX 10-20, ninode should NOT exceed 4000. This is due to a spinlock contention problem that is fixed in 11.0.

    Back to the Top

17. nproc
    Nproc sizes the process table. It restricts the total number of concurrent processes in the system. When some person/process attempts to start one more (than nproc) process, the system issues these messages:

    at console window : proc: table is full
    at user shell window: no more processes

    Set nproc to 1024.

    Back to the Top

18. npty
    This parameter limits the number of pty data structures that can be opened. These are used by network programs like rlogin, telnet, xterm, etc. We recommend this parameter be set to 512.

    Back to the Top

Kernel Parameter Recommendations

The following are the suggested kernel parameter values.

Networks

In today's networked environments, many installations are client/server configurations. Therefore, network configuration is critical to overall performance and throughput. One HP workstation can almost saturate a single ethernet wire with heavy traffic. See the section labeled Networking later in this document for tuning and configuration guidelines.

Back to the Top

1. NFS

   Network configuration will also have an impact on performance. Virtually all installations use some form of local area network to facilitate sharing of data files and to simplify system management. Most installations use NFS to mount remote file systems. This imposes a performance penalty, however, because the I/O bandwidth for accessing data on an NFS mounted disk is less than that for a directly connected disk. There are a few system configuration recommendations that can be made to maximize the convenience that NFS and the local area network provide while minimizing the performance penalty.

   • NFS configuration. On NFS servers, a good first order approximation is to run two nfsd processes per physical disk (spindle). The default is four total, which is certainly not enough on a server. On 9.x systems, too many nfsd processes can cause context switching bottlenecks, because all the nfsds are awakened any time a request comes in. On 10.x systems, this is not the case and you can safely have extra nfsd processes. Start with 30 or 40 nfsd's. On NFS clients run sixteen biod processes. In general, HP-UX 10.X has much better NFS performance than previous versions of HP-UX.
   • Patches - Always install the latest HP-UX NFS patch. HP periodically releases patches that correct problems associated with NFS, many of them performance related. If you are using NFS, you should make sure the latest patch is installed on both the client and server. See the PATCHES section for more details. General HP-UX patch information can be found at http://us-support.external.hp.com for the Americas and Asia. For europe and others, use http://europe-support.external.hp.com/.
   • Local vs. Remote. You will need to determine which things you will NFS mount, and which should be local. For performance, it would be great if nothing was accessed over the network. And "if wishes were horses, dreamers would ride", said John Butcher. Consider doing some of these things and using some of the techniques described near the end of this document, under "NFS".
   • Subnetting. In general, it is a bad idea to have too many systems on a single wire. Implementation of a switched ethernet configuration with a multi host server or a server backbone configuration can preserve existing wiring while maximizing performance. If you are doing rewiring, seriously consider using fiber for future upgradability.
   • Local paging. When applications are located remotely, set the "sticky bit" on the applications binaries, using the chmod +t command. This tells the system to page the text to the local disk. Otherwise, it is "retrieved" across the network. Of course, this would only apply when there is actual paging occurring. More recently, there is a kernel parameter, page_text_to_local, which when set to 1, will tell the kernel to page all NFS executable text pages to local swap space.
   • File locking. Make sure the revisions of statd and lockd throughout the network are compatible; if they are out of sync, it can cause mysterious file locking errors. This particularly affects user mail files and Korn shell history files.
   • Design the lan configuration to minimize inter segment traffic. To accomplish this you will have to ensure that heavily used network services (NFS, licensing, etc.) are available on the same local segment as the clients being served. Avoid heavy cross segment automounting.
   • Maximize the usage of the automounter. It allows you to centralize administration of the network and also allows greater flexibility in configuring the network. Avoid the use of specific machine names which may change over time in your mount scheme; force mount points that make sense. /net ties you to a particular server, which may change over time.
   • You can watch the network performance with Glance, the netstat command, and the nfstat command. There are other tools like NetMetrix or a LAN analyzer to watch lan performance. Additionally, you can use PerfView and MeasureWare/UX to collect data over time and analyze it. You may want to tune the timeo and retrans variables. For HP systems, small numbers 4 for retrans and 7 for timeo are good. The default values for wsize and rsize, 8K, are almost always appropriate. Do NOT use 1024 unless talking to an Apollo system running NFS 2.3 on SR10.3. 8K is appropriate for 10.4 Apollos running NFS 4.1.
   • Investigate the use of dedicated servers for computing, file serving, and licensing. A good scenario has a group of dedicated servers connected with a fast "server backbone", which is then connected to an ethernet switch, which is itself connected to the desktop systems.

   Make sure that ninode is at least 15000 on HP-UX 10.X. Remember to not go above 4000 on an HP-UX 10.20 system with multi-processors, as previously stated. Some customers have seen performance degradation on Multi Processor systems when ninode is greater 4000. Check it on your system. The details of this problem are much too detailed and complicated for this document.

   NFS file systems should be exported with the async option in /etc/exports.

   Some items that can be investigated...

   nfsd invocations

   • nfsstat -s

   UDP buffer size

   • netstat -an | grep -e Proto -e 2049

   How often the UDP buffer overflows / UDP Socket buffer overflows

   • netstat -s | grep overflow

   NFS timeouts...are they a result of packet loss? Do they correlate to errors reported by the links? Use lanadmin() or netstat -i to check this.

   IP fragment reassembly timeouts?

   • netstat -p ip

   mounting through routers?

   • check to see if routers are dropping packets

   check for transport bad checksums

   • netstat -s

   is server dropping requests as duplicates?

   • nfsstat

   is client getting duplicate replies? (badxid)

   • nfsstat on CLIENT

   Some customers have mentioned that they have had serious problems because of too many levels of hierarchy within the netgroup file. It seems that this file is re-read many times, and the more hierarchy, the longer it takes to read.

   Back to the Top

Patches

Since patch numbers change frequently, it is recommended that you always check for the latest information. Here are some general recommendations:

• Always load the latest kernel "megapatch", ARPA transport patch, NFS/automounter patches, statd/lockd patches, and SCSI patch. Many performance and reliability improvements are delivered by these patches.
• Load the latest C compiler and linker patches.
• Load HP-VUE or CDE, and X/Motif patches at your discretion. These usually contain bug fixes.
• Load the latest X server patches.

1. How to get patches. If you have WWW access go to http://us-support.external.hp.com, and follow the links to the patch list. This is also a good way to browse the latest patch list. You can also get patches by e-mail. If you know what the name of the patch you want is, send a message to support@support.mayfield.hp.com, with the text "send patchname". Don't forget to substitute the name of the patch you want for "patchname". You can get a current list by sending the text "send patchlist". To get a complete guide on using the mail server, send the text "send guide". If you have HP SupportLine access, then patches can be requested from the HP SupportLine at (800)633-3600, and are also available for FTP access.

   Back to the Top

2. How to tell what patches are loaded. First scan the directory /etc/filesets (9.x) systems, or use the swlist command (10.x). Patches are named PHxx_nnnn, where xx can be KL, NE, CO, or SS. nnnn refers to the patch number, which is always unique no matter what PHxx category is specified. If a patch has been loaded on a 9.x system, a file will exist in /etc/filesets, with the same name as the patch. If a patch has been loaded on a 10.x system, the patch should be listed in the output of swlist.

   Back to the Top

3. How to load patches. Patches are shipped as shell archives, named after the patch. Unpack the shell archive, check the README file and follow the directions.

   Back to the Top

4. Patch management. Patch management can be a fulltime job for a large site. HP recommends that large sites that don't want to tackle that particular task purchase the PSS support option. This service provides a consultant who, among other things, provides patch management. It's well worth the money.

   Back to the Top

Performance and the PATH Variable

1. The PATH Variable

   This is one of the most abused areas that causes performance problems. PATH variables that are way too long AND the positioning of the directory that contains the most frequently used tools (by the application), at the end. Try to limit your PATH statement to the paths that are most useful to your primary application. Consider writing startup scripts (wrappers) for the lesser used applications. In these wrappers, you may embed additional PATH statements to meet the needs of the application.

   Back to the Top

HP-UX 11.0

As of this revision, I feel it is "early in the game" to detail everything for 11.0. I do think it is appropriate to discuss various aspects of 11.0, specifically those that seem to be problematic.

Back to the Top

1. Points of Interest

   "FALSE" DEACTIVATIONS. There is an issue regarding process deactivations when there seems to be NO paging. The following is the description and patch and recommended work around AS OF THIS DATE (MARCH 17, 2000).

   This applies to BOTH 10.X and 11.X versions of HP-UX.

   When there are memory mapped files, the writes show up as pageouts to disk, even though there really is NO MEMORY PRESSURE. Part of the problem is/are the kernel NFS routines. If the pageout rate is anything but zero, there is a change in the logic that assumes (incorrectly) that we are under memory pressure. It causes a process to fire up and start purging buffer cache pages. This causes a performance degradation, especially if the system has a large buffer cache.

   Patch PHKL_17869 added a new counter in the kernel, k_pageout_count, used by thrashing logic to see if we are under memory pressure. This "corrects" the deactivation issues...BUT...the macro (in bcache.h) that NFS relies upon to determine if we are under memory pressure was NOT changed...it still uses the "old" counter for pageout count. It reflects cumulative pageouts including memory mapped I/O files.

   Anything that references the old counter is getting a skewed view of whether we're under memory pressure or not. Because NFS thinks that we're under pressure, it tries to "re-use" a bunch of internal kernel structures. The overhead and bookeeping to do this is causing performance problems. It REALLY should use the new counter.

   Typically (until the kernel can be modified), the way to get around the problem...reduce the size of buffer cache. This is actually what the response center will recommend to any customer that appears to be suffering from this exact problem.

   FALSE SENSE OF PAGING. There is a situation apparent (seemingly) on 11.X systems only, where the system appears to paging when there is absolutely no memory pressure. I have seen systems with as much as 3 or 4GB free and pageouts to disk are occurring. The issue is with applications that are performing operations on memory mapped files. It seems that memory mapped writes are causing this pageout activity. As of this date (March 15, 2000), I have yet to find/get an explanation of why this happens.

   This is not pageout in the sense that the system is under memory pressure. I am currently working on an explanation. Once the "mystery" :-) is solved, it should be apparent whether it is the kernel that should be modified...or the tools that are reporting the paging activity.

   PLEASE NOTE:

   The following paragraph was written in June 1999. It may be obsolete information now, but I wanted to keep it in the paper. You may want to check for a patch, and if it exists, check for installation and/or install it.

   As of this writing, there is a problem that causes the system to crash. Currently, there is no patch for it, but, there is a work-around. Until patched, you must make sure that the kernel parameter page_text_to_local is is turned off ('0') AND executables have the sticky bit turned OFF. Refer to the manual pages for chmod(1), if you need to know more about the sticky bit.

   Back to the Top

2. lotsfree, desfree and minfree

   There are three kernel parameters that have recently become tuneable by mortals. They are the "paging" parameters lotsfree, desfree and minfree. These parameters define thresholds that the kernel uses to determine swapper/vhand (the page daemon) behavior. Here is the short version, in english (sort of :-)), of how these parameters are used...

   lotsfree -- vhand begins to "age" pages. There is another parameter that is dynamically modified, gpgslim, which is where vhand begins to "steal" pages. gpgslim starts at one quarter the distance between desfree and lotsfree, and "moves" between them, based on memory pressure.

   desfree -- more serious, more furious :-) paging begins here. Much of vhand's behavior is modified at this point... how often it wakes up, how many pages to look at, what is the distance between the age and steal hands, how many pages to steal, etc.

   minfree -- at this point, the system is deactivating processes. In the "old" days this would have been where swapping took place. We no longer swap processes.

   I have noticed, on several occasions, that these parameters have been set way too high. It was very apparent on several V class machines. The suggested values are:

   on a system with up to 2GB of memory:

   • lotsfree no larger that 8192 (32MB)
   • desfree no larger than 1024 (4MB)
   • minfree no larger than 256 (1MB)

   on a system with 2GB to 8GB of memory:

   • lotsfree no larger than 16384 (64MB)
   • desfree no larger than 3072 (12MB)
   • minfree no larger than 1280 (5MB)

   on a system with a whole group of memory:

   • lotsfree 131072
   • desfree 32768
   • minfree 8192

   Back to the Top

3. Text, Data and Shared Objects Maximum Values

   The "new" maximums for text, data and shared objects on 64 bit HP-UX, for a 64 bit executable are 4TB for both text and data and 8TB combined for shared objects. The maximum size of any single shared object is 1GB.

   Back to the Top

4. EXEC_MAGIC

   A EXEC_MAGIC executable is only "legal" if it is a 32 bit application on either 64 or 32 bit HP-UX. The "old" maximums are still in effect... 1.9GB of data space, unless the "current" documented malloc() and mallopt() call combination is used. In that case, you have just under 4GB as a maximum.

   Back to the Top

5. The New Parameters for Text, Data and Stack

   Don't forget to adjust the new parameters maxtsiz_64bit, maxdsiz_64bit and maxssiz_64bit to meet your application requirements.

   Back to the Top

6. Variable Size Pages

   The chatr() command

   Let's talk a little bit about chatr() first. The command gets its' name from change attribute. It will change a programs' internal attributes. The man page tells you that by default, chatr() prints each file's magic number and file attributes. Let us digress... if you do not "know" magic numbers, or, more important - if you do not know HOW THE HECK to interpret what chatr() is displaying vs. what the man page describes as the magic number...yer DEAD. For example, when chatr()'ing an EXEC_MAGIC, you will see "normal executable" as the first attribute. You obviously know that this means EXEC_MAGIC...right? :-). If you were to od() the executable (-x), you would see that the third and fourth bytes were 0107. Obvious, eh? I think not. Check out the man page for magic(4). You will see that the first group of "#define" statements that you encounter will actually use the words like EXEC_MAGIC and the associated hex number like 0x107 AND the comment field will look something like /* normal executable */. For example:

       #define EXEC_MAGIC      0x107   /* normal executable */
   

   Whew!...had enough? Get it? OK. Let's move on.

   The only machines that support variable pages are the PA-8000 and any "follow-ons" based on the PA 2.0 arcitecture. Partial support of variable size pages has existed since HP-UX 10.20.

   The Benefits

   First, we need to take a look at the Translation Lookaside Buffer (the tlb). It is a small, high speed piece of hardware. The "current" sizes are:

   • PA8000 - 96 entries
   • PA8200 - 120 entries
   • PA8500 - 160 entries
   There are NO hardware walkers. There ia a large penalty (cycle time) to perform tlb miss handling. Applications with large data sets will spend a lot of time handling tlb misses.

   Using variable sized pages:

   • a larger piece of virtual space can be mapped with a single tlb entry
   • large reference sets can be mapped with fewer tlb entries
   • fewer entries result in fewer tlb misses.
   Many/most applications will NOT realize a performance increase. An application that spends very little time handling tlb misses will not improve much, if at all.

   How Do I Use Variable Sized Pages?

   Determine the page size that seems to be best for the application. Set the appropriate page size for text and/or data pages. Use the chatr() command to do this.

   • +pi used for text pages
   • +pd used for data pages
   Valid page sizes range from 4K to 256MB. Take care when using the -L option (Large). This option requires that the user executing the application posess MLOCK privelege (see setprivgrp(1m)).

   New Kernel Parameters

   There are three new kernel parameters, tunable by you. They are:

   • vps_pagesize
     • default/minimum page size selected
   • vps_ceiling
     • maximum page size selected by the kernel
   • vps_chatr_ceiling
     • maximum size page that can be chatr()'d

   Variable Page Size "Inhibitors"

   OR...why am I not getting my variable sized pages? I cannot go into the technical details here, but, you can find the more verbose explanation of the reasons in the white paper on variable sized pages. Here is my "list" of reasons.

   • physical memory size
   • dynamic buffer cache
   • start of virtual alignment
   • re-running a recently chatr()'d application
   • page demotion
   • physical size inflation (performance degradation)

7. Memory Windows

   Why Use Memory Windows?

   In HP-UX 10.X, the limitation on the maximum (total) size of shared "objects" is 1.75GB system wide. Typically, there are many processes sharing a limited amount of memory. This memory is utilized by all processes using any/all of the "shared object" stuff...shared memory, shared libraries and memory mapped files. Often just three or four processes need all or most of the available memory. It should be noted that only 32 bit processes are affected by this limitation. With a 8TB limitation on shared object space in 64 bit land, I assume it will be a couple of months before one of you require more! More important...ya don't need memory windows.

   Disadvantages

   Applications using a memory window cannot "see" any other memory window. Also, the current memory window is inherited accross fork(). This could cause starnge behaviour. And...should applications in multiple memory windows have a need to communicate, they would need to use the standard system wide shared memory space, .75GB in the 4th quadrant.

   When Should Memory Windows Be Used?

   On HP-UX 10.X, you could not have (even) two "sets" of processes, each sharing a 1GB segment of shared memory. This is just impossible when the total amount of shared space is 1.75GB (actually, less). On 11.X you can have multiple sets of processes, each sharing 1GB of memory. A typical example of this would be multiple instances of Oracle, SAP, etc. So. Sites or users that need to run multiple concurrent processes or applications that require the sharing of LARGE amounts of memory, should use memory windows.

   Memory Window Usage

   Memory windows are created programmatically with two new system calls, getmemwindow(2) and setmemwindow(2). If you are familiar with ipcxxx(2) type system calls, these are similar. Be aware of the new kernel paramater max_mem_window. It defaults to 0, so make sure you modify it.

   *LARGE* Memory Windows

   When using memory windows as discussed above, the "global window" (typically the first one) could get a maximum of 1.75GB, and each memory window thereafter could get 1GB. One could obtain 2.75GB for the global and 2GB for sny subsequent windows. This can be accomplished with a SHMEM_MAGIC executable. You make an executable SHMEM_MAGIC using the -M option to ld(), or the -M option to chatr().

   The REAL maximums...I always tell people that you will actually get...2.75GB (or 1.75GB) MINUS all shared memory space currently in use, MINUS all shared library space currently in use, MINUS all memory mapped file space currently in use. I have seen as much as 2.6GB.

8. Spinlock Pool Parameters

   This was "borrowed" from the web page on Configurable Kernel Parameters.

   The following parameters, all related to spinlock pools for multi-processor computers, are used similarly and are documented together here. Each parameter allocates the specified number of spinlocks for the corresponding system resource:

   bufcache_hash_locks

   Buffer-cache spinlock pool

   chanq_hash_locks

   Channel queue spinlock pool

   ftable_hash_locks

   File-table spinlock pool

   io_ports_hash_locks

   I/O-port spinlock pool

   pfdat_hash_locks

   Pfdat spinlock pool

   region_hash_locks

   Process-region spinlock pool

   sysv_hash_locks

   System V Inter-process-communication spinlock pool

   vnode_cd_hash_locks

   Vnode clean/dirty spinlock pool

   vnode_hash_locks

   Vnode spinlock pool

   These parameters are for use by advanced users only who have a thorough understanding of how spinlocks are used by multiple processors and how the number of spinlocks needed are related to system size and complexity. Do not change these from their default value unless you understand the consequences of any changes. In general, these values should not be altered without the advice of HP support engineers who are thoroughly familiar with their use.

   Setting these parameters to inappropriate values can result in severe performance problems in multi-processor systems.

   Following is a list of acceptable values. All of these parameters have the same minimum and maximum values. Only the defaults are different as indicated:

   Minimum

   64

   Maximum

   4096

   Default

   64 (ftable_hash_locks, io_ports_hash_locks)

   Default

   128 (bufcache_hash_locks, pfdat_hash_locks, region_hash_locks, sysv_hash_locks, vnode_hash_locks, vnode_cd_hash_locks)

   Default

   256 (chanq_hash_locks)

   Specify a value that is an integer exponent of 2. If you specify any other value, SAM or the kernel itself changes the parameter value to the next larger integer exponent of two (for example, specifying 100 results in the spinlock-pool value of 128.

   Description

   In simple terms, spinlocks are a mechanism used in multiple-processor systems to control the interaction of processors that must be held off while waiting for another processor to finish a task so the results can be passed to the waiting processor. Spinlocks control access to file-system vnodes, I/O ports, buffer cache, and various other resources.

   Earlier HP-UX versions allocated a fixed number of spinlocks for all resources, but beginning at HP-UX 11.0, spinlocks can be allocated for each resource type to accommodate very large and complex systems.

   In general, if the system is encountering lock contention problems that are associated with one of these hashed pools, first identify the resource spinlock pool that is associated with the contention, then increase the spinlock-pool parameter for that resource. Spinlock pools are always an integer power of two. If you specify a value that is not, the kernel always allocates a value that is the next larger integer exponent of two.

   As stated above, these parameters are for use by experienced, knowledgeable system administrators only. They should not be altered unless you are quite certain that what you are doing is the correct thing to do.

   Back to the Top