Kbase 5633: Brief Overview of Buffers, when to use Private Buffers
| Autor |
Progress Software Corporation - Progress |
| Acesso |
Público |
| Publicação |
21/01/2003 |
|
Brief Overview of Buffers, when to use Private Buffers
901015-pjh01
INTRODUCTION:
=============
Recently an increasing number of customers have inquired about the
use of private buffers and their impact on system performance.
To properly discuss this topic lets first review how Progress uses
buffers. The Progress database is made up of a series of blocks. All
of these blocks are the same size (512, 1024 or 2048 bytes depending
on the system) but each has a different structure depending on its
use (i.e., to store records, indexes, and other control information).
The blocks which contain records are called RM blocks, and each block
contains 32 slots or spaces for records.
When a Progress procedure calls for a record to be read, Progress reads
the entire block (or blocks, a record can span multiple blocks) into
an area of shared memory called the buffer pool. By doing this, a
short cut is provided for subsequent record reads. If the desired
record is contained in a block which is already in the buffer pool,
it does not need to be read again. By using this buffer pool,
Progress is saved from having to read every record required by the
application.
The size of the buffer pool is controlled by the -B parameter on the
broker startup command. There is a much greater chance of having the
sought after record in memory, if you have a large buffer pool, and
more record manager blocks in that pool. There is a point of
diminishing returns when you increase the pool size too high, and
you receive no improvement in performance (in some cases an actual
decrease in performance) because the improved probability of finding
a record in memory is offset by an increase in the amount of time
spent searching buffers.
Progress offers a tool to help determine the correct setting for the
buffer pool size. By using the Progress Monitor (promon), and look-
ing at the block access statistics and calculating the ratio of
requests versus reads over a period of time, it is possible to
determine an optimal setting.
With this understanding on how Progress uses buffers, lets look at
private buffers.
Imagine a situation where there are many "heads down" users busy
using an order entry application. In this application each order
line record that is entered, uses the item master file for the
item entered and is accessed to get the current pricing. After the
first several orders are entered, the blocks which contain the
item master records for the best selling items have been read into
the buffer pool, and each additional request for these records do
not need to be read from disk, providing excellent performance.
Then suppose someone wanted to run a customer master report, every
customer record (every block which contains a customer record)
must be read into the buffer pool. At some point the buffer pool
is going to fill up. Normally this is not a problem since Progress
uses a least recently used algorithm to pick a block to write back
to the disk to make room for the incoming block. In the case where
so many blocks need to be read, many (or all) of the blocks currently
in the buffer pool will have to be flushed to disk, causing
degradation in performance for everyone. This degradation is
caused when records in the buffer are flushed and need to be
retrieved a second time from disk.
There is an alternative to this, using private buffers. A session
started with private buffers (specified by the -O parameter) has a
buffer pool separate from the the shared buffer pool managed by the
broker. This private buffer pool is used by Progress for read-only
operations like our customer master report. Instead of reading the
blocks into the shared buffer pool, displacing all of the blocks in
the pool, the private pool is used, thereby greatly reducing the
impact of running the report.
The problems begin when you realize that it is only efficient for
one user to use private buffers at a time. If two or more users
have sessions using the -O option, it takes up a lot of memory and
they don't get to take advantage of the other's reads which add to
the system overhead as well as causing more i/o operations.
The biggest drawback to having using private buffer pools is that
interactive users don't tend to just run reports, they also update
records. When they want update something, the block that was read
into the private buffer pool must be copied back to the shared
buffer pool. If it had been updated since the first read into the
private buffer, it must be read again, wasting a read and slowing
performance.
As we have seen, private buffers can be useful if used carefully.
It should be used as a startup option for a single user doing many
read only operations (reports/inquiries). Once the reports are
finished, the user should log out of Progress and start another
session without the -O parameter. If the -O option is used for
all users, there can be substantial performance degradation, not
an increase.
The best guideline is to test using private buffers in a controlled
way. If you get a performance enhancement, it might be worth using.
But for many users the best option will be to use the memory that
was going to be used by private buffers for the -B shared buffer pool.
NOTE: Private Buffer functionality was discontinued after version 9.1B. The -O and -I startup options for version 9.1C and higher are ignored.
REFERENCES TO WRITTEN DOCUMENTATION:
===================================
- Systems Administration Guide under startup options -O
- Systems Administration Guide - Appendix B using PROMON
Progress Software Technical Support Note # 5633