Matthew Harrell <[EMAIL PROTECTED]> wrote:
>Actually, these two cases are similiar machines but the first has one
>processor and the second two. That's probably the difference you're
>seeing here. They are running the same kernel revision except one is
>compiled for SMP.
That doesn't explain
[EMAIL PROTECTED] wrote:
>On Sun, Sep 05, 1999 at 12:09:14AM -0400, Russell Nelson wrote:
>> Dave Sill writes:
>> > >: The qmail logs show remote concurrency over any given time period.
>> >
>> > Not directly, as far as I can tell. Anyone have a script that'll parse
>> > a log and chart con
[EMAIL PROTECTED] writes:
> On Sun, Sep 05, 1999 at 12:09:14AM -0400, Russell Nelson wrote:
> > No, but you could do it pretty easily with my mrtg scripts and
> > configuration. http://www.crynwr.com/mrtg/ . The two scripts are in
> > qmail-mrtg and qmail-mrtg1 in that directory.
>
> I h
On Sun, Sep 05, 1999 at 12:09:14AM -0400, Russell Nelson wrote:
> Dave Sill writes:
> > >: The qmail logs show remote concurrency over any given time period.
> >
> > Not directly, as far as I can tell. Anyone have a script that'll parse
> > a log and chart concurrency?
>
> No, but you could
Dave Sill writes:
> >: The qmail logs show remote concurrency over any given time period.
>
> Not directly, as far as I can tell. Anyone have a script that'll parse
> a log and chart concurrency?
No, but you could do it pretty easily with my mrtg scripts and
configuration. http://www.crynw
: If these are similar systems doing similar workloads, there's
: something "wrong" with the first system. The difference between the
: vmstat output formats implies that they're running different OS revs,
: which could be enough to explain the variance.
Actually, these two cases are similiar mac
Matthew Harrell <[EMAIL PROTECTED]> wrote:
> procs memoryswapiosystem cpu
> r b w swpd free buff cache si so bi bo in cs us sy id
>10 0 0 1308 3888 5856 54780 0 0 17 150 427 2163 20 76 4
>
> procs memor
Okay, here goes again. One machine does this:
procs memoryswapiosystem cpu
r b w swpd free buff cache si so bi bo in cs us sy id
4 2 1 1308 4660 7108 53960 0 0 17 285 17 9 21 32
10 0 0 1308 4372 7124 53828 0
-BEGIN PGP SIGNED MESSAGE-
On Thu, 2 Sep 1999, Aaron L. Meehan wrote:
> Quoting Matthew Harrell ([EMAIL PROTECTED]):
> > :> procs memoryswapiosystem cpu
> > :> r b w swpd free buff cache si so bi bo in cs us sy id
> > :> 4 2 1 12
:> You're right, now that I look at them they do but I swear they're from different
:> machines.
: Fascinating. I would think the odds certainly are greatly against two
: machines showing the exact same vmstat output after a number of days
: uptime. Though not quite astronomical, I suppose.
Od
Quoting Matthew Harrell ([EMAIL PROTECTED]):
> :> procs memoryswapiosystem cpu
> :> r b w swpd free buff cache si so bi bo in cs us sy id
> :> 4 2 1 1288 21824 9368 124868 0 0 15 22 18 12 8 21 29
> :>
> :>and the other
> :
: If the system in question is a Linux box, a) full memory usage is
: the normal state and b) a small amount of swap usage is normal and not
: neccessarily performance inhibiting.
: As far as a) goes, the system doesn't free up memory unless it is
: out of memory. The idea is, why wa
On Thu, Sep 02, 1999 at 01:20:49PM -0400, Greg Owen wrote:
> I'm not sure why a small amount of swap is always in use but it
> seems to be true, and not a performance inhibitor. Check the amount of swap
> in use at boot time, quiet time, and heavy use time - if they stay the same,
> then it
:> procs memoryswapiosystem cpu
:> r b w swpd free buff cache si so bi bo in cs us sy id
:> 4 2 1 1288 21824 9368 124868 0 0 15 22 18 12 8 21 29
:>
:>and the other
:>
:> procs memoryswapio
es it.
> -Original Message-
> From: James Raftery [mailto:[EMAIL PROTECTED]]
> Sent: Thursday, September 02, 1999 6:32 PM
> To: Qmail List
> Subject: Re: Any ideas?
>
>
> On Thu, Sep 02, 1999 at 01:20:49PM -0400, Greg Owen wrote:
> > in use at boot time, quiet ti
On Thu, Sep 02, 1999 at 01:20:49PM -0400, Greg Owen wrote:
> in use at boot time, quiet time, and heavy use time - if they stay the same,
> then it isn't actually actively swapping.
Absolutely. "the act of swapping" is the problem. Assigned swap space
is fine - in fact it's quite good, as otherw
> You had said that top was showing full memory usage, and your machine
> was swapping a little. If the nameserver is on the same ethernet segment
> you shouldn't see latency problems and the extra memory should
> reduce swapping further. What's being swapped isn't really an issue -
> the act of
On Thu, Sep 02, 1999 at 10:55:35AM -0400, Matthew Harrell wrote:
> Well, it's above 1 but below 10.
It's a dual-CPU box, right? Then you should be aiming for load avg. less
than 2, otherwise runable jobs are waiting for a CPU.
> They're on the same machine. Memory didn't seem to be my limitatio
Matthew Harrell <[EMAIL PROTECTED]> wrote:
>One machine shows
>
> procs memoryswapiosystem cpu
> r b w swpd free buff cache si so bi bo in cs us sy id
> 4 2 1 1288 21824 9368 124868 0 0 15 22 18 12 8 21 29
>
>and the other
: Feed directly into qmail-remote, not qmail-queue. Only queue
: when you abosolutely have to.
That's possible. The only problem there is that I would have to set up a
set number of connections I would like to use (say 150) and only allow that
many qmail-remotes to start plus I would have to det
Feed directly into qmail-remote, not qmail-queue. Only queue
when you abosolutely have to.
Dirk
On Thu, Sep 02, 1999 at 08:04:44AM -0400, Matthew Harrell wrote:
>
> Okay, I'm trying to pull even more out of my qmail box. It's a dual P2 450
> with 256 MB of RAM and the following qmail configurat
: :>I'll send along vmstat entries if anyone thinks it would help.
: : Couldn't hurt.
One machine shows
procs memoryswapiosystem cpu
r b w swpd free buff cache si so bi bo in cs us sy id
4 2 1 1288 21824 9368 124868 0 0 15 2
>: The qmail logs show remote concurrency over any given time period.
Not directly, as far as I can tell. Anyone have a script that'll parse
a log and chart concurrency?
-Dave
: The qmail logs show remote concurrency over any given time period.
Good point. I see it all the time and never think about it.
Yes, the one fast machine nears that limit. Without searching hard I see
111 qmail-remotes in the first part of one of my log files.
: > Top always shows memory al
: The machines are Dual's. Proc load is not an issue though, they never peak.
: Too many processors, IMO, just compromises stability. Each queue is bound to
: a different network card, which isn't really necessary, but convenient. I
: feel that it makes a big difference having multiple qmails on m
: Do you ever hit 120 qmail-remotes? If so, upping the concurrencyremote
: will help. You'll have to change conf-spawn and rebuild.
To be honest, one machine doesn't, one might. The instantaneous checks I can
do show a high number of qmail-remotes running but I've never seen 120. I
figured I w
> -Original Message-
> From: Matthew Harrell [mailto:[EMAIL PROTECTED]]
> Sent: Thursday, September 02, 1999 3:07 PM
> To: [EMAIL PROTECTED]; Qmail List
> Subject: Re: Any ideas?
>
>
>
> : Your problem is not QMail, it's disk. We've been
> conf
Matthew Harrell <[EMAIL PROTECTED]> wrote:
>Even with the [big-todo] patch I just assumed it must be detrimental
>to load it up that badly.
``Profile. Don't speculate.'' --DJB
-Dave
Matthew Harrell <[EMAIL PROTECTED]> wrote:
>Okay, I'm trying to pull even more out of my qmail box. It's a dual P2 450
>with 256 MB of RAM and the following qmail configuration:
>
>qmail with fsync's removed
>concurrencyremote set to 120
>big-todo patch installed
>
: Your problem is not QMail, it's disk. We've been configuring an array of
: servers to allow us to send approximately 1000 messages per second from a
: span of 4 servers, each running 4 separate qmail queues on 4 separate disks.
Actually, one of my next thoughts was to try multiple instantiatio
Your problem is not QMail, it's disk. We've been configuring an array of
servers to allow us to send approximately 1000 messages per second from a
span of 4 servers, each running 4 separate qmail queues on 4 separate disks.
My first recommendation is to turn up the concurrencyremote. The majorit
31 matches
Mail list logo
