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

Conference azur::mcc

Title:DECmcc user notes file. Does not replace IPMT.
Notice:Use IPMT for problems. Newsletter location in note 6187
Moderator:TAEC::BEROUD
Created:Mon Aug 21 1989
Last Modified:Wed Jun 04 1997
Last Successful Update:Fri Jun 06 1997
Number of topics:6497
Total number of notes:27359

806.0. "Long time to ebuild parse talbes?" by SUBWAY::JENG () Mon Mar 18 1991 09:43

    Hi,
    	
       I have DECmcc BMS V1.1 and TCP/IP AM installed in a VAXstation 3100.
    I am following the TCP/IP AM installation procedure to rebuild the
    parse tables.  
    
       However, the parse tables that have been rebuilt for 46 hours are still
    updating.  Does it usally take that long time?  The screen shows the
    following messages:
    
    $ MANAGE/TOOLKIT/PARSE_TABLE
    DECmcc Parse Table Builder
    Component Version: V1.1.0
    
    	Parse Table filename:		MCC_PTB_PARSER.BPT
    	Command Log Data filename:	MCC_PTB_PARSER.DAT
    Processing entity 1
    Processing entity 1 1
    Processing entity 1 1 0
    .
    .
    .
    Processing entity 12 3
    .
    .
    .
    
    		Thanks
    		/Eng 
T.RTitleUserPersonal
Name
DateLines
806.146 hours is a very long timeTOOK::DITMARSPeteMon Mar 18 1991 10:0711
PTB most definitely does not usually take that long.

Is there a lot of other activity on the system?

Could you do a show proc/all on the process that is running PTB?

Is PTB making progress, i.e. do you occasionally get new "Processing entity"
messages and the entity numbers seem to be increasing?

Are your dictionary/target parse table files being accessed locally, or via
the network?
806.2Is it pagefaulting like mad ?WIKKIT::WARWICKTrevor WarwickMon Mar 18 1991 12:429
    
    I recently saw a PTB get almost completely stuck. It was on a
    memory-tight timesharing system, and it ended up doing 10,000
    pagefaults per second continually for about 6 hours. In this time, it
    processed about 2 entities.
    
    I eventually had to restart it with some more WSQUOTA.
    
    Trevor
806.3WSQUOTA is too low?SUBWAY::JENGMon Mar 18 1991 15:3413
    	The PTB rebuild process is finally done with a successful message
    (48 hours total).  The TCP/IP AM installation IVP is also successful.  
    
    	This is a 8M VAXstation 3100.  The pagefaults value was over 25 
    millions, and the CPU time was 4:35:16.  During PTB rebuild process, 
    the only background activity was the clock.  Besides, the parse 
    tables are located locally.  I think Trevor makes the point, the
    WSQUOTA was too small (4000 blocks).
    
    	Could someone tell me how long does it take him/her to rebuild the
    parse tables?
    
    /Eng     
806.44 hours on my systemHAWK2::GOLDMANAmy Goldman, DTN 226-5115Tue Mar 19 1991 09:195
        On my 16MB VAXstation 3100, the longest it took was around 4
        hours, and that was with other processes going on.  WSquo for
        the account I installed from is only at 2048.
        
        amy
806.5definitely sounds like memory TOOK::CALLANDERTue Mar 19 1991 16:3914
I run a regular VAXstation/GPX with a full complement of memory, and using
the minimum required quotas I run in about 2 and 1/4 hours if nothing much
else is running; if nothing is running I have been known to run in about
2 hours even. The longest run I have had was about 5 hours and I had my
system pretty well loaded down.



Usually when PTB runs for more than a few hours you are having memory
problems; it is easier to stop and restart it then to let it finish.
I have seen it take over 24 clock hours to complete when there was not
enough memory to do it all; I have also seen if fail on the write to disk
because there wasn't enough memory for the last allocation.