# Blocks in DB Buffer

Thank you Michael for the great explanation...I have a document from Progress, but I think you summarized it better than they could....and thanks everyone else for the input. This should help us get where we need to be.

-Adam

--- In vantage@yahoogroups.com, Michael Barry <mbarry@...> wrote:
>
> Shared message blocks are the mechanism OE utilizes to communicate
> between the DB and the app servers/application. The are implemented
> as a series of queues and semaphores that effect the DB transactions
> with the business logic. Increasing the size of the message blocks
> reduces the system overhead required to manage the transactions but
> only if the average transaction allocation can fill the block size.
> If your average transaction size is less than the allocated shared
> memory block size then you are over allocating memory.
>
> Per the DB blocks in memory setting, 32 bit OE is limited to 2GB for
> all running processes so you have to make sure to leave sufficient
> memory for app servers and other db's or OE will panic.
>
> Regards,
>
> Michael
>
> Michael Barry
> Aspacia Systems Inc
> 866.566.9600
> 312.803.0730 fax
> http://www.aspacia.com/
>
> This email, and any attachments thereto, is intended only for use by
> the addressee(s) named herein and may contain legally privileged and/
> or confidential information. If you are not the intended recipient of
> this email, you are hereby notified that any dissemination,
> distribution or copying of this email, and any attachments thereto, is
> strictly prohibited. If you have received this email in error, please
> immediately notify me by telephone and permanently delete the original
> and any copy of any email and any printout thereof.
>
>
>
>
> On Oct 23, 2009, at 10:37 AM, Chris Robisch wrote:
>
> > See below from OpenEdge Deployment, Startup and Parameter Reference.
> > By lowering -shmsegsize you can increase #blocks but all you're
> > doing is cutting the same pie into smaller pieces, possibly
> > decreasing performance. Default is 128 on 32-bit and 1024 for 64-bit
> > systems.
> > "Specifying shared memory segment size can improve performance.
> > Increasing the size of the shared memory segments decreases the
> > number of segments allocated, in turn decreasing the system
> > resources needed to manage the segments."
> >
> > ----- Original Message -----
> > From: adam.whipp
> > To: vantage@yahoogroups.com
> > Sent: Friday, October 23, 2009 9:12 AM
> > Subject: [Vantage] Re: # Blocks in DB Buffer
> >
> > Joel -- Do you have more info on the -shmsegsize command? I found an
> > earlier post that suggested going as low as 128. That post also said
> > the default is 1024 when that command is omitted. What all would be
> > affected by changing this? I dropped ours to 128 and I can now get
> > the blocks all the way up to 375000 instead of 160000. I just want
> > to make sure that I am not adversely affecting performance by
> > lowering that to 128, and I am curious why that affects the number
> > of blocks in DB buffer. Thanks!
> >
> > -Adam
> >
> > --- In vantage@yahoogroups.com, "Joel Kolling" <jkolling@> wrote:
> > >
> > > I have mine set at 200000 on Windows 2003 64 Bit. I have # Lock
> > table
> > > entries: 256000 and Other server arguments : -shmsegsize 512.
> > >
> > >
> > >
> > >
> > >
> > > Joel Kolling
> > > IT Manager
> > > ITC Manufacturing, Inc.
> > > Phone: 602-648-0021
> > > Cell: 480-861-2009
> > > Fax: 602-415-1444
> > >
> > > From: vantage@yahoogroups.com [mailto:vantage@yahoogroups.com] On
> > Behalf
> > > Of Steven Gotschall
> > > Sent: Friday, October 23, 2009 8:06 AM
> > > To: vantage@yahoogroups.com
> > > Subject: Re: [Vantage] # Blocks in DB Buffer
> > >
> > >
> > >
> > >
> > >
> > > We saw the same thing happen. I could only get mine to about
> > 80,000 and
> > > that is on a 64 Bit Windows 2003 server with 16GB of Ram. We are
> > > running 8.03.408A Progress.
> > >
> > > ________________________________
> > > From: adam.whipp <adam.whipp@
> > > <mailto:adam.whipp%40nationaltubeform.com> >
> > > To: vantage@yahoogroups.com <mailto:vantage%40yahoogroups.com>
> > > Sent: Fri, October 23, 2009 10:34:18 AM
> > > Subject: [Vantage] # Blocks in DB Buffer
> > >
> > >
> > > I was hoping someone can give advice on the # of blocks in DB buffer
> > > parameter. We are on 8.03.408B on a progress database. Our
> > database is
> > > 8.6 GB and our block size is 4k. Our server is Enterprise 2003 32bit
> > > with 8 GB RAM. If I am understanding Epicor's tuning guide, we
> > should
> > > try to allocate 4 GB RAM for the database (1/2 the size of the
> > > database). However, the max blocks in DB buffer we can get to work
> > is
> > > about 160000 which is about 800 MB of RAM. If we raise that
> > number, the
> > > database starts, but the appservers won't start. I can watch the
> > > appservers try to start and they just count down to 0 and then
> > stop. Has
> > > anyone else seen this behavior? Let me know if you need any
> > additional
> > > info on our setup...Thanks!
> > >
> > > -Adam
> > >
> > > [Non-text portions of this message have been removed]
> > >
> > >
> > >
> > > No virus found in this incoming message.
> > > Checked by AVG - www.avg.com
> > > Version: 9.0.686 / Virus Database: 270.14.26/2451 - Release Date:
> > > 10/22/09 11:44:00
> > >
> > >
> > >
> > > [Non-text portions of this message have been removed]
> > >
> >
> > ------------------------------------
> >
> > Useful links for the Yahoo!Groups Vantage Board are: ( Note: You
> > must have already linked your email address to a yahoo id to enable
> > access. )
> > (1) To access the Files Section of our Yahoo!Group for Report
> > Builder and Crystal Reports and other 'goodies', please goto: http://groups.yahoo.com/group/vantage/files/
> > .
> > (2) To search through old msg's goto: http://groups.yahoo.com/group/vantage/messages
> > (3) To view links to Vendors that provide Vantage services goto: http://groups.yahoo.com/group/vantage/linksYahoo!
> > Groups Links
> >
> > [Non-text portions of this message have been removed]
> >
> >
>
>
>
> [Non-text portions of this message have been removed]
>
I was hoping someone can give advice on the # of blocks in DB buffer parameter. We are on 8.03.408B on a progress database. Our database is 8.6 GB and our block size is 4k. Our server is Enterprise 2003 32bit with 8 GB RAM. If I am understanding Epicor's tuning guide, we should try to allocate 4 GB RAM for the database (1/2 the size of the database). However, the max blocks in DB buffer we can get to work is about 160000 which is about 800 MB of RAM. If we raise that number, the database starts, but the appservers won't start. I can watch the appservers try to start and they just count down to 0 and then stop. Has anyone else seen this behavior? Let me know if you need any additional info on our setup...Thanks!

