From: terry@spcvxa.spc.edu (Terry Kennedy, Operations Mgr)
Newsgroups: vmsnet.mail.pmdf
Subject: RE: REPOST (for lack of any answer) performance problem with local
Date: 6 Oct 92 01:28:35 GMT
Organization: St. Peter's College, US
Return-Path: <epmdf@YMIR.CLAREMONT.EDU>
Resent-Date: 05 Oct 1992 21:28:35 -0400 (EDT)
Resent-From: epmdf@YMIR.CLAREMONT.EDU
CC: IPMDF@YMIR.CLAREMONT.EDU
Errors-To: epmdf@YMIR.CLAREMONT.EDU
Resent-Message-ID: <01GPLLDCNIBM8WWHO6@YMIR.CLAREMONT.EDU>
X-Vms-To: IN%"tkslen@ubvmsb.cc.buffalo.edu"
X-Vms-Cc: IPMDF@YMIR.CLAREMONT.EDU,TERRY
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
Content-Transfer-Encoding: 7BIT

tkslen@ubvmsb.cc.buffalo.edu (Lenny Miceli) writes:

[Likewise, first time I've seen this one as well]

>   This has helped the problem of files being left in the local
>   queue that should have been delivered.  That is, these files had no reason
>   not to be delivered when they were originally placed in the queue.  All
>   I would do is run @[EXE]MASTER L by hand and everything would
>   get delivered.  But, this problem still exists in a much smaller extent.
>   And, it seems when post.com runs it doesn't submit a job for bit_gateway
>   even though there are mail messages in the bit_gateway directory.  So I run
>   @[EXE]MASTER BIT_GATEWAY by hand and everything gets delivered.

  I've had a few problems with the BIT_GATEWAY channel as well - files will
sit in there across several runs of the PMDF Delivery job. In most of those
cases, simply running PMDF_ROOT:[EXE]SYNCH_CACHE will get the file moving
along. I had one the other day which was impervious to this, though. Even
invoking MASTER or releasing the delivery job didn't help.

  I also rebuild the queue file nightly and sync it every two hours.

  I enabled MASTER_DEBUG and SLAVE_DEBUG on both the bit_gateway and l chan-
nels and didn't get any debugging output.

  However, the file was processed the next time the bouncer job ran. Very
odd. This was with 4.1-6. I'm waiting for 4.1-13 and if I see it again after
I install -13, I'll pursue it further.

> 5) I now have the l channel using a batch queue on the fastest cluster machine
>   (a 6520).  I did this because the local queue would grow very large, that
>   is, 300-500 mail messages.  And local mail delivery would take approx.
>   2-3 hours.  But now this is not working anymore.  The semester has gotten
>   into full swing and today my local queue grew to 1000-1400 mail messages.
>   Keep in mind that the 6520 is not cpu starved.  When I watch the batch
>   job try to deliver the mail it get's the cpu when it needs it and it does
>   alot of I/O.  In the past, when the queue got a little big I would set
>   the job limit to 2 or 3.  But, that does not seem to help anymore.

  The periodic jobs will attempt to process all of those files. You need to
find out why they aren't being delivered in the first place. Around here,
that's usually because someone is over disk quota (we use holdexquota). This
means that the periodic job will retry all of these messages, and VMS MAIL
is a bit slow.

  Note that you can set channel options to only process new messages or to
process all messages - some tuning here may help.

  By the way, for other channels (like TCP/IP channels) you can have a fast
CPU and lots of spare cycles and still crawl. Normally TCP/IP will either
give you a connection failed error or connect. However, some systems are be-
hind routers/gateways that don't return failure indication, so PMDF will
keep trying for the timeout interval. Shortening the timeout won't help, as
that will cause messages which would otherwise go through to fail due to a
timeout during transmission.

	Terry Kennedy		Operations Manager, Academic Computing
	terry@spcvxa.bitnet	St. Peter's College, Jersey City, NJ USA
	terry@spcvxa.spc.edu	+1 201 915 9381