Errors-to: epmdf@YMIR.BITNET
X-Envelope-to: PMDF-L@IRLEARN.BITNET
X-VMS-To: IN%"info-pmdf@ymir"
MIME-version: 1.0
Content-type: TEXT/PLAIN; CHARSET=US-ASCII
Content-transfer-encoding: 7BIT
Date:         Tue, 6 Oct 92 19:31:10 GMT
From:         "Feet...!? You had FEET?" <ECF_STBO@JHUVMS>
Subject:      RE: REPOST (for lack of any answer) performance problem with
              local channel
Newsgroups: bit.listserv.pmdf-l

  God can I relate! My problems are a little different than yours, the system
here does get CPU starved.... I also have holdquota (or whatever it's called)
on the local channel so there are always fifty or two messages in there. I
don't think I've seen the problem of messages not being delivered in the
immediate delivery job, at least not enough to notice it. It sure sounds like a
major problem. If you can solve it, most of your problem of lag may go away.

  It sounds like you've done most of the important things to speed
things up. I would also recommend installing LIST.EXE /open/head/share because
it gets run most every channel job. This code probably should have been made a
routine called by the channel programs, but perhaps to retain compatibility
with older channels, this wasn't done. Unfortunately, image activations and
file creates/open/closes/read/deletes are a large part of the problem. You said
you are running batch jobs on the fast cpu to do the local channel. If you're
really doing standard batch jobs, I would recommend switching to process
symbiont jobs here too. The batch jobs have to log in, map dcl and run sylogin
and the system account's login.com every job, which is too rich for my blood. I
have some problems with the process symbiont. It sits in a 6000 page working
set for some reason. A couple of times since I've installed 4.1 the queue has
stopped for reasons I can't determine. I find no dump file in sys$system... I
might go back to CTLSMB which is what I used before 4.1, I'll have to
investigate further.

  Since you're not CPU starved, you may want to try to put images on a RAM
disk. There is at least one publicly available one, and DEC has one too. Even
when things are installed shared, open etc... there is some level of page reads
to the disk. SET.exe and some others are the most active files on my system
disk here. I don't know if it is copy on reference page faults or what, but I
think VMS should be able to do better...

  If you use domain.dat (I put everything in pmdf_config_data) it might help
a little to put some global buffers on the file. Another thing I've done to
reduce the incredible amount of I/O is modify the task_server.com procedure.
Out of the box, the thing makes a log file every job! I was getting literally
thousands of log files before a periodic job would come and delete them all
(which is another expensive operation). This type of logging will probably
be supported in the future. Also: I turned off verify. You still can see the
error messages if there are any, and you can always turn it back on if there's
a problem.

  The biggest traffic problem here, and there's no reason to think your
site is any different, is BITNET mailing lists. Make sure your local listserv
is not exploding mail to multiple recipients. It's faster to let PMDF expand
locally than have it deal with all those individual messages. If you can
encourage users to read lists on USENET rather than have mail deleivered to
their account, you can cut down on traffic. All in all, I'd say PMDF 4.1 has
much better worst case (millions of queued files) performance than 4.0. For
regular non worst case it seems maybe a little better, or about the same. I
guess the functionality enhancements balance out the performance improvements.

Tom O'Toole - ecf_stbo@jhuvms.hcf.jhu.edu - JHUVMS system programmer
Homewood Computing Facilities, Johns Hopkins University, Balto. Md. 21218
>Here comes a jet ski.
>weuh weeuhh weeuhh weeuhh WEEUHH WEEUHH WEEUHH WEEUHH weeuhh weeuhh weeuhh weuh
Comments: Gated by NETNEWS@AUVM.AMERICAN.EDU