-Adam
We saw the same thing happen. I could only get mine to about 80,000 and that is on a 64 Bit Windows 2003 server with 16GB of Ram. We are running 8.03.408A Progress.




________________________________
From: adam.whipp <adam.whipp@...>
To: vantage@yahoogroups.com
Sent: Fri, October 23, 2009 10:34:18 AM
Subject: [Vantage] # Blocks in DB Buffer

Â
I was hoping someone can give advice on the # of blocks in DB buffer parameter. We are on 8.03.408B on a progress database. Our database is 8.6 GB and our block size is 4k. Our server is Enterprise 2003 32bit with 8 GB RAM. If I am understanding Epicor's tuning guide, we should try to allocate 4 GB RAM for the database (1/2 the size of the database). However, the max blocks in DB buffer we can get to work is about 160000 which is about 800 MB of RAM. If we raise that number, the database starts, but the appservers won't start. I can watch the appservers try to start and they just count down to 0 and then stop. Has anyone else seen this behavior? Let me know if you need any additional info on our setup...Thanks!

-Adam







[Non-text portions of this message have been removed]
Ours is set to 180000 and we are running Windows Small Business Server
with 4 GB of RAM. We're on 408B.



Thanks,

Blake Clemens

IT Systems Engineer

Delmarva Millwork Corporation

