Conference vaxaxp::vmsnotes

    A directory file that exceeds 128 blocks exceeds the directory cache
    size, and one sees the result of this in the decreased performance.

    That OpenVMS is a multi-tasking operating system is not relevent.

    Check with the TeamLinks engineers, and determine what suggestions
    they might have for reducing the size of the directories.

    or to put it another way, when you exceed the cache you start to do
    I/O.  I/O is expensive.  A lot of the things users do requires I/O.  If
    the users which have exceeded the 127 block directory size that causes
    it to fall out of the cache, then those users are using I/O that could
    have better gone to service other user requests.
    
    This is the other side of multi-tasking.
    
    					Bob Harris

    
    so if the [vms$common]SYSLIB directory on my VMS V5.5-2 cluster (4 nodes)
    has  an allocated size of 128 blocks (94 used) I should look at the methods
    to decrease its allocated size?
    

:    so if the [vms$common]SYSLIB directory on my VMS V5.5-2 cluster (4 nodes)
:    has  an allocated size of 128 blocks (94 used) I should look at the methods
:    to decrease its allocated size?

    Correct -- it doesn't matter what is stored in the directory file,
    or what creates it or manages it.  The directory caching performance
    degrades at 128+ blocks.

    I will assume you have cleaned up the obvious dreck.  Alsoc consider
    moving to DEC C from VAX C, as this is one way to clean up a large
    number of files usually found in SYS$COMMON:[SYSLIB].  And you will
    want to look at what other files are in that directory...)

:has an allocated size of 128 blocks (94 used) I should look at the
:methods
:    to decrease its allocated size?

The directory caching scheme is based on the EOF (94 in this case)
and not this full size of the directory (128).

You may be able to help your performance by using the DFU utility
(NOTED::HACKERS) to compress the entires in the directory.

    1) If you aren't doing a "wildcard" lookup, but opening a file that
    you already know the name of, the size of the .DIR file isn't a
    particular problem.
    
    2) The 128 block limit is an RMS cache.  Beyond 128 blocks
    RMS just turns around and calls the XQP.  Depending on other caches 
    in various pieces of code, that may or may not generate real, actual, 
    honest disk I/O.
    
    				-John

    About compressing the directories after entries below have been
    reduced:
    
    What are my options?
    	RENAME the directory, create a new directory and copy all the
        entries back in?
    	Use the DFU utility?
    	Any others?
    
    Thanks!
    	

.3>:    so if the [vms$common]SYSLIB directory on my VMS V5.5-2 cluster (4 nodes)
.3>:    has  an allocated size of 128 blocks (94 used) I should look at the methods
.3>:    to decrease its allocated size?
.4>
.4>    Correct -- it doesn't matter what is stored in the directory file,
    
    I beg to differ. I'd like to think SYSLIB is rarely approached with
    wildcard. I can not imagine you'd be able to measure a performance
    difference between EOF at 128 blocks or 126 block SYSLIB directory 
    for normal usage.
    
    I suspect that cleaning (deleting old crud) is and compressing that 
    directory will be help as much (as little ?!) in both cases.
    
>    	RENAME the directory, create a new directory and copy all the
>        entries back in?    	Use the DFU utility?    	Any others?
    
    Yes. Of course you'd never copy the files, just the directoryt entries
    using $SET FILE/ENT or $RENAME.
    For SYSLIB and SYSEXE I'd probably bring the fresh directory into the
    searchlist for SYS$LIBRARY and SYS$SYSTEM first such as to have a 
    recovery in the case of catastropich failure while moving stuff.
    
    Searchlists of directories could also solve some directory cache problems.
    
    There is also an old 'assett' tool floating around called COMDIR.
    
    hth,
    	Hein.
    
    
    
    
    
    
    
    
    or what creates it or manages it.  The directory caching performance
    degrades at 128+ blocks.

    I will assume you have cleaned up the obvious dreck.  Alsoc consider
    moving to DEC C from VAX C, as this is one way to clean up a large
    number of files usually found in SYS$COMMON:[SYSLIB].  And you will
    want to look at what other files are in that directory...)

    

    Re. .7 -- $ set file/truncate foo.dir

:.4>    Correct -- it doesn't matter what is stored in the directory file,
:    
:    I beg to differ. I'd like to think SYSLIB is rarely approached with
:    wildcard. 

   Locally, SYS$SHARE: is approached with wildcards fairly regularly.
   And often by users, which makes the slowdown directly visible.
   And given what .0's site is usually up to...

    .0 didn't talk at all about SYS$SHARE/SYS$LIBRARY (that was .3 just
    wondering).  .0 was talking about [.A1MAIL$] directories.
    
    As Hein and I have said, unless you are doing wildcards alot,
    the directory size isn't much of a problem.
    
    What kind of environment produces regular wildcards of SYSLIB?
    I don't care about 1 every 10 minutes for some user just looking
    around in SYS$LIBRARY because they are bored.  The vast majority
    of uses of files in SYSLIB are from image activations which might
    be happening several times a second (more frequently than wildcard
    lookups of SYSLIB I'd claim).  The size of the SYSLIB.DIR file
    shouldn't have much of an affect on the access of files in SYSLIB.
    
    In addition since most of the heavily used files in SYSLIB are already 
    installed open, shared, etc. you've bypassed most of the problem areas 
    anyway...)
    
    However, back to .0s question about [.A1MAIL$] directories.  Do those
    directories get regular wildcard lookups?
    
    				-John

    
    I was just concerned with SYSLIB specifically, at first glance I
    thought it might be more of a problem because of its function but in
    reviewing the comments here about wild card lookups, it looks like we
    are not taking a performance hit simply because of the allocated size
    of the SYSLIB directory. There are no other indications/symptoms of any
    problem and this is a production cluster so I think I'll just clean out
    what I'm sure I can and leave well enough alone.
    
    I do have other directories including A1MAIL$ that are > 128 blocks in
    use so this is all interesting, thanks for the replies so far.
    
    brian

    Re .0
    
    Upgrade from MailWorks as a server to Office Server (previously known
    as ALL-IN-1 :-) ) and then you'll be able to spread all the messages
    over a larger number of directories. Of course you'll lose lots more
    disc blocks in other places.......
    
    Alternatively, get the users to create extra drawers in different
    directories and move some of the messages into them.