Newsgroups: vmsnet.mail.pmdf
Subject: RE: Open file quota problem
From: "Ned Freed, Postmaster" <ned@hmcvax.claremont.edu>
Date: Wed, 8 Apr 1992 00:45 PST
Organization: The Internet
Resent-From: epmdf@YMIR.CLAREMONT.EDU
Resent-Date: Wed, 8 Apr 1992 00:46 PST
Errors-To: epmdf@YMIR.CLAREMONT.EDU
Resent-Message-Id: <01GIL3JNMRSW8WWSEY@YMIR.CLAREMONT.EDU>
X-Vms-To: IN%"GHC@NIHKLMB.BITNET"
X-Vms-Cc: ipmdf

> I have just been informed about a problem relating to the open file
> quota which has been occuring recently on this machine.  A user was
> doing a repl/edit/extr on a 100 line mail message and tried to spawn
> out of the editor (TPU) to go into mail a second time in order to
> examine a second message.  He was unable to select a folder or do
> anything useful in mail, getting an acp quota error which appears to
> be related to the fact that he was left with a quota of only 5.  We
> start with 20 and by the time mail is up and going, replying to an
> internet message, we are usually left with 5 to 7 as a file limit.

MAIL does use a lot of shareable images. The internal design of the utility
makes this more or less impossible to avoid. The good news is that I/O to
these files is quite efficient.

> I checked the open files (show dev/fi) on the drives most likely to
> be involved and the quota reported is pretty close to what I would
> calculate from the investigation.  Some 3 to 5 files relate to
> shareable images which pmdf is pulling in, some are data files and I
> can accept that.

This sounds about right. The number is going to increase by 1 or 2 in PMDF
V4.1; we now have another (!) shareable image loaded with character set
conversion data.

> The question is what do others find as an
> acceptable limit on the open files.  As a temporary measure I have
> raised the limit to 30, but I am only shooting in the dark.  BTW -
> we are using a subprocess quota of 2, pmdf 4.0 and vms 5.3-1.
 
There's no penalty associated with bumping FILLM; as far as I know there's
nothing that's actually allocated until the files are actually used. But
the system parameter CHANNELCNT is also a limit on the number of files
(channels) that can be open at once. There is some (small) usage of memory
associated with this. I believe it is all in process P1 space and it is
not a big concern. But CHANNELCNT should be at least as big as your largest
realistic FILLM and probably a bit bigger (maybe +10 or so) than that. Every
file takes a channel but not every channel takes a file.

Another process parameter that enters into this is ENQLM. Opening files means
taking out one or more locks most of the time. Yes, there are cases where 
opening files does not require taking out a file lock, but there are other
cases where opening a file takes out more than one lock. As a result I would
recommend an ENQLM value that's roughly the same or higher than the FILLM
value you pick. Again, there are no resources associated with a large ENQLM;
the resources are only used when you actually lock something.

Another fact that deserves consideration is the sharing of FILLM that
occurs with subprocesses. It is a good thing that both FILLM and ENQLM are
pooled quotas -- your subprocesses share the quota with the main process.
This means that you simply have to consider the combined use of these things.
Other quotas are not so friendly -- I/O quotas are split between a main
process and subprocess and as such can be a real problem to set correctly.

Finally, let's consider some actual values. A FILLM of 20 is much too low.
45 is about the absolute lowest I would consider, and if you even think about
running any sort of database software or DECWindows applications I would
recommend a value of at least 90. We routinely set up accounts with a
default FILLM of 100, ENQLM of 100, and CHANNELCNT of 400. Even with these
values we occasionally find some user that needs to have a larger quota.

					Ned