On Thursday 14 June 2001 15:31, Marc Haber wrote:
[EMAIL PROTECTED] wrote:
One significant benefit of ReiserFS is that it is journalled and does
not require a lengthy fsck operation after a power failure.
However, if the journal gets corrupted, you are in for serious
trouble, because Hans
On Thursday 14 June 2001 15:31, Marc Haber wrote:
[EMAIL PROTECTED] wrote:
One significant benefit of ReiserFS is that it is journalled and does
not require a lengthy fsck operation after a power failure.
However, if the journal gets corrupted, you are in for serious
trouble, because Hans
On Fri, Jun 08, 2001 at 09:59:50PM +0800, Jason Lim wrote:
I have also thought about that... but if you have a look at Qmail's
website (http://www.qmail.org) then you'll see that a number of
extremely large mail companies (hotmail for one) uses qmail for... get
this... outgoing mail. They
On Fri, Jun 08, 2001 at 09:59:50PM +0800, Jason Lim wrote:
I have also thought about that... but if you have a look at Qmail's
website (http://www.qmail.org) then you'll see that a number of
extremely large mail companies (hotmail for one) uses qmail for... get
this... outgoing mail. They
On Mon, 11 Jun 2001 17:14:46 +0200, Russell Coker
[EMAIL PROTECTED] wrote:
One significant benefit of ReiserFS is that it is journalled and does not
require a lengthy fsck operation after a power failure.
However, if the journal gets corrupted, you are in for serious
trouble, because Hans
On Mon, 11 Jun 2001 17:14:46 +0200, Russell Coker
[EMAIL PROTECTED] wrote:
One significant benefit of ReiserFS is that it is journalled and does not
require a lengthy fsck operation after a power failure.
However, if the journal gets corrupted, you are in for serious
trouble, because Hans Reiser
On Monday 11 June 2001 10:51, Jason Lim wrote:
Too bad this is a production system or I would try it. I've never tried
reiserFS (neither has anyone else here) so we might test it along with
a 2.4 kernel later. I hear 2.4 has intergrated reiserFS support?
2.4 has integrated ReiserFS support.
On Monday 11 June 2001 10:51, Jason Lim wrote:
Too bad this is a production system or I would try it. I've never tried
reiserFS (neither has anyone else here) so we might test it along with
a 2.4 kernel later. I hear 2.4 has intergrated reiserFS support?
2.4 has integrated ReiserFS support.
- Original Message -
From: Marcin Owsiany [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Monday, June 11, 2001 7:10 AM
Subject: Re: Finding the Bottleneck
On Sun, Jun 10, 2001 at 02:04:36AM +0800, Jason Lim wrote:
I'm not exactly sure how the Linux kernel would handle this.
Right
On Saturday 09 June 2001 20:04, Jason Lim wrote:
I'm not exactly sure how the Linux kernel would handle this.
Right now, the swap is untouched. If the server needed more ram,
wouldn't it be swapping something... anything? I mean, it currently has
0kb in swap, and still has free memory.
That
On Mon, 11 Jun 2001, Russell Coker wrote:
Rik, as a general rule if a machine has 0 swap in use then can it be
assumed that the gain from adding more RAM will be minimal or
non-existant? Or is my previous assumption correct in that it could
still be able to productively use more RAM for
- Original Message -
From: Marcin Owsiany [EMAIL PROTECTED]
To: debian-isp@lists.debian.org
Sent: Monday, June 11, 2001 7:10 AM
Subject: Re: Finding the Bottleneck
On Sun, Jun 10, 2001 at 02:04:36AM +0800, Jason Lim wrote:
I'm not exactly sure how the Linux kernel would handle
PROTECTED]
To: debian-isp@lists.debian.org
Sent: Sunday, June 10, 2001 4:25 AM
Subject: Re: Finding the Bottleneck
On Sun, Jun 10, 2001 at 04:14:10AM +0800, Jason Lim wrote:
Hi,
Actually, I thought they increased performance mainly if you were
doing
large file transfers
Puhek [EMAIL PROTECTED]
Cc: Jason Lim [EMAIL PROTECTED]; debian-isp@lists.debian.org
Sent: Sunday, June 10, 2001 1:04 AM
Subject: Re: Finding the Bottleneck
On Saturday 09 June 2001 01:11, Rich Puhek wrote:
Memory memory memory! True, memory is not currently a limiting factor,
but it likely could
On Mon, Jun 11, 2001 at 04:51:03PM +0800, Jason Lim wrote:
Hi,
Too bad this is a production system or I would try it. I've never tried
reiserFS (neither has anyone else here) so we might test it along with a
2.4 kernel later. I hear 2.4 has intergrated reiserFS support?
Yup, it runs quite
On Mon, Jun 11, 2001 at 04:49:21PM +0800, Jason Lim wrote:
Hi,
AFAIK, even if there was a gig of ram in there, it would not allocate any
(or maybe just a little) to free memory, and would throw any free memory
into buffers anyway.
So 68M of buffers tells me it has ample free memory, it or
On Saturday 09 June 2001 20:04, Jason Lim wrote:
I'm not exactly sure how the Linux kernel would handle this.
Right now, the swap is untouched. If the server needed more ram,
wouldn't it be swapping something... anything? I mean, it currently has
0kb in swap, and still has free memory.
That
On Mon, 11 Jun 2001, Russell Coker wrote:
Rik, as a general rule if a machine has 0 swap in use then can it be
assumed that the gain from adding more RAM will be minimal or
non-existant? Or is my previous assumption correct in that it could
still be able to productively use more RAM for
Subject: Re: Finding the Bottleneck
On Mon, Jun 11, 2001 at 04:49:21PM +0800, Jason Lim wrote:
Hi,
AFAIK, even if there was a gig of ram in there, it would not allocate
any
(or maybe just a little) to free memory, and would throw any free
memory
into buffers anyway.
So 68M
: Finding the Bottleneck
On Saturday 09 June 2001 20:04, Jason Lim wrote:
I'm not exactly sure how the Linux kernel would handle this.
Right now, the swap is untouched. If the server needed more ram,
wouldn't it be swapping something... anything? I mean, it currently has
0kb in swap, and still has
proggies
(and they are pretty stable now too), we can't do that.
Sincerely,
Jason
- Original Message -
From: Russell Coker [EMAIL PROTECTED]
To: Jason Lim [EMAIL PROTECTED]
Sent: Monday, June 11, 2001 7:03 PM
Subject: Re: Finding the Bottleneck
On Monday 11 June 2001 10:52, you wrote
Hi,
Something VERY interested has occurred.
I kept playing around with the /var/qmail/queue directory, to see how I
could optimize it.
I also saw in some qmail-* manpage that mess pid directories, and todo
intd directories have to be on the same drive (or was that partition?
nevermind)
So
messages not preprocessed yet.
Sincerely,
Jason
- Original Message -
From: Jason Lim [EMAIL PROTECTED]
To: Russell Coker [EMAIL PROTECTED]; debian-isp@lists.debian.org
Sent: Monday, June 11, 2001 11:59 PM
Subject: Re: Finding the Bottleneck (nearly there!)
Hi,
Something VERY interested
On Sun, Jun 10, 2001 at 02:04:36AM +0800, Jason Lim wrote:
I'm not exactly sure how the Linux kernel would handle this.
Right now, the swap is untouched. If the server needed more ram, wouldn't
it be swapping something... anything? I mean, it currently has 0kb in
swap, and still has free
On Sun, Jun 10, 2001 at 02:04:36AM +0800, Jason Lim wrote:
I'm not exactly sure how the Linux kernel would handle this.
Right now, the swap is untouched. If the server needed more ram, wouldn't
it be swapping something... anything? I mean, it currently has 0kb in
swap, and still has free
On Saturday 09 June 2001 01:11, Rich Puhek wrote:
Memory memory memory! True, memory is not currently a limiting factor,
but it likely could be if he were running BIND locally. As for making
sure that the server is not authoratative for other domains, that will
help keep other DNS demands to
PROTECTED]
Cc: [EMAIL PROTECTED]
Sent: Sunday, June 10, 2001 1:07 AM
Subject: Re: Finding the Bottleneck
On Saturday 09 June 2001 08:23, Jason Lim wrote:
Well... I'm not sure if you saw the top output I sent to the list a
while back, but the swap isn't touched at all. The 128M ram seems
heard.
Sincerely,
Jason
- Original Message -
From: Alson van der Meulen [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Sunday, June 10, 2001 2:32 AM
Subject: Re: Finding the Bottleneck
On Sun, Jun 10, 2001 at 02:04:36AM +0800, Jason Lim wrote:
I'm not exactly sure how the Linux kernel
On Sun, Jun 10, 2001 at 04:14:10AM +0800, Jason Lim wrote:
Hi,
Actually, I thought they increased performance mainly if you were doing
large file transfers and such, and that small random file transfers were
not help (even hindered) by reiserFS. Don't flame me if I'm wrong as I
haven't
-
From: Rich Puhek [EMAIL PROTECTED]
To: Russell Coker [EMAIL PROTECTED]
Cc: Jason Lim [EMAIL PROTECTED]; debian-isp@lists.debian.org
Sent: Saturday, June 09, 2001 7:11 AM
Subject: Re: Finding the Bottleneck
Memory memory memory! True, memory is not currently a limiting factor,
but it likely could
On Saturday 09 June 2001 01:11, Rich Puhek wrote:
Memory memory memory! True, memory is not currently a limiting factor,
but it likely could be if he were running BIND locally. As for making
sure that the server is not authoratative for other domains, that will
help keep other DNS demands to a
On Saturday 09 June 2001 08:23, Jason Lim wrote:
Well... I'm not sure if you saw the top output I sent to the list a
while back, but the swap isn't touched at all. The 128M ram seems to be
sufficient at this time. I'm not sure that throwing more memory at it
would help much, would it? I think
PROTECTED]
Cc: debian-isp@lists.debian.org
Sent: Sunday, June 10, 2001 1:07 AM
Subject: Re: Finding the Bottleneck
On Saturday 09 June 2001 08:23, Jason Lim wrote:
Well... I'm not sure if you saw the top output I sent to the list a
while back, but the swap isn't touched at all. The 128M ram seems
On Sun, Jun 10, 2001 at 02:04:36AM +0800, Jason Lim wrote:
I'm not exactly sure how the Linux kernel would handle this.
[...]
Anyway... as for the raid solution, is there anything I should look out
for BEFORE i start implementing it? Like any particular disk or ext2
settings that would
heard.
Sincerely,
Jason
- Original Message -
From: Alson van der Meulen [EMAIL PROTECTED]
To: debian-isp@lists.debian.org
Sent: Sunday, June 10, 2001 2:32 AM
Subject: Re: Finding the Bottleneck
On Sun, Jun 10, 2001 at 02:04:36AM +0800, Jason Lim wrote:
I'm not exactly sure how
On Sun, Jun 10, 2001 at 04:14:10AM +0800, Jason Lim wrote:
Hi,
Actually, I thought they increased performance mainly if you were doing
large file transfers and such, and that small random file transfers were
not help (even hindered) by reiserFS. Don't flame me if I'm wrong as I
haven't done
Russell == Russell Coker [EMAIL PROTECTED] writes:
Russell If the NFS server has the same disk system then you will
Russell only make things worse. Anything you could do to give
Russell the NFS server better IO performance could more
Russell productively be done to the main
Maybe a local caching nameserver will help here as well.
(Just a quick though.)
Cheers, Marcel
Rich Puhek [EMAIL PROTECTED] 7 Jun 2001, at 22:47:
By the way,
In addition to checking the disk usage, memory, and the other
suggestions that have come up on the list, have you looked at DNS?
On Friday 08 June 2001 10:49, Brian May wrote:
Russell If the NFS server has the same disk system then you will
Russell only make things worse. Anything you could do to give
Russell the NFS server better IO performance could more
Russell productively be done to the main
On Thu, 07 Jun 2001 at 22:47:09 -0500, Rich Puhek wrote:
[...]
Also, there are probably some optimizations you can do for queue sort
order. I'm most familiar with Sendmail, not qmail, so I don't know the
exact settings, but try to process the queue according to recipient
domain. That way, you
]; [EMAIL PROTECTED]
Sent: Friday, June 08, 2001 6:04 PM
Subject: Re: Finding the Bottleneck
On Thu, 07 Jun 2001 at 22:47:09 -0500, Rich Puhek wrote:
[...]
Also, there are probably some optimizations you can do for queue sort
order. I'm most familiar with Sendmail, not qmail, so I don't know
]; [EMAIL PROTECTED]
Sent: Friday, June 08, 2001 5:45 PM
Subject: Re: Finding the Bottleneck
On Friday 08 June 2001 10:49, Brian May wrote:
Russell If the NFS server has the same disk system then you will
Russell only make things worse. Anything you could do to give
Russell the NFS
On Friday 08 June 2001 05:47, Rich Puhek wrote:
In addition to checking the disk usage, memory, and the other
suggestions that have come up on the list, have you looked at DNS?
Quite often you'll find that DNS lookups are severely limiting the
performance of something like a mailing list.
On Friday 08 June 2001 12:25, Jason Lim wrote:
The network is connected via 100Mb to a switch, so server to server
connections would be at that limit. Even 10Mb wouldn't be a problem as
I don't think that much data would be crossing the cable.. would it?
10Mb shouldn't be a problem for DNS.
Additionally, as far as I can see, most emails get sent to the same
moderately large list of domains (eg. aol), so the local DNS server
would've cache them already anyway.
This has been a long thread so forgive me if this has already been
discussed but...
If you are usually delivering
PROTECTED]
To: Jason Lim [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Sent: Friday, June 08, 2001 8:04 PM
Subject: Re: Finding the Bottleneck
Additionally, as far as I can see, most emails get sent to the same
moderately large list of domains (eg. aol), so the local DNS server
would've cache them
]
To: Jason Lim [EMAIL PROTECTED]; Brian May
[EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Sent: Friday, June 08, 2001 7:17 PM
Subject: Re: Finding the Bottleneck
On Friday 08 June 2001 12:25, Jason Lim wrote:
The network is connected via 100Mb to a switch, so server to server
connections would
: Russell Coker [EMAIL PROTECTED]
To: Jason Lim [EMAIL PROTECTED]; [EMAIL PROTECTED]
Sent: Friday, June 08, 2001 10:43 AM
Subject: Re: Finding the Bottleneck
On Friday 08 June 2001 00:05, Jason Lim wrote:
Thanks for your detailed reply.
As reliability is not of great importance (only the mail
Coker [EMAIL PROTECTED]
Sent: Friday, June 08, 2001 10:14 PM
Subject: Re: Finding the Bottleneck
I agree with you that splitting the mail queue to another server
wouldn't
help, especially since you've seen the top results, and know that it
isn't
very heavily loaded with other jobs in the first
On Friday 08 June 2001 16:14, Jason Lim wrote:
Today I played around with hdparm to see if I could tweak some
Specifically, I set /sbin/hdparm -a4 -c3 -d1 -m16 -u1 /dev/hdc:
-a Get/set sector count for filesystem read-ahead.
This is used to improve performance
Memory memory memory! True, memory is not currently a limiting factor,
but it likely could be if he were running BIND locally. As for making
sure that the server is not authoratative for other domains, that will
help keep other DNS demands to a minimum.
The mail server will chew up a load of
-
From: Rich Puhek [EMAIL PROTECTED]
To: Russell Coker [EMAIL PROTECTED]
Cc: Jason Lim [EMAIL PROTECTED]; [EMAIL PROTECTED]
Sent: Saturday, June 09, 2001 7:11 AM
Subject: Re: Finding the Bottleneck
Memory memory memory! True, memory is not currently a limiting factor,
but it likely could be if he
Russell == Russell Coker [EMAIL PROTECTED] writes:
Russell If the NFS server has the same disk system then you will
Russell only make things worse. Anything you could do to give
Russell the NFS server better IO performance could more
Russell productively be done to the main
Maybe a local caching nameserver will help here as well.
(Just a quick though.)
Cheers, Marcel
Rich Puhek [EMAIL PROTECTED] 7 Jun 2001, at 22:47:
By the way,
In addition to checking the disk usage, memory, and the other
suggestions that have come up on the list, have you looked at DNS?
On Friday 08 June 2001 10:49, Brian May wrote:
Russell If the NFS server has the same disk system then you will
Russell only make things worse. Anything you could do to give
Russell the NFS server better IO performance could more
Russell productively be done to the main
On Thu, 07 Jun 2001 at 22:47:09 -0500, Rich Puhek wrote:
[...]
Also, there are probably some optimizations you can do for queue sort
order. I'm most familiar with Sendmail, not qmail, so I don't know the
exact settings, but try to process the queue according to recipient
domain. That way, you
]; debian-isp@lists.debian.org
Sent: Friday, June 08, 2001 6:04 PM
Subject: Re: Finding the Bottleneck
On Thu, 07 Jun 2001 at 22:47:09 -0500, Rich Puhek wrote:
[...]
Also, there are probably some optimizations you can do for queue sort
order. I'm most familiar with Sendmail, not qmail, so I
]; debian-isp@lists.debian.org
Sent: Friday, June 08, 2001 5:45 PM
Subject: Re: Finding the Bottleneck
On Friday 08 June 2001 10:49, Brian May wrote:
Russell If the NFS server has the same disk system then you will
Russell only make things worse. Anything you could do to give
Russell
On Friday 08 June 2001 05:47, Rich Puhek wrote:
In addition to checking the disk usage, memory, and the other
suggestions that have come up on the list, have you looked at DNS?
Quite often you'll find that DNS lookups are severely limiting the
performance of something like a mailing list. Make
, 2001 6:18 PM
Subject: Re: Finding the Bottleneck
On Friday 08 June 2001 05:47, Rich Puhek wrote:
In addition to checking the disk usage, memory, and the other
suggestions that have come up on the list, have you looked at DNS?
Quite often you'll find that DNS lookups are severely limiting
On Friday 08 June 2001 12:25, Jason Lim wrote:
The network is connected via 100Mb to a switch, so server to server
connections would be at that limit. Even 10Mb wouldn't be a problem as
I don't think that much data would be crossing the cable.. would it?
10Mb shouldn't be a problem for DNS.
Additionally, as far as I can see, most emails get sent to the same
moderately large list of domains (eg. aol), so the local DNS server
would've cache them already anyway.
This has been a long thread so forgive me if this has already been
discussed but...
If you are usually delivering
]
To: Jason Lim [EMAIL PROTECTED]; Brian May
[EMAIL PROTECTED]
Cc: debian-isp@lists.debian.org
Sent: Friday, June 08, 2001 7:17 PM
Subject: Re: Finding the Bottleneck
On Friday 08 June 2001 12:25, Jason Lim wrote:
The network is connected via 100Mb to a switch, so server to server
connections would
: Russell Coker [EMAIL PROTECTED]
To: Jason Lim [EMAIL PROTECTED]; debian-isp@lists.debian.org
Sent: Friday, June 08, 2001 10:43 AM
Subject: Re: Finding the Bottleneck
On Friday 08 June 2001 00:05, Jason Lim wrote:
Thanks for your detailed reply.
As reliability is not of great importance (only
: Russell Coker [EMAIL PROTECTED]
Sent: Friday, June 08, 2001 10:14 PM
Subject: Re: Finding the Bottleneck
I agree with you that splitting the mail queue to another server
wouldn't
help, especially since you've seen the top results, and know that it
isn't
very heavily loaded with other jobs
PROTECTED]
To: Jason Lim [EMAIL PROTECTED]
Cc: debian-isp@lists.debian.org
Sent: Friday, June 08, 2001 8:04 PM
Subject: Re: Finding the Bottleneck
Additionally, as far as I can see, most emails get sent to the same
moderately large list of domains (eg. aol), so the local DNS server
would've cache
On Friday 08 June 2001 16:26, Jason Lim wrote:
This statement makes me wonder:
Also even the slowest part of a 45G drive will be twice as fast as the
fastest part of a 15G drive.
Are you sure? I never heard this before... might be a 1% difference
There is a huge difference. I have tested
On Friday 08 June 2001 16:14, Jason Lim wrote:
Today I played around with hdparm to see if I could tweak some
Specifically, I set /sbin/hdparm -a4 -c3 -d1 -m16 -u1 /dev/hdc:
-a Get/set sector count for filesystem read-ahead.
This is used to improve performance
@lists.debian.org
Sent: Friday, June 08, 2001 10:49 PM
Subject: Re: Finding the Bottleneck
On Friday 08 June 2001 16:14, Jason Lim wrote:
Today I played around with hdparm to see if I could tweak some
Specifically, I set /sbin/hdparm -a4 -c3 -d1 -m16 -u1 /dev/hdc:
-a Get/set sector count
Memory memory memory! True, memory is not currently a limiting factor,
but it likely could be if he were running BIND locally. As for making
sure that the server is not authoratative for other domains, that will
help keep other DNS demands to a minimum.
The mail server will chew up a load of
On Thursday 07 June 2001 00:11, Jason Lim wrote:
05:51:18 up 5 days, 22:38, 1 user, load average: 6.60, 7.40, 6.51
119 processes: 106 sleeping, 11 running, 2 zombie, 0 stopped
CPU states: 16.4% user, 18.3% system, 0.0% nice, 65.3% idle
Mem:128236K total, 124348K used, 3888K
PROTECTED]
Cc: [EMAIL PROTECTED]
Sent: Thursday, June 07, 2001 6:43 AM
Subject: Re: Finding the Bottleneck
On Wed, 6 Jun 2001, Jason Lim wrote:
I was wondering if there is a way to find out what/where the
bottleneck of
a large mail server is.
Look at vmstat.
vmstat can tell you about number
queue processing would help at all? Or would the
bottleneck then be shifted to NFS?
Sincerely,
Jason
- Original Message -
From: Russell Coker [EMAIL PROTECTED]
To: Jason Lim [EMAIL PROTECTED]; [EMAIL PROTECTED]
Sent: Thursday, June 07, 2001 3:21 PM
Subject: Re: Finding the Bottleneck
configuration is performing at it's
realistic limit?
Sincerely,
Jason
- Original Message -
From: Russell Coker [EMAIL PROTECTED]
To: Jason Lim [EMAIL PROTECTED]; [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Sent: Friday, June 08, 2001 3:42 AM
Subject: Re: Finding the Bottleneck
On Thursday 07 June 2001
On Thursday 07 June 2001 20:14, Jason Lim wrote:
I agree with you... it seems more and more likely that the Disks are
the limiting factor here.
I guess the next big thing to do would be to run some form of Raid
(software or hardware) for the mail queue.
Does anyone know of a cheap but
On Friday 08 June 2001 00:05, Jason Lim wrote:
Thanks for your detailed reply.
As reliability is not of great importance (only the mail queue will be
there and no critical system files), I'd go for speed and cheap price.
The client doesn't have the huge wads of cash for the optimal system
On Thursday 07 June 2001 20:14, Jason Lim wrote:
I agree with you... it seems more and more likely that the Disks are
the limiting factor here.
I guess the next big thing to do would be to run some form of Raid
(software or hardware) for the mail queue.
Does anyone know of a cheap but
headmistress of St. Paul before?
Sincerely,
Jason
- Original Message -
From: schemerz [EMAIL PROTECTED]
To: Jason Lim [EMAIL PROTECTED]
Sent: Wednesday, June 06, 2001 3:57 PM
Subject: Re: Finding the Bottleneck
On Wed, Jun 06, 2001 at 11:53:22AM +0800, Jason Lim wrote:
Hi all,
I was wondering
... :-/
Sincerely,
Jason
- Original Message -
From: Russell Coker [EMAIL PROTECTED]
To: Jason Lim [EMAIL PROTECTED]; debian-isp@lists.debian.org
Sent: Wednesday, June 06, 2001 8:05 PM
Subject: Re: Finding the Bottleneck
On Wednesday 06 June 2001 10:51, Jason Lim wrote:
Just so you know, this server
Hi all,
I was wondering if there is a way to find out what/where the bottleneck of
a large mail server is.
A client is running a huge mail server that we set up for them (running
qmail), but performance seems to be limited somewhere. Qmail has already
been optimized as far as it can go (big-todo
On Wed, 6 Jun 2001, Jason Lim wrote:
I was wondering if there is a way to find out what/where the bottleneck of
a large mail server is.
Look at vmstat.
vmstat can tell you about number of processeses waiting for run time,
amount of memory swapped to disk, blocks per second sent (and
received)
On Thursday 07 June 2001 00:11, Jason Lim wrote:
05:51:18 up 5 days, 22:38, 1 user, load average: 6.60, 7.40, 6.51
119 processes: 106 sleeping, 11 running, 2 zombie, 0 stopped
CPU states: 16.4% user, 18.3% system, 0.0% nice, 65.3% idle
Mem:128236K total, 124348K used, 3888K
PROTECTED]
Cc: debian-isp@lists.debian.org
Sent: Thursday, June 07, 2001 6:43 AM
Subject: Re: Finding the Bottleneck
On Wed, 6 Jun 2001, Jason Lim wrote:
I was wondering if there is a way to find out what/where the
bottleneck of
a large mail server is.
Look at vmstat.
vmstat can tell you
queue processing would help at all? Or would the
bottleneck then be shifted to NFS?
Sincerely,
Jason
- Original Message -
From: Russell Coker [EMAIL PROTECTED]
To: Jason Lim [EMAIL PROTECTED]; debian-isp@lists.debian.org
Sent: Thursday, June 07, 2001 3:21 PM
Subject: Re: Finding
On Friday 08 June 2001 00:05, Jason Lim wrote:
Thanks for your detailed reply.
As reliability is not of great importance (only the mail queue will be
there and no critical system files), I'd go for speed and cheap price.
The client doesn't have the huge wads of cash for the optimal system
By the way,
In addition to checking the disk usage, memory, and the other
suggestions that have come up on the list, have you looked at DNS? Quite
often you'll find that DNS lookups are severely limiting the performance
of something like a mailing list. Make sure that the mail server itself
isn't
headmistress of St. Paul before?
Sincerely,
Jason
- Original Message -
From: schemerz [EMAIL PROTECTED]
To: Jason Lim [EMAIL PROTECTED]
Sent: Wednesday, June 06, 2001 3:57 PM
Subject: Re: Finding the Bottleneck
On Wed, Jun 06, 2001 at 11:53:22AM +0800, Jason Lim wrote:
Hi all,
I was wondering
On Wednesday 06 June 2001 10:51, Jason Lim wrote:
Just so you know, this server is an:
AMD K6-2 500Mhz, 128M-133Mhz, 2 UDMA100 drives (IBM), 10M bandwidth.
How much swap is being used? If you have any serious amount of mail being
delivered then having a mere 128M of RAM will seriously hurt
... :-/
Sincerely,
Jason
- Original Message -
From: Russell Coker [EMAIL PROTECTED]
To: Jason Lim [EMAIL PROTECTED]; [EMAIL PROTECTED]
Sent: Wednesday, June 06, 2001 8:05 PM
Subject: Re: Finding the Bottleneck
On Wednesday 06 June 2001 10:51, Jason Lim wrote:
Just so you know, this server is an:
AMD
89 matches
Mail list logo
