Регистрация

Private Buffers

Готовим статьи для FAQ
Старожил
Аватара пользователя
Сообщения: 1523
Зарегистрирован: Чт сен 27, 2001 4:00 am
Откуда: Москва

Private Buffers

Сообщение dmi » Пт авг 05, 2005 5:40 pm

Разбирался с проблемой клиента, считаю, что довольно дельная статья.
----------------------------------------------------------------------
KB-P95829: How Progress uses Buffers and when to use Private Buffers (-Bp) ?
----------------------------------------------------------------------

Status: Unverified

GOAL:

When to use Private Buffers (Bp)

GOAL:

What is the impact of private buffers on system performance ?

GOAL:

Brief Overview of how Progress uses Buffers

FACT(s) (Environment):

Progress 9.1C
Progress 9.1D

FIX:

To properly discuss this topic letТs 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 (1K, 2K, 4K, 8K) 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 a number of
slots or spaces for records as defined by the "records per block" at
database creation.
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 as this is a shared
buffer pool used by all shared-memory clients. If the desired record
is contained in a block that is already in this buffer pool, it does
not need to be read again. By using this buffer pool, Progress is
saved from having to re-read every record required by the application
into memory.
The size of the buffer pool is controlled by the -B (Blocks in
Database Buffers) parameter on the broker startup command (_mprosrv)
multiplied by the database blocksize. There is a much greater chance
of having the sought after record already in memory, if you have a
large buffer pool and therefore more record manager blocks in that
pool. There is a point of diminishing returns when you increase the
pool size too high. Initially you start receiving no further
improvement 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 and eventually a rapid drop in performance
when the system starts swapping.
Progress offers a tool to help determine the correct setting for the
buffer pool size. By using the Progress Monitor (promon), Activity
screen and sampling Buffer Hits over a period of usual database
activity, aiming for the "Buffer Hits" percentage exceeding 95
percent, or until the system starts paging. A better metric is the
promon Option 3 "Block Access" to gauge the "DB Request" to "DB Read"
ratio; 0 DBReads: anynumber of DBRequests is the optimum, but
unlikely. 1 DBRead to 20 DBRequests is considered a good ballpark, but
your application "sweet point" is highly dependant on the application
itself and the activity that it taking place when these metrics are
baselined.

With this understanding on how Progress uses buffers, letТs 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 to get
the current price. 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 public buffer pool, and so each
additional request thereafter for these records do not need to be read
again 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
first be read into the public buffer pool. At some point, this buffer
pool is going to fill up. Normally this is not a problem since
Progress uses a Least Recently Used (LRU) algorithm to pick which
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 public buffer pool will have to be flushed to
disk, causing degradation in performance for everyone else accessing
the database. 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 specified by
the -Bp param.eter for the read intensive user. Each session that uses
a private read-only buffer reduces the number of public buffers
available and creates an isolated portion of private buffer pool
separate from the shared buffer pool managed by the database broker.
This private buffer pool is then used by Progress for read-only
operations like our customer master report example. As the user reads
records, if the corresponding buffers are not already in the shared
buffer pool, the records are read into their private buffer. So, when
their private buffer gets full, instead of reading the needed blocks
into the shared buffer pool, thereby displacing all of the blocks, the
buffer that was least recently used in the private pool is evicted by
the user who brought them into memory - thereby greatly reducing the
impact of running the report in the shared buffer pool.
As the private buffer pool (-Bp) is an isolated portion of public
buffer pool (-B), it is also limited by ЦB. The total ЦBp of all
client sessions is limited to a maximum of 25% of -B. The database
server startup parameter ЦBpmax, was introduced in 9.1C to limit the
maximum -Bp any single client connection can request. The default
value is 64, which was the hardcoded limit for -Bp in previous
Progress versions. In turn, ЦBpmax can be no more than 25% of the ЦB
value.
Performance problems begin when you realise that it is only efficient
for one user to use private buffers at a time. If two or more users
have sessions using the -Bp parameter, it takes up a lot more memory
and they don't get to take advantage of each other's private reads
which both adds to the system overhead as well as causing more i/o
operations. Incidentally, the converse is not true, users of the
public buffer pool may benefit from the content of the private buffer
pool reads. If another user needs a buffer that is currently in a
userТs private buffer, the buffer itself is not moved in memory, but
this buffer is effectively transferred to the public buffer pool by
adding this buffer to the public buffer list and removing it from the
private buffer list.
The biggest drawback to having private buffer pools in use, is that
interactive users don't tend to only run reports, they also update
records. When they want update something, the block that was read into
the private buffer pool must first be copied back to the public 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 only 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 -Bp parameter to release this memory back to the
public buffer pool. Private Buffers can be initialised through 4GL at
runtime using the "_MyConnection._MyConn-NumSeqBuffers' VST Table
before running the report and then unset after running the report. If
the -Bp option is used for all users, there will be a substantial
performance degradation, not an increase, because as soon as the
public buffer is filled, it will /never/ be replaced by data that is
frequently read because all users are using their own private buffers
and LRU chains and thus have to read much more from disk - which they
could potentially be sharing!
The best guideline is to test using private buffers in a controlled
way. For read-intensive users, if you get a performance enhancement it
might be worth using. But for many cases, the best option will be to
use the memory that was going to be used by private buffers for the -B
shared buffer pool..

