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 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. From memory (sic) a caching name server for an ISP with 500,000 customers that has typically >10,000 customers online at busy times will grow to about 200M of RAM. Extrapolating from that I expect that 20M of RAM should be adequate for a caching name server for the type of load we are discussing. If the machine is upgraded to a decent amount of RAM (128M is nothing by today's standards and upgrading RAM is the cheapest upgrade possible) then the amount of RAM for a caching name server should not be an issue. > Other than that, yea, some kind of RAID solution would be cool for him. > I'd also look at making sure /var/log is on a seperate drive from > /var/spool/mail. I saw an email that indicated that /swap was seperate > from /var/spool, but nothing about where the log files were located. > Not synching after evey write will help obviously, but I recall seeing > quite a benefit from seperate drive for /var/log and /var/spool. My understanding of the discussion was that there was one drive for /var/spool (which is for the queue and /var/spool/mail) and another drive for everything else. That should be fine, but getting some drives that are less than 3 years old would be a good idea... -- http://www.coker.com.au/bonnie++/ Bonnie++ hard drive benchmark http://www.coker.com.au/postal/ Postal SMTP/POP benchmark http://www.coker.com.au/projects.html Projects I am working on http://www.coker.com.au/~russell/ My home page -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
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 to be > sufficient at this time. I'm not sure that throwing more memory at it > would help much, would it? I think even if more ram is put in, it will > just use at buffers. er that MIGHT help, right? Would be an > easy solution if 256M would help get an extra 20% performance :-) More cache is very likely to help, and it requires little expense and little work to add another 128M of RAM to the machine. I'm not sure that you'll get 20% more performance, I'd expect maybe 10% - but it depends on the load patterns. For a cheap and easy way to add performance adding RAM is the best thing you can do IMHO. -- http://www.coker.com.au/bonnie++/ Bonnie++ hard drive benchmark http://www.coker.com.au/postal/ Postal SMTP/POP benchmark http://www.coker.com.au/projects.html Projects I am working on http://www.coker.com.au/~russell/ My home page -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Finding the Bottleneck
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. Here is a recent top: 101 processes: 97 sleeping, 3 running, 1 zombie, 0 stopped CPU states: 9.4% user, 14.0% system, 0.5% nice, 76.1% idle Mem:128236K total, 125492K used, 2744K free,69528K buffers Swap: 289160K total,0K used, 289160K free,10320K cached PID USER PRI NI SIZE RSS SHARE STAT %CPU %MEM TIME COMMAND 5361 qmails 4 0 2728 2728 368 R 5.6 2.1 68:58 qmail-send 11911 root 4 0 1052 1052 800 R 1.7 0.8 0:00 top 165 root 1 0 2640 2640 860 S 0.9 2.0 25:00 named 5367 qmailr17 0 464 464 324 S 0.9 0.3 6:58 qmail-rspawn 1178 root 0 0 832 832 708 S 0.3 0.6 4:30 syslogd 5365 qmaill 0 0 476 476 404 S 0.1 0.3 6:12 splogger 5368 qmailq 1 0 396 396 332 S 0.1 0.3 5:20 qmail-clean 11988 qmailr 1 0 512 512 432 S 0.1 0.3 0:00 qmail-remote 11993 qmailr 4 0 512 512 432 R 0.1 0.3 0:00 qmail-remote 11994 qmailr 4 0 512 512 432 S 0.1 0.3 0:00 qmail-remote 11996 qmailr 5 0 512 512 432 R 0.1 0.3 0:00 qmail-remote 11997 qmailr 8 0 512 512 432 S 0.1 0.3 0:00 qmail-remote 11998 qmailr 9 0 512 512 432 R 0.1 0.3 0:00 qmail-remote 11999 qmailr10 0 512 512 432 R 0.1 0.3 0:00 qmail-remote 12000 qmailr10 0 512 512 432 S 0.1 0.3 0:00 qmail-remote 1 root 0 0 532 532 472 S 0.0 0.4 0:07 init 2 root 0 0 00 0 SW0.0 0.0 0:07 kflushd I hope you can read the above because it won't be formatted right when I send it, but hopefully you get the idea. As far as I know, linux will allocate as much free ram to the buffers, rather than just leave it empty. So ~68M in buffers sort of tells me that it has plenty of memory. I mean, if you think more would really help, we could try more ram, but I doubt the bottleneck really is with the memory limit...? 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 benefit the mail queue in any way? Don't want to get everything set up, only to find I missed something critical that you already thought of! Sincerely, Jason - Original Message - From: "Russell Coker" <[EMAIL PROTECTED]> To: "Jason Lim" <[EMAIL PROTECTED]>; "Rich Puhek" <[EMAIL 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 to be > sufficient at this time. I'm not sure that throwing more memory at it > would help much, would it? I think even if more ram is put in, it will > just use at buffers. er that MIGHT help, right? Would be an > easy solution if 256M would help get an extra 20% performance :-) More cache is very likely to help, and it requires little expense and little work to add another 128M of RAM to the machine. I'm not sure that you'll get 20% more performance, I'd expect maybe 10% - but it depends on the load patterns. For a cheap and easy way to add performance adding RAM is the best thing you can do IMHO. -- http://www.coker.com.au/bonnie++/ Bonnie++ hard drive benchmark http://www.coker.com.au/postal/ Postal SMTP/POP benchmark http://www.coker.com.au/projects.html Projects I am working on http://www.coker.com.au/~russell/ My home page -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
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. > [...] > > 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 benefit the mail queue in any way? Don't want to get > everything set up, only to find I missed something critical that you > already thought of! Maybe reiserfs (or xfs) might help? I know they increase filesystem/metadata performance in some cases... -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Finding the Bottleneck
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 huge amounts of research into this, but this is just what I've 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 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 benefit the mail queue in any way? Don't want to get > > everything set up, only to find I missed something critical that you > > already thought of! > Maybe reiserfs (or xfs) might help? I know they increase > filesystem/metadata performance in some cases... > > > -- > To UNSUBSCRIBE, email to [EMAIL PROTECTED] > with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED] > > -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
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 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 huge amounts of research into this, but this is just what > I've heard. I know at least for news servers, reiserfs can be quite faster, so I guess it might be faster for mail too... There's really one way to be sure: test it ;) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Finding the Bottleneck
Hi, 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 even if more ram is put in, it will just use at buffers. er that MIGHT help, right? Would be an easy solution if 256M would help get an extra 20% performance :-) Concerning the dns server, if it was not run locally, then every single dns lookup would have to go across the network. Now that would be a LOT of requests that would otherwise have been answered nearly instantly if it was local. The mail queue is on its OWN disk (disk 2). Everything else is on disk 1. The mail queue disk ONLY has the mail queue and absolutely nothing else. It is there for that specific purpose (even though it hasn't helped that much). Also, log files in syslog already have "-" in front of the file name so they aren't synced every write. We've tried just about everything (except the raid setup) to get every last ounce of performance out of this... but it doesn't seem like its made a huge difference :-/ Sincerely, Jason - Original Message - From: "Rich Puhek" <[EMAIL PROTECTED]> To: "Russell Coker" <[EMAIL PROTECTED]> Cc: "Jason Lim" <[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 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 memory (or can anyhow.. his > doesn't seem too bad). A highly-utilized DNS server will also chew up a > load of memory. You do not want the DNS server to swap, so you need to > have enough memory to be sure it can cache enough information. > > As for speed, if you have a machine on a LAN set up as a caching-only > DNS server (that's what I was trying to say before), I'm thinking I'll > take the LAN latency hit over having the MTA competing for resources > with the DNS server. > > Other than that, yea, some kind of RAID solution would be cool for him. > I'd also look at making sure /var/log is on a seperate drive from > /var/spool/mail. I saw an email that indicated that /swap was seperate > from /var/spool, but nothing about where the log files were located. Not > synching after evey write will help obviously, but I recall seeing quite > a benefit from seperate drive for /var/log and /var/spool. > > --Rich > > > Russell Coker wrote: > > > > 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 sure that the mail > > > server itself isn't running a DNS server. Make sure you've got one or > > > > Why not? When DNS speed is important I ALWAYS install a local DNS. > > Requests to 127.0.0.1 have to be faster than any other requests... > > > > > two DNS servers in close proximity to the mail server. Make sure that > > > the DNS server process isn't swapping on the DNS servers (for the kind > > > > The output of "top" that he recently posted suggests that nothing is > > swapping. > > > > > with 128 MB of RAM as your DNS server. Also, if possible, I like to > > > have the DNS server I'm querying kept free from being the authoratative > > > server for any domains (not always practical in a real life situation, > > > I know). > > > > How does that help? > > > > If DNS caching is the issue then probably the only place to look for a > > solution is djb-dnscache. > > > > -- > > http://www.coker.com.au/bonnie++/ Bonnie++ hard drive benchmark > > http://www.coker.com.au/postal/ Postal SMTP/POP benchmark > > http://www.coker.com.au/projects.html Projects I am working on > > http://www.coker.com.au/~russell/ My home page > > > > -- > > To UNSUBSCRIBE, email to [EMAIL PROTECTED] > > with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED] > > -- > > _ > > Rich Puhek > ETN Systems Inc. > _ > > > -- > To UNSUBSCRIBE, email to [EMAIL PROTECTED] > with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED] > >
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 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. From memory (sic) a caching name server for an ISP with 500,000 customers that has typically >10,000 customers online at busy times will grow to about 200M of RAM. Extrapolating from that I expect that 20M of RAM should be adequate for a caching name server for the type of load we are discussing. If the machine is upgraded to a decent amount of RAM (128M is nothing by today's standards and upgrading RAM is the cheapest upgrade possible) then the amount of RAM for a caching name server should not be an issue. > Other than that, yea, some kind of RAID solution would be cool for him. > I'd also look at making sure /var/log is on a seperate drive from > /var/spool/mail. I saw an email that indicated that /swap was seperate > from /var/spool, but nothing about where the log files were located. > Not synching after evey write will help obviously, but I recall seeing > quite a benefit from seperate drive for /var/log and /var/spool. My understanding of the discussion was that there was one drive for /var/spool (which is for the queue and /var/spool/mail) and another drive for everything else. That should be fine, but getting some drives that are less than 3 years old would be a good idea... -- http://www.coker.com.au/bonnie++/ Bonnie++ hard drive benchmark http://www.coker.com.au/postal/ Postal SMTP/POP benchmark http://www.coker.com.au/projects.html Projects I am working on http://www.coker.com.au/~russell/ My home page
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 to be > sufficient at this time. I'm not sure that throwing more memory at it > would help much, would it? I think even if more ram is put in, it will > just use at buffers. er that MIGHT help, right? Would be an > easy solution if 256M would help get an extra 20% performance :-) More cache is very likely to help, and it requires little expense and little work to add another 128M of RAM to the machine. I'm not sure that you'll get 20% more performance, I'd expect maybe 10% - but it depends on the load patterns. For a cheap and easy way to add performance adding RAM is the best thing you can do IMHO. -- http://www.coker.com.au/bonnie++/ Bonnie++ hard drive benchmark http://www.coker.com.au/postal/ Postal SMTP/POP benchmark http://www.coker.com.au/projects.html Projects I am working on http://www.coker.com.au/~russell/ My home page
Re: Finding the Bottleneck
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. Here is a recent top: 101 processes: 97 sleeping, 3 running, 1 zombie, 0 stopped CPU states: 9.4% user, 14.0% system, 0.5% nice, 76.1% idle Mem:128236K total, 125492K used, 2744K free,69528K buffers Swap: 289160K total,0K used, 289160K free,10320K cached PID USER PRI NI SIZE RSS SHARE STAT %CPU %MEM TIME COMMAND 5361 qmails 4 0 2728 2728 368 R 5.6 2.1 68:58 qmail-send 11911 root 4 0 1052 1052 800 R 1.7 0.8 0:00 top 165 root 1 0 2640 2640 860 S 0.9 2.0 25:00 named 5367 qmailr17 0 464 464 324 S 0.9 0.3 6:58 qmail-rspawn 1178 root 0 0 832 832 708 S 0.3 0.6 4:30 syslogd 5365 qmaill 0 0 476 476 404 S 0.1 0.3 6:12 splogger 5368 qmailq 1 0 396 396 332 S 0.1 0.3 5:20 qmail-clean 11988 qmailr 1 0 512 512 432 S 0.1 0.3 0:00 qmail-remote 11993 qmailr 4 0 512 512 432 R 0.1 0.3 0:00 qmail-remote 11994 qmailr 4 0 512 512 432 S 0.1 0.3 0:00 qmail-remote 11996 qmailr 5 0 512 512 432 R 0.1 0.3 0:00 qmail-remote 11997 qmailr 8 0 512 512 432 S 0.1 0.3 0:00 qmail-remote 11998 qmailr 9 0 512 512 432 R 0.1 0.3 0:00 qmail-remote 11999 qmailr10 0 512 512 432 R 0.1 0.3 0:00 qmail-remote 12000 qmailr10 0 512 512 432 S 0.1 0.3 0:00 qmail-remote 1 root 0 0 532 532 472 S 0.0 0.4 0:07 init 2 root 0 0 00 0 SW0.0 0.0 0:07 kflushd I hope you can read the above because it won't be formatted right when I send it, but hopefully you get the idea. As far as I know, linux will allocate as much free ram to the buffers, rather than just leave it empty. So ~68M in buffers sort of tells me that it has plenty of memory. I mean, if you think more would really help, we could try more ram, but I doubt the bottleneck really is with the memory limit...? 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 benefit the mail queue in any way? Don't want to get everything set up, only to find I missed something critical that you already thought of! Sincerely, Jason - Original Message - From: "Russell Coker" <[EMAIL PROTECTED]> To: "Jason Lim" <[EMAIL PROTECTED]>; "Rich Puhek" <[EMAIL PROTECTED]> Cc: 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 to be > sufficient at this time. I'm not sure that throwing more memory at it > would help much, would it? I think even if more ram is put in, it will > just use at buffers. er that MIGHT help, right? Would be an > easy solution if 256M would help get an extra 20% performance :-) More cache is very likely to help, and it requires little expense and little work to add another 128M of RAM to the machine. I'm not sure that you'll get 20% more performance, I'd expect maybe 10% - but it depends on the load patterns. For a cheap and easy way to add performance adding RAM is the best thing you can do IMHO. -- http://www.coker.com.au/bonnie++/ Bonnie++ hard drive benchmark http://www.coker.com.au/postal/ Postal SMTP/POP benchmark http://www.coker.com.au/projects.html Projects I am working on http://www.coker.com.au/~russell/ My home page -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
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. > [...] > > 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 benefit the mail queue in any way? Don't want to get > everything set up, only to find I missed something critical that you > already thought of! Maybe reiserfs (or xfs) might help? I know they increase filesystem/metadata performance in some cases...
Re: Finding the Bottleneck
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 huge amounts of research into this, but this is just what I've heard. Sincerely, Jason - Original Message - From: "Alson van der Meulen" <[EMAIL PROTECTED]> To: 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 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 benefit the mail queue in any way? Don't want to get > > everything set up, only to find I missed something critical that you > > already thought of! > Maybe reiserfs (or xfs) might help? I know they increase > filesystem/metadata performance in some cases... > > > -- > To UNSUBSCRIBE, email to [EMAIL PROTECTED] > with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED] > >
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 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 huge amounts of research into this, but this is just what > I've heard. I know at least for news servers, reiserfs can be quite faster, so I guess it might be faster for mail too... There's really one way to be sure: test it ;)
