Re: INTEL vs. SPARC
In the last episode (Jul 08), mac said: > to keep you up to date: > > we tested with a simple dd-read on different machines and mount-points: > > 400MB file (created with "dd if=/dev/urandom of=file100Mb bs=512 > count=80" on the intel-linux-box): BTW - a 512-byte blocksize is basically testing how fast your kernel can process syscalls. bs=8k or 64k would be a better test of what mysql's activity would be. > reading the file with dd to /dev/null on > a) the sparc-solaris: > local-disk: 12sec > veritas-disk: 24sec (over fiber on symmetrix) 400/12 = 33MB/sec. Reasonable. The 24 second result (16MB/sec) on the symmetrix is pretty low; I would have expected you to be able to max out your fibre link (or at least hit 50% usage, which would be 50 or 100 MB/sec depending on the connection). > b) the intel-linux > local-disk: 2sec 200MB/sec. Very difficult to achieve on most raid-5 controllers you can put in an Intel box. More likely is that you created the file, then immediately re-read it, which means that you just pulled it out of memory. You will probably need to reboot, or dismount and remount the filesystem containing the file to ensure it reads from the disks. -- Dan Nelson [EMAIL PROTECTED] -- MySQL General Mailing List For list archives: http://lists.mysql.com/mysql To unsubscribe:http://lists.mysql.com/[EMAIL PROTECTED]
Re: INTEL vs. SPARC
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 hi there, to keep you up to date: we tested with a simple dd-read on different machines and mount-points: 400MB file (created with "dd if=/dev/urandom of=file100Mb bs=512 count=80" on the intel-linux-box): reading the file with dd to /dev/null on a) the sparc-solaris: local-disk: 12sec veritas-disk: 24sec (over fiber on symmetrix) b) the intel-linux local-disk: 2sec the intel-box does have some pretty modern scsi-disks in a raid-5. the intention was to get a feeling how much the hd's will be a part of the problem. we didn't want to get some absolute benchmarks :-)) so it points to the disks. but now somethin really cool: we took a closer look on our table and tried to figure out why the disks are so important for our select. if you remember: it was a varchar-field that took us some time. the intersection of this varchar-field an an integer-field was one of the major results we wanted. both field for themselfs had around 400.000 rows in the result-set. the intersection (WHERE myvarchar="mac" AND myint=1) only gives 130 to 500 rows. so we finally did something we should have done long before :-( we changed the varchar into a int (creating an extra table for translation) and created a combined index over both fields. the first step brought us 5 to 8 secs speedup and the combined index just got us crazy. it now takes 0.01secs. so for one specific statement the combination of better to index types and combined index with better cardinality helps a lot. but there is still the dependency to the disks. if the intersection of both int-fields wouldn't be such a small result, i am pretty sure the speed would be as bad as before. we will work on it a little bit further. but if you have some comments on that: please help us :-) thanks mac -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.3 (Darwin) iD8DBQFA7YV9vkHn/oGTPXURAmE/AJ4gE6moPl7a6guloK9SErdCzGwIJACgmbsO xXbcdWEQKxmfvo5ijF7ml+U= =NFsh -END PGP SIGNATURE- -- MySQL General Mailing List For list archives: http://lists.mysql.com/mysql To unsubscribe:http://lists.mysql.com/[EMAIL PROTECTED]
Re: INTEL vs. SPARC
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 05.07.2004, at 15:51, JOUANNET, Rodolphe wrote: do you use innodb or myisam tables ? myisam tables. -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.3 (Darwin) iD8DBQFA7P39vkHn/oGTPXURAs+EAJ9dV7ZOQWolUHQcO/CF9UHTx/XhAgCffhfY 73za73KJJjTaGsz1vHxVoqg= =yGOY -END PGP SIGNATURE- -- MySQL General Mailing List For list archives: http://lists.mysql.com/mysql To unsubscribe:http://lists.mysql.com/[EMAIL PROTECTED]
Re: INTEL vs. SPARC
mac <[EMAIL PROTECTED]> wrote: >> Are you running Linux or Solaris on these servers? > sparc: solaris 9 > intel: debian-linux (2.4.21-kernel) To achieve best performance, you better get the Official MySQL binaries from http://www.mysql.com rather then compiling by yourself. This is due to glibc patches applied to glibc for official binaries. -- For technical support contracts, goto https://order.mysql.com/?ref=ensita This email is sponsored by Ensita.net http://www.ensita.net/ __ ___ ___ __ / |/ /_ __/ __/ __ \/ /Egor Egorov / /|_/ / // /\ \/ /_/ / /__ [EMAIL PROTECTED] /_/ /_/\_, /___/\___\_\___/ MySQL AB / Ensita.net <___/ www.mysql.com -- MySQL General Mailing List For list archives: http://lists.mysql.com/mysql To unsubscribe:http://lists.mysql.com/[EMAIL PROTECTED]
Re: INTEL vs. SPARC
mac <[EMAIL PROTECTED]> wrote: > does the speed of mysql depends more on things like the processor than > other resources? Disk speed & memory size are much more important then the CPU. Processor is used to calculate while MySQL is a database. And databases move data back and forth. > if so: what kind of general suggestions can be made about using > select-statements on huge tables to be "fast" over different platforms? Allocate as much memory as you can for key_buffer. Generally, 70% of RAM is a good starting point. -- For technical support contracts, goto https://order.mysql.com/?ref=ensita This email is sponsored by Ensita.net http://www.ensita.net/ __ ___ ___ __ / |/ /_ __/ __/ __ \/ /Egor Egorov / /|_/ / // /\ \/ /_/ / /__ [EMAIL PROTECTED] /_/ /_/\_, /___/\___\_\___/ MySQL AB / Ensita.net <___/ www.mysql.com -- MySQL General Mailing List For list archives: http://lists.mysql.com/mysql To unsubscribe:http://lists.mysql.com/[EMAIL PROTECTED]
Re: intel vs sparc?
What other processes are running on the Solaris box? Solaris tends to favour giving each process a fair share of the processor rather than getting one process (e.g. MySQL) to complete as quick as possible. I suspect that if you compared the time taken for much larger queries on the Solaris machine you would find that it performs better relative to the Linux box. Also, Solaris will be much less agressive in keeping your table cached in memory than Linux is, particularly if there are a lot of other jobs running on it. That is my analysis of this type of problem having tested MySQL under Solaris 9 on an AMD box versus the Linux version on the same machine. I may be talking jibberish however! Cheers Andrew. - Original Message - From: "mac" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Saturday, July 03, 2004 3:10 PM Subject: Re: intel vs sparc? > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > hi bas, > > > You did not provide details on your harddisk in your message, you > > might want to know that > > MySQL performance is highly related to your diskconfiguration. If you > > want to speed it up you could do a softwareraid 0 over as much disks > > that fit in your machine. And also consider disks with a good cache. > > the sparcs are a litte different in case of harddisk's: > the V480 does have a veritas-fs-mountpoint with a symmetrix in > background - i asume that is pretty fast, because it was originally > focused on oracle. > the enterprise does have no raid's and really simple scsi-drives (a > litte old you know ;-) > > in comparison we have raid5 with scsi-disks and this > cciss-compac-controller. > > > so you suggest that there is a huge point in harddisk. > i might have to run a view benchmark tests directly on the disks to see > the thrououtput in reading data(-junks). > > > the only thing that bothers me is: why should the harddisk be such a > big impact if i am using an index and _not_ selecting all data (in > fact: the select brings only a view hundred rows up). > > but i try to figure out if there is a difference in reading between the > sparcs and the intel. > > > thanks for the hint > mac > > > > -BEGIN PGP SIGNED MESSAGE- > > Hash: SHA1 > > > > hi there, > > > > hope this haven't been discussed in that kind of detail in older > > topics: > > > > the facts in short: > > - - we have the same mysql-version (4.0.18) for an intel-machine and a > > sparc-machine. > > - - we have a table with about 5,500,000 rows > > - - we do a "realtivly" simple select on a varchar-50-field (with an > > index of course) > > - - the statement takes 4s on the intel- and 24s on the sparc-machine > > - - we played around with some caching-features on the sparc-side but > > there was no significant increase of speed > > > > the hardware: > > sparc: > > Sun Fire V480 > > 4 x UltraSPARC III Cu Processor 900 MHz > > 16GM RAM > > > > intel: > > Compaq DL380R02 > > 2 x Pentium III 1.1 GHz > > 4 GB RAM > > > > the installation on the sparc was done with a precompiled version. the > > intel-one was compiled by our self (but no special configue-options). > > > > we also ensured that the index on the sparc side is in good shape. > > we also tested it with the same setup on an older enterprise 450 - same > > bade timing. > > > > if you need more detail i can deliver them. > > but i am more interested in a general question: > > > > does the speed of mysql depends more on things like the processor than > > other resources? > > if so: what kind of general suggestions can be made about using > > select-statements on huge tables to be "fast" over different platforms? > > > > i am also aware of the hints about not using to huge logtables for > > statistical output rather then creating small statistic tables. > > this is something we will do, but we also need sort of guidelines for > > future projects. > > > > thanks in advance for your suggestions. > > > > with regards > > mac > > -BEGIN PGP SIGNATURE- > > Version: GnuPG v1.2.3 (Darwin) > > > > iD8DBQFA5YJVvkHn/oGTPXURApvwAKDBBcLtRH+S1+tBLsrFNmimtSki+gCgkQA6 > > MEQxsqwYzRjQx+lN+epJtao= > > =2VNS > > -END PGP SIGNATURE- > > > -BEGIN PGP SIGNATURE- > Version: GnuPG v1.2.3 (Darwin) > > iD8DBQFA5r5jvkHn/oGTPXURAogvAJ9Vccf97+qCYiMesMYA/CV3q0zYAwCeOpiW > zdYgBw/A9TrJATEZBx/yRzU= > =E2Ck > -END PGP SIGNATURE- > > > -- > MySQL General Mailing List > For list archives: http://lists.mysql.com/mysql > To unsubscribe: http://lists.mysql.com/[EMAIL PROTECTED] > > -- MySQL General Mailing List For list archives: http://lists.mysql.com/mysql To unsubscribe:http://lists.mysql.com/[EMAIL PROTECTED]
Re: intel vs sparc?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 hi bas, You did not provide details on your harddisk in your message, you might want to know that MySQL performance is highly related to your diskconfiguration. If you want to speed it up you could do a softwareraid 0 over as much disks that fit in your machine. And also consider disks with a good cache. the sparcs are a litte different in case of harddisk's: the V480 does have a veritas-fs-mountpoint with a symmetrix in background - i asume that is pretty fast, because it was originally focused on oracle. the enterprise does have no raid's and really simple scsi-drives (a litte old you know ;-) in comparison we have raid5 with scsi-disks and this cciss-compac-controller. so you suggest that there is a huge point in harddisk. i might have to run a view benchmark tests directly on the disks to see the thrououtput in reading data(-junks). the only thing that bothers me is: why should the harddisk be such a big impact if i am using an index and _not_ selecting all data (in fact: the select brings only a view hundred rows up). but i try to figure out if there is a difference in reading between the sparcs and the intel. thanks for the hint mac -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 hi there, hope this haven't been discussed in that kind of detail in older topics: the facts in short: - - we have the same mysql-version (4.0.18) for an intel-machine and a sparc-machine. - - we have a table with about 5,500,000 rows - - we do a "realtivly" simple select on a varchar-50-field (with an index of course) - - the statement takes 4s on the intel- and 24s on the sparc-machine - - we played around with some caching-features on the sparc-side but there was no significant increase of speed the hardware: sparc: Sun Fire V480 4 x UltraSPARC III Cu Processor 900 MHz 16GM RAM intel: Compaq DL380R02 2 x Pentium III 1.1 GHz 4 GB RAM the installation on the sparc was done with a precompiled version. the intel-one was compiled by our self (but no special configue-options). we also ensured that the index on the sparc side is in good shape. we also tested it with the same setup on an older enterprise 450 - same bade timing. if you need more detail i can deliver them. but i am more interested in a general question: does the speed of mysql depends more on things like the processor than other resources? if so: what kind of general suggestions can be made about using select-statements on huge tables to be "fast" over different platforms? i am also aware of the hints about not using to huge logtables for statistical output rather then creating small statistic tables. this is something we will do, but we also need sort of guidelines for future projects. thanks in advance for your suggestions. with regards mac -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.3 (Darwin) iD8DBQFA5YJVvkHn/oGTPXURApvwAKDBBcLtRH+S1+tBLsrFNmimtSki+gCgkQA6 MEQxsqwYzRjQx+lN+epJtao= =2VNS -END PGP SIGNATURE- -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.3 (Darwin) iD8DBQFA5r5jvkHn/oGTPXURAogvAJ9Vccf97+qCYiMesMYA/CV3q0zYAwCeOpiW zdYgBw/A9TrJATEZBx/yRzU= =E2Ck -END PGP SIGNATURE- -- MySQL General Mailing List For list archives: http://lists.mysql.com/mysql To unsubscribe:http://lists.mysql.com/[EMAIL PROTECTED]
Re: INTEL vs. SPARC
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 hi andrew, I don't have a vast experience of MySQL on Solaris, but I suspect this is more down to the operating system than any hardware issues. Which version of Solaris are you running on the SPARC box? it's Solaris 9 - SunOS 5.9 64bit. the mysql is a 32bit-version. cu mac -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.3 (Darwin) iD8DBQFA5bd5vkHn/oGTPXURAk+hAJ9HsMq4smLeJ5efK4/+L8wdM7BmcgCfYjMH gLOf+KCDirJtaTYnTlFpSJY= =PuhY -END PGP SIGNATURE- -- MySQL General Mailing List For list archives: http://lists.mysql.com/mysql To unsubscribe:http://lists.mysql.com/[EMAIL PROTECTED]
Re: INTEL vs. SPARC
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 hi andrew, Are you running Linux or Solaris on these servers? sparc: solaris 9 intel: debian-linux (2.4.21-kernel) with regards klaus -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.3 (Darwin) iD8DBQFA5acJvkHn/oGTPXURAlG4AJ9iAHBuX3n/RhCFzN9uj1ssC2VRAgCfcHql n9Tu0EJQUAqk7YsegQxw0So= =YaKf -END PGP SIGNATURE- -- MySQL General Mailing List For list archives: http://lists.mysql.com/mysql To unsubscribe:http://lists.mysql.com/[EMAIL PROTECTED]
Re: INTEL vs. SPARC
Are you running Linux or Solaris on these servers? Andrew. - Original Message - From: "mac" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]> Sent: Friday, July 02, 2004 4:42 PM Subject: INTEL vs. SPARC > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > hi there, > > hope this haven't been discussed in that kind of detail in older topics: > > the facts in short: > - - we have the same mysql-version (4.0.18) for an intel-machine and a > sparc-machine. > - - we have a table with about 5,500,000 rows > - - we do a "realtivly" simple select on a varchar-50-field (with an > index of course) > - - the statement takes 4s on the intel- and 24s on the sparc-machine > - - we played around with some caching-features on the sparc-side but > there was no significant increase of speed > > the hardware: > sparc: > Sun Fire V480 > 4 x UltraSPARC III Cu Processor 900 MHz > 16GM RAM > > intel: > Compaq DL380R02 > 2 x Pentium III 1.1 GHz > 4 GB RAM > > the installation on the sparc was done with a precompiled version. the > intel-one was compiled by our self (but no special configue-options). > > > we also ensured that the index on the sparc side is in good shape. > we also tested it with the same setup on an older enterprise 450 - same > bade timing. > > > if you need more detail i can deliver them. > but i am more interested in a general question: > > does the speed of mysql depends more on things like the processor than > other resources? > if so: what kind of general suggestions can be made about using > select-statements on huge tables to be "fast" over different platforms? > > i am also aware of the hints about not using to huge logtables for > statistical output rather then creating small statistic tables. > this is something we will do, but we also need sort of guidelines for > future projects. > > > thanks in advance for your suggestions. > > with regards > mac > -BEGIN PGP SIGNATURE- > Version: GnuPG v1.2.3 (Darwin) > > iD8DBQFA5YJVvkHn/oGTPXURApvwAKDBBcLtRH+S1+tBLsrFNmimtSki+gCgkQA6 > MEQxsqwYzRjQx+lN+epJtao= > =2VNS > -END PGP SIGNATURE- > > > -- > MySQL General Mailing List > For list archives: http://lists.mysql.com/mysql > To unsubscribe: http://lists.mysql.com/[EMAIL PROTECTED] > -- MySQL General Mailing List For list archives: http://lists.mysql.com/mysql To unsubscribe:http://lists.mysql.com/[EMAIL PROTECTED]
INTEL vs. SPARC
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 hi there, hope this haven't been discussed in that kind of detail in older topics: the facts in short: - - we have the same mysql-version (4.0.18) for an intel-machine and a sparc-machine. - - we have a table with about 5,500,000 rows - - we do a "realtivly" simple select on a varchar-50-field (with an index of course) - - the statement takes 4s on the intel- and 24s on the sparc-machine - - we played around with some caching-features on the sparc-side but there was no significant increase of speed the hardware: sparc: Sun Fire V480 4 x UltraSPARC III Cu Processor 900 MHz 16GM RAM intel: Compaq DL380R02 2 x Pentium III 1.1 GHz 4 GB RAM the installation on the sparc was done with a precompiled version. the intel-one was compiled by our self (but no special configue-options). we also ensured that the index on the sparc side is in good shape. we also tested it with the same setup on an older enterprise 450 - same bade timing. if you need more detail i can deliver them. but i am more interested in a general question: does the speed of mysql depends more on things like the processor than other resources? if so: what kind of general suggestions can be made about using select-statements on huge tables to be "fast" over different platforms? i am also aware of the hints about not using to huge logtables for statistical output rather then creating small statistic tables. this is something we will do, but we also need sort of guidelines for future projects. thanks in advance for your suggestions. with regards mac -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.3 (Darwin) iD8DBQFA5YJVvkHn/oGTPXURApvwAKDBBcLtRH+S1+tBLsrFNmimtSki+gCgkQA6 MEQxsqwYzRjQx+lN+epJtao= =2VNS -END PGP SIGNATURE- -- MySQL General Mailing List For list archives: http://lists.mysql.com/mysql To unsubscribe:http://lists.mysql.com/[EMAIL PROTECTED]
