Consequences of raising MAXBOBMEM for EXBUFOBJLM errors

Consequences of raising MAXBOBMEM for EXBUFOBJLM errors

Post by John Johnston » Thu, 16 Dec 1999 04:00:00



I have a system running VMS V7.2-1 that's getting a

%SYSTEM-F-EXBUFOBJLM, exceeded systemwide buffer object page limit (MAXBOBMEM)

error when trying to create a DECterm from a CDE session.  This has also
happened on a system running VMS V7.2.  I called Compaq about it and they
forwarded to me a copy of a support database article about it.  What was
forwarded to me doesn't have a title.  Here's the beginning of it:

Copyright (c) Compaq Computer Corporation 1999. All rights reserved.

PRODUCT:    Decwindows Motif[R] v1.2-5

OP/SYS:     OpenVMS Alpha Version(s) 7.2, 7.2-1

COMPONENT:  DECterm

SOURCE:     Compaq Computer Corporation

PROBLEM:

After upgrading to OpenVMS Version 7.2-1, and VMS Decwindows Motif
Version 1.2-5, users are unable to create more than 2 additional
processes after the session manager and the window manager are
started.

Compaq stated that there was no fix available yet but the issue was being
worked on.  As a workaround it was suggested that MAXBOBMEM and MAXBOBS0S1
be increased from the default value of 1600 each to 16000 each.  I tried
this and it did allow DECterms to be created.  This was without a reboot
since these are dynamic parameters.

Does anyone know if there's any downside to increasing these sysgen
parameters?  Is this just going to postpone the error?

A SHOW MEM does show that buffer objects are maxed out at 100 pages when the
error occurs.  Looking a system that isn't having the problem shows single
or double digit values for buffer objects.

Buffer Object Usage (pages):                  In Use        Peak
  32-bit System Space Windows (S0/S1)            100         100
  64-bit System Space Windows (S2)                 0           0
  Physical pages locked by buffer objects        100         100

Curiously enough, much of the system runs OK when the error occurs.  Process
creation by itself isn't a problem since I can login remotely with no
problem.  So far, processes that are running when the error starts continue
to do so.  So what does creating a DECterm do that seems to consume a buffer
object and what is a systemwide buffer object anyway?  :-)

 
 
 

Consequences of raising MAXBOBMEM for EXBUFOBJLM errors

Post by Mickey Stei » Thu, 16 Dec 1999 04:00:00


The 'MaxBob' params are a strange lot.. I had a problem with db (sybase)
connections being refused along with motif connections being refused, checked
everything until I was frapped and then talked to Dec. They suggested that
increasing maxbobmem might help so I doubled it. I really just needed to be able
to sustain about 200 simultaneous connections and amazingly enough, maxbobmem came
though. I've been running like this for months and not a single problem nor is
anything visibly different in sho mem/full --

Sooooo -- I did find out a few other things, although i can't remember the other
maxbob... params (2 more) , I remember that if you're having trouble sizing the
oracle SGA (if you happen to have oracle's db) , that the maxbobmem and the 2nd
parameter need to be set according to a formula which resides on dsnlink
somewhere. (big help that was :)

Anyway , going from 1600 to 16000 seems a bit drastic but if you're not having
problems then it's probably a decent workaround.

          good luck,
                mick


> I have a system running VMS V7.2-1 that's getting a

> %SYSTEM-F-EXBUFOBJLM, exceeded systemwide buffer object page limit (MAXBOBMEM)

> error when trying to create a DECterm from a CDE session.  This has also
> happened on a system running VMS V7.2.  I called Compaq about it and they
> forwarded to me a copy of a support database article about it.  What was
> forwarded to me doesn't have a title.  Here's the beginning of it:

> Copyright (c) Compaq Computer Corporation 1999. All rights reserved.

> PRODUCT:    Decwindows Motif[R] v1.2-5

> OP/SYS:     OpenVMS Alpha Version(s) 7.2, 7.2-1

> COMPONENT:  DECterm

> SOURCE:     Compaq Computer Corporation

> PROBLEM:

> After upgrading to OpenVMS Version 7.2-1, and VMS Decwindows Motif
> Version 1.2-5, users are unable to create more than 2 additional
> processes after the session manager and the window manager are
> started.

> Compaq stated that there was no fix available yet but the issue was being
> worked on.  As a workaround it was suggested that MAXBOBMEM and MAXBOBS0S1
> be increased from the default value of 1600 each to 16000 each.  I tried
> this and it did allow DECterms to be created.  This was without a reboot
> since these are dynamic parameters.

> Does anyone know if there's any downside to increasing these sysgen
> parameters?  Is this just going to postpone the error?

> A SHOW MEM does show that buffer objects are maxed out at 100 pages when the
> error occurs.  Looking a system that isn't having the problem shows single
> or double digit values for buffer objects.

> Buffer Object Usage (pages):                  In Use        Peak
>   32-bit System Space Windows (S0/S1)            100         100
>   64-bit System Space Windows (S2)                 0           0
>   Physical pages locked by buffer objects        100         100

> Curiously enough, much of the system runs OK when the error occurs.  Process
> creation by itself isn't a problem since I can login remotely with no
> problem.  So far, processes that are running when the error starts continue
> to do so.  So what does creating a DECterm do that seems to consume a buffer
> object and what is a systemwide buffer object anyway?  :-)


 
 
 

