Note: Information that was specified with the BUFFERS, LRUS, LRU_MAX_DIRTY, and LRU_MIN_DIRTY configuration parameters prior to Version 10.0 is now specified using the BUFFERPOOL configuration parameter.
- onconfig.std values
Operating systems with 2K default page size:
BUFFERPOOL default,buffers=10000,lrus=8,lru_min_dirty=50.00,
lru_max_dirty=60.50
BUFFERPOOL size=2k,buffers=50000,lrus=8,lru_min_dirty=50,
lru_max_dirty=60
Operating systems with 4K default page size:
BUFFERPOOL default,buffers=10000,lrus=8,lru_min_dirty=50.00,
lru_max_dirty=60.50
BUFFERPOOL size=4k,buffers=10000,lrus=8,lru_min_dirty=50,
lru_max_dirty=60
- syntax
- BUFFERPOOL default,buffers=num_buffers,lrus=num_lrus, lru_min_dirty=percent_min,lru_max_dirty=percent_max_dirty
- BUFFERPOOL size=sizek,buffers=num_buffers,lrus=num_lrus,lru_min_dirty=percent_min ,lru_max_dirty=percent_max_dirty
- takes effect
- When the database server is shut down and restarted
- utilities
- onparams -b (See onparams -b: Add a new buffer pool.) onspaces (See Specifying a Non-Default Page Size with the Same Size as the Buffer Pool. on-Monitor (See Figure 7.)
- refer to
- onspaces -c -d: Create a dbspace The IBM® Informix® Dynamic Server Administrator's Guide
The BUFFERPOOL configuration parameter consists of two lines in the onconfig.std file, as shown in this example for a platform with a default page size of 2K:
BUFFERPOOL default,buffers=10000,lrus=8,lru_min_dirty=50.00,lru_max_dirty=60.50
BUFFERPOOL size=2k,buffers=50000,lrus=8,lru_min_dirty=50,lru_max_dirty=60
The top line specifies the default values that are used if you create a dbspace with a page size which does not already have a corresponding buffer pool created at start up. The line below the default line specifies the database server's default values for a buffer pool, which are based on the database server's default page size. When you add a dbspace with a different page size with the onspaces utility or when you add a new buffer pool with the onparams utility, a new line is appended to the BUFFERPOOL configuration parameter in the onCONFIG file. The page size for each buffer pool must be a multiple of the system's default page size. Below is an example of the BUFFERPOOL lines where a third line has been appended:
BUFFERPOOL default,buffers=10000,lrus=8,lru_min_dirty=50.00,lru_max_dirty=60.50
BUFFERPOOL size=2k,buffers=50000,lrus=8,lru_min_dirty=50,lru_max_dirty=60
BUFFERPOOL size=6k,buffers=3000,lrus=8,lru_min_dirty=50,lru_max_dirty=60
The order of precedence for the BUFFERPOOL configuration parameter settings is:
- The BUFFERPOOL size line, for example:
BUFFERPOOL size=2k,buffers=50000,lrus=8,lru_min_dirty=50,lru_max_dirty=60
- Any deprecated parameters in the onCONFIG file:
- BUFFERS
- LRUS
- LRU_MAX_DIRTY
- LRU_MIN_DIRTY
For more information about deprecated configuration parameters, see Discontinued Configuration Parameters.
- The BUFFERPOOL default line, for example:
BUFFERPOOL default,buffers=10000,lrus=8,lru_min_dirty=50.00,lru_max_dirty=60.50
- Database server defaults.
When you use onspaces to create a new dbspace with a new page size, the database server takes the values of buffers, lrus, lru_min_dirty and lru_max_dirtyfrom BUFFERPOOL default line unless there already is a BUFFERPOOL entry for that page size.
You can use the onparams utility when the database server is in online, quiescent, or in administration mode to add a new buffer pool with a different page size. There must be one buffer pool for each page size used by the dbspaces and all dbspaces using that page size must use the single buffer pool with that page size. When you use the onparams utility to add a buffer pool or when you add a dbspace with a different page size with the onspaces utility, the information you specify is automatically appended to the onCONFIG file and new values are specified using the BUFFERPOOL keyword. You cannot change the values by editing theonconfig.std file. If you need to resize or delete an existing buffer pool, you must restart the database server and then run onparams again.
Buffer pools that are added while the database server is running go into virtual memory, not into resident memory. only those buffer pool entries that are specified in the onCONFIG file at startup go into resident memory, depending on the availability of the memory you are using.
The fields in the BUFFERPOOL lines are not case sensitive (so you can specify lrus or Lrus or LRUS) and the fields can appear in any order.
For more information on buffer pools, including information on resizing and deleting buffer pools, see IBM Informix Dynamic Server Administrator's Guide.
The lrus Field
- onconfig.std value
- lrus=8
- syntax
- lrus=num_lrus
- units
- Number of LRU queues
- range of values
- 32-bit platforms: 1 through 128 64-bit platforms: 1 through 512
The lrus field specifies the number of LRU (least-recently-used) queues in the shared-memory buffer pool. You can tune the value of lrus, in combination with thelru_min_dirty and lru_max_dirty fields, to control how frequently the shared-memory buffers are flushed to disk.
Setting lrus too high might result in excessive page-cleaner activity.
The buffers Field
- onconfig.std value
- : buffers=10000
- syntax
- buffers=num_buffers
- units
- Number of buffers. Each buffer is the size of the operating system page.
- range of values
- For 32-bit platform on UNIX®: with page size equal to 2048 bytes: 100 through 1,843,200 buffers (1843200 = 1800 * 1024)
with page size equal to 4096 bytes: 100 through 921,600 buffers (921,600 = ((1800 * 1024)/4096) * 2048 )
For 32-bit platform on Windows®: 100 through 524,288 buffers (524,288 = 512 * 1024)
For 64-bit platforms: 100 through 231-1 buffers (For the actual value for your 64-bit platform, see your machine notes. The maximum number of buffers on Solaris is 536,870,912.)
The buffers value specifies the maximum number of shared-memory buffers that the database server user threads have available for disk I/O on behalf of client applications. Therefore, the number of buffers that the database server requires depends on the applications. For example, if the database server accesses 15 percent of the application data 90 percent of the time, you need to allocate enough buffers to hold that 15 percent. Increasing the number of buffers can improve system performance.
Recommendation: Set the buffer space before you calculate other shared-memory parameters. on systems with a large amount of physical memory (4 GB or more), buffer space can be as much as 90 percent of physical memory.
If you also want to perform read-ahead, increase the value of buffers. After you have configured all other shared-memory parameters, if you find that you can afford to increase the size of shared memory, increase the value of buffers until buffer space reaches the recommended 25 percent maximum.
If your databases contain smart large objects, you need to consider them when you calculate the value for buffers, because smart large objects are stored in the default page size buffer pool. If your applications frequently access smart large objects that are 2 kilobytes or 4 kilobytes in size, use the buffer pool to keep them in memory longer.
Use the following formula to increase the value of
buffers:
Additional_BUFFERS = numcur_open_lo *
(lo_userdata / pagesize)- numcur_open_lo
- is the number of concurrently opened smart large objects that you can obtain from the onstat -g smb fdd option.
- lo_userdata
- is the number of bytes of smart-large-object data that you want to buffer.
- pagesize
- is the page size in bytes for the database server.
As a general rule, try to have enough buffers to hold two smart-large-object pages for each concurrently open smart large object. (The additional page is available for read-ahead purposes).
If the system uses lightweight I/O (as set by the access-mode constant LO_NOBUFFER), the system allocates the buffers from shared memory and does not store the smart large objects in the buffer pool. For information on access-mode flags and constants, see the chapter on “Working with Smart Large Objects of the Universal Data Option” in the IBM Informix ESQL/C Programmer's Manual.
The lru_min_dirty Field
- onconfig.std value
- lru_min_dirty=50.00
- syntax
- lru_min_dirty=percent_min
- units
- Percent
- range of values
- 0 through 100 (fractional values are allowed)
The lru_min_dirty field specifies the percentage of modified pages in the LRU queues at which page cleaning is no longer mandatory. Page cleaners might continue cleaning beyond this point under some circumstances. If a field is specified out of the range of values, then the default of 80.00 percent is set.
The lru_max_dirty Field
- onconfig.std value
- lru_max_dirty=60.50
- syntax
- lru_max_dirty=percent_max
- units
- Percent
- range of values
- 0 through 100 (fractional values are allowed)
The lru_max_dirty field specifies the percentage of modified pages in the LRU queues at which the queue is cleaned. If a field is specified out of the range of values, then the default of 60.00 percent is set.
The size Field
- onconfig.std value
- 2K default page size: size=2k 4K default page size: size=4k
- syntax
- size=size
- units
- Kilobytes
- range of values
- 2 through 16
The size field specifies the page size for the particular BUFFERPOOL line. The k is optional.
System Page Size
The system page size is the default page size and is platform-dependent on Dynamic Server.
You can use the following utilities to display the system page size.
- Utility
- Description
- onstat -b
- Displays the system page size, given as buffer size on the last line of the output
- oncheck -pr
- Checks the root-dbspace reserved pages and displays the system page size in the first section of its output
- ON-Monitor(UNIX)
- Displays the system page size under the Parameters > Initialize option. Displays system page size under the Parameters > Shared-Memory option, which does not require the database server to be running.
sg247559.pdf