Re: Why does MAIL DIR go slow during mail receive?
From: Mike Naime (mnaime_at_kc.rr.com)
Date: 09/12/03
- Next message: Jeff Morgan: "Re: Image tools for VMS - follow up - image file formats"
- Previous message: Mike Naime: "Re: Anyone else having problems with VMS and HSG80-based arrays?"
- In reply to: Lawrence Bleau: "Why does MAIL DIR go slow during mail receive?"
- Next in thread: Carl Perkins: "Re: Why does MAIL DIR go slow during mail receive?"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Date: Fri, 12 Sep 2003 02:49:20 GMT
You did not give anymore information on the Alphaserver config, or the
storage setup.
Do you have more than one storage disk?
Are your mail files all on one disk?
I believe that the inbound mail message has a higher priority over any other
MAIL activity since the system cannot tell exactly how many people this mail
file may need to be distributed to. Therefore, it is freezing all other
activity until it processes the inbound mail message.
Lawrence Bleau <bleau@umtof.umd.edu> wrote in message
news:bjqn2h$f68$1@grapevine.wam.umd.edu...
> I have a question about an observed slowness in VMS MAIL. I think I know
> why, but want confirmation of my theory, or how to investigate it further,
> as well as suggestions for a fix. First, my configuration: I'm running
> OpenVMS AXP V7.1-2, TCPIP V5.1 ECO 4 on my Alpha workstation.
>
> Observation: Once in a while, a user who is in MAIL does a DIR (within
> MAIL) or similar operation and his terminal session gets held for quite a
> while, nearly a minute, before MAIL responds. Ordinarily MAIL responds
> immediately (within a second or two) to such a command.
>
> During this period he can log onto another terminal session and do a DCL
> DIR and other commands; they all respond immediately, so this isn't a
> general system slowdown because of a user running a high priority job.
> Besides, we don't have any such users :-)
>
> This problem doesn't occur for each mail message, and is observed
> infrequently, but enough to bother us.
>
> By noting the time carefully and checking the accounting file, I've
noticed
> that an email message came in at that approximate time. I checked the
> TCPIP$SMTP_RECV_RUN.LOG files, and there's one that corresponds to that
> time. The incoming email message was not destined for this user, however,
> but some other user. Still, it might be related, and here's how.
>
> I checked this other user's mail file and noticed a message in the NEWMAIL
> folder that corresponds to the time of the freeze. A DIR/FULL showed me
it
> had 45 records and was stored in an external file. This user's MAIL.DIR
> file size is about 1800 blocks.
>
> Fact: For "large" mail messages, VMS MAIL stores the message in an
external
> file and stores a pointer to that file. Also, when creating a file in a
> directory that has many files, sometimes VMS needs to reshuffle the
entries
> in the .DIR file.
>
> Theory: We often get a large message, which is stored externally. Once in
> a while there is not enough room for a new entry in the .DIR file, so VMS
> has to reorganize the .DIR file's contents, moving them up a block. The
> name of the external .MAI file is almost random, so there's no telling if
> it would be inserted near the start or end of the .DIR file. Thus, it is
> fairly random how much time the system needs to do the file enter
> operation. Finally, and here's the long shot, VMS reshuffling the
MAIL.DIR
> of any user can cause a freeze or slowdown of MAIL operations by any user
> on that system.
>
> This theory would explain the intermittent nature of the problem, the
> randomness of the time interval for which MAIL is frozen, and why only
MAIL
> is affected while the rest of the system is usable.
>
> What the theory does not explain is why users other than the user who is
> receiving the message and whose MAIL.DIR file is being reshuffled should
be
> affected.
>
> As a test, I tried copying individual small files into a user's mail
> directory while a different user sat in MAIL doing the DIR command. For
> the first 6 files things proceeded normally, with each COPY operation
> taking about 1 sec. The 7th COPY operation it took well over a minute,
and
> the other user's MAIL DIR command took a similar period. During this time
> there was a high i/o rate on the user disk. Just as the COPY operation
> was about to complete the other user's DIR operation started.
>
> So, does it sound that the theory is correct? If it is, what is the
> missing part: why does it affect other users? Is there some lock MAIL
> takes out? Or is this just a cpu or i/o intensive operation that causes
> the other user to be scheduled much later? (that's stretching it, imho)
>
> And,is there a way to fix this problem?
>
> I know of one way: force each user to segment his mail file into many
> different mail files, each in a separate directory, thus reducing the size
> of each .DIR file. This is unlikely to happen, since it requires a change
> in users' behavior, and not a simple one at that.
>
> Is there another way to fix this problem, or reduce its impact? Thanks.
Get a bigger box! :-)
Or faster storage.
>
> Lawrence Bleau
> University of Maryland
> Physics Dept., Space Physics Group
> 301-405-6223
> bleau@umtof.umd.edu
- Next message: Jeff Morgan: "Re: Image tools for VMS - follow up - image file formats"
- Previous message: Mike Naime: "Re: Anyone else having problems with VMS and HSG80-based arrays?"
- In reply to: Lawrence Bleau: "Why does MAIL DIR go slow during mail receive?"
- Next in thread: Carl Perkins: "Re: Why does MAIL DIR go slow during mail receive?"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Relevant Pages
|