(800) 360-2364 x132

From: vantage@yahoogroups.com [mailto:vantage@yahoogroups.com] On Behalf
Of Steven Gotschall
Sent: Friday, October 23, 2009 11:06 AM
To: vantage@yahoogroups.com
Subject: Re: [Vantage] # Blocks in DB Buffer





We saw the same thing happen. I could only get mine to about 80,000 and
that is on a 64 Bit Windows 2003 server with 16GB of Ram. We are
running 8.03.408A Progress.

________________________________
From: adam.whipp <adam.whipp@...
<mailto:adam.whipp%40nationaltubeform.com> >
To: vantage@yahoogroups.com <mailto:vantage%40yahoogroups.com>
Sent: Fri, October 23, 2009 10:34:18 AM
Subject: [Vantage] # Blocks in DB Buffer


I was hoping someone can give advice on the # of blocks in DB buffer
parameter. We are on 8.03.408B on a progress database. Our database is
8.6 GB and our block size is 4k. Our server is Enterprise 2003 32bit
with 8 GB RAM. If I am understanding Epicor's tuning guide, we should
try to allocate 4 GB RAM for the database (1/2 the size of the
database). However, the max blocks in DB buffer we can get to work is
about 160000 which is about 800 MB of RAM. If we raise that number, the
database starts, but the appservers won't start. I can watch the
appservers try to start and they just count down to 0 and then stop. Has
anyone else seen this behavior? Let me know if you need any additional
info on our setup...Thanks!

-Adam

[Non-text portions of this message have been removed]





[Non-text portions of this message have been removed]
I have mine set at 200000 on Windows 2003 64 Bit. I have # Lock table
entries: 256000 and Other server arguments : -shmsegsize 512.





Joel Kolling
IT Manager
ITC Manufacturing, Inc.
Phone: 602-648-0021
Cell: 480-861-2009
Fax: 602-415-1444

From: vantage@yahoogroups.com [mailto:vantage@yahoogroups.com] On Behalf
Of Steven Gotschall
Sent: Friday, October 23, 2009 8:06 AM
To: vantage@yahoogroups.com
Subject: Re: [Vantage] # Blocks in DB Buffer





We saw the same thing happen. I could only get mine to about 80,000 and
that is on a 64 Bit Windows 2003 server with 16GB of Ram. We are
running 8.03.408A Progress.

________________________________
From: adam.whipp <adam.whipp@...
<mailto:adam.whipp%40nationaltubeform.com> >
To: vantage@yahoogroups.com <mailto:vantage%40yahoogroups.com>
Sent: Fri, October 23, 2009 10:34:18 AM
Subject: [Vantage] # Blocks in DB Buffer


I was hoping someone can give advice on the # of blocks in DB buffer
parameter. We are on 8.03.408B on a progress database. Our database is
8.6 GB and our block size is 4k. Our server is Enterprise 2003 32bit
with 8 GB RAM. If I am understanding Epicor's tuning guide, we should
try to allocate 4 GB RAM for the database (1/2 the size of the
database). However, the max blocks in DB buffer we can get to work is
about 160000 which is about 800 MB of RAM. If we raise that number, the
database starts, but the appservers won't start. I can watch the
appservers try to start and they just count down to 0 and then stop. Has
anyone else seen this behavior? Let me know if you need any additional
info on our setup...Thanks!

-Adam

[Non-text portions of this message have been removed]



No virus found in this incoming message.
Checked by AVG - www.avg.com
Version: 9.0.686 / Virus Database: 270.14.26/2451 - Release Date:
10/22/09 11:44:00



[Non-text portions of this message have been removed]
Joel -- Do you have more info on the -shmsegsize command? I found an earlier post that suggested going as low as 128. That post also said the default is 1024 when that command is omitted. What all would be affected by changing this? I dropped ours to 128 and I can now get the blocks all the way up to 375000 instead of 160000. I just want to make sure that I am not adversely affecting performance by lowering that to 128, and I am curious why that affects the number of blocks in DB buffer. Thanks!

