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
-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]
>