[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: Tuning of qmail-send for max performance possible?
I know Charles,
Just trying to drag the discussion back into focus here.
You may be correct about the broken pipe, data moving across a pipe should
be
instantaneous, yet I do see the "size" change when coinciding with
preprocessed mail queued.
FUSER reports that qmail-send has the pipe open, or its marked as such
anyway
ulimit as Henning brought up, reports unlimited.
The pipe permissions and file type are correct with LWQ EXACTLY.
I think I'm missing something here...
Right now 92 messages are in preprocess, and the file size for the trigger
is 92 as well.
Thanks for the effort, to everyone.
Steve Baetz
> -----Original Message-----
> From: Charles Cazabon [mailto:qmail@discworld.dyndns.org]
> Sent: Thursday, November 01, 2001 10:20 AM
> To: qmail@list.cr.yp.to
> Subject: Re: Tuning of qmail-send for max performance possible?
>
>
> Baetz, Steve <Steve.Baetz@us.didata.com> wrote:
> >
> > The choice of OS isn't the issue, it was chosen because its
> what the UNIX
> > group here supports.
>
> That's fine. My note was mostly an aside.
>
> > An ultra 2 with 2 cpus should be sufficient to handle 10k worth of
> > messages a day.
>
> Yes, it will be plenty. It's horrible overkill, in fact -- a
> 486 and a
> single IDE disk could handle it.
>
> > Now something appears to be broken between qmail-queue and
> qmail-send,
> > qmail-queue appears to be piping to the trigger, as noted when I see
> > the size value change in coincidence with the preprocessed messages,
>
> If you mean "size of the trigger", then (as others have noted) your
> trigger is broken. If by size you mean "the numbers output by
> qmail-qstat", that's a horse of another colour.
>
> > In speaking for Solaris, our E10K's and 4500's running
> multiple instances of
> > Oracle with MULTI-gigabyte databases, seems to run just
> fine thank you, with
> > no serious performance issues.
>
> This is turning religious, but I'll say this: Oracle has nothing
> whatsoever in common with qmail. qmail makes extensive use of large
> numbers of small, lightweight processes, fork()ing, network use, and
> large numbers of small files. Oracle does a little networking and
> typically accesses raw disks for storage, and doesn't fork a ton of
> small processes.
>
> No similarity. No comparison is valid.
>
> > So I'm not sure how an OS that is OPTIMIZED for its own hardware can
> > be a problem.
>
> Solaris isn't optimized for anything. Run qmail on Linux, OpenBSD,
> NetBSD, and Solaris on identical Sparc hardware; Solaris will
> lose, and
> badly. Then run qmail on Linux, FreeBSD, OpenBSD, NetBSD, and
> Solaris/x86 on identical PC hardware. Solaris will again lose, and
> badly.
>
> > This isn't a discussion to compare OS's with religious
> proportions. I need
> > help with fixing this issue, or I'm going have to go back
> to sendmail, and
> > time is of the essence.
>
> We're trying to help. People have been telling you the problem is
> likely with your trigger since the first report, but you haven't
> actually showed us the evidence we need to tell you for sure.
> `ls -l /var/qmail/queue/lock/trigger` would tell us.
>
> Charles
> --
> --------------------------------------------------------------
> ---------
> Charles Cazabon
> <qmail@discworld.dyndns.org>
> GPL'ed software available at:
http://www.qcc.sk.ca/~charlesc/software/
-----------------------------------------------------------------------