List:Database Benchmarks« Previous MessageNext Message »
From:Peter Zaitsev Date:January 19 2005 7:29am
Subject:Re: Comparing Linux 2.6/2.4 with read-only sysbench workload with
complex point selects on myisam table
View as plain text  
On Tue, 2005-01-18 at 21:05, Yusuf Goolamabbas wrote:

Yusuf,

Thank you for taking time to take a look at it. 


> I ran the following sysbench command on 2 machines (dual P3-500 with 1GB
> ram and a U2W SCSI disk, query cache and logs were turned off). 
> One machine was Redhat 7.3 with kernel 2.4.28. The other was Fedora Core
> 3 and kernel 2.6.11-rc1. mysql version was 4.0.23 on both machines. I
> had compilation failures on RH 7.3 with mysql 4.1.8

Could you please send me the log in separate Email I'll let our
production team know.  It is not that common version nowadays but
anyway.

> 
> The anticipatory scheduler was used on 2.6 kernels and the tag depth of
> the aic7xxx controller was clamped at 4 via the following modprobe.conf
> command line
> 
> options aic7xxx aic7xxx=global_tag_depth:4

Why did you reduce TCQ Depth ? 


> 
> I am not sure how to interpret the "Test Execution Summary". Whilst the
> queries/sec and read/secs favour the 2.6 kernel. However, other numbers
> in the Test Execution Summary seem to favour the 2.4 kernel. 

Yes.  2.6 kernel seems to do much better. It is however barely depending
on IO subsystem as default table size is just 10000 rows so it will well
fit in memory. 

I would guess process/thread scheduler which was a lot improved in 2.6
is helping you here. 


> 
> I also have numbers with --num-threads=2 where the difference in timings
> between the kernels isn't that much. I seem to recollect reading
> somewhere that connections == threads and this would only change in
> mysql 5.0

Right. Each connection on the client has appropriate thread which
handles it on server. This is not going to change in 5.0   You will be
able to have several cursors per connection but it is other story.


> 
> Command run
> 
> /usr/local/site/sysbench/bin/sysbench --max-requests=20000
> --num-threads=300 --test=oltp --db-ps-mode=disable
> --mysql-table-type=myisam  --oltp-read-only=on --oltp-test-mode=complex
> --oltp-simple-ranges=0 --oltp-sum-ranges=0 --oltp-order-ranges=0
> --oltp-distinct-ranges=0 --oltp-point-selects=50 run
> 
> mysql 4.0.23 on a dual P3-500 with 1GB RAM and one U2W scsi disk
> 
> 2.6.11-rc1/Fedora Core 3
> 
>    queries performed:
>         read:                            1000000
>         write:                           0
>         other:                           40000
>         total:                           1040000
>     transactions:                        20000  (108.84 per sec.)
>     deadlocks:                           0      (0.00 per sec.)
>     read/write requests:                 1000000 (5442.22 per sec.)
>     other operations:                    40000  (217.69 per sec.)
> 
> Test execution summary:
>     total time:                          183.7486s
>     total number of events:              20000
>     total time taken by event execution: 49958.1731
>     per-request statistics:
>          min:                            0.0153s
>          avg:                            2.4979s
>          max:                            56.8752s
>          approx.  95 percentile:         13.5697s
> 
> Threads fairness:
>     distribution:                        34.72/74.56
>     execution:                           28.97/72.13
> 
> 
> 2.4.28/Redhat 7.3
> 
> OLTP test statistics:
>     queries performed:
>         read:                            1014900
>         write:                           0
>         other:                           40596
>         total:                           1055496
>     transactions:                        20298  (35.80 per sec.)
>     deadlocks:                           0      (0.00 per sec.)
>     read/write requests:                 1014900 (1790.10 per sec.)
>     other operations:                    40596  (71.60 per sec.)
> 
> Test execution summary:
>     total time:                          566.9525s
>     total number of events:              20298
>     total time taken by event execution: 3244.7024
>     per-request statistics:
>          min:                            0.0163s
>          avg:                            0.1599s
>          max:                            9.4082s
>          approx.  95 percentile:         0.2502s
> Threads fairness:
>     distribution:                        93.56/97.96
>     execution:                           66.49/88.37


Very interesting.   2.6 kernel runs very fast but it allows some threads
to starve - so you can see higher average response time as well as much
higher 95% percentile response time.   Also  Thread fairness is pretty
poor - this parameters measure what is the difference between number of
requests threads was able to get. In perfect case it should be close 100
meaning all threads processed about same number of requests. 




-- 
Peter Zaitsev, Senior Support Engineer
MySQL AB, www.mysql.com



Thread
Comparing Linux 2.6/2.4 with read-only sysbench workload with complex point selects on myisam tableYusuf Goolamabbas19 Jan
  • Re: Comparing Linux 2.6/2.4 with read-only sysbench workload withcomplex point selects on myisam tablePeter Zaitsev19 Jan
    • Re: Comparing Linux 2.6/2.4 with read-only sysbench workload with complex point selects on myisam tableYusuf Goolamabbas19 Jan
      • Re: Comparing Linux 2.6/2.4 with read-only sysbench workload withcomplex point selects on myisam tablePeter Zaitsev19 Jan