On Fri, May 12, 2000 at 12:40:28AM -0600, Neil Schemenauer wrote:
> On Thu, May 11, 2000 at 10:54:37PM -0700, John White wrote:
> > If you're looking for queue speed, you want RAID 1+0 with a
> > NVRAM cache to accellerate the small block writes.
>
> zeroseek would be even cooler.
Don't use zer
On Thu, May 11, 2000 at 10:54:37PM -0700, John White wrote:
> If you're looking for queue speed, you want RAID 1+0 with a
> NVRAM cache to accellerate the small block writes.
zeroseek would be even cooler.
Neil
--
There are two rules for success in life:
Rule 1: Don't tell people everythi
On Thu, May 11, 2000 at 09:01:27AM -0400, Steve Craft wrote:
> To throw my $.02 at this issue, if this is looking like a "low level" speed
> issue, why not tinker with the hardware? Taking the two disks that hold
> /var and putting them on a RAID0 set should give you a serious speed boost
> witho
To throw my $.02 at this issue, if this is looking like a "low level" speed
issue, why not tinker with the hardware? Taking the two disks that hold
/var and putting them on a RAID0 set should give you a serious speed boost
without touching your (otherwise working) qmail config.
-Original
At 02:40 AM 5/10/2000, Neil Schemenauer wrote:
>You should find the bottleneck before you jump to any
>conclusions. What version of the Linux kernel are you using?
2.2.12 compiled with higher process limit (4090), higher file and inode
limits (16000/48000), smp support, and drivers for SCSI and
On Wed, May 10, 2000 at 10:09:09AM -0700, [EMAIL PROTECTED] wrote:
Boy a few early morning typos here. Some corrections:
> While it's hard to tell without looking, by guess is that your inbound
> submission rate is killing the spindle that your disk lives on.
That would be "that your queue live
On Wed, May 10, 2000 at 01:30:53AM -0700, Flemming Funch wrote:
> At 09:39 AM 5/9/2000, Matthew B. Henniges wrote:
> >On a dual celeron 466 with 512Mb ram. and 3 10k scsi drives (one for
> >/var/qmail/queue, one for /var/log, one for /usr/home)
> >concurrency remote at 500
> >concurrency local at
Are you using syslogd ?
RDA.-
-Original Message-
From: Flemming Funch <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED] <[EMAIL PROTECTED]>
Date: Wednesday, May 10, 2000 5:28 AM
Subject: RE: QMail Performance Question & Miscellaneous Issues
>At 09:39 AM 5/9/2000, Matthe
On Wed, May 10, 2000 at 01:30:53AM -0700, Flemming Funch wrote:
> So .. eh... would it likely be my disk I/O that slows it down
> (how do I test that?), or should I be switching to FreeBSD, or
> am I doing something stupid?
You should find the bottleneck before you jump to any
conclusions. What
At 09:39 AM 5/9/2000, Matthew B. Henniges wrote:
>On a dual celeron 466 with 512Mb ram. and 3 10k scsi drives (one for
>/var/qmail/queue, one for /var/log, one for /usr/home)
>concurrency remote at 500
>concurrency local at 50
>FreeBSD 3.4-S
>localhost dnscache
>
>It will push 12 Million on a good
>I have a question about qmail regarding its mail handling capacity.
>How many remote emails can qmail send simulataneously, assuming it is run
>on a Dual-CPU PIII 500Mhz with 512Mb RAM and a SCSI hard disk? The internet
>bandwidth is 10 Mbps.
On a dual celeron 466 with 512Mb ram. and 3 10k
"Bryan White" <[EMAIL PROTECTED]> wrote:
>Do you have any feel for how to evaluate what is an optimum number of
>remotes?
Measure the delivery rate at various settings of concurrencyremote.
Choose the setting that yields the highest delivery rate.
>At 400 remotes I still have 80% CPU idle time.
On Mon, May 08, 2000 at 10:56:43AM -0400, Bryan White wrote:
> >It's not even that hard, that was the first time I had ever fiddled
> with
> > the Kernel source. We went to 4096, which should allow for quite a few
> > qmail-remotes. : )
>
> Do you have any feel for how to evaluate what is an
> The documentation of RedHat.com is technically accurate, just not
> complete. There are two limits. One is the total number of
> files handles for all processes. This is adjustable through
> /proc/sys/fs/file-max. The other limit is the number of file
> handles opened by a single process. T
>It's not even that hard, that was the first time I had ever fiddled
with
> the Kernel source. We went to 4096, which should allow for quite a few
> qmail-remotes. : )
Do you have any feel for how to evaluate what is an optimum number of
remotes? At 400 remotes I still have 80% CPU idle tim
On Sun, May 07, 2000 at 01:17:13PM -0600, Steve Wolfe wrote:
> Despite the docs at RedHat.com, saying how easy it is to
> increase the file-handle limit on the new kernels, I found that
> it simply didn't work. Editing the source and recompiling the
> kernel (as you had to in older kernels) did th
> Another allows increasing the maximum number of
> concurrent remotes beyond 250. The patch allows up to 500 but that limit
> seems to be linux related.
I would imagine that to be because Linux by default only allows 1024 file
handles to be open at once. If each of the qmail-remotes has a m
From: "Steve Wolfe" <[EMAIL PROTECTED]>
Date: Sat, 6 May 2000 21:22:30 -0600
. . .
> Another question is about the Mail header. What is the header that I
should
> add into a generated email so that undelivered/bounced emails go to this
> specific email address instead? For ex
On Sun, May 07, 2000 at 08:41:11AM -0400, Bryan White wrote:
[snip]
>
> I have played with removing flush statements from qmail-queue.c. This
> dramatically increases the rate at which qmail-inject puts stuff into the
> queue. This led to very large queues (my sending process backs off when the
> I have a question about qmail regarding its mail handling capacity.
> How many remote emails can qmail send simulataneously, assuming it is run
> on a Dual-CPU PIII 500Mhz with 512Mb RAM and a SCSI hard disk? The
internet
> bandwidth is 10 Mbps.
>
> If I run 2 parallel processes that sends o
> I have a question about qmail regarding its mail handling capacity.
> How many remote emails can qmail send simulataneously, assuming it is run
> on a Dual-CPU PIII 500Mhz with 512Mb RAM and a SCSI hard disk? The
internet
> bandwidth is 10 Mbps.
A lot. : )
There is a hard-coded limit t
21 matches
Mail list logo
