Why is MySQL nearly twice as fast on Linux?
Chris Elsworth
chris at shagged.org
Mon May 24 08:03:52 PDT 2004
On Mon, May 24, 2004 at 10:13:36AM -0400, Daniel Eischen wrote:
> On Mon, 24 May 2004, Petri Helenius wrote:
>
> > Thomas Hurst wrote:
> >
> > >
> > >Only if you're only using one table. While this is true in this
> > >benchmark, it isn't really relevent because we're only testing selects,
> > >which are pure reads. There should be no table locking getting in the
> > >way; Linux's performance would seem to confirm this.
> > >
> >
> > I changed the test to use InnoDB table type and saw 50% performance
> > improvement.
>
> Are you able to run the test using InnoDB under Linux also
> (just to see if Linux also gets a ~50% improvement)?
I have to aplogise unreservedly. Despite thoroughly testing the
different table types for the last half an hour, I've only just
realised that I had skip-innodb in my.cnf and thus the InnoDB tables
were actually being created as MyISAM tables.
Please consider all the InnoDB results just posted as void and
replaced with the following:
root at cluestick:~/super-smack-1.2# src/super-smack smacks/select-key_i.smack 4 100000
Query Barrel Report for client smacker1
connect: max=0ms min=0ms avg= 0ms from 4 clients
Query_type num_queries max_time min_time q_per_s
select_index 800000 0 0 22509.05
This one got a bit more interesting. Since InnoDB is transactional, it
maintains a log of updates. Every update incurs a log write. With
innodb_flush_log_at_trx_commit =1 ..
root at cluestick:~/super-smack-1.2# src/super-smack smacks/update-select_i.smack 4 100000
Query Barrel Report for client smacker
connect: max=1ms min=0ms avg= 0ms from 4 clients
Query_type num_queries max_time min_time q_per_s
select_index 400000 0 0 2517.41
update_index 400000 1 0 2517.41
However, with
innodb_flush_log_at_trx_commit = 0, meaning InnoDB does *not* have to
flush the log after every update:
root at cluestick:~/super-smack-1.2# src/super-smack smacks/update-select_i.smack 4 100000
Query Barrel Report for client smacker
connect: max=0ms min=0ms avg= 0ms from 4 clients
Query_type num_queries max_time min_time q_per_s
select_index 400000 0 0 8473.54
update_index 400000 0 0 8473.54
Obviously, the first update test is thoroughly disk bound; 2500
transactions per second to disk, at a rate of 13MB/s. Select
performance is unchanged as to the setting of
innodb_flush_log_at_trx_commit, as you might expect.
--
Chris
More information about the freebsd-threads
mailing list