Buffer Pool Statistics

Each object loaded in the buffer pool requires a directory entry that contains information on this object. The space for these directory entries is allocated in the buffer pool.

After the space used by the directory entries has been allocated, the remaining space is divided into blocks called text records (whose size, by default, is 4 KB). An object can occupy one or more text records, depending on its size.

The buffer pool size can be specified with the NTBPI macro in the parameter module or with the BPI profile parameter described in the Parameter Reference documentation.

You can change the text record size of an existing buffer pool if you reinitialize the buffer pool by using the INITIALIZE command.

The default text record size is set to 4 KB. However, if you use applications that consist of many rather small objects, we recommend that you reduce it to 2 KB. This reduces the percentage of unused space in the buffer pool, although it can lead to Algorithm 2 (see METHOD=S in the Operations documentation) being invoked more frequently.

The buffer pool is initialized when:

• originally starting the buffer pool,

• executing the INITIALIZE SYSBPM direct command, or

• executing the REFRESH command of the GBP operating program; see also Global Buffer Pool Operating Functions in the Operations documentation.

The difference between the total text record size and the total object size shows the amount of unused size in the text record section and can also be an indicator for the system administrator of whether to modify the text record size.

This value should not be significantly less than 75%. If the buffer pool is almost full, any value above 75% indicates good usage of the buffer pool. If the usage is significantly less than 75%, the text record size should be reduced.

Tipp:
If the buffer pool is almost full (that is, the value in the field Text Records - Used is almost 100%), any value above 75% indicates good usage of the buffer pool. If the usage is significantly less than 75%, the text record size should be reduced.

The use count counts all applications currently executing an object. If an object is currently not in use, its use count changes to 0 (zero).

If the location is successful, the object has been found in the buffer pool or the BP cache and need not be loaded from a Natural system file thereby saving calls and I/Os.

A Quick Locate call is the attempt to locate an object in the buffer pool by using the internal fast locate table. For further information, see Internal Fast Locate Table.

In this case, the library (name, database ID and file number) and the position of the object in the buffer pool of the last successful locate call for this object is used again to locate the object.

This is the most efficient way to locate an object.

A failed Quick Locate call indicates that an object could not be located at its previous position in the buffer pool by using the internal fast locate table (see the relevant section in Performance Considerations).

This occurs if the object has either been deleted from the buffer pool or was moved to another position. A Quick Locate call that failed results in a Normal Locate call but without a steplib search since the Natural runtime remembers the library that contains the object.

The value of Normal after Quick is always identical to the value of Quick Locate Calls - failed.

A Normal after Quick call is successful if the requested object is still in the buffer pool but at another position.

A failed Normal after Quick call indicates that the requested object is no longer available in the buffer pool. As a result, the object is reloaded from the system file by using the library entry in the internal fast locate table (see the relevant section in Performance Considerations).

A Normal Locate call is the attempt to locate an object in the buffer pool without using the internal fast locate table (see the relevant section in Performance Considerations).

A Normal Locate call always occurs if an object is referenced for the first time within a Natural session after a LOGON system command has been performed. The Natural runtime does not yet know the library where the object resides, compared with a Quick Locate call.

A failed Normal Locate call indicates that an object (identified by its name and the library where it resides) could not be located in the buffer pool.

A failed Normal Locate will either result in a load from the BP cache or a system file, or a Normal Locate call for the next library in the steplib chain.

Normal Locate calls that perform unsuccessful steplib searches do not result in the load of an object from the BP cache or the system file.

STEPLIB Searches does not count Locate calls for objects that are neither contained in the current library nor any steplib or system file (error message Invalid command, or program does not exist in library). Locate calls that fail due to incorrect programming add to the counter of Normal Locate Calls - failed.

The number of STEPLIB Searches is calculated by using the following formula:

Normal Locate Calls - failed  -  (Number Loads into BP  -   Normal after Quick - failed)

The fewer the number of STEPLIB Searches, the better the buffer pool is performing.

See also Searching in Steplibs.

The load into the buffer pool (storage allocation request) can be triggered either by a load from the database or by a load from the BP cache.

As several load calls may be necessary to load a single object, this value provides the actual number of object loads made since the most recent buffer pool refresh.

When loading an object, the buffer pool manager uses different search algorithms: see METHOD=S and METHOD=N in the Operations documentation.

An object load cannot finish if the load operation is canceled due to any of the following reasons:

• A concurrent object load occurred: see Loads from DB - concurrent.

• During the object load, an Adabas response code occurs.

• During the object load, a SYSBPM delete operation is executed for this object.

Concurrent object loads occur if two or more Natural sessions that run simultaneously request the same object. While an object is being loaded by one session, other sessions request the same object and start loading it before a session has finished loading. In this case, the same object is loaded more than once.

The first session that finishes loading the object will mark the object of the other sessions to be deleted from the buffer pool. The other sessions will then stop loading the object, remove the object marked for deletion from the buffer pool and use the object loaded successfully by the first session.