Consequences of raising MAXBOBMEM for EXBUFOBJLM errors

Post by Theo Jakobu » Fri, 17 Dec 1999 04:00:00



> I have a system running VMS V7.2-1 that's getting a

> %SYSTEM-F-EXBUFOBJLM, exceeded systemwide buffer object page limit (MAXBOBMEM)

> error when trying to create a DECterm from a CDE session.  This has also
> happened on a system running VMS V7.2.  I called Compaq about it and they
> forwarded to me a copy of a support database article about it.  What was
> forwarded to me doesn't have a title.  Here's the beginning of it:

> Copyright (c) Compaq Computer Corporation 1999. All rights reserved.

> PRODUCT:    Decwindows Motif[R] v1.2-5

> OP/SYS:     OpenVMS Alpha Version(s) 7.2, 7.2-1

> COMPONENT:  DECterm

> SOURCE:     Compaq Computer Corporation

> PROBLEM:

> After upgrading to OpenVMS Version 7.2-1, and VMS Decwindows Motif
> Version 1.2-5, users are unable to create more than 2 additional
> processes after the session manager and the window manager are
> started.

> Compaq stated that there was no fix available yet but the issue was being
> worked on.  As a workaround it was suggested that MAXBOBMEM and MAXBOBS0S1
> be increased from the default value of 1600 each to 16000 each.  I tried
> this and it did allow DECterms to be created.  This was without a reboot
> since these are dynamic parameters.

> Does anyone know if there's any downside to increasing these sysgen
> parameters?  Is this just going to postpone the error?

> A SHOW MEM does show that buffer objects are maxed out at 100 pages when the
> error occurs.  Looking a system that isn't having the problem shows single
> or double digit values for buffer objects.

> Buffer Object Usage (pages):                  In Use        Peak
>   32-bit System Space Windows (S0/S1)            100         100
>   64-bit System Space Windows (S2)                 0           0
>   Physical pages locked by buffer objects        100         100

> Curiously enough, much of the system runs OK when the error occurs.  Process
> creation by itself isn't a problem since I can login remotely with no
> problem.  So far, processes that are running when the error starts continue
> to do so.  So what does creating a DECterm do that seems to consume a buffer
> object and what is a systemwide buffer object anyway?  :-)

I had the identical problem in June there were some entries in this
groups at June 18.
I did trial and error tests and have now a stable system with
MIN_MAXBOBMEM = 50000 and MIN_MAXBOBS0S1 = 50000 in
SYS$SYSTEM:MODPARAMS.DAT. The other parameter is MAXBOBS2 = 1600 which I
didn't change.

--

***********************************************************
*                                                         *
*  Theo Jakobus                                           *
*  Fraunhofer-Institut fuer Angewandte Festkoerperphysik  *
*  Tullastr. 72                                           *
*  D-79108 Freiburg                                       *
*  Germany                                                *
*  Phone:   +49-(0)761-5159-325                           *
*  FAX :    +49-(0)761-5159-200                           *

*  http://www.iaf.fhg.de                                  *
*                                                         *
***********************************************************

 
 
 

Consequences of raising MAXBOBMEM for EXBUFOBJLM errors

Post by John Johnston » Sat, 18 Dec 1999 04:00:00