-Adam


--- In vantage@yahoogroups.com, "Joel Kolling" <jkolling@...> wrote:
>
> I have mine set at 200000 on Windows 2003 64 Bit. I have # Lock table
> entries: 256000 and Other server arguments : -shmsegsize 512.
>
>
>
>
>
> Joel Kolling
> IT Manager
> ITC Manufacturing, Inc.
> Phone: 602-648-0021
> Cell: 480-861-2009
> Fax: 602-415-1444
>
> From: vantage@yahoogroups.com [mailto:vantage@yahoogroups.com] On Behalf
> Of Steven Gotschall
> Sent: Friday, October 23, 2009 8:06 AM
> To: vantage@yahoogroups.com
> Subject: Re: [Vantage] # Blocks in DB Buffer
>
>
>
>
>
> We saw the same thing happen. I could only get mine to about 80,000 and
> that is on a 64 Bit Windows 2003 server with 16GB of Ram. We are
> running 8.03.408A Progress.
>
> ________________________________
> From: adam.whipp <adam.whipp@...
> <mailto:adam.whipp%40nationaltubeform.com> >
> To: vantage@yahoogroups.com <mailto:vantage%40yahoogroups.com>
> Sent: Fri, October 23, 2009 10:34:18 AM
> Subject: [Vantage] # Blocks in DB Buffer
>
>
> I was hoping someone can give advice on the # of blocks in DB buffer
> parameter. We are on 8.03.408B on a progress database. Our database is
> 8.6 GB and our block size is 4k. Our server is Enterprise 2003 32bit
> with 8 GB RAM. If I am understanding Epicor's tuning guide, we should
> try to allocate 4 GB RAM for the database (1/2 the size of the
> database). However, the max blocks in DB buffer we can get to work is
> about 160000 which is about 800 MB of RAM. If we raise that number, the
> database starts, but the appservers won't start. I can watch the
> appservers try to start and they just count down to 0 and then stop. Has
> anyone else seen this behavior? Let me know if you need any additional
> info on our setup...Thanks!
>
> -Adam
>
> [Non-text portions of this message have been removed]
>
>
>
> No virus found in this incoming message.
> Checked by AVG - www.avg.com
> Version: 9.0.686 / Virus Database: 270.14.26/2451 - Release Date:
> 10/22/09 11:44:00
>
>
>
> [Non-text portions of this message have been removed]
>
See below from OpenEdge Deployment, Startup and Parameter Reference. By lowering -shmsegsize you can increase #blocks but all you're doing is cutting the same pie into smaller pieces, possibly decreasing performance. Default is 128 on 32-bit and 1024 for 64-bit systems.
"Specifying shared memory segment size can improve performance. Increasing the size of the shared memory segments decreases the number of segments allocated, in turn decreasing the system resources needed to manage the segments."

----- Original Message -----
From: adam.whipp
To: vantage@yahoogroups.com
Sent: Friday, October 23, 2009 9:12 AM
Subject: [Vantage] Re: # Blocks in DB Buffer


Joel -- Do you have more info on the -shmsegsize command? I found an earlier post that suggested going as low as 128. That post also said the default is 1024 when that command is omitted. What all would be affected by changing this? I dropped ours to 128 and I can now get the blocks all the way up to 375000 instead of 160000. I just want to make sure that I am not adversely affecting performance by lowering that to 128, and I am curious why that affects the number of blocks in DB buffer. Thanks!

-Adam


