From: Subject: HP-UX Tuning Guide Date: Thu, 10 Apr 2008 14:25:08 -0300 MIME-Version: 1.0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Location: http://docs.hp.com/en/1219/tuningwp.html X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 HP-UX Tuning Guide

HP-UX Kernel Tuning and Performance Guide



Getting The Best = Performance
From Your=20 Hewlett-Packard Systems 
Version 3.1
Revision Date: March 15, 2000

Author: Stephen Ciullo

Index
  1. Introduction =
  2. Hardware=20 Considerations=20
  3. CPU=20
  4. Memory=20
    1. Physical=20 Memory=20
    2. Physical Memory=20 and Performance=20
      1. Where is the=20 Memory Going?=20
      2. Determining=20 Memory Requirements
    3. Memory=20 Management=20
    4. Virtual = Address=20 Space
  5. Disk =
    1. To = Improve=20 Disk I/O Performance=20
    2. File=20 Systems=20
    3. Logical = Volume=20 Manager=20
    4. Secondary=20 Storage=20
    5. Swap=20
      1. How Much=20 Swap Do I Have?=20
      2. How Much=20 Swap Do I Need?=20
      3. Configuring = Swap=20 Space
  6. HP-UX = Kernel=20 Configuration=20
    1. Configuring=20 Kernel Parameters in 9.X=20
    2. Configuring=20 Kernel Parameters in 10.X=20
    3. Configurable=20 Parameters=20
    4. Kernel=20 Parameters=20
      1. bufpages=20
      2. create_fas= tlinks=20
      3. dbc_max_pc= t=20
      4. fs_async= =20
      5. hpux_aes_ove= rride=20
      6. maxdsiz<= /A>=20
      7. maxfiles=20
      8. maxfiles= _lim=20
      9. maxssiz<= /A>=20
      10. maxswa= pchunks=20
      11. maxtsiz<= /A>=20
      12. maxuprc<= /A>=20
      13. maxusers=20
      14. netmemmax<= /I>=20
      15. nfile =
      16. ninode=20
      17. nproc =
      18. npty=20
    5. Kernel=20 Parameter Recommendations
  7. Networks=20
    1. NFS =
  8. Patches=20
    1. How to get=20 patches=20
    2. How to tell=20 what patches are loaded=20
    3. How to load=20 patches=20
    4. Patch=20 Management
  9. Performance=20 and the PATH variable=20
    1. The = PATH=20 Variable
  10. HP-UX = 11.0=20
    1. Points = of=20 Interest=20
    2. lotsfree,=20 desfree and minfree=20
    3. Text, Data=20 and Shared Objects Maximum Values=20
    4. EXEC_MAGIC =
    5. The = New=20 Parameters for Text, Data and Stack=20
    6. Variable=20 Size Pages=20
    7. Memory=20 Windows=20
    8. Spinlock Pool=20 Parameters

  1. Introduction

    This document describes how a HP-UX kernel is tuned and configured. = The=20 intent is to provide customers, developers, application designers, and = HP's=20 technical consultants the information necessary to optimize = performance of=20 existing configurations and to make intelligent decisions when running = applications on HP-UX. This is not a manual and we do not go into the = specific=20 reasons for many of the recommendations contained herein.

    Back to = the=20 Top

  2. Hardware Considerations

    HP, and other hardware vendors, offer a broad selection of products = with a=20 wide range of CPU performance, memory and disk options. Obviously, the = performance of an application will be affected by the hardware on = which you=20 choose to run.

    There are five key hardware areas that directly affect the = performance you=20 will obtain from your application: CPU, Memory, Disk, Graphics, and = Network.=20 It is not a wise choice to buy the fastest CPU and configure it with=20 insufficient memory.

    There are many things to consider when you are choosing the = hardware for=20 your system. The compute needs may vary from the very simple to the = incredibly=20 complex. The best way to select the appropriate hardware is to try to = answer=20 the following questions:

    • How many users need to access the system at any one time?=20
    • Is it a server or a client?=20
    • What are the server needs ?=20
    • What are the application software needs?

    There might be several different configurations necessary for your=20 environment. You might need different configurations for different = users. The=20 best way to select the appropriate hardware is to perform tests that = duplicate=20 your intended use of the system. With test results in hand, you will = have the=20 information you need to make well informed hardware decisions.

    Back to = the=20 Top

  3. CPU

    CPU performance is the single most important factor when you want = to get=20 the most work done in the shortest possible time. If it takes five = seconds to=20 perform a particular operation, is it worth it to spend an extra = $10,000 to do=20 it in three seconds? However, if the operation takes five hours and = the time=20 can be reduced to one or two hours, it may be worth the additional = expense.=20

    Computational tasks are most affected by CPU performance. Be sure = to=20 consider investment protection. The CPU that seems adequate today may = not meet=20 your needs in the near future. The rapid pace of hardware development = makes=20 existing systems obsolete in a very short period of time.

    Back to = the=20 Top

  4. Memory

    One of the most commonly asked questions is "How much memory do I = need?".=20 Unfortunately, the real answers to this question are "Enough" and "It=20 depends". The amount of memory you need is directly related to the = size of the=20 applications with which you are working. While 'X' amount of memory = may allow=20 you to run your application, it may not be large enough to allow for = optimal=20 performance.

    There is a lot of confusion regarding cache memory, configuration = of swap=20 space, swap's relationship to physical memory, kernel parameters = affecting=20 memory allocation, and performance. It is important to understand = memory=20 management in order to understand these relationships.

    Back to = the=20 Top

    1. Physical Memory

      Physical memory is composed of hardware known as RAM (Random = Access=20 Memory) usually installed in SIMM or DIMM's. For the CPU to execute = a=20 process, the relevant pages of a process must exist in the physical = memory.=20

      The more physical memory there is, the more processes can be run = and/or=20 the larger a process (or processes) can be, without the system = having to=20 "page out". When the system has no more room in memory and begins to = page=20 out, performance will begin to degrade.

      Not all physical memory is available to user processes. The = kernel=20 occupies some main memory and it is never paged. The amount of main = memory=20 not reserved for the kernel is termed available memory. Available = memory is=20 used by the system for executing processes.

      Back to = the=20 Top

    2. Physical Memory and Performance

      The amount of memory available to applications is determined by = the=20 amount of swap configured plus physical memory. The amount of = physical=20 memory available will directly affect when or if paging will occur. = Paging=20 imposes a serious performance penalty. There is a critical threshold = for=20 physical memory, below which the system spends much of its CPU time = paging.=20 When it begins to spend most, if not all of the cpu time paging, it = is known=20 as thrashing. Thrashing is evident by the fact that system = performance=20 virtually comes to a standstill.

      In a best case scenario, paging would never occur. However, not = everyone=20 has the luxury of enormous amounts of memory. Understanding how = memory size=20 affects performance is important. HP's performance monitoring tools=20 (Glance/GlancePlus/MeasureWare/PerfView) can help in tracking memory = and=20 associated bottlenecks/problems.

      Back to = the=20 Top

      1. Where Is The Memory Going?

        To help you understand minimum memory requirements, it helps to = understand how memory is consumed. Minimally, you will have the = following=20 resources consuming memory:

        • HP-UX Operating System
          		• 10-12 MB
        • Windowing System
          		• 21 MB (X11)  25 MB (VUE)  32 MB (CDE)=20

        HP-UX uses paging to move pages in and out of physical memory. = The=20 operating system and any pages that have been explicitly (or = implicitly)=20 locked are not subject to paging. Only the pages of a process that = are=20 required for execution will be paged in. Text (instructions) pages = are=20 never "paged out".

        Back = to the=20 Top

      2. Determining Memory Requirements

        One way to determine whether the amount of physical memory in = your=20 system is adequate would be to run benchmarks with increasing = levels of=20 physical memory and use one of HP's performance tools to monitor = the=20 system. This will tell you if your system is paging. It would be=20 beneficial if you could run your real "production" applications to = perform=20 the test.

        Back = to the=20 Top

    3. Memory Management

      HP-UX memory management is composed of 3 basic elements: cache, = memory=20 and swap space. Swap space can be composed of two types: device swap = and=20 file system swap. Device swap can be made up of primary swap space = that is=20 defined on the root disk and secondary swap space which is defined = on other=20 disk volumes. All of these elements can be configured/optimized = through=20 HP-UX kernel parameter tuning.

      The data and instructions of any process (a program in execution) = must be=20 available to the CPU by residing in physical memory at the time of=20 execution. Physical memory (also called "main memory"), is shared by = all=20 processes. To execute a process, the kernel accesses it's parts = through a=20 per-process virtual address space that has been mappe into physical = memory.=20

      The term "memory management" refers to the rules that govern = physical and=20 virtual memory and allow for efficient sharing of the system's = resources by=20 user and system processes.

      The total size of a user process(es) is permitted to exceed = physical=20 memory by using an approach termed demand-paged virtual = memory.=20 Demand paged virtual memory enables you to execute a process by = bringing=20 into main memory pages of the process as needed (on demand), and = writing out=20 to disk the pages of a process that have not been recently accessed. =

      The HP-UX operating system uses paging to manage virtual memory. = Paging=20 involves moving small units (called pages) of a process between main = memory=20 and disk space.

      One method for increasing the efficiency of memory allocation is = the use=20 of the mallopt() command. The mallopt()call must appear prior to any = malloc() call in the application. One mallopt() at the beginning of = the=20 program should be sufficient, depending on what one is doing. = mallopt() is=20 also needed when attempting to obtain "process large data space" (a = data=20 segment larger than the deafult maximum of 1.9GB if EXEC_MAGIC). = This=20 command is unique to HP-UX and controls the memory allocation = algorithm and=20 other optimization options within the malloc library. Use of = mallopt() can=20 improve application execution time up to 10X, depending on the data = size. It=20 is important that the Maxfast and Numlblks options (i.e. the first = two=20 options to mallopt) be defined to reflect the data size links being=20 accessed.

      Back to = the=20 Top

    4. Virtual Address Space

      Process virtual address space is mapped via a structure named = "vas"=20 (Virtual Address Space). The vas contains information about, and = pointers to=20 the various parts of a process, both in memory and on disk. One = virtual=20 address space (vas) exists per process and serves several purposes: =

      • It provides the overall description of each process.=20
      • It contains pointers to other elements in the process = structure=20 mapping per-process regions. (pregions)

      Each process can have a maximum of 4 Gb virtual address space = (this=20 changes in HP-UX 11.0). The four GB virtual address space is divided = into=20 four one-GB quadrants. This (and the descriptions following, will = change in=20 11.0). Each quadrant has associated with it:

      • The first quadrant always contains the process's text segment = (code),=20 and sometimes some of the data (EXEC_MAGIC).=20
      • The second quadrant contains the data segment (static data, = stack, and=20 heap, etc.).=20
      • The third quadrant contains shared library code, shared memory = mapped=20 files and sometimes shared memory.=20
      • The fourth quadrant contains shared memory segments, shared=20 memory-mapped files, shared library code, and I/O space. =

      As stated, the vas structure points to per-process regions, or = pregions.=20 Pregions represent the specific segments of a process, including = text=20 (process instructions), data, u_area and kernel stack, user stack, = shared=20 memory, shared libraries, etc.

      The maximum size of various memory segments is controlled by the = values=20 of certain configurable kernel parameters. It is beyond the scope of = this=20 paper to discuss all the process segments. The following, however, = is a=20 description of the segments most relevant to this discussion:

      Text - The text segment contains a process's = instructions=20 and may be shared by multiple processes. The maximum size of the = text=20 segment is limited by the configurable parameter maxtsiz.

      Data - The data segment contains a process's = initialized=20 (data) and uninitialized (.bss) data structures, along with the = heap,=20 private "shared" data, "user" stack, etc. A process can dynamically = grow its=20 data space (heap). The maximum size for the process data space is = governed=20 by the configurable kernel parameter maxdsiz.

      Stack - Space used for local variables, subroutine = return=20 addresses, kernel routines, etc. The u_area contains information = about=20 process characteristics. The kernel stack contains a process's stack = while=20 executing in kernel mode. Both the u_area and kernel stack are fixed = in=20 size. Space available for the user stack is determined by the = configurable=20 parameter maxssiz.

      Shared Memory - Address space which is shareable = among=20 multiple processes.

      Back to = the=20 Top

  5. Disk

    Application data can be quite large. Disk I/O is one of the "Big = Three"=20 bottlenecks (CPU and Memory being the other two). Disk I/O can also be = the=20 limiting factor in overall performance if a system does an inordinate = amount=20 of paging on a frequent basis.

    HP's philosophy is to design balanced systems in which no single = component=20 becomes a performance bottleneck. HP has made significant enhancements = to I/O=20 performance in order to keep pace with the speed of our CPUs. I/O = performance=20 depends on several parts of the system working together efficiently. = The I/O=20 subsystems have been redesigned so that they now offer the industry's = fastest=20 and most functional I/O as standard features.

    Back to = the=20 Top

    1. To Improve Disk I/O Performance:

      Distribute the work load across multiple disks. Disk I/O=20 performance can be improved by splitting the work load. In poor=20 configurations, a single drive contains the operating system, swap = space,=20 and data file access simultaneously. If these different tasks can be = distributed across multiple disks then the job can be shared, = providing=20 subsequent performance improvements. For example, a system might be=20 configured with four logical volumes, spread across more than one = physical=20 volume. The HP-UX operating system could exist on one volume, the=20 application on a second volume, swap space interleaved across all = local disk=20 drives and data files on a fourth volume.

      Split swap space across two or more disk volumes. Device = swap=20 space can be distributed across disk volumes and interleaved. This = will=20 improve performance if your system starts paging. This is discussed = in more=20 detail in the section on Swap Space Configuration later in this = document.=20

      Enable Asynchronous I/O - By default, HP-UX uses = synchronous disk=20 I/O, when writing file system "meta structures" (super block, = directory=20 blocks, inodes, etc.) to disk. This means that any file system = activity of=20 this type must complete writing to the disk before the program is = allowed to=20 continue; the process does not regain control until completion of = the=20 physical I/O. When HP-UX writes to disk asynchronously, I/O is = scheduled at=20 some later time and the process regains control immediately, without = waiting.

      Synchronous writes of the meta structures ensure file system = integrity in=20 case of system crash, but this kind of disk writing also impedes = system=20 performance. Run-time performance increases significantly (up to = roughly ten=20 percent) on I/O intensive applications when all disk writes occur=20 asynchronously; little effect is seen for compute-bound processes.=20 Benchmarks have shown that load times for large files can be = improved by as=20 much as 20% using asynchronous I/O. However, if a system using = asynchronous=20 disk writes of meta structures crashes, recovery might require = system=20 administrator intervention using fsck and, might also cause data = loss. You=20 must determine whether the improved performance is worth the slight = risk of=20 data loss in the event of a system crash. A UPS device, used in a = power=20 failure event will help reduce the risk of lost data.

      Asynchronous writing of the file system meta structures is = enabled by=20 setting the value of the kernel parameter fs_async to 1 and disabled = by=20 setting it to 0, the default. For instructions on how to configure = kernel=20 parameters, see the section Kernel Configuration Parameters later in = this=20 document.

      Back to = the=20 Top

    2. File Systems

      When using UFS (HFS) file systems, configure them with a block = size of=20 64K and a fragment size of 8K. HFS file systems have historically = preferred=20 to perform I/O in 64K block sizes. We have improved performance by = using a=20 VxFS (JFS) file system when it is being used as a "scratch" file = system...a=20 file system that you do not care about when the application crashes, = or when=20 it completes successfully. When doing so, you need to mount this = file system=20 with three specific options in order to gain performance. They are: =

      • nolog=20
      • mincache=3Dtmpcache=20
      • convosync=3Ddelay

      The on-line (advanced) JFS product is required to use these = options. In=20 my experience, the JFS block size is of no consequence when using = JFS. JFS=20 likes to perform I/O in 64K chunks, regardless of the block size. = Supported=20 block sizes are 1, 2, 4, and 8K. There is no fragment on a JFS file = system.=20

      When striping with LVM, one should make sure that the file system = block=20 size and the LVM stripe size are identical. This will aid = performance.

      When mounting file systems, they should be positioned at mount = points=20 that are as close to the "root" of the tree. This will help = "shorten"=20 directory search paths. It is very important that file systems that = contain=20 "tools" that will be used by the application(s), be mounted as close = to the=20 top as possible.

      As of the current version of this document, there is a JFS "mega = patch"=20 for performance. The patch number is PHKL_14613 for the 700 series = and=20 PHKL_14491 for 800 series systems.

      NOTE: Be sure to review the patch catalog for these = patches to be=20 sure that these are the most current patches.=20

      Check your buffer cache size. Some say 128K for each 1000 IOPS a = server=20 expects to deliver.

      Check your disk and file system configurations:

      • LVM configuration/layout=20
      • Multiple disk striping?=20
      • HFS? ...check your block/fragment sizes=20
      • JFS? ...check your mount options

      Reads and writes...server and client block sizes should match. = Pay=20 attention to the suggestions for file systems (above).

      Back to = the=20 Top

    3. Logical Volume Manager

      The following are simply recommendations...you do not have to do = them.=20 Obviously, there are pros and cons with everything. This is not the = focus of=20 this document, but there is value in a brief review. Use as many = physical=20 disks as possible. Stripe them if you can. If you have followed the = file=20 system recommendation of using a 64K block size, use a 64K stripe = size as=20 well. I would suggest a 64K stripe size for LVM anyway. Hopefully, = you will=20 have identical disks (make, model, size, geometry, etc.). When you = have=20 control, place your logical volumes so that the "pieces" a logical = volume=20 are located in the same place across the physical devices. For = example,=20 having four physical devices, you "stripe" a logical volume so that = 25% of=20 appears on each of the four disks, and, each piece appears at the = "top" of=20 the disk.

      Back to = the=20 Top

    4. Secondary Storage

      Main memory is where the data and instructions required for = program=20 execution are stored. During process execution, data and = instructions reside=20 in cpu registers and cache. These are very fast and very expensive = pieces of=20 hardware. Program files are kept in secondary storage (disk = drives).

      Back to = the=20 Top

    5. Swap

      A temporary form of data storage is swap space. It should be = noted that=20 HP-UX does not "swap" any more, it pages and, as a "last resort" = deactivates=20 processes. The process of deactivation replaces what was formerly = known as=20 swapping entire processes out.

      While executing a program, data and instructions can be paged = (copied) to=20 and from secondary storage, if the system load warrants.

      Swap space is initially allocated when the system is configured. = HP-UX=20 supports two types of swap space: device swap and file system swap. = Device=20 swap is allocated on a disk "outside" of any file system space and = can be:=20

      • a entire disk=20
      • an area on a disk=20
      • a logical part of a physical disk

      If the entire disk hasn't been designated as swap, the remaining = space on=20 the disk can be used for a file system. File system swap space is = allocated=20 from a mounted file system and can be added dynamically to a running = system.=20 Device swap can also be added dynamically to a running system. Sam = or the=20 swapon() command can be used to enable device or file system swap. =

      NOTE: File-system swap has significantly lower performance = than=20 device swap. The I/O for file system swap will contend with user I/O = on that=20 particular file system. Using file system swap space should be = avoided. Once=20 allocated, you cannot remove either type of swap without rebooting = the=20 system. HP-UX uses a swap space reservation method (to insure it has = space=20 available), but only allocates the space when it actually needs to = write to=20 it.

      Back to = the=20 Top

      1. How much swap do I have?


        SAM, Glance/GlancePlus, top, and swapinfo all = show swap=20 information. To see how much swap space is configured on your = system, and=20 how much is in use, execute one of the following commands:

        • top
        • Glance / GlancePlus
          •      /usr/perf/bin/glance = HP-UX 9.X systems
               /opt/perf/bin/glance = HP-UX 10.X systems
        • sam
          		• requires root
        • /etc/swapinfo -t
          		• HP-UX 9.X systems - requires root
        • /usr/sbin/swapinfo -t
          		• HP-UX 10.X systems - requires = root

        Any user can execute top and Glance.

        Back = to the=20 Top

      2. How Much Swap Do I need?

        The amount of swap, added to the amount of memory available, = defines=20 the virtual memory available for processes. The minimum = recommendation is=20 twice as much swap space as physical memory. Keep in mind, this is = an=20 "old" formula. If you have two, three, four or many more gigabytes = of=20 physical memory, this would result in way too much swap space. = Granted,=20 there are the pathological cases that would require you to have = eight to=20 ten gigabytes of swap with, say, four gigabytes of physical = memory. If you=20 try to execute a process that would exceed the amount of available = memory=20 plus available swap, you will get a "out of memory" message. If = you=20 configure more swap than you will ever need, you are wasting disk = space.=20 The correct swap size will vary considerably depending on the size = and=20 number of application(s) run on a system.

        The correct swap size can be determined by monitoring swap = usage while=20 working with real data. This could be done either with the = swapinfo=20 command or using a tool like HP's GlancePlus. GlancePlus allows = you to=20 monitor system resources on a per process basis and will display = the high=20 water mark (since you started glance). You would configure a = system with=20 more swap space than you expect to need, then run GlancePlus while = running=20 an application(s). By monitoring the high water mark, you can = determine=20 the maximum swap space used and adjust the swap size accordingly.=20 Obviously, if you experience out of memory errors, swap size is = too small.=20

        There are many systems with less swap space than physical = memory. This=20 is perfectly fine. The person who specified the system probably=20 recommended all that memory so that they would not have to swap! = We have=20 seen systems with with swap space equal to 50% that of physical = memory.=20 Just be sure to have swapmem_on EQUAL TO 1!!

        NOTE: For best performance, swap space should be = distributed=20 evenly across all disks configured with swap, at the same priority = .

        Back = to the=20 Top

      3. Configuring Swap Space

        As previously mentioned, device swap is preferred over file = system swap=20 to achieve the best performance. The ideal swap configuration is = device=20 swap spread across multiple identical disks. Each quantity of swap = space=20 being equal in size. Once this is done, assign each space the same = priority. This implies interleaving. This means that if your = system starts=20 to page, the paging requests will be "round robin'd" among the = swap=20 spaces. This is how you would want your system to page, should it = run out=20 of memory. If possible, it is even better to place the disks = containing=20 the swap space on separate cards/controllers. This eliminates the=20 controller as a "single point of bottleneck".

        SAM is one method for adding and configuring swap space. Swap=20 configuration is under the Disks and File System area of SAM. For = more=20 information on configuring swap, please see the on-line Help = section=20 within SAM's Swap Configuration. If you wish to use the swapon = command,=20 review the man page, swapon(2).

        Back = to the=20 Top

  6. HP-UX Kernel Configuration

    This section explains HP-UX configurable kernel parameters that = affect=20 system capacity and/or performance. Most of this section is common for = HP-UX=20 9.X and HP-UX 10.X. Specific differences are noted.

    Back to = the=20 Top

    1. Configuring Kernel Parameters in 9.X

      In HP-UX 9.X we recommend manual kernel configuration. All work = related=20 to creating a new kernel in 9.X takes place in the /etc/conf = directory.=20 Follow these steps:

      • cd /etc/conf=20
      • cp dfile dfile.old=20
      • vi dfile=20
      • Modify the dfile to include the kernel parameters and values = suggested=20 above.=20
      • config dfile=20
      • make -f config.mk=20
      • mv /hp-ux /hp-ux.old=20
      • mv /etc/conf/hp-ux /hp-ux=20
      • cd / ; shutdown -ry 0

      NOTE: For more information on manual kernel configuration, = please=20 see the HP-UX System Administration "Systems Administration Tasks" = book.=20

      Back to = the=20 Top

    2. Configuring Kernel Parameters in 10.X

      In HP-UX 10.X we recommend modifying the kernel parameters SAM = allows,=20 and then manually modifying the hpux_aes_overide parameter. = The=20 hpux_aes_override kernel parameter is the only recommended parameter = that=20 must be modified manually. We recommend using SAM for the other = parameters=20 to take advantage of its built-in kernel parameter rule check = function.=20

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

      To configure a kernel manually, you must be super-user. All work = related=20 to creating a new kernel in 10.X takes place in the /stand/build = directory.=20 Follow these steps:

      • cd /stand/build=20
      • /usr/lbin/sysadm/system_prep -s system=20
      • vi system=20
      • Either add or modify the entries to match:=20
      • hpux_aes_override 1=20
      • mk_kernel -s system=20
      • mv /stand/system /stand/system.prev=20
      • mv /stand/build/system /stand/system=20
      • mv /stand/vmunix /stand/vmunix.prev=20
      • mv /stand/build/vmunix_test /stand/vmunix=20
      • cd / ; shutdown -ry 0

      NOTE: For more information on manual kernel configuration, = please=20 see the HP-UX 10.X System Administration "Systems Administration = Tasks"=20 Book. .

      To configure the remaining kernel parameters with SAM, follow = these=20 steps:

      • Login to the system as root=20
      • Place the list of kernel parameter values (above) in the file: =
      • /usr/sam/lib/kc/tuned/stuff.tune=20

        (The first line should be "STUFF Applications" in the format = shown in=20 the general "Configuring Kernel Parameters" section above.)

      • Start SAM by typing the command: sam=20
      • With the mouse, double-click on Kernel Configuration .=20
      • On the next screen, double-click on Configurable Parameters.=20
      • SAM will display a screen with a list of all configurable = parameters=20 and their current and pending values. Click on the Actions = selection on=20 the menu bar and select Apply Tuned Parameter Set ... on the = pull-down=20 menu. Select STUFF Applications from the list and click on the OK = button.=20
      • Click on the Actions selection on the menu bar and select = Create A New=20 Kernel. A confirmation window will be displayed warning you that a = reboot=20 is required. Click on YES to proceed.=20
      • SAM will build the new kernel and then display a form with two = options:=20
        • Move Kernel Into Place and Reboot the System Now=20
        • Exit Without Moving the Kernel Into Place=20
        • If you select the first option and then click on OK, the new = kernel=20 will be moved into place and the system will be automatically = rebooted.=20
        • If you select the second option move the kernel from the=20 /stand/build directory into the /stand/vmunix =

      Back to = the=20 Top

    3. Configurable Parameters

      HP-UX configurable kernel parameters limit the size of the text, = data,=20 and stack segments for each individual process. These parameters = have=20 pre-defined defaults, but can be reconfigured in the kernel. Some = may need=20 to be adjusted when swap space is increased. This is discussed in = more=20 detail in the section on configuring the HP-UX kernel.

      bufpages
      create_fastlinks =
      fs_async=20
      hpux_aes_override
      maxdsiz =
      maxfiles=20
      maxfiles_lim
      maxssiz =
      maxswapchunks=20
      maxtsiz
      maxuprc
      netmemmax=20
      nfile
      ninode
      nproc =
      npty=20
      		Sets number of buffer pages
      Store symbolic link = data in=20 the inode
      Sets asynchronous write to disk
      Controls = directory=20 creation on automounted disk drives
      Limits the size of the = data=20 segment.
      Limits the soft file limit per process
      Limits = the=20 hard file limit per processes
      Limits the size of the stack = segment.
      Limits the maximum number of swap chunks =
      Limits the=20 size of the text (code) segment.
      Limits the maximum number = of user=20 processes
      Sets the network dynamic memory limit
      Limits = the=20 maximum number of "opens" in the system
      Limits the maximum = number=20 of open inodes in memory
      Limits the maximum number of = concurrent=20 processes
      Sets the maximum number of pseudo ttys=20

      Back to = the=20 Top

    4. Kernel Parameters

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

        Back = to the=20 Top

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

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

        Back = to the=20 Top

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

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

        Back = to the=20 Top

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

        Back = to the=20 Top

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

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

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

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

        Back = to the=20 Top

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

        Memory fault(coredump)=20

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

        Back = to the=20 Top

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

        Back = to the=20 Top

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

        Back = to the=20 Top

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

        Back = to the=20 Top

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

        NOTE: Never modify the kernel parameter, = swchunk.

        Back = to the=20 Top

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

        Back = to the=20 Top

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

        no more processes=20

        We recommend maxuprc be set to 200.

        Back = to the=20 Top

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

        Back = to the=20 Top

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

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

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

        Back = to the=20 Top

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

        file: table is full=20

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

        Back = to the=20 Top

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

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

        Back = to the=20 Top

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

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

        Set nproc to 1024.

        Back = to the=20 Top

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

        Back = to the=20 Top

    5. Kernel Parameter Recommendations

      The following are the suggested kernel parameter values.

      # Parameter Value
      bufpages 0 # on HP-UX 10.X
      create_fastlinks 1
      dbc_max_pct 25
      fs_async 1
      maxdsiz 2063806464
      maxfiles 200
      maxfiles_lim 2048
      maxssiz (80*1024*1024)
      maxswapchunks 4096
      maxtsiz (1024*1024*1024)
      maxuprc 200
      maxusers 124
      netmemmax 0 # on desktop systems
      -1 # on data servers
      nfile 2800
      ninode 15000 # 4000 on HP-UX 10.20 multi-processor systems
      nproc 1024
      npty 512

    Back to = the=20 Top

  7. Networks

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

    Back to = the=20 Top

    1. NFS

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

      Make sure that ninode is at least 15000 on HP-UX 10.X. = Remember to=20 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=20 Processor systems when ninode is greater 4000. Check it on = your=20 system. The details of this problem are much too detailed and = complicated=20 for this document.

      NFS file systems should be exported with the async option in=20 /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=20 errors reported by the links? Use lanadmin() or netstat -i to check = this.=20

      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=20 of too many levels of hierarchy within the netgroup file. It seems = that this=20 file is re-read many times, and the more hierarchy, the longer it = takes to=20 read.

      Back to = the=20 Top

  8. Patches

    Since patch numbers change frequently, it is recommended that you = always=20 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=20 performance and reliability improvements are delivered by these = patches.=20
    • Load the latest C compiler and linker patches.=20
    • Load HP-VUE or CDE, and X/Motif patches at your discretion. = These=20 usually contain bug fixes.=20
    • Load the latest X server patches.=20

    1. How to get patches. If you have WWW access go to=20 http://us-support.external.hp.com, and follow the links to the patch = list.=20 This is also a good way to browse the latest patch list. You can = also get=20 patches by e-mail. If you know what the name of the patch you want = is, send=20 a message to support@support.mayfield.hp.com, with the text "send=20 patchname". Don't forget to substitute the name of the patch you = want for=20 "patchname". You can get a current list by sending the text "send=20 patchlist". To get a complete guide on using the mail server, send = the text=20 "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=20 for FTP access.

      Back to = the=20 Top

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

      Back to = the=20 Top

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

      Back to = the=20 Top

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

      Back to = the=20 Top

  9. Performance and the PATH Variable

    1. The PATH Variable

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

      Back to = the=20 Top

  10. HP-UX 11.0

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

    Back to = the=20 Top

    1. Points of Interest

      "FALSE" DEACTIVATIONS. There is an issue regarding process = deactivations when there seems to be NO paging. The = following=20 is the description and patch and recommended work around AS OF = THIS=20 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=20 disk, even though there really is NO MEMORY PRESSURE. Part of the = problem=20 is/are the kernel NFS routines. If the pageout rate is anything but = zero,=20 there is a change in the logic that assumes (incorrectly) that we = are under=20 memory pressure. It causes a process to fire up and start purging = buffer=20 cache pages. This causes a performance degradation, especially if = the system=20 has a large buffer cache.

      Patch PHKL_17869 added a new counter in the kernel, = k_pageout_count, used=20 by thrashing logic to see if we are under memory pressure. This = "corrects"=20 the deactivation issues...BUT...the macro (in bcache.h) that NFS = relies upon=20 to determine if we are under memory pressure was NOT changed...it = still uses=20 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=20 whether we're under memory pressure or not. Because NFS thinks that = we're=20 under pressure, it tries to "re-use" a bunch of internal kernel = structures.=20 The overhead and bookeeping to do this is causing performance = problems. It=20 REALLY should use the new counter.

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

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

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

      PLEASE NOTE:

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

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

      Back to = the=20 Top

    2. lotsfree, desfree and minfree

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

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

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

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

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

      on a system with up to 2GB of memory:

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

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

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

      on a system with a whole group of memory:

      • lotsfree 131072=20
      • desfree 32768=20
      • minfree 8192

      Back to = the=20 Top

    3. Text, Data and Shared Objects Maximum Values

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

      Back to = the=20 Top

    4. EXEC_MAGIC

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

      Back to = the=20 Top

    5. The New Parameters for Text, Data and Stack

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

      Back to = the=20 Top

    6. Variable Size Pages

      The chatr() command

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

      The Benefits

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

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

      Using variable sized pages:=20

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

      How Do I Use Variable Sized Pages?

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

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

      New Kernel Parameters

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

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

      Variable Page Size "Inhibitors"

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

      • physical memory size=20
      • dynamic buffer cache=20
      • start of virtual alignment=20
      • re-running a recently chatr()'d application=20
      • page demotion=20
      • 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=20 "objects" is 1.75GB system wide. Typically, there are many processes = sharing=20 a limited amount of memory. This memory is utilized by all processes = using=20 any/all of the "shared object" stuff...shared memory, shared = libraries and=20 memory mapped files. Often just three or four processes need all or = most of=20 the available memory. It should be noted that only 32 bit processes = are=20 affected by this limitation. With a 8TB limitation on shared object = space in=20 64 bit land, I assume it will be a couple of months before one of = you=20 require more! More important...ya don't need memory windows.

      Disadvantages

      Applications using a memory window cannot "see" any other memory = window.=20 Also, the current memory window is inherited accross = fork().=20 This could cause starnge behaviour. And...should applications in = multiple=20 memory windows have a need to communicate, they would need to use = the=20 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=20 sharing a 1GB segment of shared memory. This is just impossible when = the=20 total amount of shared space is 1.75GB (actually, less). On 11.X you = can=20 have multiple sets of processes, each sharing 1GB of memory. A = typical=20 example of this would be multiple instances of Oracle, SAP, etc. So. = Sites=20 or users that need to run multiple concurrent processes or = applications that=20 require the sharing of LARGE amounts of memory, should use memory = windows.=20

      Memory Window Usage

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

      *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=20 window thereafter could get 1GB. One could obtain 2.75GB for = the=20 global and 2GB for sny subsequent windows. This can be = accomplished=20 with a SHMEM_MAGIC executable. You make an executable = SHMEM_MAGIC=20 using the -M option to ld(), or the -M = option to=20 chatr().

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

    8. Spinlock Pool Parameters

      This was "borrowed" from the web page on Config= urable=20 Kernel Parameters.

      The following parameters, all related to spinlock pools for=20 multi-processor computers, are used similarly and are documented = together=20 here. Each parameter allocates the specified number of spinlocks for = the=20 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=20 understanding of how spinlocks are used by multiple processors and = how the=20 number of spinlocks needed are related to system size and = complexity. Do not=20 change these from their default value unless you understand the = consequences=20 of any changes. In general, these values should not be altered = without the=20 advice of HP support engineers who are thoroughly familiar with = their use.=20

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

      Following is a list of acceptable values. All of these parameters = have=20 the same minimum and maximum values. Only the defaults are different = as=20 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,=20 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=20 other value, SAM or the kernel itself changes the parameter value to = the=20 next larger integer exponent of two (for example, specifying 100 = results in=20 the spinlock-pool value of 128.

      Description

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

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

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

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

      Back to = the=20 Top

    (c) Copyright 1998=20 Hewlett-Packard Company.