The numbers of objects calculated by the counters Loads from DB - finished and Loads from DB - concurrent are usually identical. The numbers only differ if the concurrent load is only detected after both sessions have finished the load.

The number of system file accesses is calculated as follows:

• Adabas system file: The number of Load Calls plus the number of Loads from DB (see above). The total number does not include Adabas RC calls.

• VSAM system file: The number of Load Calls.

This field shows the number of times a storage allocation request satisfied the search criteria of Algorithm 2 as described in METHOD=S in the Operations documentation.

This field indicates the number of times a search has been performed starting from the top of the buffer pool. This number gives an estimate of the frequency of cycling through the buffer pool in a wrap-around fashion.

The time and date when Number Load Cycles was last increased.

This field indicates the number of times a chain of locked buffer pool entries had to be unlocked, because they could not satisfy the allocation request.

The number of slots, that is, the size of the hash table will be calculated internally depending on the number of text records.

A collision is caused if the name of two different objects is mapped to the same slot by the hash algorithm. In this case, a collision resolution is used in order to find another slot.

In addition, the percentage of these slots related to all slots used is displayed.

This ratio serves as a buffer pool efficiency indicator. The larger the number, the better the buffer pool is performing. This is the primary indicator of performance from one buffer pool session to the next.

The time in hours, minutes and seconds (hh:mm:ss) since the buffer pool was last completely reused (wrapped around).

Objects are loaded into the buffer pool one after the other (in sequential order) filling the top of the buffer pool first and the bottom last. When the bottom of the buffer pool has been reached, the buffer end is wrapped around and the next object is loaded again at the top of the buffer pool.

When the buffer pool has been filled completely for the first time, a new object loaded into the buffer overwrites an object that was loaded in the previous wrap-around cycle and that is not currently locked (marked as resident or in use).

Every object loaded into the buffer pool is assigned a directory entry that contains information such as the name of the object, the library where it is stored and the BP Load Time time stamp of the loading into the buffer pool.

Wrap Time Last is evaluated each time an object is loaded into the buffer pool. Wrap Time Last indicates the time period between the last loading of an object (BP Load Time) and the last overwriting of an object.

The longer the period of a wrap-around cycle, the better the buffer pool is performing. This period can vary considerably at night or over a weekend when user traffic is low compared with normal working hours.

The average time in hours, minutes and seconds (hh:mm:ss) of one wrap-around cycle since the buffer pool was initialized or refreshed.

Wrap Time Avg is calculated by dividing the life time of the buffer pool by the number of wrap-around cycles.

Wrap Time Last compared with Wrap Time Avg shows whether the buffer pool is currently being used more frequently than on average.

The value is calculated by dividing successful Get calls by successful Put calls. It shows the overall reuse factor; that is, how often an object loaded once into the BP cache could be successfully reloaded into the buffer pool. The higher the value, the better the BP cache efficiency.

Example of an Object Reuse Factor:
A ratio of 5.70 indicates that an object loaded in the BP cache was swapped into the buffer pool 5.7 times on average.

Objects are loaded into the BP cache one after the other (in sequential order) filling the top of the BP cache first and the bottom last. When the bottom of the BP cache has been reached, the end of the BP cache is wrapped around and the next object is loaded again at the top of the BP cache. When the BP cache has been filled completely for the first time, a new object loaded into the buffer overwrites the object that was loaded in the previous wrap-around cycle.

Each object loaded into the BP cache is assigned a directory entry that contains information such as the name of the object, the library where it is stored and the BPC Load Time time stamp when it was loaded into the BP cache.

Wrap Time Last is evaluated every time an object is loaded into the BP cache. Wrap Time Last indicates the time period between the last loading of an object (BPC Load Time) and the last overwriting of an object.

The longer the period of a wrap-around cycle, the better the BP cache is performing. This period can vary considerably at night or over a weekend when user traffic is low compared with normal working hours.

Wrap Time Avg is calculated by dividing the life time of the BP cache by the number of wrap-around cycles.

Wrap Time Last compared with Wrap Time Avg shows whether the BP cache is currently being used more frequently than on average.

This value indicates the percentage of objects the buffer pool could load from the BP cache, instead of the Natural system file FNAT or FUSER. The higher the value, the better the cache efficiency.

Keep in mind that a search for an object in a chain of steplibs may increase the number of Search calls the buffer pool sends to the BP cache. However, these calls will not result in a successful Get call or a load from the Natural system file, because an object may not be found in a steplib. Get / Search % does not consider the search through a long chain of steplibs that is frequently used. We recommend that you use as few steplibs as possible to increase overall performance.

Example of a Get / Search % value:
A value of 70% indicates that 70 % of all objects loaded into the buffer pool were retrieved from the BP cache and 30% were loaded from the system file.

PF8
(Load)

Displays the Buffer Pool Load/Locate Statistics screen.

PF8
(Gen)

Displays the General Buffer Pool Statistics screen.