--- In vantage@yahoogroups.com, "Joel Kolling" <jkolling@...> wrote:
>
> I have mine set at 200000 on Windows 2003 64 Bit. I have # Lock table
> entries: 256000 and Other server arguments : -shmsegsize 512.
>
>
>
>
>
> Joel Kolling
> IT Manager
> ITC Manufacturing, Inc.
> Phone: 602-648-0021
> Cell: 480-861-2009
> Fax: 602-415-1444
>
> From: vantage@yahoogroups.com [mailto:vantage@yahoogroups.com] On Behalf
> Of Steven Gotschall
> Sent: Friday, October 23, 2009 8:06 AM
> To: vantage@yahoogroups.com
> Subject: Re: [Vantage] # Blocks in DB Buffer
>
>
>
>
>
> We saw the same thing happen. I could only get mine to about 80,000 and
> that is on a 64 Bit Windows 2003 server with 16GB of Ram. We are
> running 8.03.408A Progress.
>
> ________________________________
> From: adam.whipp <adam.whipp@...
> <mailto:adam.whipp%40nationaltubeform.com> >
> To: vantage@yahoogroups.com <mailto:vantage%40yahoogroups.com>
> Sent: Fri, October 23, 2009 10:34:18 AM
> Subject: [Vantage] # Blocks in DB Buffer
>
>
> I was hoping someone can give advice on the # of blocks in DB buffer
> parameter. We are on 8.03.408B on a progress database. Our database is
> 8.6 GB and our block size is 4k. Our server is Enterprise 2003 32bit
> with 8 GB RAM. If I am understanding Epicor's tuning guide, we should
> try to allocate 4 GB RAM for the database (1/2 the size of the
> database). However, the max blocks in DB buffer we can get to work is
> about 160000 which is about 800 MB of RAM. If we raise that number, the
> database starts, but the appservers won't start. I can watch the
> appservers try to start and they just count down to 0 and then stop. Has
> anyone else seen this behavior? Let me know if you need any additional
> info on our setup...Thanks!
>
> -Adam
>
> [Non-text portions of this message have been removed]
>
>
>
> No virus found in this incoming message.
> Checked by AVG - www.avg.com
> Version: 9.0.686 / Virus Database: 270.14.26/2451 - Release Date:
> 10/22/09 11:44:00
>
>
>
> [Non-text portions of this message have been removed]
>




------------------------------------

Useful links for the Yahoo!Groups Vantage Board are: ( Note: You must have already linked your email address to a yahoo id to enable access. )
(1) To access the Files Section of our Yahoo!Group for Report Builder and Crystal Reports and other 'goodies', please goto: http://groups.yahoo.com/group/vantage/files/.
(2) To search through old msg's goto: http://groups.yahoo.com/group/vantage/messages
(3) To view links to Vendors that provide Vantage services goto: http://groups.yahoo.com/group/vantage/linksYahoo! Groups Links





[Non-text portions of this message have been removed]
Shared message blocks are the mechanism OE utilizes to communicate
between the DB and the app servers/application. The are implemented
as a series of queues and semaphores that effect the DB transactions
with the business logic. Increasing the size of the message blocks
reduces the system overhead required to manage the transactions but
only if the average transaction allocation can fill the block size.
If your average transaction size is less than the allocated shared
memory block size then you are over allocating memory.

Per the DB blocks in memory setting, 32 bit OE is limited to 2GB for
all running processes so you have to make sure to leave sufficient
memory for app servers and other db's or OE will panic.

Regards,

Michael

Michael Barry
Aspacia Systems Inc
866.566.9600
312.803.0730 fax
http://www.aspacia.com/

This email, and any attachments thereto, is intended only for use by
the addressee(s) named herein and may contain legally privileged and/
or confidential information. If you are not the intended recipient of
this email, you are hereby notified that any dissemination,
distribution or copying of this email, and any attachments thereto, is
strictly prohibited. If you have received this email in error, please
immediately notify me by telephone and permanently delete the original
and any copy of any email and any printout thereof.




On Oct 23, 2009, at 10:37 AM, Chris Robisch wrote:

