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

Conference clt::cms

Title:	DEC Code Management System
Notice:	Current version: V3.8-2 (see Note 3.2)
Moderator:	EDSDS6::TOWNSEND

Created:	Mon Feb 03 1986
Last Modified:	Thu Jun 05 1997
Last Successful Update:	Fri Jun 06 1997
Number of topics:	2491
Total number of notes:	9373

2484.0. "DElete performance, group/class on Alpha??" by KERNEL::PULLEY (Come! while living waters flow) Wed Apr 30 1997 14:02

    Hi,
    
    I've a customer who's moved from using CMS on VAX 3100/90, to an Alpha
    2100.
    They copied the library over, which has a .cms file of about 30000
    blocks, and a .his file about 100000 blocks.
    They noticed it took hours to delete, they can't remember if it was a
    class or a group.
    (I get the impression they've done this sort of thing before on the VAX
    and it didn't take that long).
    
    The porcess doing the delete, was for a lot of the time in PFW (page
    fault wait).
    Their swdef=6000, wsextent=64000.
    The wsmax=393216 pagelets.
    They seen this behaviour a couple of times now.
    
    Is this just badly set VMS parameters?
    If so any comments as to how to check them out?
    
    Thanks,
    Steve.

T.R	Title	User	Personal Name	Date	Lines
2484.1	Quick question...	EDSDS6::TOWNSEND	Paul - DECset Engineering	`Wed Apr 30 1997 19:03`	5
	Hi Steve, What version of CMS are they using? -Paul
2484.2		KERNEL::PULLEY	Come! while living waters flow	`Thu May 01 1997 07:37`	4
	It's v3.8-2, and the VMS is v6.2. Steve.
2484.3	PFW: Pagefault Wait	XDELTA::HOFFMAN	Steve, OpenVMS Engineering	`Thu May 01 1997 10:03`	28
	A process in PFW (pagefault wait) state would tend to point to an insufficient process working set configuration, or to insufficient system physical memory, or to some, uh, weird setting in the system memory management parameters. Poor application locality of reference can tend to require larger working sets. SHOW WORK will show the working set limits, but you will want to examine the sizes OpenVMS is using -- SHOW SYSTEM will display the working set in use, and SHOW MEMORY can be used to examine the available physical memory. I'd start by looking at the process working set sizes in the UAF, and the settings in the SYSGEN PQL* parameters. I'd also start looking at the size of the directories associated with this CMS library -- there is a "knee" in performance when a directory reaches 128 blocks. Cleaning out any weirdness in MODPARAMS.DAT, and running several passes of AUTOGEN with FEEDBACK, might also prove useful here. When the problem occurs, one can also use monitoring tools -- such as SHOW PROCESS, SHOW SYSTEM, SDA, SHOW MEMORY, and MONITOR -- to monitor the process and system activity.