Re: Sysadmin article
On Sat, 16 Jun 2001, Albert D. Cahalan wrote: I'd say the real winner was NT. It mostly kept up with Linux, trashed FreeBSD and Solaris, and didn't need any tuning to do it. FWIW, somebody pointed out (and I overlooked) that the test ran RSETs instead of real mail messages. Excuse me, but when in the hell was the last time that your MX sat around receiving RSETs all day?! Anybody running NT or 2000 out-of-the-box with IIS... yup, that's a real winner. http://www.eeye.com/ Next benchmark: How long does it take for an untuned box to get 0wn3d? OEM NT4, anybody? Remember, it must be straight out of the box. Back to work for me. I have to build / upgrade a few servers; when done, there will be no more Linux on our network. I guess the only choice now is if I should tune these systems to work well in real life, or if I want to have a system that RSETs mail quickly... Anybody have a real-world benchmark suite for our new Web server? I'm thinking of something along the lines that sends the request, only uses HEAD instead of GET or POST... Eddy --- Brotsman Dreger, Inc. EverQuick Internet Division Phone: +1 (316) 794-8922 Wichita/(Inter)national Phone: +1 (785) 865-5885 Lawrence --- Date: Mon, 21 May 2001 11:23:58 + (GMT) From: A Trap [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: Please ignore this portion of my mail signature. These last few lines are a trap for address-harvesting spambots. Do NOT send mail to [EMAIL PROTECTED], or you are likely to be blocked. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Sysadmin article
Wes Peters writes: Albert D. Cahalan wrote: No, no, no. You have to tune the systems EQUALLY. Um, how? :-) What if some random admin was picked to tune the systems? Maybe he is a Solaris admin, but he honestly tries to tune the other systems. Sure you wouldn't complain that he did a bad job if FreeBSD lost? Driver quality varies too, so hardware choice matters. It is not OK to test on identical hardware, unless the purchaser selects random off-the-shelf hardware to avoid any bias. There are 2 sane ways to benchmark: 1. Use an out-of-the box config on randomly selected hardware. This is what a typical low-paid admin will throw together, so it certainly is a valid test. It is best to run this test many times, since an OS may get unlucky with hardware selection. (tuning is equal: none at all) But this is not a valid test. I certainly wouldn't hire someone who knows NOTHING about the platform to run a critical service on it, why would I accept a benchmark run in such a manner? This is a completely ludicrous statement. Not. Lots of places don't have the time, money, or judgement to hire an expert. Even if they do, they often don't want to be stuck relying on that expert too much. Maybe he quits one day, and soon after that his manager gets stuck rebuilding the system. It's nice to have an OS doesn't require serious hacking and careful hardware selection to operate with reasonable performance. The other problem is the impossibility of any such benchmark to discover the underlying reasons behind the default configuration. Re-run the same test, pulling the power cord once an hour (pretend you're in California here) and see which spends most of it's time in fsck. I don't have a problem with that test, even if I may dislike the results. It is a perfectly reasonable test to run. In the Sysadmin article, the biggest error was that the admin crudely tuned the FreeBSD and Linux boxes. No, he crudely tuned the FreeBSD and Solaris boxes, while proving his foregone conclusion that Linux was the cat's ass. Gee, that was a surprise. Oh sorry, Linux got the same treatment as FreeBSD and Solaris. Only the NT box was untuned, and it beat FreeBSD BTW. He did ulimit -n 8192 on all three UNIX-like systems, and... Linux: echo 65536 /proc/sys/fs/file-max FreeBSD: kern.maxfiles=65536 kern.maxfilesperproc=32768 Solaris: set rlim_fd_max=0x8000 set rlim_fd_cur=0x8000 Hey, no fair! FreeBSD and Solaris got twice as much tuning as the Linux box, and NT got none. But you don't like the results, so you say this was somehow unfair. I'd say the real winner was NT. It mostly kept up with Linux, trashed FreeBSD and Solaris, and didn't need any tuning to do it. He should have left both with out-of-the-box limits to be fair to NT and Solaris. No, he should have configured all of them as close to equally as possible. That is pretty much what he did. Oh, you mean he should fairly tune them for performance? Let's see you tune an NT box as well as your FreeBSD box. Except for an open competition, benchmarking on tuned boxes is crap. There just isn't any way to be fair. It is absurd to suggest that he should have been hacking away at compile-time constants. Every OS had a default kernel. And nobody on the planet, other than you, would use it for this or any other application. I'd rather not, but I might if I was pressed for time. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Sysadmin article
(cc trimmed) Albert D. Cahalan wrote: No, he crudely tuned the FreeBSD and Solaris boxes, while proving his foregone conclusion that Linux was the cat's ass. Gee, that was a surprise. Oh sorry, Linux got the same treatment as FreeBSD and Solaris. Only the NT box was untuned, and it beat FreeBSD BTW. He did ulimit -n 8192 on all three UNIX-like systems, and... (details snipped) Hey, no fair! FreeBSD and Solaris got twice as much tuning as the Linux box, and NT got none. But you don't like the results, so you say this was somehow unfair. I'd say the real winner was NT. It mostly kept up with Linux, trashed FreeBSD and Solaris, and didn't need any tuning to do it. All he was doing was increasing the maximum files per process. Without this the test wouldn't even run properly, so I certainly wouldn't call it 'performance tuning'. (...) Oh, you mean he should fairly tune them for performance? Let's see you tune an NT box as well as your FreeBSD box. Except for an open competition, benchmarking on tuned boxes is crap. There just isn't any way to be fair. Agreed. However the operating systems tested all take a different approach to what gets included or tuned in a default install. FreeBSD (and Solaris AFAIK) both ship with rather conservative defaults. Linux on the other hand tends to need relatively little tuning 'out of the box', for example ext2fs can only really be compared to UFS with softupdates (or mounted async). I just hope nobody does any of these types of benchmarks on FreeBSD 4.3-RELEASE with IDE disks... AFAIK all the others leave IDE write-caching turned on (not sure about Solaris there though). This thread has probably been going on long enough... Jonathan To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Sysadmin article
And this is where ? I just tried it and received the error message of no manual entry for tuning. Cheers, Mark On Fri, 15 Jun 2001 01:43:10 -0400, Brent Verner said: On 15 Jun 2001 at 00:38 (-0500), Stephen Montgomery-Smith wrote: | Mike Silbersack wrote: | | | Matt's performance manpage covers a lot of this, but is probably not as | easy to digest as an interactive script. | | | What do I type to read this man page? $ man tuning To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message -- Mark Sergeant Unix Systems Administrator Fortune follows... Sodd's Second Law: Sooner or later, the worst possible set of circumstances is bound to occur. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Sysadmin article
On Fri, Jun 15, 2001 at 01:45:57AM -0500, Mark Sergeant wrote: And this is where ? I just tried it and received the error message of no manual entry for tuning. It was added to the system on 2001-05-27 so if your system is older than that you won't have it. Cheers, Mark On Fri, 15 Jun 2001 01:43:10 -0400, Brent Verner said: On 15 Jun 2001 at 00:38 (-0500), Stephen Montgomery-Smith wrote: | Mike Silbersack wrote: | | | Matt's performance manpage covers a lot of this, but is probably not as | easy to digest as an interactive script. | | | What do I type to read this man page? $ man tuning -- Insert your favourite quote here. Erik Trulsson [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Sysadmin article
Ahh ok, Well I am going to wait a little while before make worlding as it seems a few too many things I use are broken for now. Cheers, Mark On Fri, 15 Jun 2001 09:14:57 +0200, Erik Trulsson said: On Fri, Jun 15, 2001 at 01:45:57AM -0500, Mark Sergeant wrote: And this is where ? I just tried it and received the error message of no manual entry for tuning. It was added to the system on 2001-05-27 so if your system is older than that you won't have it. Cheers, Mark On Fri, 15 Jun 2001 01:43:10 -0400, Brent Verner said: On 15 Jun 2001 at 00:38 (-0500), Stephen Montgomery-Smith wrote: | Mike Silbersack wrote: | | | Matt's performance manpage covers a lot of this, but is probably not as | easy to digest as an interactive script. | | | What do I type to read this man page? $ man tuning -- Mark Sergeant Unix Systems Administrator Fortune follows... That boy's about as sharp as a pound of wet liver -- Foghorn Leghorn To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Sysadmin article
Devin Butterfield wrote: On Thursday 14 June 2001 9:13, Alfred Perlstein wrote: * Rajappa Iyer [EMAIL PROTECTED] [010614 22:23] wrote: http://www.sysadminmag.com/articles/2001/0107/0107a/0107a.htm Any obvious reasons why FreeBSD performed so poorly for these people? Because they did benchmarks on systems without tuning. So why doesn't FreeBSD ship with a tuned configuration? Just curious... Tuning trades performance for reliability. By default, FreeBSD is reliable for any general purpose application, and does not overcommit resources which will never end up being used in the majority of applications. They have a special purpose application written to a particular architecture with a particular implementation model. Tuning FreeBSD for this use would de-tune it for other uses. See my other posting. -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Sysadmin article
Rajappa Iyer wrote: http://www.sysadminmag.com/articles/2001/0107/0107a/0107a.htm Any obvious reasons why FreeBSD performed so poorly for these people? Here is a repeat of my post to -advocacy: -- Terry The article is meaningless. Too bad they titled it Which OS is Fastest for High- Performance Network Applications? instead of Which OS is Fastest for MailEngine?. The only implied caveat is the statement Our customers frequently ask us which operating system is best for running our software in paragraph 3 of the Background section. This should have been in bold type in the first paragraph. -- It makes a number of very large blunders, which are really inexcusable, given that it tries to represent itself as a fair and unbiased comparison. These blunders are in the tuning of FreeBSD, the best architecture for FreeBSD applications (one shich they did not even try to consider), in their choice of which items they could micro-benchmark would really be indicative of real-world performance, and, finally, in their experimental methodology. Here is a short list, off the top of my head: 1) The mail server they were using doesn't come with any of these systems out of the box. 2) Threaded processes are vastly inferior to finite state automatons, when it comes to CPU utilization on single CPU systems, and even on multiple CPU systems, if there is async I/O that can be scheduled on multiple CPUs. 3) FreeBSD turns of write caching on IDE drives, by default, in FreeBSD 4.3 and above; you can set it to be like Linux, Solaris, and Windows, if you don't care about your data. On FreeBSD 4.2 and below, Soft Updates are not enabled by default. Either way, without tuning, you lose. 4) IDE drives do not support tagged command queueing, except IBM DTLA drives, which are known to fail due to overheating and due to their electronics being too slow for their radial track density for interior tracks. 5) Real servers with storage and I/O requirements use SCSI drives so they can benefit from tagged command queues, which allow I/O to be interleaved instead of serialized. 6) No well designed mail server keeps all queue files in the same directory, unless it has been designed to run on a particular system where that is not a problem; this is a design portability issue, not a performance issue. 7) Sendmail can handle 400,000 8k emails in a 24 hour period on a 500MHz box, if it is properly set up and queue dispersal is optimally configured (e.g. with the patches from ftp://ftp.whistle.com/ ). 8) The most efficient asynchornous architecture for an application is OS-dependent. 9) There are more than 3 ways to skin a cat, or to architect a task. 10) Sending an RSET instead of data measures only the connection setup and teardown speeds, and does not measure real throughput, and is not representative of real world behaviour, in which mail messages, when sent, contain data, and not just trivial addressing information. 11) Mail servers which support the ESMTP PIPELINE ability have significantly higher throughput, even when just doing addressing. 12) You can not tweak FreeBSD's network connection limits at run time; socket structurse, inpcb's, and tcpcb's are allocated via a zone allocator, prior to the system actually being started. This zone can not be resized. Without the patch I posted to make maxfiles boot-time tunable, FreeBSD can not increase the number of sockets and files that it can simultaneously handle, without a kernel recompile. Thus the tweaking used was useless. 13) For each connection, there is a tcptmpl structure, which is used for keepalives. This structure will consume one mbuf per connection; in addition, the average TCP window size will be 16k; so you will need 16k/2k (8) mbufs for custer pointers plus 16k/256 (64) mbufs for the window data, plus one mbuf per connection, pplus one mbuf per connection, if you are setting options. This means that you will potentially need 74 mbufs per connection you intend to support; without patching, this also is not tunable except at compile time, and the value was not tuned. 14) The average througput per network architecture is extremely misleading, both because of the limited and inefficient architectures used in the test, and in using an average to determine which was the best architecture for use on all OSs. Per OS numbers would have been much more meaningful, since the final architecture was chosen based on the average, and
Re: Sysadmin article
Mike Silbersack wrote: Rather than a tuned configuration, what would be useful is a script that would evaluate a system and give tuning hints. This might be simple for someone familiar with shell scripting or perl. It could do something like: [ ... Eliza program for FreeBSD ... ] Doing this is non-trivial. Many of the things they should have tuned can not be tuned except at compile time. Any object allocated out of a zone before the VM is started, such as inpcb's and tcpcb's, in order to render the objects pageable, are allocated from a zone which is not growable, and takes a static amount of kernel virtual address space. This is not obvious, unless you look very carefully at the code. Similarly, allocations wich must be able to occur at interrupt time, such as replacement mbuf's for ring buffer contents in ethernet drivers, similarly, must come from a static pre-allocation. By definition, you can not resize these things at runtime. Things in zones are type-stable, as well, which means that even if you don't use all of them, they are deducted from your total available memory, which might instead be better spent in buffer cache, directory lookup cache, or any of hundreds of other resources. -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Sysadmin article
On Fri, Jun 15, 2001 at 02:09:19AM -0700, Terry Lambert wrote: Mike Silbersack wrote: Rather than a tuned configuration, what would be useful is a script that would evaluate a system and give tuning hints. This might be simple for someone familiar with shell scripting or perl. It could do something like: [ ... Eliza program for FreeBSD ... ] Doing this is non-trivial. Many of the things they should have tuned can not be tuned except at compile time. And Mike did not imply this tuning could be done without recompiling. As a matter of fact, one of the suggestions in his example involved the words 'change to X and recompile'. G'luck, Peter -- I've heard that this sentence is a rumor. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Sysadmin article
Terry Lambert wrote: Rajappa Iyer wrote: http://www.sysadminmag.com/articles/2001/0107/0107a/0107a.htm Any obvious reasons why FreeBSD performed so poorly for these people? Here is a repeat of my post to -advocacy: -- Terry The article is meaningless. Too bad they titled it Which OS is Fastest for High- Performance Network Applications? instead of Which OS is Fastest for MailEngine?. The only implied caveat is the statement Our customers frequently ask us which operating system is best for running our software in paragraph 3 of the Background section. This should have been in bold type in the first paragraph. -- It makes a number of very large blunders, which are really inexcusable, given that it tries to represent itself as a fair and unbiased comparison. Becareful before you state some of these - while I agree that the article and testing methods were not perfect, it is not what you think: 2) Threaded processes are vastly inferior to finite state automatons, when it comes to CPU utilization on single CPU systems, and even on multiple CPU systems, if there is async I/O that can be scheduled on multiple CPUs. That is both a true-ism and a false-ism, depending on the way it is coded, the coder, and the architecture of the OS and hardware... 3) FreeBSD turns of write caching on IDE drives, by default, in FreeBSD 4.3 and above; you can set it to be like Linux, Solaris, and Windows, if you don't care about your data. On FreeBSD 4.2 and below, Soft Updates are not enabled by default. Either way, without tuning, you lose. And if you read the article, you may find the following text: We installed all operating systems on identical 4-GB SCSI-3 drives (IBM model DCAS-34330), and ran the tests on the same machine (ASUS P3B motherboard, Intel Pentium III 550-MHz processor, 384-MB SDRAM, Adaptec 2940UW SCSI controller, ATI Rage Pro 3D video card, Intel EtherExpress Pro 10/100 Ethernet card). So, IDE drive issue (they just suck) is not an issue here. Yes, IDE has problems, but if they did not use it, don't claim that it was an issue. 4) IDE drives do not support tagged command queueing, except IBM DTLA drives, which are known to fail due to overheating and due to their electronics being too slow for their radial track density for interior tracks. Again, don't claim it as a problem when they specifically stated that SCSI was used and which specific SCSI drive and hardware setup. 5) Real servers with storage and I/O requirements use SCSI drives so they can benefit from tagged command queues, which allow I/O to be interleaved instead of serialized. I agree. And, it seems, so did the testers. [...] 13) For each connection, there is a tcptmpl structure, which is used for keepalives. This structure will consume one mbuf per connection; in addition, the average TCP window size will be 16k; so you will need 16k/2k (8) mbufs for custer pointers plus 16k/256 (64) mbufs for the window data, plus one mbuf per connection, pplus one mbuf per connection, if you are setting options. This means that you will potentially need 74 mbufs per connection you intend to support; without patching, this also is not tunable except at compile time, and the value was not tuned. Is this not a potential issue with the OS? 14) The average througput per network architecture is extremely misleading, both because of the limited and inefficient architectures used in the test, and in using an average to determine which was the best architecture for use on all OSs. Per OS numbers would have been much more meaningful, since the final architecture was chosen based on the average, and not based on what was best for the OS being tested. I fully agree. That part of the test/description was completely wrong just because it assumed too many things and did not give a reasonable example of each implementation (and how each did on each OS). It is obvious that in the current stable FreeBSD that anything that is heavily threaded will not do as well as on other operating systems that have better threading support. But this can also be seen as a reasonable complaint against FreeBSD. And we know that and the next major FreeBSD release will have addressed it. -- Michael Sinz Worldgate Communications [EMAIL PROTECTED] A master's secrets are only as good as the master's ability to explain them to others. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
RE: Sysadmin article
From: Robert Watson [mailto:[EMAIL PROTECTED]] There was some discussion of this on freebsd-advocacy yesterday and today, and it sounded like it came down to poor tuning (not enabling soft updates, et al) in combination with a heavy reliance on threading, where we currently don't do so well. Did anyone offer to contact Lyris directly to identify a configuration which would have fared better in their tests? Since their application is available for FreeBSD, it is in our best interests for to help them out. -Charles To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
RE: Sysadmin article
On Fri, 15 Jun 2001, Charles Randall wrote: Did anyone offer to contact Lyris directly to identify a configuration which would have fared better in their tests? Since their application is available for FreeBSD, it is in our best interests for to help them out. On a side note, I did contact them about 2 days before this article appeared since TWA uses Lyris (now on FreeBSD :-) it was running on linux) and asked them if they planned on supporting kqueue in the FreeBSD version. The tech rep said they had no plans but she would forward it to the developers since I made a feature request. The software itself is a bit goofy. It keeps defered mail around for *way* to long. We have 1.2 million subscribers to mail on monday. It sends out about 98% in 4 hours of the list subscribers. And has ~4500 defered mails because of down mail hosts, undeliverable mails, etc.. And it keeps them around for DAYS instead of flushing the queue periodically. Which it should since that is what this is app's main goal is for is a mailing list/spam sender. I have yet to find a way to manually force the queue to flush on it either. It uses a FoxPro DB to store members in AFAIK. Why it's not a berkeley db is beyond me. On a 1-10 I give the app a 7 for its purpose. I still think a properly tuned Postfix box would destroy this software but they claim otherwise. Naturally. = -Chris Watson (316) 326-3862 | Sr. Unix Administrator Work: [EMAIL PROTECTED] | Trans World Airlines, Kansas City, MO Home: [EMAIL PROTECTED] | http://www.twa.com = WINDOWS: Where do you want to go today? LINUX: Where do you want to go tomorrow? BSD: Are you guys coming or what? = irc.openprojects.net #FreeBSD -Join the revolution! ICQ: 20016186 To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Sysadmin article
On Fri, Jun 15, 2001 at 01:43:10AM -0400, Brent Verner wrote: On 15 Jun 2001 at 00:38 (-0500), Stephen Montgomery-Smith wrote: | Mike Silbersack wrote: | Matt's performance manpage covers a lot of this, but is probably not as | easy to digest as an interactive script. | What do I type to read this man page? $ man tuning This is a cool thing. I suggest mentioning it in /etc/motd along with the bug reporting stuff and pointer to heir(7). PGP signature
Re: Sysadmin article
I would heartily endorse having the out of the box FreeBSD install be tuned better... Sysadmin can't be knocked for not doing the tuning as running an out of the box config is what a vast majority of users do, imho, so their performance tests and the poor results from FreeBSD are perfectly valid indication of what can be expected without tuning. Softupdates on by default sounds great to me, as I can't think of any common situations that would be hurt by it. But I'm sure someone will correct me if I'm wrong on this. Now if we could only speed up SMP too... cheers, --dr On Friday 15 June 2001 04:23, Robert Watson wrote: On Fri, 15 Jun 2001, Alfred Perlstein wrote: * Rajappa Iyer [EMAIL PROTECTED] [010614 22:23] wrote: http://www.sysadminmag.com/articles/2001/0107/0107a/0107a.htm Any obvious reasons why FreeBSD performed so poorly for these people? Because they did benchmarks on systems without tuning. A simple email to the lists asking for help would have probably done a world of difference. There was some discussion of this on freebsd-advocacy yesterday and today, and it sounded like it came down to poor tuning (not enabling soft updates, et al) in combination with a heavy reliance on threading, where we currently don't do so well. A question I posed on -advocacy was when, if ever, we should consider simply enabling soft updates by default on non-root file systems. We claim that soft updates improves both performance and reliability (at the cost of increased kernel complexity), making it a prime candidate for the limelight. Would people be opposed to a change to sysinstall so that (once we're clear that soft updates has stabilized in -CURRENT) such that selecting the default partitioning enables soft updates on any file system not mounted as / unless specifically toggled off? How about other tuning: we've previously discussed increasing the default max socket buffer sizes, for example, to allow better tuning for faster network segments. The point has been made that on FreeBSD, we select somewhat conservative (safe) settings by default, and give admins the option to trade off safety and performance as they see fit. On the other hand, there may be further changes we can make that stay well within the realm of safe, yet improve default performance helping us out on Joe Blow's Untuned Performance Test (as you know, many performance tests in popular media don't involve consulting the authors of the code first for tuning help). Likewise, we've gradually been shifting in stance from a we want to run well on tiny systems to we recognize that memory is cheap, and performance is important, let the little guys do more tuning than the medium guys. Robert N M Watson FreeBSD Core Team, TrustedBSD Project [EMAIL PROTECTED] NAI Labs, Safeport Network Services To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Sysadmin article
On Fri, 15 Jun 2001, Dragos Ruiu wrote: I would heartily endorse having the out of the box FreeBSD install be tuned better... Sysadmin can't be knocked for not doing the tuning as running an out of the box config is what a vast majority of users do, imho, so their performance tests and the poor results from FreeBSD are perfectly valid indication of what can be expected without tuning. Softupdates on by default sounds great to me, as I can't think of any common situations that would be hurt by it. But I'm sure someone will correct me if I'm wrong on this. Now if we could only speed up SMP too... Well, I think this is especially true in light of the recent decision to turn WCE back on by default for IDE. Robert N M Watson FreeBSD Core Team, TrustedBSD Project [EMAIL PROTECTED] NAI Labs, Safeport Network Services To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Sysadmin article
On Fri, 15 Jun 2001, Terry Lambert wrote: [ ... Eliza program for FreeBSD ... ] Doing this is non-trivial. Many of the things they should have tuned can not be tuned except at compile time. I think you just hit the nail on the head and managed to identify the problem... regards, Rik -- Executive summary of a recent Microsoft press release: we are concerned about the GNU General Public License (GPL) http://www.surriel.com/ http://www.conectiva.com/ http://distro.conectiva.com/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Sysadmin article
:On Fri, 15 Jun 2001, Dragos Ruiu wrote: : : I would heartily endorse having the out of the box FreeBSD install be : tuned better... : : Sysadmin can't be knocked for not doing the tuning as running an out of : the box config is what a vast majority of users do, imho, so their : performance tests and the poor results from FreeBSD are perfectly valid : indication of what can be expected without tuning. : : Softupdates on by default sounds great to me, as I can't think of any : common situations that would be hurt by it. But I'm sure someone will : correct me if I'm wrong on this. Now if we could only speed up SMP : too... : :Well, I think this is especially true in light of the recent decision to :turn WCE back on by default for IDE. : :Robert N M Watson FreeBSD Core Team, TrustedBSD Project :[EMAIL PROTECTED] NAI Labs, Safeport Network Services On the otherhand, what these people were testing was a 'high performance' system. If you intend to push a system to its limits, you damn well better be prepared to tune it properly or you are just wasting your time. On any operating system. You will never find joe-user running his system into the ground with thousands of simultanious connections and ten thousand files in a mail directory, so it's silly to configure the system from a joe-user perspective. Slashdot respondants did a pretty good job identifying the problems - network mbufs, softupdates, Robert here just brought up the possibility of IDE write caching being turned off, etc etc etc. The fact that the bozos doing the 'benchmark' knew about sysctl but only tuned the file descriptor limit is a pretty good indication of how biased they were. I'll bet they didn't even bother compiling up a kernel... something that is utterly trivial in a FreeBSD system, and if they did they certainly didn't bother tuning it. -Matt To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Sysadmin article
On Thu, Jun 14, 2001 at 10:23:21PM -0400, Rajappa Iyer wrote: http://www.sysadminmag.com/articles/2001/0107/0107a/0107a.htm Any obvious reasons why FreeBSD performed so poorly for these people? Yes, it's not very difficult to guess why. If you read the tuning(7) manpage in recent 4.x FreeBSD systems you will notice that even the order in which you lay out the partitions on the disks ruding installation time can play a significant role in filesystem speed. Softupdates are disabled by default, and for a good reason too (reliability is more important than raw speed to the people who install FreeBSD for the first time; if it isn't they can always enable softupdates later on). Write-back caching is disabled in the disks, even if they support it. This is yet another step towards making the default installation of FreeBSD as reliable a system as it can be. Installing an operating system (be it FreeBSD, linux, Windows or what else) and failing to tune the system to perform as good as possible for the application, is no decent way of doing a benchmark. And when is comes to benchmarks, you have to tune ALL the systems that are involved. You have to perform the test on identical hardware (if such a thing is ever possible[1]). When doing benchmarks, you have to present a lot more data than a simple bar or line graph with the results, for the benchmarks to be of any practical value to somebody else. An exact description of the hardware involved, details about the installation of the software, tuning decisions and tweaks performed during installation that will make the software perform better for a given application, what application you are interested in and testing with this benchmark, post installation tuning, what software you used for doing the benchmark, was it compiled by you or somebody else? what compiler and tools you used to generate the software of the benchmark, what special options you gave if any, and finally what the benchmark was, how long it took, did it finish successfully or fail, and those infamous charts with the results. You see, there's more to a benchmark than just a few charts, and we have not been given account about any of that by the authors of the articles in question. -giorgos [1] Even disks os the same manufacturer, and the same declared size, speed, characteristics, etc. do have slight differences some times. [-- Sorry about this long rant, but the whole story about this article is starting to get on my nerves :P --] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Sysadmin article
:softupdates later on). Write-back caching is disabled in the disks, :even if they support it. This is yet another step towards making the :default installation of FreeBSD as reliable a system as it can be. Well, not any more... we caved in on that one because the performance loss was insane. But for 4.2 it was turned off. -Matt To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Sysadmin article
On Friday, June 15, 2001, at 02:37 PM, Giorgos Keramidas wrote: On Thu, Jun 14, 2001 at 10:23:21PM -0400, Rajappa Iyer wrote: http://www.sysadminmag.com/articles/2001/0107/0107a/0107a.htm Any obvious reasons why FreeBSD performed so poorly for these people? Yes, it's not very difficult to guess why. If you read the tuning(7) manpage in recent 4.x FreeBSD systems you will notice that even the order in which you lay out the partitions on the disks ruding installation time can play a significant role in filesystem speed. Softupdates are disabled by default, and for a good reason too (reliability is more important than raw speed to the people who install FreeBSD for the first time; if it isn't they can always enable softupdates later on). [...] Is softupdates known to be unreliable, or is it merely a distrust of new code? To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Sysadmin article
On Fri, Jun 15, 2001 at 06:31:12PM -0400, Josh Osborne wrote: On Friday, June 15, 2001, at 02:37 PM, Giorgos Keramidas wrote: On Thu, Jun 14, 2001 at 10:23:21PM -0400, Rajappa Iyer wrote: http://www.sysadminmag.com/articles/2001/0107/0107a/0107a.htm Any obvious reasons why FreeBSD performed so poorly for these people? Yes, it's not very difficult to guess why. If you read the tuning(7) manpage in recent 4.x FreeBSD systems you will notice that even the order in which you lay out the partitions on the disks ruding installation time can play a significant role in filesystem speed. Softupdates are disabled by default, and for a good reason too (reliability is more important than raw speed to the people who install FreeBSD for the first time; if it isn't they can always enable softupdates later on). [...] Is softupdates known to be unreliable, or is it merely a distrust of new code? Matt has explained this better than I could ever do, in his tuning(7) manpage -- a recent, but very valuable addition to our manpages. To quote the manpage: First, softupdates guarentees filesystem consistency in the case of a crash but could very easily be several seconds (even a minute!) behind updating the physical disk. If you crash you may lose more work then otherwise. Secondly, softupdates delays the freeing of filesystem blocks. If you have a filesystem (such as the root filesystem) which is close to full, doing a major update of it, e.g. make installworld, can run it out of space and cause the update to fail. -giorgos To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Sysadmin article
:Of course, assuming dirpref and Ian's new directory cache have been MFC'd :by the time 4.4 comes out, it will scream on that same benchmark. : :Mike Silby Silbersack Yup! Even without dirpref. -Matt To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Sysadmin article
On Fri, 15 Jun 2001, Matt Dillon wrote: :softupdates later on). Write-back caching is disabled in the disks, :even if they support it. This is yet another step towards making the :default installation of FreeBSD as reliable a system as it can be. Well, not any more... we caved in on that one because the performance loss was insane. But for 4.2 it was turned off. -Matt Actually, I think write caching was on for 4.2. I'd hate to see what their benchmark would've shown with write caching and softupdates off. shudder Of course, assuming dirpref and Ian's new directory cache have been MFC'd by the time 4.4 comes out, it will scream on that same benchmark. Mike Silby Silbersack To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Sysadmin article
Giorgos Keramidas writes: Installing an operating system (be it FreeBSD, linux, Windows or what else) and failing to tune the system to perform as good as possible for the application, is no decent way of doing a benchmark. And when is comes to benchmarks, you have to tune ALL the systems that are involved. You have to perform the test on identical hardware (if such a thing is ever possible[1]). No, no, no. You have to tune the systems EQUALLY. Um, how? :-) What if some random admin was picked to tune the systems? Maybe he is a Solaris admin, but he honestly tries to tune the other systems. Sure you wouldn't complain that he did a bad job if FreeBSD lost? Driver quality varies too, so hardware choice matters. It is not OK to test on identical hardware, unless the purchaser selects random off-the-shelf hardware to avoid any bias. There are 2 sane ways to benchmark: 1. Use an out-of-the box config on randomly selected hardware. This is what a typical low-paid admin will throw together, so it certainly is a valid test. It is best to run this test many times, since an OS may get unlucky with hardware selection. (tuning is equal: none at all) 2. Run an open bring-your-own hardware competition like SPECweb99. Every OS gets tuned by fanatical experts, and every OS gets the hardware it runs best on. Hardware selection can only be limited by purchase date and monetary value -- it isn't fair to specify how the money is spent. (tuning is equal: maximum possible) In the Sysadmin article, the biggest error was that the admin crudely tuned the FreeBSD and Linux boxes. He should have left both with out-of-the-box limits to be fair to NT and Solaris. It is absurd to suggest that he should have been hacking away at compile-time constants. Every OS had a default kernel. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Sysadmin article
On Sat, Jun 16, 2001 at 02:22:39AM +0300, Giorgos Keramidas wrote: Matt has explained this better than I could ever do, in his tuning(7) manpage -- a recent, but very valuable addition to our manpages. It, indeed, must be very recent: I have upgraded my system just last month, but I have no tuning man page. Where can I get it from? Adam -- Apply standard disk lamer To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Sysadmin article
On Fri, Jun 15, 2001 at 09:45:53PM -0500, G. Adam Stanislav wrote: On Sat, Jun 16, 2001 at 02:22:39AM +0300, Giorgos Keramidas wrote: Matt has explained this better than I could ever do, in his tuning(7) manpage -- a recent, but very valuable addition to our manpages. It, indeed, must be very recent: I have upgraded my system just last month, but I have no tuning man page. Where can I get it from? http://www.FreeBSD.org/cgi/cvsweb.cgi/src/share/man/man7/tuning.7?rev=1.2content-type=text/x-cvsweb-markup --clark To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Sysadmin article
On Thu, Jun 14, 2001 at 10:23:21PM -0400, Rajappa Iyer wrote: http://www.sysadminmag.com/articles/2001/0107/0107a/0107a.htm Any obvious reasons why FreeBSD performed so poorly for these people? Hrm... the filesystem test, I think, is fairly obvious. The default filesystem configuration doesn't have softupdates. Linux always outperforms FreeBSD on filesystem tests using out of the box configurations. The others I'm iffy on. There was still a file system element in the other tests as well (delivering e-mail) and depending on the way they layout their email the new dirpref code may help out a bit? -Steve rsi -- [EMAIL PROTECTED] a.k.a. Rajappa Iyer. They also surf who stand in the waves. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Sysadmin article
* Rajappa Iyer [EMAIL PROTECTED] [010614 22:23] wrote: http://www.sysadminmag.com/articles/2001/0107/0107a/0107a.htm Any obvious reasons why FreeBSD performed so poorly for these people? Because they did benchmarks on systems without tuning. A simple email to the lists asking for help would have probably done a world of difference. -- -Alfred Perlstein [[EMAIL PROTECTED]] Instead of asking why a piece of software is using 1970s technology, start asking why software is ignoring 30 years of accumulated wisdom. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Sysadmin article
On Fri, 15 Jun 2001, Alfred Perlstein wrote: * Rajappa Iyer [EMAIL PROTECTED] [010614 22:23] wrote: http://www.sysadminmag.com/articles/2001/0107/0107a/0107a.htm Any obvious reasons why FreeBSD performed so poorly for these people? Because they did benchmarks on systems without tuning. A simple email to the lists asking for help would have probably done a world of difference. There was some discussion of this on freebsd-advocacy yesterday and today, and it sounded like it came down to poor tuning (not enabling soft updates, et al) in combination with a heavy reliance on threading, where we currently don't do so well. A question I posed on -advocacy was when, if ever, we should consider simply enabling soft updates by default on non-root file systems. We claim that soft updates improves both performance and reliability (at the cost of increased kernel complexity), making it a prime candidate for the limelight. Would people be opposed to a change to sysinstall so that (once we're clear that soft updates has stabilized in -CURRENT) such that selecting the default partitioning enables soft updates on any file system not mounted as / unless specifically toggled off? How about other tuning: we've previously discussed increasing the default max socket buffer sizes, for example, to allow better tuning for faster network segments. The point has been made that on FreeBSD, we select somewhat conservative (safe) settings by default, and give admins the option to trade off safety and performance as they see fit. On the other hand, there may be further changes we can make that stay well within the realm of safe, yet improve default performance helping us out on Joe Blow's Untuned Performance Test (as you know, many performance tests in popular media don't involve consulting the authors of the code first for tuning help). Likewise, we've gradually been shifting in stance from a we want to run well on tiny systems to we recognize that memory is cheap, and performance is important, let the little guys do more tuning than the medium guys. Robert N M Watson FreeBSD Core Team, TrustedBSD Project [EMAIL PROTECTED] NAI Labs, Safeport Network Services To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Sysadmin article
On Thursday 14 June 2001 9:13, Alfred Perlstein wrote: * Rajappa Iyer [EMAIL PROTECTED] [010614 22:23] wrote: http://www.sysadminmag.com/articles/2001/0107/0107a/0107a.htm Any obvious reasons why FreeBSD performed so poorly for these people? Because they did benchmarks on systems without tuning. So why doesn't FreeBSD ship with a tuned configuration? Just curious... -- Regards, Devin. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Sysadmin article
On Thu, 14 Jun 2001, Devin Butterfield wrote: So why doesn't FreeBSD ship with a tuned configuration? Just curious... -- Regards, Devin. Why? Because you haven't sent in the changes which would implement it yet. :) Rather than a tuned configuration, what would be useful is a script that would evaluate a system and give tuning hints. This might be simple for someone familiar with shell scripting or perl. It could do something like: check if filesystems are mounted with softupdates You could increase filesystem performance greatly by enabling softupdates. See the tunefs manpage. check on max used mbufs Your system seems to be using a large number of mbufs; you should increase the maximum allowed. See the mbuf manpage. Are you using a UPS? Yes You may wish to enable ide write caching to increase performance. See the ata manpage for the tradeoffs involved. How many connections will this server experience at one time? 5000 MAXUSERS is set too low for 5000, please change to X and recompile How many connections per process? 2000 Maxfiles is too low, please change X to Y. The list could go on and on. While these are all sysctls and kernel options known all to well to some of us, they could take a long time to track down for people new to FreeBSD. Matt's performance manpage covers a lot of this, but is probably not as easy to digest as an interactive script. Anyone have some free time? :) Mike Silby Silbersack To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Sysadmin article
Mike Silbersack wrote: Matt's performance manpage covers a lot of this, but is probably not as easy to digest as an interactive script. What do I type to read this man page? -- Stephen Montgomery-Smith [EMAIL PROTECTED] http://www.math.missouri.edu/~stephen To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Sysadmin article
On 15 Jun 2001 at 00:38 (-0500), Stephen Montgomery-Smith wrote: | Mike Silbersack wrote: | | | Matt's performance manpage covers a lot of this, but is probably not as | easy to digest as an interactive script. | | | What do I type to read this man page? $ man tuning To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