> Sooooo -- I did find out a few other things, although i can't remember the other
> maxbob... params (2 more) , I remember that if you're having trouble sizing the
> oracle SGA (if you happen to have oracle's db) , that the maxbobmem and the 2nd
> parameter need to be set according to a formula which resides on dsnlink
> somewhere. (big help that was :)

> Anyway , going from 1600 to 16000 seems a bit drastic but if you're not having
> problems then it's probably a decent workaround.

Thanks for the reply.  The formula is in the article that was forwarded to me
by Compaq.


> I had the identical problem in June there were some entries in this
> groups at June 18.
> I did trial and error tests and have now a stable system with
> MIN_MAXBOBMEM = 50000 and MIN_MAXBOBS0S1 = 50000 in
> SYS$SYSTEM:MODPARAMS.DAT. The other parameter is MAXBOBS2 = 1600 which I
> didn't change.

The situation is odd.  When the problem occured SHOW MEM showed the usage at
100 pages which was the sysgen limit.  At this point no DECterms could be
created and only one or possibly none were active.  I increased the sysgen
limit and could then create new DECterms.  The SHOW MEM value went up as new
DECterms were created but it then went back down as the DECterms were closed.
 
 
 

Consequences of raising MAXBOBMEM for EXBUFOBJLM errors

Post by Jan Vorbruegge » Sat, 18 Dec 1999 04:00:00



> The situation is odd.  When the problem occured SHOW MEM showed the usage at
> 100 pages which was the sysgen limit.  At this point no DECterms could be
> created and only one or possibly none were active.  I increased the sysgen
> limit and could then create new DECterms.  The SHOW MEM value went up as new
> DECterms were created but it then went back down as the DECterms were closed.

Well, that's what you'd expect if creating a DECterm actually consumed buffer
objects, wouldn't you?

Now, of course the _real_ question is what DECterms are using them for!

        Jan

 
 
 

Consequences of raising MAXBOBMEM for EXBUFOBJLM errors

Post by Brian Schenkenberger, VAXma » Sat, 18 Dec 1999 04:00:00




>> The situation is odd.  When the problem occured SHOW MEM showed the usage at
>> 100 pages which was the sysgen limit.  At this point no DECterms could be
>> created and only one or possibly none were active.  I increased the sysgen
>> limit and could then create new DECterms.  The SHOW MEM value went up as new
>> DECterms were created but it then went back down as the DECterms were closed.

>Well, that's what you'd expect if creating a DECterm actually consumed buffer
>objects, wouldn't you?

>Now, of course the _real_ question is what DECterms are using them for!

What they were designed for -- simplifying and expediting driver I/O.  
Also, it's the pseudo-terminal driver that is using them so, anything
employing PTDs will consume your MAXBOBMEM system quota.

--

 
 
 

Consequences of raising MAXBOBMEM for EXBUFOBJLM errors

Post by Fred Kleinsorg » Sat, 18 Dec 1999 04:00:00


MAXBOBMEM was invented to prevent someone consuming all physical memory by
placing a system wide limit on physical memory consumption by Buffer
Objects.

Because of the way some database applications work, MAXBOBS0S1 and S2 were
created to put similar limits on Virtual Address space (as opposed to
physical memory).

The DECwindows errrors that are "normally" seen come from the
X11 server, not from DECterm (for instance, the 3D30/4D20).  The failures do
NOT prevent operation -- because the code simply then uses PIO instead of
DMA.  The Buffer Object prevents the need for doing lots of lock/unlocks for
DMA.

If you get the error for DECwindows, just crank up MAXBOBMEM *and*
MAXBOBS0S1 -- there is NO WAY TO DISTINGUISH A
FAILURE OF ANY OF THE THREE.  DECwindows does not use
S2 space.

In the NEXT release of OpenVMS, these parameters GO AWAY.
The exec group has determined that other mechanisms adequately
protect the system resource usage, and these limits simply get in
the way of proper operation.

 
 
 

1. %SYSTEM-F-EXBUFOBJLM

Hi Folks

I'm new to VMS, so perhaps this is a stupid question:
Whenever I connect to my Linux Workstation over DECnet
(set host), and redirected some X11 programs onto the
VMS screen, I can't open any additional DECterms.
They all fail with:
%SYSTEM-F-EXBUFOBJLM, exceeded systemwide buffer object page limit
(MAXBOBMEM)

Logging off and on again doesent help, logon over the network (DECnet)
still works. The only way I found to fix it was to reboot...

It's a AlphaStation 250 4/266 96MB RAM running OpenVMS 7.2,
TCPIP V5.0-9, DWMOTIF V1.2-5 and DECNET_OSI V7.2 .

Thanks for any help.

Regards,
Roland

2. Debouncing

3. SYSTEM-F-EXBUFOBJLM

4. commun dialog

5. Help! Ping o' Death consequences!

6. Sell Your 3D Models on the Internet; Beta Testers Wanted for Cybazaar(TM)

7. A consequence of open a file and don't write to it...

8. Surplus Tech : SRAM HP95 compatible?

9. %SYSTEM-F-EXBUFOBJLM explanation anyone?

10. Q: What is the consequence of moving the SYSTEM login directory?

11. Raise CPUMAXIMUM (CPU time limit) for a running job

12. Installing DCE raises multithread caution

13. What is a 'code tree' in relation to MAXBOBMEM?