[Search for users] [Overall Top Noters] [List of all Conferences] [Download this site]

Conference iosg::all-in-1_v30

Title:*OLD* ALL-IN-1 (tm) Support Conference
Notice:Closed - See Note 4331.l to move to IOSG::ALL-IN-1
Moderator:IOSG::PYE
Created:Thu Jan 30 1992
Last Modified:Tue Jan 23 1996
Last Successful Update:Fri Jun 06 1997
Number of topics:4343
Total number of notes:18308

1585.0. "%OAFC-E-INTERR (Insufficient memory)" by DV780::BAILEYR (OICU812!) Thu Oct 08 1992 23:17

ALL-IN-1 v3.0
VMS v5.4-3
Approx. 4000 subscribers

In attempting to seed the File Cabinet manually (extracting the 
relevant commands in A1$POSTINSTALL.COM), I'm encountering the 
following error msgs after approx. 2 1/2 hours:
.
.
>DO oalib:oafc$part_seed

(several of these:)
>OAFC Error Report : %OAFC-E-INTERR, Internal error in File Cabinet Server
>        Insufficient memory
>OAFC Error Report : %OAFC-E-INTERR, Internal error in File Cabinet Server
>        Insufficient memory
>%OA-F-VMGETFATAL, LIB$GET_VM failure, 280 bytes at 00000000 - IN OADSA IN ROUTIN
>E OA$DSA_COPY_PROTOTYPE
>
>$

I'm using the ALL-IN-1 manager's account for this and from another 
terminal, did a show proc/acc/id=xxx:

>Accounting information:
> Buffered I/O count:     72734  Peak working set size:       4096
> Direct I/O count:       21957  Peak virtual size:         116964
> Page faults:           199363  Mounted volumes:                0
> Images activated:           9
> Elapsed CPU time:          0 01:11:49.13
> Connect time:              0 02:52:19.47

This is what the UAF entry looks like for the manager's acct:
.
.
>Expiration:            (none)    Pwdminimum: 15   Login Fails:     0
>Pwdlifetime:       9999 00:00    Pwdchange:  24-AUG-1992 10:30
>Last Login:  8-OCT-1992 09:17 (interactive), 19-SEP-1992 08:50 (non-interactive)
>Maxjobs:         0  Fillm:       100  Bytlm:        36000
>Maxacctjobs:     0  Shrfillm:      0  Pbytlm:           0
>Maxdetach:       0  BIOlm:        50  JTquota:      15000
>Prclm:          10  DIOlm:        50  WSdef:          512
>Prio:            4  ASTlm:       100  WSquo:         2048
>Queprio:         0  TQElm:        50  WSextent:      4096
>CPU:        (none)  Enqlm:       350  Pgflquo:     100000
>Authorized Privileges:
>  CMKRNL SYSNAM GRPNAM DETACH PRMMBX TMPMBX WORLD OPER EXQUOTA
>  NETMBX VOLPRO PHY_IO PRMGBL SYSGBL SYSPRV SYSLCK READALL
>Default Privileges:
>  CMKRNL SYSNAM GRPNAM DETACH PRMMBX TMPMBX WORLD OPER EXQUOTA
>  NETMBX VOLPRO PHY_IO PRMGBL SYSGBL SYSPRV SYSLCK READALL

I think we have our VIRTUALPAGECNT high enough:

>SYSGEN>  SHOW VIRT
>Parameter Name            Current    Default     Min.     Max.     Unit  Dynamic
>--------------            -------    -------    -------  -------   ----  -------
>VIRTUALPAGECNT             204800       9216       512   1000000 Pages

I verified all of the SYSGEN parameters and process quotas, as specified in
the Installation Guide and the Pre-Installation check completed with no errors.

Is there any way to "checkpoint" my progress, so I won't have to start
completely over every time?

Any other places I can look?

