Parameter -B

Unfortunately, there is no simple answer to this question.

The -B database configuration parameter sets the number of database buffers that the database storage manager keeps in memory. Each buffer is used to hold a copy of a database block that has been read from disk so that if the same block is needed again, it can be accessed from the memory resident copy instead of reading it from disk, which takes longer. This helps performance. We call this set of buffers the "database buffer pool" and in a multi-user system it is kept in shared memory segments, allocated by the operating system, so it can be accessed by multiple processes at the same time. The size of the buffer pool, in bytes, will be approximately 1.1 times the value of -B times the database block size.

But memory is a finite resource and in most situations, it is not possible to keep /every/ block in memory. If you set -B to 1,000, then there will be room for 1,000 blocks. Once 1,000 different blocks have been read into memory, the next time a block not already in memory is needed, one of the blocks that is already there has to be thrown away to make room. The storage manager usually picks the one that was accessed least recently.

In general, the larger the value you use for -B, the better, but only up to a point. This is so for a variety of reasons:

• First, the buffer pool does not need to be larger than the whole database.

• Second, on 32-bit versions of OpenEdge, you cannot use more than approximately 2 gigabytes of shared memory.

• Third, as you increase the size of the buffer pool, performance will usually improve, but the /amount/ of improvement decreases as you increase the value of -B.

• A few other reasons I won't go into just now

You can find more information on this topic, and other database performance related topics, in the article " OpenEdge RDBMS Performance Tuning Made Simple" available here on PSDN at this link:

http://www.psdn.com/library/entry.jspa?entryID=1407

-gus

I saw in Progress Database Manual, something about problems with APW.

The APW verify all buffer pool to test if there is some modified block to write to disk. If the buffer pool is too much large than needed, the APW spend more resources doing this checking.

Is this an assertion or a question? Or a rumor you have heard somewhere?

I don't know what documentation you are referring to, but the APW's are very lightweight and do not consume much resources at all. I suppose it is theoretically possible for the APW's to consume cpu cyles for short time periods if the default settings of their configuration parameters are changed, or if the database buffer pool is extremely large (like 5,000,000 or something).

The APW's do go through the entire linked list of buffers at the beginning of each checkpoint cycle to construct the list of buffers that have to be written to disk before the end of the cycle. This is rarely a problem.

-gus

In Progress V9.1D can the -B parameter be set too large?

In the manual I can read: The size of the database buffer pool is set by the -B (Blocks in Database Buffers) startup

parameter. The maximum is 500,000 blocks.

Our parameter is set to 524288 (db blocksize is 1024) but the "Buffer Hits" percentage is 0 (zero!).

Could the parameter be too high?

In Progress V9.1D can the -B parameter be set too

large?

In the manual I can read: The size of the database

buffer pool is set by the -B (Blocks in Database

Buffers) startup

parameter. The maximum is 500,000 blocks.

Our parameter is set to 524288 (db blocksize is 1024)

but the "Buffer Hits" percentage is 0 (zero!).

Could the parameter be too high?

I believe the maximum is a misnomer.. The real maximum is the amount of memory your version can attach to (32bit is limited to just under 2GB or memory) and at 524288 you are allocating about 500MB of memory, so not near the limit (if you are 32bit).

The 'Buffer Hits' in promon could be suffering from overflow (due to the amount of time the DB has been up), especially if you are looking at the initial screen.. Wait 5 minutes and refresh for a better view, or calculate it yourself (I don't remember the calculation off the top of my head, but I am sure someone will post it)..

Kevin

Message was edited by:

Kevin Saunders

You're right... I forgot to refresh the srceen. Buffer hits now are mostly above 90% so I guess that's OK.

Thanks for your response.

Buffer hits now are mostly above 90% so I guess that's OK. Thanks for your response.

Anything below about 98% should be considered an opportunity for improvement.