/dmi

Старожил
Аватара пользователя
Сообщения: 2871
Зарегистрирован: Ср май 12, 2004 6:03 pm
Откуда: Питер

Re: Private Buffers

Сообщение George » Пт авг 05, 2005 6:22 pm

Я не согласен с негативным отношением автора статьи (Ruanne Cluer), которое она высказывает по поводу частных буферов. Но сейчас я не готов подробно изложить свою точку зрения и тем более подкрепить ее результатами экспериментов.

Приведу лишь ссылку на более подробное объяснение того, как работают частные буфера в Progress'е:

OpenEdge Revealed: Mastering the OpenEdge Database With Fathom Management
by Adam Backman
Expert Series
http://www.progress.com/progress_softwa ... pf/mpf.pdf

Managing OpenEdge Database Resources
Private buffers (-Bp)

Private buffers allow a read-intensive user to isolate a portion of the buffer pool. Up to 25 percent of buffers can be allocated as private buffers. Private buffers work as follows:

1. The user requests a number of buffers to be allocated as private.

2. As the user reads records, if the corresponding buffers are not already in the buffer pool, the records are read into these buffers.

3. Instead of following the rules for buffer eviction, the user only evicts buffers that are in their private buffers. By default, the buffer that was least recently used is evicted. Private buffers are maintained on their own chain and are evicted by the user who brought them into memory.

4. If another user wants a buffer that is currently in another user’s private buffers, this buffer is “transferred” from the private buffers to the general buffer pool. The transfer is a process of removing the buffer from the user’s private buffer list and adding it to the general buffer list. The buffer itself is not moved.

The general idea is to share memory where you can, use memory efficiently where possible, increase memory on the broker side first, and then increase client memory usage.

Соглашусь с Руан, что лучшем вариантом использования частных буферов являлось бы их програмное выделение перед запуском отчетов и освобождение буферов после завершения отчета. Т.е. использование _MyConnection._MyConn-NumSeqBuffers.

Модератор
Сообщения: 407
Зарегистрирован: Чт июл 12, 2001 4:00 am

re:Private Buffers

Сообщение van » Пт авг 12, 2005 4:00 pm

ты наверное подумал, что твое сообщение потерялось и еще раз написал
;)
нет. просто топик перенесен вот куда
http://forum.infobit.ru/viewtopic.php?t=561
а сюда уже не надо писать.
тут статьи для faq

Вернуться в СТАТЬИ

Кто сейчас на конференции

Сейчас этот форум просматривают: нет зарегистрированных пользователей и гости: 1