> See below from OpenEdge Deployment, Startup and Parameter Reference.
> By lowering -shmsegsize you can increase #blocks but all you're
> doing is cutting the same pie into smaller pieces, possibly
> decreasing performance. Default is 128 on 32-bit and 1024 for 64-bit
> systems.
> "Specifying shared memory segment size can improve performance.
> Increasing the size of the shared memory segments decreases the
> number of segments allocated, in turn decreasing the system
> resources needed to manage the segments."
>
> ----- Original Message -----
> From: adam.whipp
> To: vantage@yahoogroups.com
> Sent: Friday, October 23, 2009 9:12 AM
> Subject: [Vantage] Re: # Blocks in DB Buffer
>
> Joel -- Do you have more info on the -shmsegsize command? I found an
> earlier post that suggested going as low as 128. That post also said
> the default is 1024 when that command is omitted. What all would be
> affected by changing this? I dropped ours to 128 and I can now get
> the blocks all the way up to 375000 instead of 160000. I just want
> to make sure that I am not adversely affecting performance by
> lowering that to 128, and I am curious why that affects the number
> of blocks in DB buffer. Thanks!
>
> -Adam
>
> --- In vantage@yahoogroups.com, "Joel Kolling" <jkolling@...> wrote:
> >
> > I have mine set at 200000 on Windows 2003 64 Bit. I have # Lock
> table
> > entries: 256000 and Other server arguments : -shmsegsize 512.
> >
> >
> >
> >
> >
> > Joel Kolling
> > IT Manager
> > ITC Manufacturing, Inc.
> > Phone: 602-648-0021
> > Cell: 480-861-2009
> > Fax: 602-415-1444
> >
> > From: vantage@yahoogroups.com [mailto:vantage@yahoogroups.com] On
> Behalf
> > Of Steven Gotschall
> > Sent: Friday, October 23, 2009 8:06 AM
> > To: vantage@yahoogroups.com
> > Subject: Re: [Vantage] # Blocks in DB Buffer
> >
> >
> >
> >
> >
> > We saw the same thing happen. I could only get mine to about
> 80,000 and
> > that is on a 64 Bit Windows 2003 server with 16GB of Ram. We are
> > running 8.03.408A Progress.
> >
> > ________________________________
> > From: adam.whipp <adam.whipp@...
> > <mailto:adam.whipp%40nationaltubeform.com> >
> > To: vantage@yahoogroups.com <mailto:vantage%40yahoogroups.com>
> > Sent: Fri, October 23, 2009 10:34:18 AM
> > Subject: [Vantage] # Blocks in DB Buffer
> >
> >
> > I was hoping someone can give advice on the # of blocks in DB buffer
> > parameter. We are on 8.03.408B on a progress database. Our
> database is
> > 8.6 GB and our block size is 4k. Our server is Enterprise 2003 32bit
> > with 8 GB RAM. If I am understanding Epicor's tuning guide, we
> should
> > try to allocate 4 GB RAM for the database (1/2 the size of the
> > database). However, the max blocks in DB buffer we can get to work
> is
> > about 160000 which is about 800 MB of RAM. If we raise that
> number, the
> > database starts, but the appservers won't start. I can watch the
> > appservers try to start and they just count down to 0 and then
> stop. Has
> > anyone else seen this behavior? Let me know if you need any
> additional
> > info on our setup...Thanks!
> >
> > -Adam
> >
> > [Non-text portions of this message have been removed]
> >
> >
> >
> > No virus found in this incoming message.
> > Checked by AVG - www.avg.com
> > Version: 9.0.686 / Virus Database: 270.14.26/2451 - Release Date:
> > 10/22/09 11:44:00
> >
> >
> >
> > [Non-text portions of this message have been removed]
> >
>
> ------------------------------------
>
> Useful links for the Yahoo!Groups Vantage Board are: ( Note: You
> must have already linked your email address to a yahoo id to enable
> access. )
> (1) To access the Files Section of our Yahoo!Group for Report
> Builder and Crystal Reports and other 'goodies', please goto: http://groups.yahoo.com/group/vantage/files/
> .
> (2) To search through old msg's goto: http://groups.yahoo.com/group/vantage/messages
> (3) To view links to Vendors that provide Vantage services goto: http://groups.yahoo.com/group/vantage/linksYahoo!
> Groups Links
>
> [Non-text portions of this message have been removed]
>
>



[Non-text portions of this message have been removed]