Re: FreeBSD MySQL still WAY slower than Linux
# [EMAIL PROTECTED] / 2005-06-21 16:51:10 +0200: For accurate measurements and comparisons, you have to make sure to use _exactly_ the same physical location on the disk. No you don't. You want to make a side-by-side comparison of two products, and if one of them underperforms, it just underperforms. You cannot use a poor location selection strategy in the driver as an excuse for poor operation. In all honesty, I'm getting somewhat irritated by all the dd is meaningless performance measurement tool, use something real and similar arguments: dd is a real command for real work, and if it shows abysmal performance of sequential writes, then there's a problem. But then again -- as others have already mentioned, serial write speed is not the most important factor for database performance (although the WAL journal files of advanced transactional databases like PostgreSQL are written in a sequential way), so the usefulness of this benchmark is very debatable. Well, how about a few GB large table physically ordered (clustered) on a column, that goes through repeated sequential scans? This *is* a real-world situation, and every bit of speed counts (the live server I'm talking about has the database on SCSI disks, but development machines frequently differ). -- How many Vietnam vets does it take to screw in a light bulb? You don't know, man. You don't KNOW. Cause you weren't THERE. http://bash.org/?255991 ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: FreeBSD MySQL still WAY slower than Linux
On Tue, 28 Jun 2005 18:51, Roman Neuhauser wrote: No you don't. You want to make a side-by-side comparison of two products, and if one of them underperforms, it just underperforms. You cannot use a poor location selection strategy in the driver as an excuse for poor operation. Why not? It's not a side-by-side comparison if the underlying hardware is different.. I don't think ascribing ALL the poor performance to being on the wrong part of the disk is putting your head in the sand, but it DOES make a difference. In all honesty, I'm getting somewhat irritated by all the dd is meaningless performance measurement tool, use something real and similar arguments: dd is a real command for real work, and if it shows abysmal performance of sequential writes, then there's a problem. dd is a useful start, but you shouldn't read too much into the results since, in general, dd doesn't reflect real world usage patterns. There are some people who seem to want to ignore the results and shoot them down with bland assertions about how poorly the tests have been run. There are also people doing crappy tests, however there IS a middle ground where I think most reasonable people are sitting - they want decent tests, and have a good attitude to fixing the problems. -- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au The nice thing about standards is that there are so many of them to choose from. -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C pgp44ZGHL3pRO.pgp Description: PGP signature
Re: FreeBSD MySQL still WAY slower than Linux
# [EMAIL PROTECTED] / 2005-06-28 19:04:18 +0930: On Tue, 28 Jun 2005 18:51, Roman Neuhauser wrote: No you don't. You want to make a side-by-side comparison of two products, and if one of them underperforms, it just underperforms. You cannot use a poor location selection strategy in the driver as an excuse for poor operation. dd is a useful start, but you shouldn't read too much into the results since, in general, dd doesn't reflect real world usage patterns. Huh? Various people have reacted to the dd doesn't reflect real world with but I *do* use dd in real world. -- How many Vietnam vets does it take to screw in a light bulb? You don't know, man. You don't KNOW. Cause you weren't THERE. http://bash.org/?255991 ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: FreeBSD MySQL still WAY slower than Linux
Roman Neuhauser wrote: In all honesty, I'm getting somewhat irritated by all the dd is meaningless performance measurement tool, use something real and similar arguments: dd is a real command for real work, and if it shows abysmal performance of sequential writes, then there's a problem. There _is_ something strange with dd as sequential block reads with bonnie (and vfs.read_max=16) is faster than reading direct from the device with dd! RAID0 7*36GB Maxtor 10K4, MegaRAID 320-2E default newfs ---Sequential Output ---Sequential Input-- -Per Char- --Block--- -Rewrite-- -Per Char- --Block--- 5.4 2048 106839 84.7 115268 32.1 30204 9.0 78264 80.2 136833 21.5 5.4v2048 105996 84.4 114560 32.2 29208 8.8 81671 84.7 227416 39.4 v = vfs.read_max=16 I don't have exact numbers at hand but dd if=/dev/amrd0 of=/dev/null bs=1024k count=1024 gave about ~120MB/s not anywhere near 227MB! /Martin ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: FreeBSD MySQL still WAY slower than Linux
On Tue, 28 Jun 2005 20:43, Roman Neuhauser wrote: # [EMAIL PROTECTED] / 2005-06-28 19:04:18 +0930: On Tue, 28 Jun 2005 18:51, Roman Neuhauser wrote: No you don't. You want to make a side-by-side comparison of two products, and if one of them underperforms, it just underperforms. You cannot use a poor location selection strategy in the driver as an excuse for poor operation. dd is a useful start, but you shouldn't read too much into the results since, in general, dd doesn't reflect real world usage patterns. Huh? Various people have reacted to the dd doesn't reflect real world with but I *do* use dd in real world. Read what I said.. ... IN GENERAL ... -- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au The nice thing about standards is that there are so many of them to choose from. -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C pgpNXPS8a6siL.pgp Description: PGP signature
Re: FreeBSD MySQL still WAY slower than Linux
Hi, i wouldn't start a principal discussion, but i have too? I have one Machine! and on this machine with identical Hardware, identical real! not same not side by side, real the same disk, processor, ram, board.. -- read my other postings, it's recommendet. on this machine i have made 4 installations on same disk, of 4 types/Versions of Os'es 1: RELENG_4 2: RELENG_5 3: Drangonfly_REL_1.2 4: GENTOO_2005_02 The disk was alway same partitioning: first 1G for Swap rest for system then i login in the system and made: # cd /; /usr/bin/time dd if=/dev/zero bs=1024 count=1024k of=zerofile; rm zerofile then i install the next system from a dump on same disk so that i can compare the time-consumption on these 4 systems. i think dd ist not the best for performace-tests or something else, but dd is a handy tool for quick test what's going on with your system write/read-speedness. so other people have suggested me that dd was not everytime writes to the same parts of diske, while the underlying fs-drivers made other steps on other systems ( and other fs-types) I would only compare the performace from 2 Versions of FreeBSD, while i mean that the performance from RELENG_5 is more slower than under GENTOO and it is double as slow as under RELENG_4. i would not test the performance of my system, i would only compare. best regards michael 2005/6/28, Daniel O'Connor [EMAIL PROTECTED]: On Tue, 28 Jun 2005 20:43, Roman Neuhauser wrote: # [EMAIL PROTECTED] / 2005-06-28 19:04:18 +0930: On Tue, 28 Jun 2005 18:51, Roman Neuhauser wrote: No you don't. You want to make a side-by-side comparison of two products, and if one of them underperforms, it just underperforms. You cannot use a poor location selection strategy in the driver as an excuse for poor operation. dd is a useful start, but you shouldn't read too much into the results since, in general, dd doesn't reflect real world usage patterns. Huh? Various people have reacted to the dd doesn't reflect real world with but I *do* use dd in real world. Read what I said.. ... IN GENERAL ... -- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au The nice thing about standards is that there are so many of them to choose from. -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: FreeBSD MySQL still WAY slower than Linux
Michael Schuh wrote: # cd /; /usr/bin/time dd if=/dev/zero bs=1024 count=1024k of=zerofile; I would only compare the performace from 2 Versions of FreeBSD, while i mean that the performance from RELENG_5 is more slower than under GENTOO and it is double as slow as under RELENG_4. Let me guess: Intel ICH5 or 6300ESB south bridge and ATA disk (Seagate Barracuda 7200.7)? There is something wrong in the RELENG_5 ATA driver that makes this combination perform really slow on writes (~16MB/s). When connecting a nearly identical SATA drive to the machine it performs as expected with ~55MB/s sequential writes. RELENG_4 performs as expected and I think ATA mkIII in CURRENT also works. /Martin ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: kpdf crashes with LIBPTHREAD_SYSTEM_SCOPE set (Was: Re: FreeBSD MySQL still WAY slower than Linux)
On Tuesday, 28. June 2005 06:43, Daniel Eischen wrote: I can't reproduce it in -current. -bash-2.05b$ uname -a FreeBSD orion 6.0-CURRENT FreeBSD 6.0-CURRENT #0: Thu May 5 13:29:41 EDT 2005 Yeah, you already said that before. So where do we go from here? Should I try to get a backtrace of the crash? With gdb? Ktrace? Should I compile libpthread of other parts of the system with special debug flags? Should I report this on freebsd-threads instead? Or should I just let the issue go? -- ,_, | Michael Nottebrock | [EMAIL PROTECTED] (/^ ^\) | FreeBSD - The Power to Serve | http://www.freebsd.org \u/ | K Desktop Environment on FreeBSD | http://freebsd.kde.org pgplrvZCQCI9J.pgp Description: PGP signature
Re: kpdf crashes with LIBPTHREAD_SYSTEM_SCOPE set (Was: Re: FreeBSD MySQL still WAY slower than Linux)
On Tue, 28 Jun 2005, Michael Nottebrock wrote: On Tuesday, 28. June 2005 06:43, Daniel Eischen wrote: I can't reproduce it in -current. -bash-2.05b$ uname -a FreeBSD orion 6.0-CURRENT FreeBSD 6.0-CURRENT #0: Thu May 5 13:29:41 EDT 2005 Yeah, you already said that before. So where do we go from here? Should I try to get a backtrace of the crash? With gdb? Ktrace? Should I compile libpthread of other parts of the system with special debug flags? Should I report this on freebsd-threads instead? Or should I just let the issue go? What CFLAGS did you use to build your ports/system? Run it under gdb and see what you get. -- DE ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: FreeBSD MySQL still WAY slower than Linux
On Tue, 2005-06-28 at 11:21 +0200, Roman Neuhauser wrote: # [EMAIL PROTECTED] / 2005-06-21 16:51:10 +0200: For accurate measurements and comparisons, you have to make sure to use _exactly_ the same physical location on the disk. No you don't. You want to make a side-by-side comparison of two products, and if one of them underperforms, it just underperforms. You cannot use a poor location selection strategy in the driver as an excuse for poor operation. The point people are making is that location can have a significant effect on performance, and so should not be dismissed out of hand. Here is what I get when I run diskinfo on one of the (somewhat elderly) disks I use in my desktop system (this is a drive I use for data, and it is idle): zappa# diskinfo -tv /dev/ad4 /dev/ad4 512 # sectorsize 25590620160 # mediasize in bytes (24G) 49981680# mediasize in sectors 49585 # Cylinders according to firmware. 16 # Heads according to firmware. 63 # Sectors according to firmware. Seek times: Full stroke: 250 iter in 5.159189 sec = 20.637 msec Half stroke: 250 iter in 4.206125 sec = 16.825 msec Quarter stroke: 500 iter in 7.151951 sec = 14.304 msec Short forward:400 iter in 2.794380 sec =6.986 msec Short backward: 400 iter in 4.135579 sec = 10.339 msec Seq outer: 2048 iter in 0.332711 sec =0.162 msec Seq inner: 2048 iter in 0.363152 sec =0.177 msec Transfer rates: outside: 102400 kbytes in 7.677977 sec =13337 kbytes/sec middle:102400 kbytes in 9.151475 sec =11189 kbytes/sec inside:102400 kbytes in 14.345492 sec = 7138 kbytes/sec Note how the transfer rate for the outside is almost twice that of the inside. Suppose I run tests on two different operating systems, one of which resides in a partition on the inside portion and the other in one on the outside portion. (Note that however good or bad it may be, the location selection strategy in the driver can only lay out data within the confines of the partition.) Now, I do a dd test and find that the outside OS is almost twice as fast as the other. Would it be wise to conclude that the slower OS is woefully inefficient compared to the faster one? Suppose both tests turn out to take roughly the same time. Should I conclude that the OS residing on the inside is just as efficient as the other OS? Cheers, Paul. -- e-mail: [EMAIL PROTECTED] Without music to decorate it, time is just a bunch of boring production deadlines or dates by which bills must be paid. --- Frank Vincent Zappa ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: FreeBSD MySQL still WAY slower than Linux
Yes, i know that and i agree with them. that was the reason, why my disk is tiled on first physical Gigabyte for Swap, and the rest for the system my target was to compare 2 Versions not 2 Os-Types like FreeBSD and Linux, but FreeBSD and FreeBSD, in cases RELENG_4 with RELENG_5. so that the little difference between the different places for files, remember i install everytime at the beginning of second Gig on disk, should be flawlessy and not make the results so big, that the RELENG_4 has the double of speed from RELENG_5! best regards michael 2005/6/28, Paul Mather [EMAIL PROTECTED]: On Tue, 2005-06-28 at 11:21 +0200, Roman Neuhauser wrote: # [EMAIL PROTECTED] / 2005-06-21 16:51:10 +0200: For accurate measurements and comparisons, you have to make sure to use _exactly_ the same physical location on the disk. No you don't. You want to make a side-by-side comparison of two products, and if one of them underperforms, it just underperforms. You cannot use a poor location selection strategy in the driver as an excuse for poor operation. The point people are making is that location can have a significant effect on performance, and so should not be dismissed out of hand. Here is what I get when I run diskinfo on one of the (somewhat elderly) disks I use in my desktop system (this is a drive I use for data, and it is idle): zappa# diskinfo -tv /dev/ad4 /dev/ad4 512 # sectorsize 25590620160 # mediasize in bytes (24G) 49981680# mediasize in sectors 49585 # Cylinders according to firmware. 16 # Heads according to firmware. 63 # Sectors according to firmware. Seek times: Full stroke: 250 iter in 5.159189 sec = 20.637 msec Half stroke: 250 iter in 4.206125 sec = 16.825 msec Quarter stroke: 500 iter in 7.151951 sec = 14.304 msec Short forward:400 iter in 2.794380 sec =6.986 msec Short backward: 400 iter in 4.135579 sec = 10.339 msec Seq outer: 2048 iter in 0.332711 sec =0.162 msec Seq inner: 2048 iter in 0.363152 sec =0.177 msec Transfer rates: outside: 102400 kbytes in 7.677977 sec =13337 kbytes/sec middle:102400 kbytes in 9.151475 sec =11189 kbytes/sec inside:102400 kbytes in 14.345492 sec = 7138 kbytes/sec Note how the transfer rate for the outside is almost twice that of the inside. Suppose I run tests on two different operating systems, one of which resides in a partition on the inside portion and the other in one on the outside portion. (Note that however good or bad it may be, the location selection strategy in the driver can only lay out data within the confines of the partition.) Now, I do a dd test and find that the outside OS is almost twice as fast as the other. Would it be wise to conclude that the slower OS is woefully inefficient compared to the faster one? Suppose both tests turn out to take roughly the same time. Should I conclude that the OS residing on the inside is just as efficient as the other OS? Cheers, Paul. -- e-mail: [EMAIL PROTECTED] Without music to decorate it, time is just a bunch of boring production deadlines or dates by which bills must be paid. --- Frank Vincent Zappa ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: FreeBSD MySQL still WAY slower than Linux
# [EMAIL PROTECTED] / 2005-06-28 11:38:44 -0400: Note how the transfer rate for the outside is almost twice that of the inside. Suppose I run tests on two different operating systems, one of which resides in a partition on the inside portion and the other in one on the outside portion. Which is not the case according to the OP... (Note that however good or bad it may be, the location selection strategy in the driver can only lay out data within the confines of the partition.) Now, I do a dd test and find that the outside OS is almost twice as fast as the other. Would it be wise to conclude that the slower OS is woefully inefficient compared to the faster one? Suppose both tests turn out to take roughly the same time. Should I conclude that the OS residing on the inside is just as efficient as the other OS? ... rendering this completely irrelevant. I have seen people come to a freebsd list with completely flawed comparisons or benchmarks: OSs installed on different partitions side by side, not taking VM cache into account, whatever, and be told that their numbers are flawed. I have also seen people test a specific subsystem (dd), and be told that their numbers don't reflect real world. And I have seen people test real world performance (install FreeBSD, install MySQL, run a stress test, reformat, install Linux, install MySQL, run a stress test) and get responses that try to make up reasons why the bad results are the testers fault). Heck, if installing an operating system, a database, and running it isn't a real world test, I don't know what is. Even if the bug is FreeBSD puts /var/db/mysql in the wrong part of the disk (then it's still a problem in FreeBSD, not in the messenger). I just wish people here were less defensive, that's all. -- How many Vietnam vets does it take to screw in a light bulb? You don't know, man. You don't KNOW. Cause you weren't THERE. http://bash.org/?255991 ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: FreeBSD MySQL still WAY slower than Linux
# [EMAIL PROTECTED] / 2005-06-28 18:29:59 +0200: 2005/6/28, Paul Mather [EMAIL PROTECTED]: On Tue, 2005-06-28 at 11:21 +0200, Roman Neuhauser wrote: # [EMAIL PROTECTED] / 2005-06-21 16:51:10 +0200: For accurate measurements and comparisons, you have to make sure to use _exactly_ the same physical location on the disk. No you don't. You want to make a side-by-side comparison of two products, and if one of them underperforms, it just underperforms. You cannot use a poor location selection strategy in the driver as an excuse for poor operation. The point people are making is that location can have a significant effect on performance, and so should not be dismissed out of hand. Yes, i know that and i agree with them. that was the reason, why my disk is tiled on first physical Gigabyte for Swap, and the rest for the system my target was to compare 2 Versions not 2 Os-Types like FreeBSD and Linux, but FreeBSD and FreeBSD, in cases RELENG_4 with RELENG_5. so that the little difference between the different places for files, remember i install everytime at the beginning of second Gig on disk, should be flawlessy and not make the results so big, that the RELENG_4 has the double of speed from RELENG_5! I can feel your pain. -- How many Vietnam vets does it take to screw in a light bulb? You don't know, man. You don't KNOW. Cause you weren't THERE. http://bash.org/?255991 ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: FreeBSD MySQL still WAY slower than Linux
On Tue, 2005-06-28 at 18:39 +0200, Roman Neuhauser wrote: # [EMAIL PROTECTED] / 2005-06-28 11:38:44 -0400: Note how the transfer rate for the outside is almost twice that of the inside. Suppose I run tests on two different operating systems, one of which resides in a partition on the inside portion and the other in one on the outside portion. Which is not the case according to the OP... (Note that however good or bad it may be, the location selection strategy in the driver can only lay out data within the confines of the partition.) Now, I do a dd test and find that the outside OS is almost twice as fast as the other. Would it be wise to conclude that the slower OS is woefully inefficient compared to the faster one? Suppose both tests turn out to take roughly the same time. Should I conclude that the OS residing on the inside is just as efficient as the other OS? ... rendering this completely irrelevant. ...especially when you've cut out the context of my reply. :-) My apologies if it wasn't clear, but I was responding to your apparent assertion that location does not matter in disk performance benchmarks. If I had been responding to a specific aspect of the OP's benchmark (or indeed anything the OP has said), I'm sure I would have quoted that to make the context clear. I have seen people come to a freebsd list with completely flawed comparisons or benchmarks: OSs installed on different partitions side by side, not taking VM cache into account, whatever, and be told that their numbers are flawed. I have also seen people test a specific subsystem (dd), and be told that their numbers don't reflect real world. And I have seen people test real world performance (install FreeBSD, install MySQL, run a stress test, reformat, install Linux, install MySQL, run a stress test) and get responses that try to make up reasons why the bad results are the testers fault). Heck, if installing an operating system, a database, and running it isn't a real world test, I don't know what is. Even if the bug is FreeBSD puts /var/db/mysql in the wrong part of the disk (then it's still a problem in FreeBSD, not in the messenger). I just wish people here were less defensive, that's all. What you see as being defensive I see as being rigorous. If someone is making a claim based upon a performance benchmark, people will quiz the person conducting the benchmark to ascertain exactly how it has been undertaken. To put any stock in a benchmark result, it is important to be able to convince yourself it is a meaningful result. Well, at least most people I've encountered believe that to be the case. As it says in the BUGS section of the diskinfo man page: There are in order of increasing severity: lies, damn lies, statistics, and computer benchmarks. ;-) Cheers, Paul. -- e-mail: [EMAIL PROTECTED] Without music to decorate it, time is just a bunch of boring production deadlines or dates by which bills must be paid. --- Frank Vincent Zappa ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: FreeBSD MySQL still WAY slower than Linux
(Note that however good or bad it may be, the location selection strategy in the driver can only lay out data within the confines of the partition.) Now, I do a dd test and find that the outside OS is almost twice as fast as the other. Would it be wise to conclude that the slower OS is woefully inefficient compared to the faster one? Suppose both tests turn out to take roughly the same time. Should I conclude that the OS residing on the inside is just as efficient as the other OS? ... rendering this completely irrelevant. I have seen people come to a freebsd list with completely flawed comparisons or benchmarks: OSs installed on different partitions side by side, not taking VM cache into account, whatever, and be told that their numbers are flawed. I have also seen people test a specific subsystem (dd), and be told that their numbers don't reflect real world. And I have seen people test real world performance (install FreeBSD, install MySQL, run a stress test, reformat, install Linux, install MySQL, run a stress test) and get responses that try to make up reasons why the bad results are the testers fault). Heck, if installing an operating system, a database, and running it isn't a real world test, I don't know what is. Even if the bug is FreeBSD puts /var/db/mysql in the wrong part of the disk (then it's still a problem in FreeBSD, not in the messenger). When one does the dd-test (on identical hardware), one should think that half the time FreeBSD would have the highest throughput, and the rest of the time Linux will, if the location of the partition that the test is performed on, is indeed located at a random location which should be the case when the test is performed often enough. When several people does this test and draws the conclusion that Linux (and FreeBSD 4.11) does this faster than 5.4/6, either only those who see this pattern post their numbers to this list, or Linux (and 4.11 to some degree) is indeed faster at this particular operation. And the test itself doesn't tell the complete story, but it does give an indication of what lies ahead. Arguing that the placement of the partion where the test is performed on is relevant, but then sometimes FreeBSD 5/6 should be faster. regards Claus ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: FreeBSD MySQL still WAY slower than Linux
# [EMAIL PROTECTED] / 2005-06-28 13:03:04 -0400: On Tue, 2005-06-28 at 18:39 +0200, Roman Neuhauser wrote: My apologies if it wasn't clear, but I was responding to your apparent assertion that location does not matter in disk performance benchmarks. We seem to have a misunderstaning, I didn't mean anything like that. I just wish people here were less defensive, that's all. What you see as being defensive I see as being rigorous. If someone is making a claim based upon a performance benchmark, people will quiz the person conducting the benchmark to ascertain exactly how it has been undertaken. To put any stock in a benchmark result, it is important to be able to convince yourself it is a meaningful result. Well, at least most people I've encountered believe that to be the case. Say I install FreeBSD (using default partitions), install MySQL from a package on the CD, run a stress test, collect numbers, then repeat the process with a Linux installed over the previous FreeBSD installation, and find out that FreeBSD allows the MySQL server process 1/3 queries less, what (if anything) will be wrong in my claim that MySQL/FreeBSD is slower than MySQL/Linux? -- How many Vietnam vets does it take to screw in a light bulb? You don't know, man. You don't KNOW. Cause you weren't THERE. http://bash.org/?255991 ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: FreeBSD MySQL still WAY slower than Linux
On Tue, 2005-06-28 at 19:17 +0200, Roman Neuhauser wrote: # [EMAIL PROTECTED] / 2005-06-28 13:03:04 -0400: What you see as being defensive I see as being rigorous. If someone is making a claim based upon a performance benchmark, people will quiz the person conducting the benchmark to ascertain exactly how it has been undertaken. To put any stock in a benchmark result, it is important to be able to convince yourself it is a meaningful result. Well, at least most people I've encountered believe that to be the case. Say I install FreeBSD (using default partitions), install MySQL from a package on the CD, run a stress test, collect numbers, then repeat the process with a Linux installed over the previous FreeBSD installation, and find out that FreeBSD allows the MySQL server process 1/3 queries less, what (if anything) will be wrong in my claim that MySQL/FreeBSD is slower than MySQL/Linux? To make the specific claim above, it would be okay, at least in my book. To make a more general claim, pedantically speaking, you should, e.g., replicate your benchmark using various different hardware combinations, to rule out the possibility of a pathological case affecting one or other OS (e.g., where one OS has much better driver support for some specific hardware aspect than the other). Also, you would need to be careful how you stated your claim. For example, it would be better to say something like untuned MySQL/Particular-FreeBSD-Version on a default install is slower than untuned MySQL/Particular-Linux-Distribution on a default install. If you test many Linux distributions and find they beat out all the FreeBSDs, then a more general MySQL/FreeBSD and MySQL/Linux might be appropriate. Similarly, if no amount of tuning lets FreeBSD MySQL compete with Linux, I'd say your original statement would be defensible. However, if some combinations of MySQL and FreeBSD tuning perform better than some well-tuned MySQL/Linux distributions, then it's not so straightforward to claim MySQL/FreeBSD is slower than MySQL/Linux. (It may be that default tunings favour one or the other. I'm sure the Linux people would gripe that you're using filesystem X instead of filesystem Y, which would give better performance.:) If you just want to make a benchmark statement about untuned installs on default distributions, that's fine, but I'm not sure how illuminating that is for the real world given that production systems are normally tuned for performance. Although this might seem like splitting hairs to the extreme, I guess the point I'm making is that benchmarks can be highly subjective. Unless you learn the context and point of view in which it was performed, you can't really tell if the results apply to you. In fact, even a very good benchmark may not yield the expected performance in the real world when run in an environment containing other systems (e.g., Apache, Squid, Postfix, etc.) that interact and contend for resources and affect performance in a way not measured when the systems are benchmarked in isolation. I guess the preferred colour for the consumers of benchmarks is black and white, when in reality what you get are subtle shades of grey. :-) Cheers, Paul. -- e-mail: [EMAIL PROTECTED] Without music to decorate it, time is just a bunch of boring production deadlines or dates by which bills must be paid. --- Frank Vincent Zappa ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: FreeBSD MySQL still WAY slower than Linux
On Tue, Jun 28, 2005 at 07:17:39PM +0200, Roman Neuhauser wrote: # [EMAIL PROTECTED] / 2005-06-28 13:03:04 -0400: On Tue, 2005-06-28 at 18:39 +0200, Roman Neuhauser wrote: My apologies if it wasn't clear, but I was responding to your apparent assertion that location does not matter in disk performance benchmarks. We seem to have a misunderstaning, I didn't mean anything like that. I just wish people here were less defensive, that's all. What you see as being defensive I see as being rigorous. If someone is making a claim based upon a performance benchmark, people will quiz the person conducting the benchmark to ascertain exactly how it has been undertaken. To put any stock in a benchmark result, it is important to be able to convince yourself it is a meaningful result. Well, at least most people I've encountered believe that to be the case. Say I install FreeBSD (using default partitions), install MySQL from a package on the CD, run a stress test, collect numbers, then repeat the process with a Linux installed over the previous FreeBSD installation, and find out that FreeBSD allows the MySQL server process 1/3 queries less, what (if anything) will be wrong in my claim that MySQL/FreeBSD is slower than MySQL/Linux? We care about why MySQL appears to be slower, how to improve the situation, and not numbers from poorly done benchmarks which ignored the effect of debugging options, version, disk mount options, etc., which is IMHO meaningless. Maybe a key feature of the new FreeBSD installer would be to automatically tune the user's system (including kernel and other loader/sysctl tunings) according to installed ports :-) To make benchmarks a help provided to improve FreeBSD, a better start would be to run MySQL with profiling options compiled in, to find out the bottleneck and report them (maybe with patches if you have some idea). Cheers, -- Xin LI delphij frontfree net http://www.delphij.net/ See complete headers for GPG key and other information. pgpYEsqFi8zEQ.pgp Description: PGP signature
Re: FreeBSD MySQL still WAY slower than Linux
On 28-Jun-05, at 1:01 PM, Xin LI wrote: We care about why MySQL appears to be slower, how to improve the situation, and not numbers from poorly done benchmarks which ignored the effect of debugging options, version, disk mount options, etc., which is IMHO meaningless. Maybe a key feature of the new FreeBSD installer would be to automatically tune the user's system (including kernel and other loader/sysctl tunings) according to installed ports :-) To make benchmarks a help provided to improve FreeBSD, a better start would be to run MySQL with profiling options compiled in, to find out the bottleneck and report them (maybe with patches if you have some idea). Cheers, -- Xin LI delphij frontfree nethttp://www.delphij.net/ See complete headers for GPG key and other information. I'm by far not a developer or a programmer, but I am a sysadmin running MySQL on FreeBSD 4.x and 5.x And I am having performance problems running FreeBSD 5.4 + SMP with MySQL. I don't seem to have these problems on my other 4.x servers. The Hardware: Dell PowerEdge 2850 Dual 2.8 XEON 4Gig of RAM Raid controller PERC 4/DC 2x 36Gig 10K drives running Raid 1 for the system 4x72Gig 15K drives running raid 0+1 for where to put my mysql innodb based database. The database is about 10Gigs in size all InnoDB tables. This box is currently setup to slave from the master. My goal is to get the box to replace the master. Currently it is not used in production, so I am free to do what I want to this box. I'm running MySQL 4.1.12 I noticed a couple things PAE kernel (no SMP) System crashed while simply slaving from the master. The system seemed stable doing nothing for 36 hours prior to this. SMP Kernel System was stable, however slaving from the master seemed to me VERY slow. GENERIC Kernel System was stable, and slaving was quite a bit faster. My Goal, is to provide some information that the real miracle workers, the programmers and developers that can contribute to FreeBSD help me identify the problems and where they lie and how to best go about finding solutions for these problems. So my question is. What kind of information can I provide you all to help identify the problems that I'm seeing, and quite possibly others are seeing. Xin, you are talking about something regarding profiling of mysql. If you can point me in the right direction to setup my box to provide the necessary information, I have the time and the will to provide the right information so we can move forward in making FreeBSD the Operating System we all want it to be. I also promise to post some usable information for other people wanting to setup MySQL on FreeBSD once we have identified where are problems lie. This is probably the best way I, myself can contribute back to the FreeBSD Community. Thank you, Stephane. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: FreeBSD MySQL still WAY slower than Linux
Having just read this thread, I'd like to say that all messages are making valid points, and all participants agree with each other. However, the argumentative discussion is creating a lot of noise. Meanwhile, there are people doing meaningful work on this. A good standby would be to patch your 5.4 with ATAMKIII. As a CURRENT user, i'd like to state that this code is very stable, although I havn't done benchmarks, valid or otherwise. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: FreeBSD MySQL still WAY slower than Linux
I also quickly put a wiki together to help me document any kind of testing or patching we can try. Feel free to contribute. My hope is we can refer others to this document, and not create too much noise on this list as others have suggested is being created (the noise that is). I hope this can help us out to get MySQL humming on -STABLE, if it isn't already. Thanks, Stephane On 28-Jun-05, at 5:08 PM, Stephane Raimbault wrote: On 28-Jun-05, at 1:01 PM, Xin LI wrote: We care about why MySQL appears to be slower, how to improve the situation, and not numbers from poorly done benchmarks which ignored the effect of debugging options, version, disk mount options, etc., which is IMHO meaningless. Maybe a key feature of the new FreeBSD installer would be to automatically tune the user's system (including kernel and other loader/sysctl tunings) according to installed ports :-) To make benchmarks a help provided to improve FreeBSD, a better start would be to run MySQL with profiling options compiled in, to find out the bottleneck and report them (maybe with patches if you have some idea). Cheers, -- Xin LI delphij frontfree nethttp://www.delphij.net/ See complete headers for GPG key and other information. I'm by far not a developer or a programmer, but I am a sysadmin running MySQL on FreeBSD 4.x and 5.x And I am having performance problems running FreeBSD 5.4 + SMP with MySQL. I don't seem to have these problems on my other 4.x servers. The Hardware: Dell PowerEdge 2850 Dual 2.8 XEON 4Gig of RAM Raid controller PERC 4/DC 2x 36Gig 10K drives running Raid 1 for the system 4x72Gig 15K drives running raid 0+1 for where to put my mysql innodb based database. The database is about 10Gigs in size all InnoDB tables. This box is currently setup to slave from the master. My goal is to get the box to replace the master. Currently it is not used in production, so I am free to do what I want to this box. I'm running MySQL 4.1.12 I noticed a couple things PAE kernel (no SMP) System crashed while simply slaving from the master. The system seemed stable doing nothing for 36 hours prior to this. SMP Kernel System was stable, however slaving from the master seemed to me VERY slow. GENERIC Kernel System was stable, and slaving was quite a bit faster. My Goal, is to provide some information that the real miracle workers, the programmers and developers that can contribute to FreeBSD help me identify the problems and where they lie and how to best go about finding solutions for these problems. So my question is. What kind of information can I provide you all to help identify the problems that I'm seeing, and quite possibly others are seeing. Xin, you are talking about something regarding profiling of mysql. If you can point me in the right direction to setup my box to provide the necessary information, I have the time and the will to provide the right information so we can move forward in making FreeBSD the Operating System we all want it to be. I also promise to post some usable information for other people wanting to setup MySQL on FreeBSD once we have identified where are problems lie. This is probably the best way I, myself can contribute back to the FreeBSD Community. Thank you, Stephane. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable- [EMAIL PROTECTED] ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: FreeBSD MySQL still WAY slower than Linux
speaking of noise how about I include a URL http://www.segr.ca/index.php/FreeBSD/MySQL sheesh... sorry to all. Stephane On 28-Jun-05, at 8:55 PM, Stephane Raimbault wrote: I also quickly put a wiki together to help me document any kind of testing or patching we can try. Feel free to contribute. My hope is we can refer others to this document, and not create too much noise on this list as others have suggested is being created (the noise that is). I hope this can help us out to get MySQL humming on -STABLE, if it isn't already. Thanks, Stephane On 28-Jun-05, at 5:08 PM, Stephane Raimbault wrote: On 28-Jun-05, at 1:01 PM, Xin LI wrote: We care about why MySQL appears to be slower, how to improve the situation, and not numbers from poorly done benchmarks which ignored the effect of debugging options, version, disk mount options, etc., which is IMHO meaningless. Maybe a key feature of the new FreeBSD installer would be to automatically tune the user's system (including kernel and other loader/sysctl tunings) according to installed ports :-) To make benchmarks a help provided to improve FreeBSD, a better start would be to run MySQL with profiling options compiled in, to find out the bottleneck and report them (maybe with patches if you have some idea). Cheers, -- Xin LI delphij frontfree nethttp://www.delphij.net/ See complete headers for GPG key and other information. I'm by far not a developer or a programmer, but I am a sysadmin running MySQL on FreeBSD 4.x and 5.x And I am having performance problems running FreeBSD 5.4 + SMP with MySQL. I don't seem to have these problems on my other 4.x servers. The Hardware: Dell PowerEdge 2850 Dual 2.8 XEON 4Gig of RAM Raid controller PERC 4/DC 2x 36Gig 10K drives running Raid 1 for the system 4x72Gig 15K drives running raid 0+1 for where to put my mysql innodb based database. The database is about 10Gigs in size all InnoDB tables. This box is currently setup to slave from the master. My goal is to get the box to replace the master. Currently it is not used in production, so I am free to do what I want to this box. I'm running MySQL 4.1.12 I noticed a couple things PAE kernel (no SMP) System crashed while simply slaving from the master. The system seemed stable doing nothing for 36 hours prior to this. SMP Kernel System was stable, however slaving from the master seemed to me VERY slow. GENERIC Kernel System was stable, and slaving was quite a bit faster. My Goal, is to provide some information that the real miracle workers, the programmers and developers that can contribute to FreeBSD help me identify the problems and where they lie and how to best go about finding solutions for these problems. So my question is. What kind of information can I provide you all to help identify the problems that I'm seeing, and quite possibly others are seeing. Xin, you are talking about something regarding profiling of mysql. If you can point me in the right direction to setup my box to provide the necessary information, I have the time and the will to provide the right information so we can move forward in making FreeBSD the Operating System we all want it to be. I also promise to post some usable information for other people wanting to setup MySQL on FreeBSD once we have identified where are problems lie. This is probably the best way I, myself can contribute back to the FreeBSD Community. Thank you, Stephane. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable- [EMAIL PROTECTED] ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable- [EMAIL PROTECTED] ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: kpdf crashes with LIBPTHREAD_SYSTEM_SCOPE set (Was: Re: FreeBSD MySQL still WAY slower than Linux)
On Monday, 20. June 2005 19:17, Daniel Eischen wrote: Works here on a month or two old -current. I'm using /usr/local/ant/docs/appendix_e.pdf as a test (it's 60 pages or so). Crashes for me: [EMAIL PROTECTED]:127:~ env LIBPTHREAD_SYSTEM_SCOPE=1 kpdf 'http://drtc.isibang.ac.in/%7Eprachi/apache-ant-1.5.4/docs/appendix_e.pdf ' Bus error [EMAIL PROTECTED]:1:~ kpdf 'http://drtc.isibang.ac.in/%7Eprachi/apache-ant-1.5.4/docs/appendix_e.pdf ' [EMAIL PROTECTED]:0:~ I don't have a -CURRENT machine to test. Try -stable. I just retried with today's 5.4-STABLE - still crashes. -- ,_, | Michael Nottebrock | [EMAIL PROTECTED] (/^ ^\) | FreeBSD - The Power to Serve | http://www.freebsd.org \u/ | K Desktop Environment on FreeBSD | http://freebsd.kde.org pgp2LUSMeYtz6.pgp Description: PGP signature
Re: FreeBSD MySQL still WAY slower than Linux
Steve Roome wrote: I posted these results and anything else that went with this thread to the freebsd-performance mailing list. -current proved a slightly better performer for us, but not enough to bring it even close to the performance we get with gentoo. Off the top of my head the select key benchmarks were ROUGHLY: FreeBSD 5.various + MySQL 4.various: ROUGHLY 16k queries/second FreeBSD 6.0-current + MySQL 4.1.12 : ROUGHLY 18k queries/second Gentoo-something + MySQL 4.1.something : ROUGHLY 30k queries/second. The exact figures were posted to performance- (6.0 tests) and stable- (gentoo vs. freebsd 5.x). Good luck to anyone who can manage to get MySQL to perform as well on FreeBSD as Linux, we've been right out of luck so far and that's really not advocating FreeBSD very well, which is what I'd rather be doing. I missed the mail where you mentioned this (apologies), thanks for updating us, well - me anyway :-) Hmmm - the results are a bit discouraging aren't they? I notice that (you mentioned) the Mysql guys were going to see if they can identify where the issue is. That would be good! best wishes Mark ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: kpdf crashes with LIBPTHREAD_SYSTEM_SCOPE set (Was: Re: FreeBSD MySQL still WAY slower than Linux)
On Mon, 27 Jun 2005, Michael Nottebrock wrote: On Monday, 20. June 2005 19:17, Daniel Eischen wrote: Works here on a month or two old -current. ?I'm using /usr/local/ant/docs/appendix_e.pdf as a test (it's 60 pages or so). Crashes for me: [EMAIL PROTECTED]:127:~ env LIBPTHREAD_SYSTEM_SCOPE=1 kpdf 'http://drtc.isibang.ac.in/%7Eprachi/apache-ant-1.5.4/docs/appendix_e.pdf ' Bus error [EMAIL PROTECTED]:1:~ kpdf 'http://drtc.isibang.ac.in/%7Eprachi/apache-ant-1.5.4/docs/appendix_e.pdf ' [EMAIL PROTECTED]:0:~ I don't have a -CURRENT machine to test. Try -stable. I just retried with today's 5.4-STABLE - still crashes. I can't reproduce it in -current. -bash-2.05b$ uname -a FreeBSD orion 6.0-CURRENT FreeBSD 6.0-CURRENT #0: Thu May 5 13:29:41 EDT 2005 -- DE ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: FreeBSD MySQL still WAY slower than Linux
Michael Schuh [EMAIL PROTECTED] wrote: now i have another question, if i use the same Os in 2 versions (RELENG_4, RELENG_5) can i hope that the tests are made on the same part of disk? yoda Hope you always can. But rely on it you should not. /yoda ;-) or in other words can an dd on the two OS' es so much different because they use an totally other part of disk? I think no, the strategie from dd under one OS should not be changed if the OS-Version has changed. It's not the dd which decides where to put the file, it's the filesystem code. And yes, there can be differences between RELENG_4 and RELENG_5. In particular, in RELENG_5 you have UFS2, not the old UFS. There have always been changes to the FS code, for example I remember that the allocation of directories has changed some time ago to improve metadata performance for large trees (known as dirpref). As I said: The only way to make sure you hit the same physical place on the disk is to use a raw partition, not a file on some filesystem. Note that even small differences in the placement of the file can have a noticeable effect on the speed. Apart from the speed differences of the disk cylinders, it can also happen that the file is allocated in a non-contiguous way, especially if it is large and the filesystem already contains a lot of files, and/or had a lot of write+delete operations previously (i.e. causing fragmentation). the part with serial IO related to database-performance have i understand, but i quests me have the others understand my meanings? That I don't know. Best regards Oliver -- Oliver Fromme, secnetix GmbH Co KG, Oettingenstr. 2, 80538 München Any opinions expressed in this message may be personal to the author and may not necessarily reflect the opinions of secnetix in any way. anyone new to programming should be kept as far from C++ as possible; actually showing the stuff should be considered a criminal offence -- Jacek Generowicz ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: FreeBSD MySQL still WAY slower than Linux
Hi Oliver, 2005/6/22, Oliver Fromme [EMAIL PROTECTED]: Michael Schuh [EMAIL PROTECTED] wrote: now i have another question, if i use the same Os in 2 versions (RELENG_4, RELENG_5) can i hope that the tests are made on the same part of disk? yoda Hope you always can. But rely on it you should not. /yoda ;-) That's right. :-D or in other words can an dd on the two OS' es so much different because they use an totally other part of disk? I think no, the strategie from dd under one OS should not be changed if the OS-Version has changed. It's not the dd which decides where to put the file, it's the filesystem code. And yes, there can be differences between RELENG_4 and RELENG_5. In particular, in RELENG_5 you have UFS2, not the old UFS. There have always been changes to the FS code, for example I remember that the allocation of directories has changed some time ago to improve metadata performance for large trees (known as dirpref). As I said: The only way to make sure you hit the same physical place on the disk is to use a raw partition, not a file on some filesystem. Yes i have that understand. And that was the reason why i make in future these tests new with an raw-partition on the same part of disk. so that i never must hope, so i become knowledge and i know the facts :-D Note that even small differences in the placement of the file can have a noticeable effect on the speed. Apart from the speed differences of the disk cylinders, it can also happen that the file is allocated in a non-contiguous way, especially if it is large and the filesystem already contains a lot of files, and/or had a lot of write+delete operations previously (i.e. causing fragmentation). yes this is also clear for me, but in my case, it was only a small disk (8GB) and it has only the OS, nothing more, nothing less. And as i made these tests, i have all the performance for me and my OS. *gr* i be the master of disaster.. *lol* We should have all more humor...the life it's more funny.. the part with serial IO related to database-performance have i understand, but i quests me have the others understand my meanings? i must hope so :-D, i can not sure That I don't know. Best regards Oliver -- Oliver Fromme, secnetix GmbH Co KG, Oettingenstr. 2, 80538 München Any opinions expressed in this message may be personal to the author and may not necessarily reflect the opinions of secnetix in any way. anyone new to programming should be kept as far from C++ as possible; actually showing the stuff should be considered a criminal offence -- Jacek Generowicz thank you for your suggestions best regards Michael Schuh ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: FreeBSD MySQL still WAY slower than Linux
hello, first sorry for my bad english, with noop i mean no operation. i can live with a better performance from postgresql under RELENG_5 :-D i find it great. As i sayed i have the installations always made in the same way, so that i mean. I mean i have alwas made the swap on the first gig of the disk, and the installation on the rest of the disk. and i have no multiple os'es on these disk. I know that other diskpart's have other performance.. :-D i mean i have really strictly regarded where my os'es are installed for these tests. what i not can ensure, is that the Gentoo uses the same parts for the programs, relying of the implemantation from ext2fs/ext3fs than BSD under UFS. But i think really that are enough reasons to say this test speaking a real language, and gave me not bad results. I be not a noob or an newby, so that i know that the io performance of a disk is related to the sectors that i use for regarding this performance. :-D i have made the test always on the same hardware, not compatible or equal, really the same, same disk, same processor, same board, same ram, same ethernet-card, all same i would not say look for a faster io-performance, that is not the only factor for database performance, but what is when your disk-access uses the double of time as before? then can you not say ohhh my problem is not related to disk-io ;-) i would not say that the io of disk ist the only important factor, but it is in fact an important factor. make a simple test: install a database-intensive application on an PII400 with DDRS-4,3GB SCSI-disk and make 500.000 inserts in an postgresql and an mysql database. so you can see that it uses many many time, change the disk to an ATA66 disk with good performance (better then the DDRS or DCAS) and then you see, that the disk-prformance is an important fact. i would you only make sensible for the view that you cannot only digging at the ipc-performance or the threading. I know that are also important factors, but what is if the base of all of these factors are lame? then you are lying on an mixed error behaviour that are not really representative. you search the error in first time on the wrong place. i think first view the diskperformance in versus of the Os'es and the versions, then digging deeper and search the oil in threading.:-)) i woul not start a principle discussion, that is not my target, my target is an really performant OS, that go's he's way forward and not backward's. I have seen that the disk-performance (ata-related) is much slower in RELENG_5 than in RELENG_4, and this is a step backwards to me, if its so much slower. about five or ten percent is not really bad an can comes from an other scheduling, as you can see in dragonfly, but halv as good as before ist for me not acceptable for production uses. best regards michael 2005/6/21, Mark Kirkwood [EMAIL PROTECTED]: Michael Schuh wrote: Hello, yes random IO is more targetted to Databases. noop, i have the installation always made in the same way, and i have respected the different diskperformace in different disk-parts. this was the reason for #cd /; at the beginning of my tests. In the first test i have me shooting self in my foot and i bites me in my ass :-))) I was referring to the partitions and slices on the physical disk - each operating system is installed in a different one of these, and so is in a different physical part of the disk - hence you cannot reliably compare IO rates between them (This very issue has been discussed before I recall - try a Google search, as it is quite interesting). my suggestion going more in the direction...first solve all disk(ata) related performace issues, then test the mysql-performaces issues again to secure that you are not lying on an mixing of many problems :-) While noone would complain about faster sequential IO, it is almost certainly not the issue effecting database performance - for instance I find Postgresql consistently faster on RELENG_5 (5.3 onwards) than on RELENG_4 (using the pgbench program). cheers Mark ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: FreeBSD MySQL still WAY slower than Linux
Michael Schuh [EMAIL PROTECTED] wrote: As i sayed i have the installations always made in the same way, so that i mean. I mean i have alwas made the swap on the first gig of the disk, and the installation on the rest of the disk. and i have no multiple os'es on these disk. The problem is that the file (from dd of=foo) can still end up at completely different physical places on the disk. It depends on the filesystem (ext2, ext3, UFS, whatever) and on the allocation strategies of the filesystem code. UFS might start filling cylinder groups from the beginning of the disk, while ext3 might start at the end (does ext3 even _have_ cylinder groups?). This was just an example, but you get the idea. Of course, it also depends on how much data there already is on the filesystem, and how it is distributed over the disk. For accurate measurements and comparisons, you have to make sure to use _exactly_ the same physical location on the disk. From userland you don't have a way to control the physical allocation of files. Therefore, the only reliable way is to leave an unused partition on the disk, do _not_ put a filesystem on it, and use the raw device in the »dd« command. If you do this, you will always hit the same physical location on the disk. But then again -- as others have already mentioned, serial write speed is not the most important factor for database performance (although the WAL journal files of advanced transactional databases like PostgreSQL are written in a sequential way), so the usefulness of this benchmark is very debatable. Best regards Oliver -- Oliver Fromme, secnetix GmbH Co KG, Oettingenstr. 2, 80538 München Any opinions expressed in this message may be personal to the author and may not necessarily reflect the opinions of secnetix in any way. I started using PostgreSQL around a month ago, and the feeling is similar to the switch from Linux to FreeBSD in '96 -- 'wow!'. -- Oddbjorn Steffensen ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: FreeBSD MySQL still WAY slower than Linux
Hello Oliver, ah, that are the hint that i missed. now i have another question, if i use the same Os in 2 versions (RELENG_4, RELENG_5) can i hope that the tests are made on the same part of disk? or in other words can an dd on the two OS' es so much different because they use an totally other part of disk? I think no, the strategie from dd under one OS should not be changed if the OS-Version has changed. the part with serial IO related to database-performance have i understand, but i quests me have the others understand my meanings? best regards Michael Schuh 2005/6/21, Oliver Fromme [EMAIL PROTECTED]: Michael Schuh [EMAIL PROTECTED] wrote: As i sayed i have the installations always made in the same way, so that i mean. I mean i have alwas made the swap on the first gig of the disk, and the installation on the rest of the disk. and i have no multiple os'es on these disk. The problem is that the file (from dd of=foo) can still end up at completely different physical places on the disk. It depends on the filesystem (ext2, ext3, UFS, whatever) and on the allocation strategies of the filesystem code. UFS might start filling cylinder groups from the beginning of the disk, while ext3 might start at the end (does ext3 even _have_ cylinder groups?). This was just an example, but you get the idea. Of course, it also depends on how much data there already is on the filesystem, and how it is distributed over the disk. For accurate measurements and comparisons, you have to make sure to use _exactly_ the same physical location on the disk. From userland you don't have a way to control the physical allocation of files. Therefore, the only reliable way is to leave an unused partition on the disk, do _not_ put a filesystem on it, and use the raw device in the »dd« command. If you do this, you will always hit the same physical location on the disk. But then again -- as others have already mentioned, serial write speed is not the most important factor for database performance (although the WAL journal files of advanced transactional databases like PostgreSQL are written in a sequential way), so the usefulness of this benchmark is very debatable. Best regards Oliver -- Oliver Fromme, secnetix GmbH Co KG, Oettingenstr. 2, 80538 München Any opinions expressed in this message may be personal to the author and may not necessarily reflect the opinions of secnetix in any way. I started using PostgreSQL around a month ago, and the feeling is similar to the switch from Linux to FreeBSD in '96 -- 'wow!'. -- Oddbjorn Steffensen ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: FreeBSD MySQL still WAY slower than Linux
On Fri, Jun 17, 2005 at 10:30:25AM -0500, Greg Barniskis wrote: I think he meant comparing 36,000 on CentOS (async) to 24,000 on CURRENT (sync). I wondered that myself, and having searched out the answer I find that it is declared in http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/configtuning-disk.html that async provides fast writes at the cost of no guarantee at all for a consistent state of the filesystem. So, you choose: fast but not so reliable writes, or slower writes with fast, reliable disaster recovery. Thanks to the FreeBSD team for choosing the sensible default, even if it results in the occasional Linux is faster! debate. Dang smirky penguins... you're flightless I tell ya, flightless. =) Note that it's very easy to accidentally configure MySQL in such a manner that you don't have any data integrity anyway. For example, if you fat-finger 'innodb' as 'innodd' or something MySQL siletly creates a MyISAM table for you. So if you care about data integrity, you should probably look beyond MySQL in the first place. -- Jim C. Nasby, Database Consultant [EMAIL PROTECTED] Give your computer some brain candy! www.distributed.net Team #1828 Windows: Where do you want to go today? Linux: Where do you want to go tomorrow? FreeBSD: Are you guys coming, or what? ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: FreeBSD MySQL still WAY slower than Linux
Hello, i follows up these thread and i think you all digging on the false possible error location.. I have made many performance tests with RELENG_4 related to RELENG_5 and DragonFly and Gentoo. My results was that RELENG_5 is half as RELENG_4 fast by disk-access (ata-related). I have seen that RELENG_5 with GENERIC Kernel and only modified option HZ=2000. the spread begind with Gentoo (mentoided from me as the slowest, but errare humanum est) Gentoo : 100% time consumption RELENG_4: 67% time consumtion DrangonFly Rel1.2 69-72% time consumption (i think preemtion) RELENG_5 134% time consumtion these tests are made on physically the same Hardware (real, not equal system, same system, same disk, same RAM) with the command: # cd /; /usr/bin/time dd if=/dev/zero bs=1024 count=1024k of=zerofile; rm zerofile the tests are made more then 3 times/period/system. I have made the tests to the beginning of stable-5, and by the release 5.4. after the Release from DragonFly. By the first time i have made a mailing on stable, and i become the answer thath these issues become fixed on RELENG_6. so i think you have to wait on the developers :-(( best regards Michael ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: FreeBSD MySQL still WAY slower than Linux
Michael Schuh wrote: My results was that RELENG_5 is half as RELENG_4 fast by disk-access (ata-related). I have seen that RELENG_5 with GENERIC Kernel and only modified option HZ=2000. the spread begind with Gentoo (mentoided from me as the slowest, but errare humanum est) Gentoo : 100% time consumption RELENG_4: 67% time consumtion DrangonFly Rel1.2 69-72% time consumption (i think preemtion) RELENG_5 134% time consumtion these tests are made on physically the same Hardware (real, not equal system, same system, same disk, same RAM) with the command: # cd /; /usr/bin/time dd if=/dev/zero bs=1024 count=1024k of=zerofile; You have shown that sequential IO is slower in RELENG_5 (I think others have observed this also - check out Google)...However, random IO is often more important for databases, and RELENG_5 can be faster than RELENG_4 (try out iozone, it makes testing this easy). Also note that if your operating systems are installed in different parts of the same disk, then this will effect your results too - as some parts are faster than others. With respect to Mysql performance, I would suspect threading or threading/kernel interaction as the culprit. (That reminds me, I don't recall seeing the original poster re-doing the tests with 6.0-CURRENT - that would be interesting). cheers Mark ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: FreeBSD MySQL still WAY slower than Linux
Hello, yes random IO is more targetted to Databases. noop, i have the installation always made in the same way, and i have respected the different diskperformace in different disk-parts. this was the reason for #cd /; at the beginning of my tests. In the first test i have me shooting self in my foot and i bites me in my ass :-))) my suggestion going more in the direction...first solve all disk(ata) related performace issues, then test the mysql-performaces issues again to secure that you are not lying on an mixing of many problems :-) I think this was better then seek around corners that are not so relevant... or the result is not so dramatically greetings Michael 2005/6/20, Mark Kirkwood [EMAIL PROTECTED]: Michael Schuh wrote: My results was that RELENG_5 is half as RELENG_4 fast by disk-access (ata-related). I have seen that RELENG_5 with GENERIC Kernel and only modified option HZ=2000. the spread begind with Gentoo (mentoided from me as the slowest, but errare humanum est) Gentoo : 100% time consumption RELENG_4: 67% time consumtion DrangonFly Rel1.2 69-72% time consumption (i think preemtion) RELENG_5 134% time consumtion these tests are made on physically the same Hardware (real, not equal system, same system, same disk, same RAM) with the command: # cd /; /usr/bin/time dd if=/dev/zero bs=1024 count=1024k of=zerofile; You have shown that sequential IO is slower in RELENG_5 (I think others have observed this also - check out Google)...However, random IO is often more important for databases, and RELENG_5 can be faster than RELENG_4 (try out iozone, it makes testing this easy). Also note that if your operating systems are installed in different parts of the same disk, then this will effect your results too - as some parts are faster than others. With respect to Mysql performance, I would suspect threading or threading/kernel interaction as the culprit. (That reminds me, I don't recall seeing the original poster re-doing the tests with 6.0-CURRENT - that would be interesting). cheers Mark ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: FreeBSD MySQL still WAY slower than Linux
On Fri, 17 Jun 2005, David Sze wrote: FreeBSD/amd64 5.4-RELEASE (libpthread, system and process scope) FreeBSD/amd64 6.0-CURRENT (libpthread, libthr, system and process scope) CentOS/amd64 4.0 (i.e. RHEL4.0) I couldn't get libthr to work on FreeBSD/amd64 5.4-RELEASE, mysqld would immediately coredump and the stacktrace looked like it was corrupted (i.e. hundreds of stack frames, all of which were ???). The libthr in 5.x is basically an early prototype compared to the more mature work on 6.x, so this result is not all that surprising. David Xu has put a very large amount of work into the libthr on 6.x with some very good results. It turns out that the problem was the same thing everyone usually points the finger at, but no one actually mentioned this time: Linux mounts its partitions async by default. I don't have the exact numbers in front of me right now, but these were the ballpark figures (I'm not going to separate out results for all of the different threading libraries for FreeBSD because the deltas weren't huge): This is actually an interesting observation -- on 6.x using P4 Xeon hardware, I've seen a substantial performance improvement from running with libthr with MySQL. Sometimes as much as 30% - 50%. However, amd64 is quite a different beast. BTW, could you run 'file' on the Linux and FreeBSD MySQL binaries and confirm that they're both either 32-bit i386 binaries, or 64-bit amd64 binaries? That last CentOS number is not a typo, it was an order of magnitude slower. I didn't try other file systems on CentOS, just the default ext3. It's possible that reiserfs or xfs might not be as affected by switching from async to sync. So my production server is now happily running mysql 4.1 on 6.0-CURRENT :). I was interested to observe, in some benchmarking a few months ago, that 4.0 MySQL performance on FreeBSD 6.x is a *lot* faster than 4.1 MySQL performance. I don't track MySQL feature development, but I couldn't help but wonder if either there had been substantial reliability changes that impacted file system semantics (which might be indicated by sync/async issues), or whether there had been a lot of performance optimization work for Linux that had swung its use of IPC/etc primitives towards ones that work better on Linux than FreeBSD? BTW, could you confirm that on 6.x, you're setting /etc/malloc.conf so that it's not scrubbing memory on free()? In particular: ln -s jz /etc/malloc.conf as root. Most 6.x debugging features are set as part of the kernel configuration, and your performance results suggest that you've caught them all already, I think, but this one is user space. Also, make sure you are compiling without INVARIANT_SUPPORT -- for packet send tests, I find that even without INVARIANTS, I see a 4% hit for having INVARIANT_SUPPORT in the kernel. Robert N M Watson ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
kpdf crashes with LIBPTHREAD_SYSTEM_SCOPE set (Was: Re: FreeBSD MySQL still WAY slower than Linux)
On Saturday, 11. June 2005 17:05, Daniel Eischen wrote: You can set the environment variable LIBPTHREAD_SYSTEM_SCOPE to force libpthread to use system scope. I've played around with that variable (set it in .xsession) and found that kpdf (from graphics/kdegraphics3) will reproducably crash if it is set. Unsetting it in a shell running on top of a KDE started with mentioned .xsession and launching kpdf from there will remedy the problem. The backtrace I get is probably useless, let me know if (and how) I should recompile libpthread or other system libraries with debug symbols ... This is on 5.4-STABLE, two-three weeks old. Cheers, -- ,_, | Michael Nottebrock | [EMAIL PROTECTED] (/^ ^\) | FreeBSD - The Power to Serve | http://www.freebsd.org \u/ | K Desktop Environment on FreeBSD | http://freebsd.kde.org pgp75sKZRZku1.pgp Description: PGP signature
Re: kpdf crashes with LIBPTHREAD_SYSTEM_SCOPE set (Was: Re: FreeBSD MySQL still WAY slower than Linux)
On Mon, 20 Jun 2005, Michael Nottebrock wrote: On Saturday, 11. June 2005 17:05, Daniel Eischen wrote: You can set the environment variable LIBPTHREAD_SYSTEM_SCOPE to force libpthread to use system scope. I've played around with that variable (set it in .xsession) and found that kpdf (from graphics/kdegraphics3) will reproducably crash if it is set. Unsetting it in a shell running on top of a KDE started with mentioned .xsession and launching kpdf from there will remedy the problem. The backtrace I get is probably useless, let me know if (and how) I should recompile libpthread or other system libraries with debug symbols ... This is on 5.4-STABLE, two-three weeks old. Works here on a month or two old -current. I'm using /usr/local/ant/docs/appendix_e.pdf as a test (it's 60 pages or so). -- DE ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: kpdf crashes with LIBPTHREAD_SYSTEM_SCOPE set (Was: Re: FreeBSD MySQL still WAY slower than Linux)
On Monday, 20. June 2005 18:53, Daniel Eischen wrote: Works here on a month or two old -current. I'm using /usr/local/ant/docs/appendix_e.pdf as a test (it's 60 pages or so). Crashes for me: [EMAIL PROTECTED]:127:~ env LIBPTHREAD_SYSTEM_SCOPE=1 kpdf 'http://drtc.isibang.ac.in/%7Eprachi/apache-ant-1.5.4/docs/appendix_e.pdf' Bus error [EMAIL PROTECTED]:1:~ kpdf 'http://drtc.isibang.ac.in/%7Eprachi/apache-ant-1.5.4/docs/appendix_e.pdf' [EMAIL PROTECTED]:0:~ I don't have a -CURRENT machine to test. -- ,_, | Michael Nottebrock | [EMAIL PROTECTED] (/^ ^\) | FreeBSD - The Power to Serve | http://www.freebsd.org \u/ | K Desktop Environment on FreeBSD | http://freebsd.kde.org pgpwHbXsgShVs.pgp Description: PGP signature
Re: kpdf crashes with LIBPTHREAD_SYSTEM_SCOPE set (Was: Re: FreeBSD MySQL still WAY slower than Linux)
On Mon, 20 Jun 2005, Michael Nottebrock wrote: On Monday, 20. June 2005 18:53, Daniel Eischen wrote: Works here on a month or two old -current. I'm using /usr/local/ant/docs/appendix_e.pdf as a test (it's 60 pages or so). Crashes for me: [EMAIL PROTECTED]:127:~ env LIBPTHREAD_SYSTEM_SCOPE=1 kpdf 'http://drtc.isibang.ac.in/%7Eprachi/apache-ant-1.5.4/docs/appendix_e.pdf' Bus error [EMAIL PROTECTED]:1:~ kpdf 'http://drtc.isibang.ac.in/%7Eprachi/apache-ant-1.5.4/docs/appendix_e.pdf' [EMAIL PROTECTED]:0:~ I don't have a -CURRENT machine to test. Try -stable. -- Dan Eischen ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: FreeBSD MySQL still WAY slower than Linux
Michael Schuh wrote: Hello, yes random IO is more targetted to Databases. noop, i have the installation always made in the same way, and i have respected the different diskperformace in different disk-parts. this was the reason for #cd /; at the beginning of my tests. In the first test i have me shooting self in my foot and i bites me in my ass :-))) I was referring to the partitions and slices on the physical disk - each operating system is installed in a different one of these, and so is in a different physical part of the disk - hence you cannot reliably compare IO rates between them (This very issue has been discussed before I recall - try a Google search, as it is quite interesting). my suggestion going more in the direction...first solve all disk(ata) related performace issues, then test the mysql-performaces issues again to secure that you are not lying on an mixing of many problems :-) While noone would complain about faster sequential IO, it is almost certainly not the issue effecting database performance - for instance I find Postgresql consistently faster on RELENG_5 (5.3 onwards) than on RELENG_4 (using the pgbench program). cheers Mark ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: FreeBSD MySQL still WAY slower than Linux
I've posted a longer reply, with a trimmed cc list on the -performance mailing list if anyone is still interested and I'll leave it off -stable as it's probably become somewhat off topic now. Sadly, I don't think simply having an async FS is going to solve our problem though. :( Ta, Steve Roome For refernce: On Fri, Jun 17, 2005 at 09:28:54AM -0400, David Sze wrote: At 05:15 PM 16/06/2005 +0100, Steve Roome wrote this to All: It turns out that the problem was the same thing everyone usually points the finger at, but no one actually mentioned this time: Linux mounts its partitions async by default. I don't have the exact numbers in front of me right now, but these were the ballpark figures (I'm not going to separate out results for all of the different threading libraries for FreeBSD because the deltas weren't huge): ... ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: FreeBSD MySQL still WAY slower than Linux
On Friday 17 June 2005 23:47, Javier Henderson wrote: Wilko Bulte wrote: On Fri, Jun 17, 2005 at 02:26:48PM -0700, Javier Henderson wrote.. Wilko Bulte wrote: On Fri, Jun 17, 2005 at 11:12:06PM +0200, Matthias Buelow wrote.. Wilko Bulte [EMAIL PROTECTED] writes: If you give me $5 per Unix system found there I can retire here and now. For financial transaction processing, and the customer's accounts? Yes. Go and visit the London City and check their computer rooms. You will be surprised about the number of UNIX boxes. You don't think IBM, HP, Sun etc sell their UNIX machines just to ISPs or..? But are those Unix servers actually processing bank transactions and holding customer accounts? Why not? As an aside: what do you think telecom operators run their main billing systems on? UNIX... I'm sure some do. Others run theirs on VMS. Any idea what downtime costs per hour on those systems? A lot. So how is this relevant for freebsd-stable@ ? ... Thanks! -- /\ Best regards, | [EMAIL PROTECTED] \ / Max Laier | ICQ #67774661 X http://pf4freebsd.love2party.net/ | [EMAIL PROTECTED] / \ ASCII Ribbon Campaign | Against HTML Mail and News pgpRDPXg1ZiQO.pgp Description: PGP signature
Re: FreeBSD MySQL still WAY slower than Linux
Thank you all for your suggestions on this thread, here's a brief breakdown of most of the ideas from people: Billy Newsom: COMPILER, DISK, MYSQLVERSION Daniel Eischen: +/-HTT, Thread scopes Greg Lehey: MALLOC Guy Helmer: PREEMPTIVE, vfs.read_max Jon Dama: David Xu's Thrds, Ptmalloc, cpu affinity, sched+hwcacheing Kris Kennaway: +/-HTT Robert Watson: Thread scopes, LIBTHR/Linuxthr on 5 and 6?, LOCKING, HTT, SMP/UP Thomas Hurst: FreeBSD-current, Don't overload mysql! Vladimir Chukharev: COMPILEOPTS, TABLETYPES Xin Li: PROFILE, HTT insignificant The bad news is that I've not managed to get very far at all lately as MySQL has been crashing too much to even stop and test stuff elsewhere. The good news though, is that the Mysql folks have agreed to setup tests to profile mysql on identical hardware running FreeBSD and Linux with an aim to find out exactly where the problem really is. They reckon they'll spend at least two weeks trying to find out why Linux is so much faster - if they do this right I'd be surprised if we can't improve things quite a lot. Also, it'd be good if any of you who still have an interest in this could add any ideas or suggestions that may help *them* with their testing. If so, just get in touch with me asap before they get too stuck into anything that might prove fruitless. Here's hoping we can get MySQL running as well on FreeBSD as it ought to. Thanks again everyone, Steve Roome ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: FreeBSD MySQL still WAY slower than Linux
On Thu, 16 Jun 2005, Steve Roome wrote: The good news though, is that the Mysql folks have agreed to setup tests to profile mysql on identical hardware running FreeBSD and Linux with an aim to find out exactly where the problem really is. They reckon they'll spend at least two weeks trying to find out why Linux is so much faster - if they do this right I'd be surprised if we can't improve things quite a lot. Also, it'd be good if any of you who still have an interest in this could add any ideas or suggestions that may help *them* with their testing. If so, just get in touch with me asap before they get too stuck into anything that might prove fruitless. Here's hoping we can get MySQL running as well on FreeBSD as it ought to. Please let me know if there's any support for this activity I can provide. I spent a fair amount of time identifying bottlenecks for MySQL in the 5.x cycle, and I know David Xu ([EMAIL PROTECTED]) has also spent quite a bit of time looking at the threading side, resulting in a lot of his work on libthr in 6.x. It would probably be a good idea to (a) move further discussion to [EMAIL PROTECTED], and (b) make sure that the performance work is starting with a recent 6.x baseline (with debugging turned off). thanks for the time you've been putting into this! Robert N M Watson ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: FreeBSD MySQL still WAY slower than Linux
At 05:15 PM 16/06/2005 +0100, Steve Roome wrote this to All: Thank you all for your suggestions on this thread, here's a brief breakdown of most of the ideas from people: Billy Newsom: COMPILER, DISK, MYSQLVERSION Daniel Eischen: +/-HTT, Thread scopes Greg Lehey: MALLOC Guy Helmer: PREEMPTIVE, vfs.read_max Jon Dama: David Xu's Thrds, Ptmalloc, cpu affinity, sched+hwcacheing Kris Kennaway: +/-HTT Robert Watson: Thread scopes, LIBTHR/Linuxthr on 5 and 6?, LOCKING, HTT, SMP/UP Thomas Hurst: FreeBSD-current, Don't overload mysql! Vladimir Chukharev: COMPILEOPTS, TABLETYPES Xin Li: PROFILE, HTT insignificant The bad news is that I've not managed to get very far at all lately as MySQL has been crashing too much to even stop and test stuff elsewhere. The good news though, is that the Mysql folks have agreed to setup tests to profile mysql on identical hardware running FreeBSD and Linux with an aim to find out exactly where the problem really is. They reckon they'll spend at least two weeks trying to find out why Linux is so much faster - if they do this right I'd be surprised if we can't improve things quite a lot. Also, it'd be good if any of you who still have an interest in this could add any ideas or suggestions that may help *them* with their testing. If so, just get in touch with me asap before they get too stuck into anything that might prove fruitless. Here's hoping we can get MySQL running as well on FreeBSD as it ought to. I just spent a couple days comparing MySQL 4.1 performance on: FreeBSD/amd64 5.4-RELEASE (libpthread, system and process scope) FreeBSD/amd64 6.0-CURRENT (libpthread, libthr, system and process scope) CentOS/amd64 4.0 (i.e. RHEL4.0) I couldn't get libthr to work on FreeBSD/amd64 5.4-RELEASE, mysqld would immediately coredump and the stacktrace looked like it was corrupted (i.e. hundreds of stack frames, all of which were ???). This was the hardware: Dell PowerEdge 2850 Dual Xeon 3.6GHz EMT64, HTT disabled 4GB RAM amr RAID controller w/256MB battery backed cache 5 x 73GB 15K RPM SCSI disks configured as one RAID5 w/64KB stripe I was seeing the same sort of super-smack numbers that everyone's been reporting, i.e. that Linux box was twice as fast as FreeBSD. It turns out that the problem was the same thing everyone usually points the finger at, but no one actually mentioned this time: Linux mounts its partitions async by default. I don't have the exact numbers in front of me right now, but these were the ballpark figures (I'm not going to separate out results for all of the different threading libraries for FreeBSD because the deltas weren't huge): super-smack select-key 5.4-RELEASE ~20,000 queries/second 6.0-CURRENT ~24,000 queries/second CentOS w/async ~36,000 queries/second CentOS w/sync ~26,000 queries/second super-smack update-select 5.4-RELEASE ~4,000 queries/second 6.0-CURRENT ~4,500 queries/second CentOS w/async ~7,500 queries/second CentOS w/sync ~750 queries/second That last CentOS number is not a typo, it was an order of magnitude slower. I didn't try other file systems on CentOS, just the default ext3. It's possible that reiserfs or xfs might not be as affected by switching from async to sync. So my production server is now happily running mysql 4.1 on 6.0-CURRENT :). ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: FreeBSD MySQL still WAY slower than Linux
[...] super-smack select-key 5.4-RELEASE ~20,000 queries/second 6.0-CURRENT ~24,000 queries/second CentOS w/async ~36,000 queries/second CentOS w/sync ~26,000 queries/second super-smack update-select 5.4-RELEASE ~4,000 queries/second 6.0-CURRENT ~4,500 queries/second CentOS w/async ~7,500 queries/second CentOS w/sync ~750 queries/second That last CentOS number is not a typo, it was an order of magnitude slower. I didn't try other file systems on CentOS, just the default ext3. It's possible that reiserfs or xfs might not be as affected by switching from async to sync. So my production server is now happily running mysql 4.1 on 6.0-CURRENT :). I don't get it. You get 30% less perfomance, running a non-production release for production, and happy about it? U. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED] ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: FreeBSD MySQL still WAY slower than Linux
David Sze wrote: At 05:15 PM 16/06/2005 +0100, Steve Roome wrote this to All: Thank you all for your suggestions on this thread, here's a brief breakdown of most of the ideas from people: Billy Newsom: COMPILER, DISK, MYSQLVERSION Daniel Eischen: +/-HTT, Thread scopes Greg Lehey: MALLOC Guy Helmer: PREEMPTIVE, vfs.read_max Jon Dama: David Xu's Thrds, Ptmalloc, cpu affinity, sched+hwcacheing Kris Kennaway: +/-HTT Robert Watson: Thread scopes, LIBTHR/Linuxthr on 5 and 6?, LOCKING, HTT, SMP/UP Thomas Hurst: FreeBSD-current, Don't overload mysql! Vladimir Chukharev: COMPILEOPTS, TABLETYPES Xin Li: PROFILE, HTT insignificant The bad news is that I've not managed to get very far at all lately as MySQL has been crashing too much to even stop and test stuff elsewhere. The good news though, is that the Mysql folks have agreed to setup tests to profile mysql on identical hardware running FreeBSD and Linux with an aim to find out exactly where the problem really is. They reckon they'll spend at least two weeks trying to find out why Linux is so much faster - if they do this right I'd be surprised if we can't improve things quite a lot. Also, it'd be good if any of you who still have an interest in this could add any ideas or suggestions that may help *them* with their testing. If so, just get in touch with me asap before they get too stuck into anything that might prove fruitless. Here's hoping we can get MySQL running as well on FreeBSD as it ought to. I just spent a couple days comparing MySQL 4.1 performance on: FreeBSD/amd64 5.4-RELEASE (libpthread, system and process scope) FreeBSD/amd64 6.0-CURRENT (libpthread, libthr, system and process scope) CentOS/amd64 4.0 (i.e. RHEL4.0) I couldn't get libthr to work on FreeBSD/amd64 5.4-RELEASE, mysqld would immediately coredump and the stacktrace looked like it was corrupted (i.e. hundreds of stack frames, all of which were ???). This was the hardware: Dell PowerEdge 2850 Dual Xeon 3.6GHz EMT64, HTT disabled 4GB RAM amr RAID controller w/256MB battery backed cache 5 x 73GB 15K RPM SCSI disks configured as one RAID5 w/64KB stripe I was seeing the same sort of super-smack numbers that everyone's been reporting, i.e. that Linux box was twice as fast as FreeBSD. It turns out that the problem was the same thing everyone usually points the finger at, but no one actually mentioned this time: Linux mounts its partitions async by default. I don't have the exact numbers in front of me right now, but these were the ballpark figures (I'm not going to separate out results for all of the different threading libraries for FreeBSD because the deltas weren't huge): super-smack select-key 5.4-RELEASE ~20,000 queries/second 6.0-CURRENT ~24,000 queries/second CentOS w/async ~36,000 queries/second CentOS w/sync ~26,000 queries/second super-smack update-select 5.4-RELEASE ~4,000 queries/second 6.0-CURRENT ~4,500 queries/second CentOS w/async ~7,500 queries/second CentOS w/sync ~750 queries/second That last CentOS number is not a typo, it was an order of magnitude slower. I didn't try other file systems on CentOS, just the default ext3. It's possible that reiserfs or xfs might not be as affected by switching from async to sync. So my production server is now happily running mysql 4.1 on 6.0-CURRENT :). that explains quite a bit. but why use FreeBSD when you can just turn on async on your partitions and get faster queries? ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: FreeBSD MySQL still WAY slower than Linux
Uzi wrote: [...] super-smack select-key 5.4-RELEASE ~20,000 queries/second 6.0-CURRENT ~24,000 queries/second CentOS w/async ~36,000 queries/second CentOS w/sync ~26,000 queries/second super-smack update-select 5.4-RELEASE ~4,000 queries/second 6.0-CURRENT ~4,500 queries/second CentOS w/async ~7,500 queries/second CentOS w/sync ~750 queries/second That last CentOS number is not a typo, it was an order of magnitude slower. I didn't try other file systems on CentOS, just the default ext3. It's possible that reiserfs or xfs might not be as affected by switching from async to sync. So my production server is now happily running mysql 4.1 on 6.0-CURRENT :). I don't get it. You get 30% less perfomance, running a non-production release for production, and happy about it? Try reading it again. The last time I checked, 24k queries/sec _is_ faster than 20k queries/sec. And 4.5k queries/sec is faster than 4.0k queries/sec. John -- John T. FarmerOwner CTOGoldSword Systems [EMAIL PROTECTED] 865-691-6498 Knoxville TN Consulting, Design, Development of Networks Software ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: FreeBSD MySQL still WAY slower than Linux
J. T. Farmer wrote: Uzi wrote: [...] super-smack select-key 5.4-RELEASE ~20,000 queries/second 6.0-CURRENT ~24,000 queries/second CentOS w/async ~36,000 queries/second CentOS w/sync ~26,000 queries/second super-smack update-select 5.4-RELEASE ~4,000 queries/second 6.0-CURRENT ~4,500 queries/second CentOS w/async ~7,500 queries/second CentOS w/sync ~750 queries/second That last CentOS number is not a typo, it was an order of magnitude slower. I didn't try other file systems on CentOS, just the default ext3. It's possible that reiserfs or xfs might not be as affected by switching from async to sync. So my production server is now happily running mysql 4.1 on 6.0-CURRENT :). I don't get it. You get 30% less perfomance, running a non-production release for production, and happy about it? Try reading it again. The last time I checked, 24k queries/sec _is_ faster than 20k queries/sec. And 4.5k queries/sec is faster than 4.0k queries/sec. John i think you're missing the point... using CURRENT on a production machine is a bad idea... the performance is great, but hardly worth the risk of breaking something. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: FreeBSD MySQL still WAY slower than Linux
J. T. Farmer wrote: Uzi wrote: [...] super-smack select-key 5.4-RELEASE ~20,000 queries/second 6.0-CURRENT ~24,000 queries/second CentOS w/async ~36,000 queries/second CentOS w/sync ~26,000 queries/second super-smack update-select 5.4-RELEASE ~4,000 queries/second 6.0-CURRENT ~4,500 queries/second CentOS w/async ~7,500 queries/second CentOS w/sync ~750 queries/second That last CentOS number is not a typo, it was an order of magnitude slower. I didn't try other file systems on CentOS, just the default ext3. It's possible that reiserfs or xfs might not be as affected by switching from async to sync. So my production server is now happily running mysql 4.1 on 6.0-CURRENT :). I don't get it. You get 30% less perfomance, running a non-production release for production, and happy about it? Try reading it again. The last time I checked, 24k queries/sec _is_ faster than 20k queries/sec. And 4.5k queries/sec is faster than 4.0k queries/sec. I think he meant comparing 36,000 on CentOS (async) to 24,000 on CURRENT (sync). I wondered that myself, and having searched out the answer I find that it is declared in http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/configtuning-disk.html that async provides fast writes at the cost of no guarantee at all for a consistent state of the filesystem. So, you choose: fast but not so reliable writes, or slower writes with fast, reliable disaster recovery. Thanks to the FreeBSD team for choosing the sensible default, even if it results in the occasional Linux is faster! debate. Dang smirky penguins... you're flightless I tell ya, flightless. =) -- Greg Barniskis, Computer Systems Integrator South Central Library System (SCLS) Library Interchange Network (LINK) gregb at scls.lib.wi.us, (608) 266-6348 ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: FreeBSD MySQL still WAY slower than Linux
On Fri, Jun 17, 2005 at 11:28:24AM -0400, JM wrote: i think you're missing the point... using CURRENT on a production machine is a bad idea... the performance is great, but hardly worth the risk of breaking something. Under normal circumstances I'd agree, but -CURRENT is already in code freeze in preparation for the upcoming 6.0 release: http://www.freebsd.org/releases/6.0R/schedule.html I also follow the cvs-src mailing list pretty closely, and I like the stability and performance increases that have gone into there. It seems like most of them won't be backported to RELENG_5 because they break ABI compatibility. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: FreeBSD MySQL still WAY slower than Linux
Greg Barniskis [EMAIL PROTECTED] writes: that async provides fast writes at the cost of no guarantee at all for a consistent state of the filesystem. So, you choose: fast but not so reliable writes, or slower writes with fast, reliable disaster recovery. Thanks to the FreeBSD team for choosing the sensible default, even if it results in the occasional Linux is faster! debate. Dang smirky penguins... you're flightless I tell ya, flightless. =) Is CentOS using ext2? I thought everyone moved to ext3 already, which provides nearly the speed of ext2+async but is safe due to its journal. If you make such comparisons, please use current technology, and not the status quo of 5 years ago. [Apart from that, over the last decade, I've lost more UFS filesystems than ext2, so at least for me, that purported unsafety of ext2+async mounts is theoretical at best. In the end, with today's write-caches usually enabled, both are essentially the same, anyways.] mkb. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: FreeBSD MySQL still WAY slower than Linux
On Fri, Jun 17, 2005 at 05:47:56PM +0200, Matthias Buelow wrote: Is CentOS using ext2? I thought everyone moved to ext3 already, which provides nearly the speed of ext2+async but is safe due to its journal. If you make such comparisons, please use current technology, and not the status quo of 5 years ago. CentOS uses ext3 by default. How does having a journal help if the journal is stored on the same async filesystem? Unless the journal writes are guaranteed sync. [Apart from that, over the last decade, I've lost more UFS filesystems than ext2, so at least for me, that purported unsafety of ext2+async mounts is theoretical at best. In the end, with today's write-caches usually enabled, both are essentially the same, anyways.] AFAIK, SCSI disks normally have write caching disabled. Proper RAID controllers also won't do write-back caching by default unless there's a battery backup. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: FreeBSD MySQL still WAY slower than Linux
David Sze wrote: On Fri, Jun 17, 2005 at 11:28:24AM -0400, JM wrote: i think you're missing the point... using CURRENT on a production machine is a bad idea... the performance is great, but hardly worth the risk of breaking something. Under normal circumstances I'd agree, but -CURRENT is already in code freeze in preparation for the upcoming 6.0 release: http://www.freebsd.org/releases/6.0R/schedule.html I also follow the cvs-src mailing list pretty closely, and I like the stability and performance increases that have gone into there. It seems like most of them won't be backported to RELENG_5 because they break ABI compatibility. code freeze != glitch free XD ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: FreeBSD MySQL still WAY slower than Linux
On Fri, Jun 17, 2005 at 12:05:54PM -0400, JM wrote: David Sze wrote: Under normal circumstances I'd agree, but -CURRENT is already in code freeze in preparation for the upcoming 6.0 release: http://www.freebsd.org/releases/6.0R/schedule.html I also follow the cvs-src mailing list pretty closely, and I like the stability and performance increases that have gone into there. It seems like most of them won't be backported to RELENG_5 because they break ABI compatibility. code freeze != glitch free XD RELENG_5_X, RELENG_5, RELENG_4_X, RELENG_4 != glitch free Point being, in both cases the key is to follow the mailing lists, not make decisions on what to use based solely on the way they're labelled. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: FreeBSD MySQL still WAY slower than Linux
Matthias Buelow wrote: Greg Barniskis [EMAIL PROTECTED] writes: that async provides fast writes at the cost of no guarantee at all for a consistent state of the filesystem. So, you choose: fast but not so reliable writes, or slower writes with fast, reliable disaster recovery. Thanks to the FreeBSD team for choosing the sensible default, even if it results in the occasional Linux is faster! debate. Dang smirky penguins... you're flightless I tell ya, flightless. =) Is CentOS using ext2? I thought everyone moved to ext3 already, which provides nearly the speed of ext2+async but is safe due to its journal. If you make such comparisons, please use current technology, and not the status quo of 5 years ago. OK, my bad. I did not do thorough research, just enough to satisfy my curiosity. If ext3 does well and safely, then more power to 'em. Anyway, sorry, what I wrote was not intended to be flame bait, just blowing off a little steam. I'll go crawl back under my rock now. However, I stand by the assertion that a slow, certain default is better than a fast, uncertain one. That async was ever the Linux default is troubling (to me), and I've got plenty other reasons to prefer BSD over Linux (which is why I didn't do thorough research in the first place -- no interest at all in migrating, even if there's a database speed boost). -- Greg Barniskis, Computer Systems Integrator South Central Library System (SCLS) Library Interchange Network (LINK) gregb at scls.lib.wi.us, (608) 266-6348 ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: FreeBSD MySQL still WAY slower than Linux
David Sze [EMAIL PROTECTED] writes: CentOS uses ext3 by default. How does having a journal help if the journal is stored on the same async filesystem? Unless the journal writes are guaranteed sync. The journal guarantees that the filesystem will always be consistent. If a journal entry doesn't make it to disk, the operation has never happened; and the journal entry won't get removed, until the metadata update has been performed. So the worst thing that could happen is, that the same operation will be performed twice, once normally, and once at log replay on reboot. This is not an issue, since such metadata operations (delete file from directory, write a value into superblock, etc.) are usually idempotent. That's the basic function of all journalled filesystems, and that's why you don't need to run fsck on them. You don't need to write the journal synchronously, you can do these things in groups. The softupdates mechanism does something similar; only it doesn't maintain an on-disk journal, and hence needs fsck after boot to fix up the free block bitmaps and stuff (basically performing a garbage collection on the filesystem, which, unfortunately, is pretty slow). mkb. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: FreeBSD MySQL still WAY slower than Linux
i think you're missing the point... using CURRENT on a production machine is a bad idea... the performance is great, but hardly worth the risk of breaking something. In general, this is true. But since we're in the glide path to a release, and since we have measures in place to keep destablizing commits out of the tree, CURRENT these days isn't a scary place to be if you validate the specific version of current you are deploying. There's risks there, but it isn't like it was at the worst part of the 5.x release cycle where you counted yourself lucky if CURRENT booted on your hardware and was still running the next day... Warner ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: FreeBSD MySQL still WAY slower than Linux
* David Sze ([EMAIL PROTECTED]) wrote: super-smack select-key 5.4-RELEASE ~20,000 queries/second 6.0-CURRENT ~24,000 queries/second CentOS w/async ~36,000 queries/second CentOS w/sync ~26,000 queries/second Uh, this should be an entirely cached set of reads, why does mounting sync reduce performance this much? Does FreeBSD see a similar boost with async mounts? super-smack update-select 5.4-RELEASE ~4,000 queries/second 6.0-CURRENT ~4,500 queries/second CentOS w/async ~7,500 queries/second CentOS w/sync ~750 queries/second Is this even relevent? Async is by far the most common setup on Linux, one which seems very stable and safe, especially on XFS/Reiser. Of course if FreeBSD can't match Linux/async performance, but still perform like this on a potentially safer sync mount, that's fine by me, but I'm having trouble buying that select-key performance. Even standalone multi-second and non-concurrent selects demonstrate this 30-40% lower performance than Linux on the same hardware. -- Thomas 'Freaky' Hurst http://hur.st/ ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: FreeBSD MySQL still WAY slower than Linux
On Fri, Jun 17, 2005 at 06:20:59PM +0200, Matthias Buelow wrote: David Sze [EMAIL PROTECTED] writes: CentOS uses ext3 by default. How does having a journal help if the journal is stored on the same async filesystem? Unless the journal writes are guaranteed sync. The journal guarantees that the filesystem will always be consistent. If a journal entry doesn't make it to disk, the operation has never happened; and the journal entry won't get removed, until the metadata update has been performed. So the worst thing that could happen is, that the same operation will be performed twice, once normally, and once at log replay on reboot. This is not an issue, since such metadata operations (delete file from directory, write a value into superblock, etc.) are usually idempotent. That's the basic function of all journalled filesystems, and that's why you don't need to run fsck on them. You don't need to write the journal synchronously, you can do these things in groups. The softupdates mechanism does something similar; only it doesn't maintain an on-disk journal, and hence needs fsck after boot to fix up the free block bitmaps and stuff (basically performing a garbage collection on the filesystem, which, unfortunately, is pretty slow). I'm not sure filesystem consistency alone is good enough. Say your bank's database crashes right after you make a deposit. When it comes back up it's consistent, but only up to 5 minutes before the crash due to the async mount. For this type of application, something in the system has to be keeping a journal on a sync mount in order for recovery to be both consistent and correct. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: FreeBSD MySQL still WAY slower than Linux
On Fri, 17 Jun 2005 13:57:26 -0500 David Sze [EMAIL PROTECTED] wrote: I'm not sure filesystem consistency alone is good enough. Say your bank's database crashes right after you make a deposit. When it comes back up it's consistent, but only up to 5 minutes before the crash due to the async mount. For this type of application, something in the system has to be keeping a journal on a sync mount in order for recovery to be both consistent and correct. For that critical an application the transaction should be stored in multiple physically separated locations and confirmed by the two faced kermit\w\w\w two phase commit protocol. Said implementation had better have the correct disaster restart protocol implemented too. -- C:WIN | Directable Mirror Arrays The computer obeys and wins.| A better way to focus the sun You lose and Bill collects. |licences available see |http://www.sohara.org/ ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: FreeBSD MySQL still WAY slower than Linux
--On Freitag, 17. Juni 2005 17:47 Uhr +0200 Matthias Buelow [EMAIL PROTECTED] wrote: Greg Barniskis [EMAIL PROTECTED] writes: Is CentOS using ext2? I thought everyone moved to ext3 already, which provides nearly the speed of ext2+async but is safe due to its journal. If you make such comparisons, please use current technology, and not the status quo of 5 years ago. ext3 delivers abysmal performance on concurrent write operations. XFS is substantially faster. We experienced postgresql database files becoming corrupt under high load (bulk imports; more than a hand full updates per second) on xfs fileystems (2.6.3 - 2.6.5 timeframe). We're about to move this client's (a pure Linux shop as yet) postgresql servers to FreeBSD/amd64. The first experimental setup on FreeBSD/amd64 (single processor, 1.4 GHz, 2 single SCSI disks 10kUPM, 5-stable, SMP-Kernel) delivers the quintupled (application specific) insert/update throughput over the current production setup (dual XEON, 4 spindle Hardware RAID 1+0, Linux/i386 2.6.x SMP). I hope to get my hands on a larger hardware testbed, so that I'd be able to do side by side comparisons. [Apart from that, over the last decade, I've lost more UFS filesystems than ext2, so at least for me, that purported unsafety of ext2+async mounts is theoretical at best. In the end, with today's write-caches usually enabled, both are essentially the same, anyways.] That makes your arguments pointless. I wouldn't even think of running a database server on an async mounted filesystem; all the more I wouldn't connect a drive with enabled write cache to a production box. -Andreas I lost exactly two UFS filesystems since my very FreeBSD beginnings and that was in the very early 3-current days shortly after the very first softupdates patches ... ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: FreeBSD MySQL still WAY slower than Linux
David Sze [EMAIL PROTECTED] writes: I'm not sure filesystem consistency alone is good enough. Say your bank's database crashes right after you make a deposit. When it comes back up it's consistent, but only up to 5 minutes before the crash due to the async mount. A bank doesn't run on Unix. It runs on mainframes, with such funny features like processors executing each instruction in parallel, and comparing the results. Completely different universe here. On Unix, filesystem consistency is the best you'll normally get. You _can_ mount filesystems synchronously, both with UFS aswell as ext2/3 etc., but the performance is abysmal. Maybe useful in particular situations but you probably wouldn't want to run your desktop (or busy server) with it. I mean, just try it and see (and make sure writeback-caching on the disks is disabled, when possible.) mkb. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: FreeBSD MySQL still WAY slower than Linux
On Fri, Jun 17, 2005 at 11:01:30PM +0200, Matthias Buelow wrote.. David Sze [EMAIL PROTECTED] writes: I'm not sure filesystem consistency alone is good enough. Say your bank's database crashes right after you make a deposit. When it comes back up it's consistent, but only up to 5 minutes before the crash due to the async mount. A bank doesn't run on Unix. It runs on mainframes, with such funny Total bull.. features like processors executing each instruction in parallel, and comparing the results. Completely different universe here. Sorry, when was the last time you saw a bank backoffice computer room? If you give me $5 per Unix system found there I can retire here and now. -- Wilko Bulte [EMAIL PROTECTED] ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: FreeBSD MySQL still WAY slower than Linux
Andreas Braukmann [EMAIL PROTECTED] writes: That makes your arguments pointless. I wouldn't even think of running a database server on an async mounted filesystem; all the more I wouldn't connect a drive with enabled write cache to a production box. So you remount all filesystems -o sync on your FreeBSD servers? And you're still satisfied with the performance? mkb. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: FreeBSD MySQL still WAY slower than Linux
Wilko Bulte [EMAIL PROTECTED] writes: If you give me $5 per Unix system found there I can retire here and now. For financial transaction processing, and the customer's accounts? I hope it's not my bank.. mkb. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: FreeBSD MySQL still WAY slower than Linux
On Fri, Jun 17, 2005 at 11:12:06PM +0200, Matthias Buelow wrote.. Wilko Bulte [EMAIL PROTECTED] writes: If you give me $5 per Unix system found there I can retire here and now. For financial transaction processing, and the customer's accounts? Yes. Go and visit the London City and check their computer rooms. You will be surprised about the number of UNIX boxes. You don't think IBM, HP, Sun etc sell their UNIX machines just to ISPs or..? I hope it's not my bank.. It might very well be your bank.. -- Wilko Bulte [EMAIL PROTECTED] ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: FreeBSD MySQL still WAY slower than Linux
Wilko Bulte wrote: On Fri, Jun 17, 2005 at 11:12:06PM +0200, Matthias Buelow wrote.. Wilko Bulte [EMAIL PROTECTED] writes: If you give me $5 per Unix system found there I can retire here and now. For financial transaction processing, and the customer's accounts? Yes. Go and visit the London City and check their computer rooms. You will be surprised about the number of UNIX boxes. You don't think IBM, HP, Sun etc sell their UNIX machines just to ISPs or..? I hope it's not my bank.. It might very well be your bank.. I'm sorry to say it, but there is a lot of mainframes a quite few unix boxes in the central accounting and transfer departments. remember that there are a shitload of Cobol Mainframes that are still used by a lot of banks.. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: FreeBSD MySQL still WAY slower than Linux
Wilko Bulte wrote: On Fri, Jun 17, 2005 at 11:12:06PM +0200, Matthias Buelow wrote.. Wilko Bulte [EMAIL PROTECTED] writes: If you give me $5 per Unix system found there I can retire here and now. For financial transaction processing, and the customer's accounts? Yes. Go and visit the London City and check their computer rooms. You will be surprised about the number of UNIX boxes. You don't think IBM, HP, Sun etc sell their UNIX machines just to ISPs or..? But are those Unix servers actually processing bank transactions and holding customer accounts? -jav ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: FreeBSD MySQL still WAY slower than Linux
Wilko Bulte [EMAIL PROTECTED] writes: Yes. Go and visit the London City and check their computer rooms. You will be surprised about the number of UNIX boxes. You don't think IBM, HP, Sun etc sell their UNIX machines just to ISPs or..? And these are the machines where the master account data is stored? It might very well be your bank.. I've browsed a bit.. they seem to be using one (or more) S/390 (zSeries). Although a different branch office indeed seems to have replaced it for a couple pSeries machines with AIX and some Veritas clusters but I don't know what the purpose of this installation is. But in general I'd think that mainframes are still dominant here. From what I've heard, all transactions are also printed, in real-time, on paper (by high-speed lineprinters), so that even when the machines fail completely and lose transaction data, there is still a hardcopy log. At least I hope that this is (still) true. mkb. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: FreeBSD MySQL still WAY slower than Linux
On Fri, Jun 17, 2005 at 11:26:56PM +0200, Owe Andr? J?rgensen wrote.. Wilko Bulte wrote: On Fri, Jun 17, 2005 at 11:12:06PM +0200, Matthias Buelow wrote.. Wilko Bulte [EMAIL PROTECTED] writes: If you give me $5 per Unix system found there I can retire here and now. For financial transaction processing, and the customer's accounts? Yes. Go and visit the London City and check their computer rooms. You will be surprised about the number of UNIX boxes. You don't think IBM, HP, Sun etc sell their UNIX machines just to ISPs or..? I hope it's not my bank.. It might very well be your bank.. I'm sorry to say it, but there is a lot of mainframes a quite few unix boxes in the central accounting and transfer departments. remember that there are a shitload of Cobol Mainframes that are still used by a lot of banks.. Sure. But that does not mean there are not a lot of UNIX machines carrying high-value financial data in the banking world. What we forgot: there are quite some Tandem boxes too, for things like dealing rooms and ATM networks etc. -- Wilko Bulte [EMAIL PROTECTED] ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: FreeBSD MySQL still WAY slower than Linux
On Fri, Jun 17, 2005 at 02:26:48PM -0700, Javier Henderson wrote.. Wilko Bulte wrote: On Fri, Jun 17, 2005 at 11:12:06PM +0200, Matthias Buelow wrote.. Wilko Bulte [EMAIL PROTECTED] writes: If you give me $5 per Unix system found there I can retire here and now. For financial transaction processing, and the customer's accounts? Yes. Go and visit the London City and check their computer rooms. You will be surprised about the number of UNIX boxes. You don't think IBM, HP, Sun etc sell their UNIX machines just to ISPs or..? But are those Unix servers actually processing bank transactions and holding customer accounts? Why not? As an aside: what do you think telecom operators run their main billing systems on? UNIX... Any idea what downtime costs per hour on those systems? -- Wilko Bulte [EMAIL PROTECTED] ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: FreeBSD MySQL still WAY slower than Linux
Javier Henderson wrote: Wilko Bulte wrote: [ ... ] Yes. Go and visit the London City and check their computer rooms. You will be surprised about the number of UNIX boxes. You don't think IBM, HP, Sun etc sell their UNIX machines just to ISPs or..? But are those Unix servers actually processing bank transactions and holding customer accounts? Some of 'em, sure. They tended to use a lot of Sun E or HP Apollo 9000 boxen. They also used Unix boxes a lot for trading system/forecasting, often using inhouse software development and a bit of outside consulting. At one point, SBC had over 3000 NeXT systems there. [ I worked at a company which developed and deployed NEXTSTEP software for the various big banks in Chicago, FNBC, SBC, UBS, and the CBX (commodity exchange). ITS, run by a guy called Ted Shelton. ] -- -Chuck PS: You'd be surprised at how many ATMs and POS machines are running IBM's OS/2 ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: FreeBSD MySQL still WAY slower than Linux
Wilko Bulte wrote: On Fri, Jun 17, 2005 at 02:26:48PM -0700, Javier Henderson wrote.. Wilko Bulte wrote: On Fri, Jun 17, 2005 at 11:12:06PM +0200, Matthias Buelow wrote.. Wilko Bulte [EMAIL PROTECTED] writes: If you give me $5 per Unix system found there I can retire here and now. For financial transaction processing, and the customer's accounts? Yes. Go and visit the London City and check their computer rooms. You will be surprised about the number of UNIX boxes. You don't think IBM, HP, Sun etc sell their UNIX machines just to ISPs or..? But are those Unix servers actually processing bank transactions and holding customer accounts? Why not? As an aside: what do you think telecom operators run their main billing systems on? UNIX... I'm sure some do. Others run theirs on VMS. Any idea what downtime costs per hour on those systems? A lot. -jav ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: FreeBSD MySQL still WAY slower than Linux
--On Freitag, 17. Juni 2005 23:10 Uhr +0200 Matthias Buelow [EMAIL PROTECTED] wrote: Andreas Braukmann [EMAIL PROTECTED] writes: That makes your arguments pointless. I wouldn't even think of running a database server on an async mounted filesystem; all the more I wouldn't connect a drive with enabled write cache to a production box. So you remount all filesystems -o sync on your FreeBSD servers? And you're still satisfied with the performance? no. But I don't mount them async, either. The default noasync in combination with softupdates on disks with disabled write caches is perfectly fine with me. -Andreas ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: FreeBSD MySQL still WAY slower than Linux
On Fri, Jun 17, 2005 at 02:47:54PM -0700, Javier Henderson wrote.. Wilko Bulte wrote: On Fri, Jun 17, 2005 at 02:26:48PM -0700, Javier Henderson wrote.. Wilko Bulte wrote: On Fri, Jun 17, 2005 at 11:12:06PM +0200, Matthias Buelow wrote.. Wilko Bulte [EMAIL PROTECTED] writes: If you give me $5 per Unix system found there I can retire here and now. For financial transaction processing, and the customer's accounts? Yes. Go and visit the London City and check their computer rooms. You will be surprised about the number of UNIX boxes. You don't think IBM, HP, Sun etc sell their UNIX machines just to ISPs or..? But are those Unix servers actually processing bank transactions and holding customer accounts? Why not? As an aside: what do you think telecom operators run their main billing systems on? UNIX... I'm sure some do. Others run theirs on VMS. Most run Tru64. Not a lot run VMS. We had stock exchanges run VMS. Like the Dutch Stock Exchange and the Australian one for example. Any idea what downtime costs per hour on those systems? A lot. -jav --- end of quoted text --- -- Wilko Bulte [EMAIL PROTECTED] ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: FreeBSD MySQL still WAY slower than Linux
Andreas Braukmann [EMAIL PROTECTED] writes: no. But I don't mount them async, either. The default noasync in combination with softupdates on disks with disabled write caches is perfectly fine with me. Noasync only makes sense in the absence of softupdates. With softupdates, metadata is written asynchronously (I mean, that's the whole point, or at least half of it.) Besides, I thought you were talking about synchronous mounts (i.e., synchronous metadata _and_ data writes, which for most uses are just impractical). mkb. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: FreeBSD MySQL still WAY slower than Linux
Wilko Bulte wrote: On Fri, Jun 17, 2005 at 11:26:56PM +0200, Owe Andr? J?rgensen wrote.. Wilko Bulte wrote: On Fri, Jun 17, 2005 at 11:12:06PM +0200, Matthias Buelow wrote.. Wilko Bulte [EMAIL PROTECTED] writes: If you give me $5 per Unix system found there I can retire here and now. For financial transaction processing, and the customer's accounts? Yes. Go and visit the London City and check their computer rooms. You will be surprised about the number of UNIX boxes. You don't think IBM, HP, Sun etc sell their UNIX machines just to ISPs or..? I hope it's not my bank.. It might very well be your bank.. I'm sorry to say it, but there is a lot of mainframes a quite few unix boxes in the central accounting and transfer departments. remember that there are a shitload of Cobol Mainframes that are still used by a lot of banks.. Sure. But that does not mean there are not a lot of UNIX machines carrying high-value financial data in the banking world. What we forgot: there are quite some Tandem boxes too, for things like dealing rooms and ATM networks etc. this is a FreeBSD vs Linux MySQL performance thread. not a pissing contest about banking mainframes... ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: FreeBSD MySQL still WAY slower than Linux
matthias, On Fri, Jun 17, 2005 at 11:12:06PM +0200, Matthias Buelow wrote: Wilko Bulte [EMAIL PROTECTED] writes: If you give me $5 per Unix system found there I can retire here and now. For financial transaction processing, and the customer's accounts? I hope it's not my bank.. i know i'm not so well thought of around these parts .. but for my $AUD0.02 worth. my last two contracts, believe it or not i was a systems analyst for some 12 years before i was retired out of my last contract to become a permanently disabled man, now on permanent disability welfare. the nature of my disabilites leaves me with impeared communications skills and severe chronic pain, for which i take lareg quantities of very heavy duty analgesics .. whchi also impear teh (already impearde) communications skills. i'm writing to let you know that two of australias largest banks not only run whooping great mainframes but also run mainframe UNIX, no not linux but commercial UNIX and for the 6 plus years i worked in teh backoffice in a development on a cash management tool the only errors i saw the mainfreme and its unix operating system make were directly attributable to human errors .. mainly misskeying on teh transactions scripts or latter when teh OCR readers didn't deccipher the humans handwriting on teh transactons slipps. also but in teh lmosta rare as hens teeth was a poorly MICR encoded transaction script that gage ambigious results on multiple passes through the decoder that lead to poor quality data. umm yes computers make mistakes, and mainframes make bigger mistakes, and unix makes really big mistakes but its usually the case that its been told precisely to do that, whchis wrong by its human handler. please note: i'm not putting teh tellers and data operatiors on teh freing line. its teh banks management that loking to squeeze every last drop of profit from n aging, ols and creaking system thats making all these so called computer errors .. its so easy to accuse somebody or thing when its not able (or given a chance) to defend itself. sory i;m starting to mount my soap box here .. tak care matthias mainframes are only very big unix boxen in desguise. best wish and most warm regards jonathan -- powered by .. QNX, OS9 and freeBSD -- http://caamora com au/operating system === appropriate solution in an inappropriate world === ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: FreeBSD MySQL still WAY slower than Linux
On 17 Jun, David Sze wrote: AFAIK, SCSI disks normally have write caching disabled. All the ones that I've encountered in recent years have had write caching enabled. I always have to remember to use camcontrol to disable WCE when I install a new disk. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: FreeBSD MySQL still WAY slower than Linux
On Fri, 2005-Jun-17 10:38:34 -0400, David Sze wrote: It turns out that the problem was the same thing everyone usually points the finger at, but no one actually mentioned this time: Linux mounts its partitions async by default. This shouldn't be an issue here. The FreeBSD default has always been that data is written asynchronously (see below) and there should be virtually no metadata updates in a database application. If an application needs control over when the data is physically written to the disk (eg a database server), it needs to use fsync(2) and/or msync(2) calls. If Linux (or FreeBSD) isn't complying with fsync(2) or msync(2) semantics then it has a serious problem. super-smack select-key 5.4-RELEASE ~20,000 queries/second 6.0-CURRENT ~24,000 queries/second CentOS w/async ~36,000 queries/second CentOS w/sync ~26,000 queries/second I can't see where this benchmark is doing any writes so I'd like to see an explanation of the difference in CentOS performance figures before making any decision on CentOS vs FreeBSD. super-smack update-select 5.4-RELEASE ~4,000 queries/second 6.0-CURRENT ~4,500 queries/second CentOS w/async ~7,500 queries/second CentOS w/sync ~750 queries/second That last CentOS number is not a typo, it was an order of magnitude slower. That's a surprising difference - I wouldn't have expected it to be so large. A couple of people have mentioned the impact of journalling. Journalling improves performance by converting time-critical random I/Os into time-critical sequential I/Os and background random I/Os - and sequential I/O is many orders of magnitude faster than random I/O. All transactional databases do their own journalling (REDO logs). As long as the database correctly issues filesystem synchronisation commands and the filesystem correctly implements them, database application, a journalling filesystem provides no benefits. A more interesting test would be a client that issues a series of updates to a server and, immediately after receiving the acknowledge for the last update turns, off the server's power. After the server is rebooted, confirm that all the updates have been applied correctly. Filesystem I/O behaviour: DataMetadata Mount type asyncasync async async sync 'traditional' UFS asyncasync[*] UFS + softupdates sync sync sync 'Metadata' covers directory updates and some inode updates [*] softupdates controls write ordering to ensure on-disk consistency. -- Peter Jeremy ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: FreeBSD MySQL still WAY slower than Linux
On Fri, 2005-Jun-17 23:42:08 +0200, Wilko Bulte wrote: On Fri, Jun 17, 2005 at 02:26:48PM -0700, Javier Henderson wrote.. Wilko Bulte wrote: Yes. Go and visit the London City and check their computer rooms. You will be surprised about the number of UNIX boxes. You don't think IBM, HP, Sun etc sell their UNIX machines just to ISPs or..? But are those Unix servers actually processing bank transactions and holding customer accounts? Unix and mainframes are not mutually exclusive - the major mainframe vendors will be happy to supply Unix on their mainframes. The big benefit of mainframes is data integrity - your typical mainframe will have error detection and/or correction on _all_ data paths, including through the ALU, all levels of cache and all I/O paths. The other benefit of mainframes is massive I/O bandwidth and the ability to usefully use the available bandwidth. Why not? As an aside: what do you think telecom operators run their main billing systems on? UNIX... Any idea what downtime costs per hour on those systems? Not just billing systems. My employer sells Unix systems used for call processing (intelligent networks) as well as PABX's built on Unix kernels. And downtime at the call processing end is more expensive than the billing end - customers won't notice if the bill is hr late (or a call is undercharged) but they do notice if they can't ring the home-delivery pizza shop when they're hungry. I think this is getting somewhat off-topic: I don't think any banks or telcos have business critical systems running on FreeBSD or Linux with MySQL databases. And the FreeBSD-S/390 port is nowhere near Tier-1 status yet. -- Peter Jeremy ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: FreeBSD MySQL still WAY slower than Linux
You can set the environment variable LIBPTHREAD_SYSTEM_SCOPE to force libpthread to use system scope. This is easier than rebuilding libpthread (with SYSTEM_SCOPE_ONLY defined) and allows you to use M:N for some applications and 1:1 for others. Is the sysctl kern.threads.thr_scope_sys supposed to achieve the same thing ? using the environment variable solves a different problem I have, but setting the sysctl doesn't. Is there any way to force pthreads to system scope by default ? -pcf. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: FreeBSD MySQL still WAY slower than Linux
On Mon, 13 Jun 2005, Pete French wrote: You can set the environment variable LIBPTHREAD_SYSTEM_SCOPE to force libpthread to use system scope. This is easier than rebuilding libpthread (with SYSTEM_SCOPE_ONLY defined) and allows you to use M:N for some applications and 1:1 for others. Is the sysctl kern.threads.thr_scope_sys supposed to achieve the same thing ? using the environment variable solves a different problem I have, but setting the sysctl doesn't. Is there any way to force pthreads to system scope by default ? kern.threads.thr_scope_sys is for libthr only. Reread the above for the answer to your last question. -- DE ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: FreeBSD MySQL still WAY slower than Linux
Reread the above for the answer to your last question. Sorry, rephrased - 'How can I set that environment variable for all processes?' I'm kind of embarassed to have to ask, as this should surely be very simple, but I cant think of anywhere to set system-wide environment variables which all processes will have. I've only ever done this in shell profiles before and I cant think of anywhere global to set something like this. I tried 'man environ' and similar but it doesnt help ? -pcf. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: FreeBSD MySQL still WAY slower than Linux
On Mon, 13 Jun 2005, Pete French wrote: Reread the above for the answer to your last question. Sorry, rephrased - 'How can I set that environment variable for all processes?' login.conf perhaps? I'm kind of embarassed to have to ask, as this should surely be very simple, but I cant think of anywhere to set system-wide environment variables which all processes will have. I've only ever done this in shell profiles before and I cant think of anywhere global to set something like this. I tried 'man environ' and similar but it doesnt help The answer to your question was in parenthesis (rebuild libpthread with SYSTEM_SCOPE_ONLY defined). -- DE ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: FreeBSD MySQL still WAY slower than Linux
On Tue, 14 Jun 2005 01:24, Pete French wrote: I'm kind of embarassed to have to ask, as this should surely be very simple, but I cant think of anywhere to set system-wide environment variables which all processes will have. I've only ever done this in shell profiles before and I cant think of anywhere global to set something like this. I tried 'man environ' and similar but it doesnt help Not sure you can actually.. Setting it in login.conf might do almost what you want. Although in the context of this discussion you could add it to the mysql user login script I imagine. -- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au The nice thing about standards is that there are so many of them to choose from. -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C pgp8EOQk0Dp45.pgp Description: PGP signature
Re: FreeBSD MySQL still WAY slower than Linux
Just wondering: How much processor migration takes place on linux mysql? Do the threads mostly stick to the same processors? I've noticed that on FreeBSD the 4BSD scheduler doesn't do much to preserve cache coherency. What sort of cache/TLB misses do you see running mysql linux vs. mysql freebsd? -Jon On Sat, 11 Jun 2005, Robert Watson wrote: On Fri, 10 Jun 2005, Steve Roome wrote: We're using mostly: 5.4-STABLE FreeBSD 5.4-STABLE #0: Mon Jun 6 12:22:18 BST 2005 In my experience, the following factors make a big performance difference: - Thread package. In 5.x, you get process scope threads by default, but it turns out MySQL is tuned for system scope threads, and this is particularly visible in the supersmack benchmark, which competes many client processes against a few server threads. I'm not sure what the condition is of libthr on 5.x, but you could give it a spin. In 6.x, libthr has been largely rewritten and is a great deal faster. I think there's a compile-time option to make libpthread use system scope threads but the details ellude me. The Linuxthreads library may well provide a substantial improvement -- not as good for MySQL as the 6.x libthr, but perhaps much more appropriate than libpthread. - Locking model. Make sure that debug.mpsafenet is set to 1 (i.e., there aren't components in the kernel that force Giant over the network stack. Chances are there are none, but it's worth checking). - Twiddling hyper-threading, which helps or hurts differently in various configurations. - On a UP system, consider compiling a kernel without options SMP to reduce locking overhead. I've found the single largest remaining factor to be threading package -- over the past year or so I've about doubled MySQL performance on 5.x leading up to 5.3, largely through SMP locking work, but the remainder of the difference appears to be in the threading package. Robert N M Watson ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED] ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: FreeBSD MySQL still WAY slower than Linux
Steve Roome wrote: We're using mostly: 5.4-STABLE FreeBSD 5.4-STABLE #0: Mon Jun 6 12:22:18 BST 2005 This is on a Dell PowerEdge 2850. (2 * 2.8 GHz Xeons, 4GB ram, disks), we've been keeping up with stable because supposedly all these new fixes to threading will help us out here. We're trying to get FreeBSD to perform reasonably well, in comparison to Linux, or even what we should expect to see. We're getting about half the performance we get from gentoo on the same application (mysql). [snip] Thanks in advance for anyone that has a clue on this, and has anyone figured out why FreeBSD is just so amazingly slow compared to Linux. Have you looked around for different compilers and/or different compiler options? I was just remembering how different code can be, depending on which gcc, for example, was used, and definitely which optimization. (i.e. Try gcc -v on both systems to see if they match; next see if all compiler options match when they are compiling like -march=pentiumpro.) Meanwhile, I have heard good things about compiler fill in the blank for whatever. Not too long ago, I remember hearing about people who preferred to use, say, an Intel compiler for certain things. It might be interesting to see if FreeBSD 4.11 is just as slow as 5.x. And try feeding the right compiler flags using /etc/make.conf or its equivalent. You should also think about whether the file systems are mounted using similar, or equally-performing systems. Rumour has it that Linux file systems performance is [flame bait mysteriously deleted]... Your benchmark may produce some interesting results, for example, depending on whether it thrashes a disk, or mainly hits memory. Do they perform the same on small sized (cached) lookups and then FreeBSD bogs down on disk throughput, for example? Last, but not least, I have heard some not-so-impressive things about MySQL 4.1 when compared to 4.0. Perhaps the things I heard were in reality specific to FreeBSD, and so by dropping back to 4.0 on a test server, you might see an unexpected performance boost? (Be sure and delete the tables between runs.) 4.0 is still in the ports tree, and I have heard of some who wished they never upgraded to 4.1. But going backwards is not pretty for a live database, so test both versions now. Billy ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: FreeBSD MySQL still WAY slower than Linux
On Fri, 10 Jun 2005, Steve Roome wrote: We're using mostly: 5.4-STABLE FreeBSD 5.4-STABLE #0: Mon Jun 6 12:22:18 BST 2005 In my experience, the following factors make a big performance difference: - Thread package. In 5.x, you get process scope threads by default, but it turns out MySQL is tuned for system scope threads, and this is particularly visible in the supersmack benchmark, which competes many client processes against a few server threads. I'm not sure what the condition is of libthr on 5.x, but you could give it a spin. In 6.x, libthr has been largely rewritten and is a great deal faster. I think there's a compile-time option to make libpthread use system scope threads but the details ellude me. The Linuxthreads library may well provide a substantial improvement -- not as good for MySQL as the 6.x libthr, but perhaps much more appropriate than libpthread. - Locking model. Make sure that debug.mpsafenet is set to 1 (i.e., there aren't components in the kernel that force Giant over the network stack. Chances are there are none, but it's worth checking). - Twiddling hyper-threading, which helps or hurts differently in various configurations. - On a UP system, consider compiling a kernel without options SMP to reduce locking overhead. I've found the single largest remaining factor to be threading package -- over the past year or so I've about doubled MySQL performance on 5.x leading up to 5.3, largely through SMP locking work, but the remainder of the difference appears to be in the threading package. Robert N M Watson ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: FreeBSD MySQL still WAY slower than Linux
On 6/11/05, Robert Watson [EMAIL PROTECTED] wrote: I think there's a compile-time option to make libpthread use system scope threads but the details ellude me. The Linuxthreads library may well provide a substantial improvement -- not as good for MySQL as the 6.x libthr, but perhaps much more appropriate than libpthread. It is a sysctl in -current kern.threads.thr_scope, it had a different name under 5-stable but does the same thing I think. Jiawei -- Without the userland, the kernel is useless. --inspired by The Tao of Programming ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: FreeBSD MySQL still WAY slower than Linux
I've been working with Steve on this project. We've been playing with various tuning
factors, including kernel changes, different stripe sizes on the RAID, my.cnf
tuning, libmap.conf, and although we can gain a bit here and there, we can't account for
the doubling of performance with Gentoo. Anyway, I've included the dmesg and kernel
config.
And /etc/make.conf ?
The Gentoo install was pretty vanilla-flavoured, as neither Steve or I had
installed Gentoo before, and both of us are pretty rusty on any form of Linux.
IIRC Gentoo on install detects the processor type and sets
for gcc the -march option. FreeBSD does not. Also Gentoo defaults
to -O3 (or -O2? I don't have it anymore to check...), so better
to par in that also.
Since Gentoo compiles practically everything in place,
these parameters might affect the results quite much.
At least I would check this ;-)
BTW, if you will make world and kernel with -march set, you
probably better patch it, or you might get a broken loader
(sorry for cutpaste, tabs might be broken):
$ cat progs/loader.patch
--- /usr/src/lib/libstand/Makefile.orig Fri Jun 10 14:03:07 2005
+++ /usr/src/lib/libstand/Makefile Fri Jun 10 14:03:45 2005
@@ -20,6 +20,7 @@
.endif
.if ${MACHINE_ARCH} == i386
CFLAGS+= -mpreferred-stack-boundary=2
+CFLAGS+= -mno-sse2
.endif
.if ${MACHINE_ARCH} == powerpc
CFLAGS+= -msoft-float -D_STANDALONE
--- /usr/src/sys/boot/ficl/Makefile.origFri Jun 10 14:04:05 2005
+++ /usr/src/sys/boot/ficl/Makefile Fri Jun 10 14:04:29 2005
@@ -12,6 +12,7 @@
.endif
.if ${MACHINE_ARCH} == i386 || ${MACHINE_ARCH} == amd64
CFLAGS+= -mpreferred-stack-boundary=2
+CFLAGS+= -mno-sse2
.endif
.if ${MACHINE_ARCH} == powerpc
CFLAGS+= -msoft-float
Similar (with more -mno-smthng) patches are applied by obrien to HEAD,
but not to STABLE yet AFAIK, for more see recent discussions in freebsd-current,
subj: Newest loader...
Incidentally, this does not seem to be I/O-bound. The data is big enough to
stay in the table cache anyway.
I just noticed these particular tests were done on FreeBSD without HTT, whereas
the Gentoo test was. However, I can tell you that in earlier runs, the
difference between HTT and non-HTT on FreeBSD for this benchmark was negligible.
Regards,
Tom
--- [snip] ---
Copyright (c) 1992-2005 The FreeBSD Project.
Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994
The Regents of the University of California. All rights reserved.
FreeBSD 5.4-STABLE #0: Thu Jun 9 09:13:03 BST 2005
[EMAIL PROTECTED]:/usr/src/sys/i386/compile/PE2850_i386_4
Timecounter i8254 frequency 1193182 Hz quality 0
CPU: Intel(R) Xeon(TM) CPU 2.80GHz (2793.01-MHz 686-class CPU)
Origin = GenuineIntel Id = 0xf41 Stepping = 1
Features=0xbfebfbffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CLFLUSH,DTS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE
real memory = 3489398784 (3327 MB)
avail memory = 3418517504 (3260 MB)
--
V.Chukharev
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: FreeBSD MySQL still WAY slower than Linux
One thing more... I've seen a message on a PostgreSQL list that MySQL can _silently_ change the type of the tables if it cannot find some library. Check that you have really same DBs in Gentoo and FreeBSD. -- V.Chukharev ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
general libthread questions [Was: Re: FreeBSD MySQL still WAY slower than Linux]
Am Samstag, 11. Juni 2005 10:00 schrieb Robert Watson: On Fri, 10 Jun 2005, Steve Roome wrote: [...] - Thread package. In 5.x, you get process scope threads by default, but it turns out MySQL is tuned for system scope threads, and this is particularly visible in the supersmack benchmark, which competes many client processes against a few server threads. I'm not sure what the condition is of libthr on 5.x, but you could give it a spin. In 6.x, libthr has been largely rewritten and is a great deal faster. I think there's a compile-time option to make libpthread use system scope threads but the details ellude me. The Linuxthreads library may well provide a substantial improvement -- not as good for MySQL as the 6.x libthr, but perhaps much more appropriate than libpthread. OT, but can someone please gvie me a link which describes the pthread and lib_thr stuff. And how would I tell a port to compile with a specific threading library (if my understanding is correct)? Maybe one can name typical applications for specific threading libraries? Thanks a lot, -Harry pgpxccEoGLn7W.pgp Description: PGP signature
Re: FreeBSD MySQL still WAY slower than Linux
Robert Watson wrote: On Fri, 10 Jun 2005, Steve Roome wrote: We're using mostly: 5.4-STABLE FreeBSD 5.4-STABLE #0: Mon Jun 6 12:22:18 BST 2005 In my experience, the following factors make a big performance difference: - Thread package. In 5.x, you get process scope threads by default, but it turns out MySQL is tuned for system scope threads, and this is particularly visible in the supersmack benchmark, which competes many client processes against a few server threads. I'm not sure what the condition is of libthr on 5.x, but you could give it a spin. In 6.x, libthr has been largely rewritten and is a great deal faster. I think there's a compile-time option to make libpthread use system scope threads but the details ellude me. The Linuxthreads library may well provide a substantial improvement -- not as good for MySQL as the 6.x libthr, but perhaps much more appropriate than libpthread. You can set the environment variable LIBPTHREAD_SYSTEM_SCOPE to force libpthread to use system scope. This is easier than rebuilding libpthread (with SYSTEM_SCOPE_ONLY defined) and allows you to use M:N for some applications and 1:1 for others. -- DE ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: FreeBSD MySQL still WAY slower than Linux
On Fri, Jun 10, 2005 at 06:05:37PM +0100, Steve Roome wrote: We're using mostly: 5.4-STABLE FreeBSD 5.4-STABLE #0: Mon Jun 6 12:22:18 BST 2005 Show your kernel config etc. Kris pgpfXpy1EB8Ez.pgp Description: PGP signature
Re: FreeBSD MySQL still WAY slower than Linux
Hi Kris, On 10 Jun 2005, at 18:17, Kris Kennaway wrote: Show your kernel config etc. I've been working with Steve on this project. We've been playing with various tuning factors, including kernel changes, different stripe sizes on the RAID, my.cnf tuning, libmap.conf, and although we can gain a bit here and there, we can't account for the doubling of performance with Gentoo. Anyway, I've included the dmesg and kernel config. The Gentoo install was pretty vanilla-flavoured, as neither Steve or I had installed Gentoo before, and both of us are pretty rusty on any form of Linux. Incidentally, this does not seem to be I/O-bound. The data is big enough to stay in the table cache anyway. I just noticed these particular tests were done on FreeBSD without HTT, whereas the Gentoo test was. However, I can tell you that in earlier runs, the difference between HTT and non-HTT on FreeBSD for this benchmark was negligible. Regards, Tom --- [snip] --- Copyright (c) 1992-2005 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD 5.4-STABLE #0: Thu Jun 9 09:13:03 BST 2005 [EMAIL PROTECTED]:/usr/src/sys/i386/compile/PE2850_i386_4 Timecounter i8254 frequency 1193182 Hz quality 0 CPU: Intel(R) Xeon(TM) CPU 2.80GHz (2793.01-MHz 686-class CPU) Origin = GenuineIntel Id = 0xf41 Stepping = 1 Features=0xbfebfbffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE ,MCA,CMOV,PAT,PSE36,CLFLUSH,DTS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE real memory = 3489398784 (3327 MB) avail memory = 3418517504 (3260 MB) ACPI APIC Table: DELL PE BKC ioapic0: Changing APIC ID to 7 ioapic1: Changing APIC ID to 8 ioapic1: WARNING: intbase 32 != expected base 24 ioapic2: Changing APIC ID to 9 ioapic2: WARNING: intbase 64 != expected base 56 ioapic3: Changing APIC ID to 10 ioapic3: WARNING: intbase 96 != expected base 88 ioapic0 Version 2.0 irqs 0-23 on motherboard ioapic1 Version 2.0 irqs 32-55 on motherboard ioapic2 Version 2.0 irqs 64-87 on motherboard ioapic3 Version 2.0 irqs 96-119 on motherboard npx0: math processor on motherboard npx0: INT 16 interface acpi0: DELL PE BKC on motherboard acpi0: Power Button (fixed) Timecounter ACPI-fast frequency 3579545 Hz quality 1000 acpi_timer0: 24-bit timer at 3.579545MHz port 0x808-0x80b on acpi0 cpu0: ACPI CPU on acpi0 pcib0: ACPI Host-PCI bridge port 0xcf8-0xcff on acpi0 pci0: ACPI PCI bus on pcib0 pcib1: ACPI PCI-PCI bridge at device 2.0 on pci0 pci1: ACPI PCI bus on pcib1 pcib2: ACPI PCI-PCI bridge at device 0.0 on pci1 pci2: ACPI PCI bus on pcib2 amr0: LSILogic MegaRAID 1.51 mem 0xdfec-0xdfef, 0xd80f-0xd80f irq 46 at device 14.0 on pci2 amr0: LSILogic PERC 4e/Di Firmware 513O, BIOS H418, 256MB RAM pcib3: ACPI PCI-PCI bridge at device 0.2 on pci1 pci3: ACPI PCI bus on pcib3 pcib4: ACPI PCI-PCI bridge at device 4.0 on pci0 pci4: ACPI PCI bus on pcib4 pcib5: ACPI PCI-PCI bridge at device 5.0 on pci0 pci5: ACPI PCI bus on pcib5 pcib6: ACPI PCI-PCI bridge at device 0.0 on pci5 pci6: ACPI PCI bus on pcib6 em0: Intel(R) PRO/1000 Network Connection, Version - 1.7.35 port 0xecc0-0xecff mem 0xdfbe-0xdfbf irq 64 at device 7.0 on pci6 em0: Ethernet address: 00:11:43:ec:b1:7f em0: Speed:N/A Duplex:N/A pcib7: ACPI PCI-PCI bridge at device 0.2 on pci5 pci7: ACPI PCI bus on pcib7 em1: Intel(R) PRO/1000 Network Connection, Version - 1.7.35 port 0xdcc0-0xdcff mem 0xdf9e-0xdf9f irq 65 at device 8.0 on pci7 em1: Ethernet address: 00:11:43:ec:b1:80 em1: Speed:N/A Duplex:N/A pcib8: ACPI PCI-PCI bridge at device 6.0 on pci0 pci8: ACPI PCI bus on pcib8 pcib9: ACPI PCI-PCI bridge at device 0.0 on pci8 pci9: ACPI PCI bus on pcib9 pcib10: ACPI PCI-PCI bridge at device 0.2 on pci8 pci10: ACPI PCI bus on pcib10 pcib11: ACPI PCI-PCI bridge at device 30.0 on pci0 pci11: ACPI PCI bus on pcib11 pci11: display, VGA at device 13.0 (no driver attached) isab0: PCI-ISA bridge at device 31.0 on pci0 isa0: ISA bus on isab0 atapci0: Intel ICH5 UDMA100 controller port 0xfc00-0xfc0f, 0x376,0x170-0x177,0x3f6,0x1f0-0x1f7 at device 31.1 on pci0 ata0: channel #0 on atapci0 ata1: channel #1 on atapci0 atkbdc0: Keyboard controller (i8042) port 0x64,0x60 irq 1 on acpi0 atkbd0: AT Keyboard irq 1 on atkbdc0 kbd0 at atkbd0 sio0: 16550A-compatible COM port port 0x3f8-0x3ff irq 4 flags 0x10 on acpi0 sio0: type 16550A orm0: ISA Option ROMs at iomem 0xec000-0xe,0xc-0xcafff on isa0 sc0: System console at flags 0x100 on isa0 sc0: VGA 16 virtual consoles, flags=0x300 vga0: Generic ISA VGA at port 0x3c0-0x3df iomem 0xa-0xb on isa0 sio1: configured irq 3 not in bitmap of probed irqs 0 sio1: port may not be enabled Timecounter TSC frequency 2793011648 Hz quality 800 Timecounters tick every 10.000 msec acd0: CDROM SAMSUNG CD-ROM SN-124/N104 at ata0-master PIO4 amrd0: LSILogic MegaRAID logical drive on amr0 amrd0:
Re: FreeBSD MySQL still WAY slower than Linux
* Steve Roome ([EMAIL PROTECTED]) wrote: We're trying to get FreeBSD to perform reasonably well, in comparison to Linux, or even what we should expect to see. We're getting about half the performance we get from gentoo on the same application (mysql). Fancy giving CURRENT a try? For the record, we run FreeBSD 5.3 in production as our master database server without problems, so long as we keep the few heavy queries we do off it: Uptime: 6044357 Threads: 146 Questions: 1963912006 Slow queries: 1842 Opens: 182277 Flush tables: 3733 Open tables: 357 Queries per second avg: 324.917 But it would be nice not to fall back on Linux for our slaves to do the heavy lifting. Maybe FreeBSD 6 will be less disappointing in this regard. -- Thomas 'Freaky' Hurst http://hur.st/ ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: FreeBSD MySQL still WAY slower than Linux
Steve Roome wrote: We're using mostly: 5.4-STABLE FreeBSD 5.4-STABLE #0: Mon Jun 6 12:22:18 BST 2005 This is on a Dell PowerEdge 2850. (2 * 2.8 GHz Xeons, 4GB ram, disks), we've been keeping up with stable because supposedly all these new fixes to threading will help us out here. We're trying to get FreeBSD to perform reasonably well, in comparison to Linux, or even what we should expect to see. We're getting about half the performance we get from gentoo on the same application (mysql). The discussion on the 'freebsd-threads' mailing list about a year ago seems to match our experiences nowadays pretty well: http://lists.freebsd.org/pipermail/freebsd-threads/2004-May/002002.html Nothing much seems to have changed, although lots of people claim that FreeBSD 5.x is now fine, it doesn't seem to be. Here's a rough breakdown of the sort of performance we're seeing, this is the default select-key super-smack but setup for innodb rather than myisam. Using the simple 'select-key.smack' Super-Smack benchmark (50 clients with 1000 runs each): OS CPUsBuild ThreadingKqueries/sec - FreeBSD 1 Pro KSE 10.6 FreeBSD 1 Pro libthr 10.6 FreeBSD 2 Pro libthr 14.4 FreeBSD 2 Source libthr 14.5 FreeBSD 2 Source KSE/P (static) 15.7 FreeBSD 2 Source KSE/P (dynamic) 15.8 FreeBSD 2 Source KSE/S (dynamic) 15.8 FreeBSD 2 Pro KSE 15.9 FreeBSD 2 Source LinuxThreads 17.7 Gentoo 2 Source NPTL 34.0 !! (KSE/P = KSE with Process Scope Threading, KSE/S = KSE with System Scope Threading) Quick ideas: Have you tried a kernel with PREEMPTION enabled? I haven't quantified the effect, but it's improved performance in some situations. Have you tried increasing vfs.read_max? Guy -- Guy Helmer, Ph.D., Principal System Architect, Palisade Systems, Inc. [EMAIL PROTECTED] http://www.palisadesys.com/~ghelmer ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: FreeBSD MySQL still WAY slower than Linux
Hi Guy, On 10 Jun 2005, at 21:37, Guy Helmer wrote: Have you tried a kernel with PREEMPTION enabled? I haven't quantified the effect, but it's improved performance in some situations. Have you tried increasing vfs.read_max? Thanks for your suggestions... I've given them a go, and it looks like there's no discernible difference in performance for either/ both, on KSE, libthr or LinuxThreads. =( Regards, Tom ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