Thnks
Randy
T.RTitleUserPersonal
Name
DateLines
1585.2Raise PGFLQUOAIMTEC::VOLLER_IGordon (T) Gopher for PresidentFri Oct 09 1992 02:0014
    Randy,
    
    	The ALLIN1 MANAGER's account is running out of VM.
    	
    	The reason for this is PGFLQUO (100,000 - from UAF) being
    	exceeded as the amount of VM in use is 116,964 (Peak virtual size -
        from Accounting information.
    
    	Solution = raise ALLIN1's PGFLQUO (try 200,000 - maximum allowed
        due to VIRTUALPAGECNT value)
    
    Cheers,
    Iain.
    
1585.3WSEXTIOSG::TALLETTGimmee an Alpha colour notebook...Fri Oct 09 1992 11:1016
    
    	...and for performance improvements, I think I'd raise
    	the manager's WSEXTENT as the FCS is banging up on the
    	4096 working set limit and page faulting (admittedly
    	probably only soft faults).
    
    	Not that I would even hint at the suggestion of a bug, but
    	you might want to watch the FCS's Virtual pages from time
    	to time for a memory leak, as 100,000 sounds a bit excessive,
    	ours only uses 20K pages.
    
    	How long had this FCS been running? Were there a lot of active
    	users at the time?
    
    Regards,
    Paul
1585.4Still upgrading - no user load yetDV780::BAILEYROICU812!Fri Oct 09 1992 18:5323
    Iain/Paul,
    
    >How long had this FCS been running? Were there a lot of active
    >users at the time?
    
    We're still in the process of ugrading from 2.4.  We had profile
    problems which caused the A1$POSTINSTALL grief, so we're
    performing each step manually now.  The only user logged in was
    the manager and a system-type who was just monitoring the manager
    process.  The FCS was up for approx. 24 hours prior to the
    DO OAFC$PART_SEED attempt and again - no activity.
                                                                       
    I bumped up the PGFLQUOTA to 200k and increased the WSEXTENT to
    7680 and will advise the results.  The system in question is an
    8250 with 20mb of memory and is being used as a test system to
    allow us to upgrade and migrate any 2.4 customizations off-line.
    
    STARS mentioned *************************** related to memory
    problems.  Could this be related to our problem?
     
    Tnks again!
    Randy
    

1585.6IOSG::PYEGraham - ALL-IN-1 Sorcerer's ApprenticeFri Oct 09 1992 20:4111
    I've hacked the previous note, because it mentioned a possible patch
    which is not committed, or available and we prefer not to discuss
    futures in this notesfile.
    
    I've not heard of a problem that would explain the effect you're
    seeing, and considering how lightly your system is loaded, it seems to
    be taking a damm long time to do the seeding!
    
    Perhaps Paul's right and you've discovered a new memory leak???
    
    Graham
1585.7Raising WSEXT helped!DV780::BAILEYROICU812!Fri Oct 09 1992 22:4523
Looks like raising WSEXTENT certainly helped!  After I raised it
to 7680 and started the OAFC$PART_SEED script again, I watched it
from another process and "Peak ws size" was right around 4310 for
over an hour and "Page faults" were down around 5500 or so. 
Sometime during approx. the last 30 minutes the peak ws hit 7680
and the number of pg faults reached 29750 or so, but still
allowed the script to complete. 

 Buffered I/O count:     88868  Peak working set size:       7680
 Direct I/O count:       24904  Peak virtual size:          41196
 Page faults:            30507  Mounted volumes:                0
 Images activated:           7
 Elapsed CPU time:          0 01:16:08.50
 Connect time:              0 03:33:47.13

>I've hacked the previous note, because it mentioned a possible patch
>which is not committed, or available and we prefer not to discuss
>futures in this notesfile.

Oooppps!  Just trying to keep Graham on his toes ;)   My apologies...

Thanks again for the aid!
Randy 
1585.8Doesn't look like a leak anymoreIOSG::TALLETTGimmee an Alpha colour notebook...Mon Oct 12 1992 11:2410
    
    	I take back my suspicion of a memory leak. It sounded as if the
    	FCS had been running for a long time and then keeled over, but
    	if you're still doing the upgrade, then the FCS hasn't had much
    	to do at all - it is much more likely to be system setup problems.
    
    	Okay JD, I'm ready for the punishment....
    
    Regards,
    Paul