DBT-2 is a TPC-C like OLTP benchmark, and very popular amongst
many MySQL users. It is used by MySQL QA team to test the
stability and performance before release. However, steps to setup
DBT-2 is a little bit messy, and its README files include some
dummy information. So I introduce you these steps below:
1. Download it!
You can download the source code from here: http://osdldbt.sourceforge.net/
2. Required packages
The following perl packages are required to build DBT-2.
Unfortunately, configure script doesn't complain even if they are
missing. Install them using, e.g. CPAN.
shell> sudo cpan Statistics::Descriptive
shell> sudo cpan Test::Parser
shell> sudo cpan Test::Reporter
If you want to make a graph from the output, you have to install
gnuplot in advance. e.g. Ubuntu …
Well I am still not happy with a lot of the code, but I have had some people ask me to help test my attempt at a new MySQL benchmark. So I cleaned up the code a bit and pushed what I had to LaunchPad. It’s way to early for this to be ready for prime time, I am using it to stress flash, but as I do i am still finding issues, so use at your own risk. My goal is to make this more generic and allow user customizable SQL files to be loaded in…. something like:
1 | select * from table where a =? | rand | a | 1000 2 | select * from table1,table2 where table1.id=table2.id and c = ? and d=? | rand,1-200 | c,d | 10
This would mean execute query #1 , using a random value from a 1000 times in a loop before exiting… and then execute query 2, 10 times using a rand value from c, and a value between 1-200 for d….
But that is a ways off.
For now I support 4 tests which are hard coded in:
mx = mixed wokload of …[Read more]
I recently released some RAID testing I did using the sysbench testing framework. In light of the recent attention paid to multi-core CPU scalability, I have been working on some related tests trying to identify sources of contention using that same set of tests.
After effectively turning off every single innodb safety setting
(like flush_log_at_trx_commit, checksums, doublewrite, etc.), and
not seeing any real performance increase, I started to wonder
what was going on.
Surely my test client server wasn't the problem, it had plenty of
idle CPU according to top, right? Wrong.
I've been able to drive more QPS to my mysql test servers by
starting up parallel sysbench tests from multiple test servers,
but using (more or less) the same number of total test threads.
I recently released some RAID testing I did using the sysbench testing framework. In light of the recent attention paid to multi-core CPU scalability, I have been working on some related tests trying to identify sources of contention using that same set of tests.
After effectively turning off every single innodb safety setting
(like flush_log_at_trx_commit, checksums, doublewrite, etc.), and
not seeing any real performance increase, I started to wonder
what was going on.
Surely my test client server wasn't the problem, it had plenty of
idle CPU according to top, right? Wrong.
I've been able to drive more QPS to my mysql test servers by
starting up parallel sysbench tests from multiple test servers,
but using (more or less) the same number of total test threads.
I've been doing some benchmarking recently to satisfy the curiosity about 5.1's performance compared with 4.1. The major question this time revolves around how much additional performance an external RAID array can provide (for us it's typically beyond the 6 drives a Dell 2950 can hold).
These tests are done on using an MSA-30 drive enclosure with
15k-SCSI drives. The testing framework is sysbench
oltp. The test names are hopefully
fairly obvious: selects = single selects, reads = range
tests, xacts = transaction tests, etc. Transaction tests
are counting individual queries, not transactions. The
"Rdm" tests are using a uniform distribution, whereas the
non-'Rdm' tests are 75% of queries are using 10% of the rows.
…
[Read more]I've been doing some benchmarking recently to satisfy the curiosity about 5.1's performance compared with 4.1. The major question this time revolves around how much additional performance an external RAID array can provide (for us it's typically beyond the 6 drives a Dell 2950 can hold).
These tests are done on using an MSA-30 drive enclosure with
15k-SCSI drives. The testing framework is sysbench
oltp. The test names are hopefully
fairly obvious: selects = single selects, reads = range
tests, xacts = transaction tests, etc. Transaction tests
are counting individual queries, not transactions. The
"Rdm" tests are using a uniform distribution, whereas the
non-'Rdm' tests are 75% of queries are using 10% of the rows.
…
[Read more]There's been a lot of rumors floating around internally at Yahoo that it's best to turn off some of your CPU cores when using Innodb, especially if you have a machine with > 4 cores. At this point there's no question in my mind that Innodb doesn't perform much better when you double your cores from 4 to 8, but I really wanted to know if 8 actually performed worse.
To test, I used a Dell 2950 with 6 drives and a simple mysqlslap
test script. There's basically no I/O going on here, just a
small table in memory being queried a lot. To be fair, I
actually got this test from Venu. I used maxcpu=4 in my grub.conf to
limit the cpus (I also tested with tasksel and it seemed to have
the same effect as maxcpu).
There's been a lot of rumors floating around internally at Yahoo that it's best to turn off some of your CPU cores when using Innodb, especially if you have a machine with > 4 cores. At this point there's no question in my mind that Innodb doesn't perform much better when you double your cores from 4 to 8, but I really wanted to know if 8 actually performed worse.
To test, I used a Dell 2950 with 6 drives and a simple mysqlslap
test script. There's basically no I/O going on here, just a
small table in memory being queried a lot. To be fair, I
actually got this test from Venu. I used maxcpu=4 in my grub.conf to
limit the cpus (I also tested with tasksel and it seemed to have
the same effect as maxcpu).
My earlier post mysql versus postgresql brought me lots of negative comments - that i did not compare the transactional database of pgsql with the transactional engine (innodb) of mysql. The main reason why i did not do that was because i had found InnoDB to be very slow as compared to MyISAM.
But after all those comments i ran the benchmarks again using the same scripts and the same technology
I created and ran some simple tests on mysql and postgresql to figure out which one is faster. It is already known that postgresql is more stable and reliable than mysql. pgsql has a rich set of features. It is a complete RDBMS and also supports fulltext search.
All benchmarks were done on my laptop - Intel core 2 duo (2.0 GHz) with 4MB L2 cache & 2 GB ram. I have 64 Bit ubuntu system loaded