Comments on: PBXT benchmarks http://www.mysqlperformanceblog.com/2007/04/08/pbxt-benchmarks/ Percona's MySQL & InnoDB performance and scalability blog Sat, 11 Feb 2012 16:45:54 +0000 hourly 1 http://wordpress.org/?v=3.2.1 By: Scaling to 256-way the Sun way | MySQL Performance Blog http://www.mysqlperformanceblog.com/2007/04/08/pbxt-benchmarks/comment-page-1/#comment-376317 Scaling to 256-way the Sun way | MySQL Performance Blog Wed, 12 Nov 2008 04:55:32 +0000 http://www.mysqlperformanceblog.com/2007/04/08/pbxt-benchmarks/#comment-376317 [...] is hard to tell without knowing what the queries are but if you just want to look at the queries - check this out - these are a year and a half old benchmarks on the single MySQL instance showing over 50.000 [...] [...] is hard to tell without knowing what the queries are but if you just want to look at the queries – check this out – these are a year and a half old benchmarks on the single MySQL instance showing over 50.000 [...]

]]> By: unisol http://www.mysqlperformanceblog.com/2007/04/08/pbxt-benchmarks/comment-page-1/#comment-208855 unisol Thu, 29 Nov 2007 18:45:30 +0000 http://www.mysqlperformanceblog.com/2007/04/08/pbxt-benchmarks/#comment-208855 tried running super-smack on the server - the situation was not that bad for 8 cores, neither it was much better - 8 cores gave at most 20% more transactions than 4 or didn't give anything visible at all... So basically I hit both mysql scalability and FreeBSD scheduler issues... ./super-smack -d mysql update-select.smack 120 500 4 cpus: Query Barrel Report for client smacker connect: max=8ms min=0ms avg= 1ms from 120 clients Query_type num_queries max_time min_time q_per_s select_index 60000 12 0 7253.63 update_index 60000 23 0 7253.63 8cpus: Query Barrel Report for client smacker connect: max=63ms min=1ms avg= 31ms from 120 clients Query_type num_queries max_time min_time q_per_s select_index 60000 15 0 7464.76 update_index 60000 10 0 7464.76 ./super-smack -d mysql select-key.smack 120 500 4cpus: Query Barrel Report for client smacker1 connect: max=57ms min=0ms avg= 11ms from 120 clients Query_type num_queries max_time min_time q_per_s select_index 120000 17 0 23242.07 8cpus: Query Barrel Report for client smacker1 connect: max=10ms min=0ms avg= 2ms from 120 clients Query_type num_queries max_time min_time q_per_s select_index 120000 8 0 27558.95 tried running super-smack on the server – the situation was not that bad for 8 cores, neither it was much better – 8 cores gave at most 20% more transactions than 4 or didn’t give anything visible at all… So basically I hit both mysql scalability and FreeBSD scheduler issues…

./super-smack -d mysql update-select.smack 120 500
4 cpus:
Query Barrel Report for client smacker
connect: max=8ms min=0ms avg= 1ms from 120 clients
Query_type num_queries max_time min_time q_per_s
select_index 60000 12 0 7253.63
update_index 60000 23 0 7253.63

8cpus:
Query Barrel Report for client smacker
connect: max=63ms min=1ms avg= 31ms from 120 clients
Query_type num_queries max_time min_time q_per_s
select_index 60000 15 0 7464.76
update_index 60000 10 0 7464.76

./super-smack -d mysql select-key.smack 120 500
4cpus:
Query Barrel Report for client smacker1
connect: max=57ms min=0ms avg= 11ms from 120 clients
Query_type num_queries max_time min_time q_per_s
select_index 120000 17 0 23242.07

8cpus:
Query Barrel Report for client smacker1
connect: max=10ms min=0ms avg= 2ms from 120 clients
Query_type num_queries max_time min_time q_per_s
select_index 120000 8 0 27558.95

]]> By: unisol http://www.mysqlperformanceblog.com/2007/04/08/pbxt-benchmarks/comment-page-1/#comment-208848 unisol Thu, 29 Nov 2007 17:25:42 +0000 http://www.mysqlperformanceblog.com/2007/04/08/pbxt-benchmarks/#comment-208848 6 cores gives 11-13 requests/s, which is way better launching screen and 2x "top" with update interval set to 0 in a couple of its windows and renicing them to -20 (which significantly loaded 2 cores) + "screen" got a huge bytes flow as well - Did Not affect performance in any way, I was still getting the same 11-13 requests/s, even after renicing of mysqld and httpd to 20. (FreeBSD-7.0, sched_ule). 6 cores gives 11-13 requests/s, which is way better
launching screen and 2x “top” with update interval set to 0 in a couple of its windows and renicing them to -20 (which significantly loaded 2 cores) + “screen” got a huge bytes flow as well – Did Not affect performance in any way, I was still getting the same 11-13 requests/s, even after renicing of mysqld and httpd to 20. (FreeBSD-7.0, sched_ule).

]]> By: unisol http://www.mysqlperformanceblog.com/2007/04/08/pbxt-benchmarks/comment-page-1/#comment-208835 unisol Thu, 29 Nov 2007 17:02:30 +0000 http://www.mysqlperformanceblog.com/2007/04/08/pbxt-benchmarks/#comment-208835 I've encounterd completely weird results with mysql on an 8cpu server - it performed 3!! :( times slower than on the same 4cpu server: FreeBSD-6.2/7.0, amd64 both sched_4bsd an sched_ule tested 2xIntel Xeon(R) CPU E5335 @ 2.00GHz (quad core) 4GB ram mysql-4.1.22/from FreeBSD ports apache+php tests done with apache benchmark on a web page that does some 20 selects (one is select count(*) as count from ... where ... - the slowest one), and a couple of inserts/updates as well. ab -c 125 -n 500 http://dumb-sql-design/dumb-sql-page.php results: 2 cores (kernel params.h modified with MAXCPU set to 2 and 4 to diable extra cores): 9-11 requests/s 4 cores: 18-20 requests/s all 8 cores: 5-7 requests/s, whatever did I try to do - nothing really helped. The kernel doesn't boot with 5 cores :) I’ve encounterd completely weird results with mysql on an 8cpu server – it performed 3!! :( times slower than on the same 4cpu server:
FreeBSD-6.2/7.0, amd64
both sched_4bsd an sched_ule tested
2xIntel Xeon(R) CPU E5335 @ 2.00GHz (quad core)
4GB ram
mysql-4.1.22/from FreeBSD ports
apache+php

tests done with apache benchmark on a web page that does some 20 selects (one is select count(*) as count from … where … – the slowest one), and a couple of inserts/updates as well.
ab -c 125 -n 500 http://dumb-sql-design/dumb-sql-page.php

results:
2 cores (kernel params.h modified with MAXCPU set to 2 and 4 to diable extra cores):
9-11 requests/s

4 cores:
18-20 requests/s

all 8 cores:
5-7 requests/s, whatever did I try to do – nothing really helped.

The kernel doesn’t boot with 5 cores :)

]]> By: Norton Security http://www.mysqlperformanceblog.com/2007/04/08/pbxt-benchmarks/comment-page-1/#comment-197003 Norton Security Sun, 18 Nov 2007 16:35:04 +0000 http://www.mysqlperformanceblog.com/2007/04/08/pbxt-benchmarks/#comment-197003 Well, sounds interesting to me. Thanks for submitting the figures showing the performance details. Do you ever use FreeBSD for MySQL benchmarks? To my dismay, I noticed that the 5.0.24 version breaks at around 100 CUC on my 1Gb RAM pentium 4 box running FreeBSD 6.2. I went through the Performance Tuning tips found at MySQL's website, but it doesn't seem to be helping to increase the CUC number without crashing the database engine. Any suggestions, monks? Well, sounds interesting to me. Thanks for submitting the figures showing the performance details. Do you ever use FreeBSD for MySQL benchmarks? To my dismay, I noticed that the 5.0.24 version breaks at around 100 CUC on my 1Gb RAM pentium 4 box running FreeBSD 6.2. I went through the Performance Tuning tips found at MySQL’s website, but it doesn’t seem to be helping to increase the CUC number without crashing the database engine. Any suggestions, monks?

]]> By: MySQL Performance Blog » MySQL Storage Engines - PBXT http://www.mysqlperformanceblog.com/2007/04/08/pbxt-benchmarks/comment-page-1/#comment-124766 MySQL Performance Blog » MySQL Storage Engines - PBXT Mon, 14 May 2007 21:51:35 +0000 http://www.mysqlperformanceblog.com/2007/04/08/pbxt-benchmarks/#comment-124766 [...] we already seen in our benchmarks PBXT both performs and scales well in many read workloads. We did not check writes because this is [...] [...] we already seen in our benchmarks PBXT both performs and scales well in many read workloads. We did not check writes because this is [...]

]]> By: Roland Bouman http://www.mysqlperformanceblog.com/2007/04/08/pbxt-benchmarks/comment-page-1/#comment-106287 Roland Bouman Tue, 10 Apr 2007 18:27:09 +0000 http://www.mysqlperformanceblog.com/2007/04/08/pbxt-benchmarks/#comment-106287 Peter, thanks for pointing that out. That seems indeed to be an important difference. Thanks ;) Peter,

thanks for pointing that out. That seems indeed to be an important difference.

Thanks ;)

]]> By: peter http://www.mysqlperformanceblog.com/2007/04/08/pbxt-benchmarks/comment-page-1/#comment-106094 peter Tue, 10 Apr 2007 08:55:10 +0000 http://www.mysqlperformanceblog.com/2007/04/08/pbxt-benchmarks/#comment-106094 One important note about PBXT write benchmarks - PBXT currently does not flushes data and logs to the disk, meaning it does not call fsync() or uses other techniques. These means it can hardly be compare to Innodb apples to apples. innodb_flush_logs_at_trx_commit=2 settings is kind of close, but not exactly because Innodb will still flush logs every second and flush data files when it writes to them while PBXT will relay on OS buffering so you can't predict when data gets flushed. One important note about PBXT write benchmarks – PBXT currently does not flushes data and logs to the disk, meaning it does not call fsync() or uses other techniques.

These means it can hardly be compare to Innodb apples to apples. innodb_flush_logs_at_trx_commit=2 settings is kind of close, but not exactly because Innodb will still flush logs every second and flush data files when it writes to them while PBXT will relay on OS buffering so you can’t predict when data gets flushed.

]]> By: Roland Bouman http://www.mysqlperformanceblog.com/2007/04/08/pbxt-benchmarks/comment-page-1/#comment-106063 Roland Bouman Tue, 10 Apr 2007 06:57:37 +0000 http://www.mysqlperformanceblog.com/2007/04/08/pbxt-benchmarks/#comment-106063 Great, very interesting! I did a few tests re. speed of INSERTs to compare InnoDB, PBXT, MyISAM (and Archive and CSV). These were all single thread tests and I don't dare to claim a general applicability of the test, but: Although somewhat slower than MyISAM, PBXT was in all cases relatively very close as compared to InnoDB. Also, whereas the difference between PBXT and MyISAM remained quite constant as more rows where inserted (I went up to 4G rows) InnoDB seemed to take increasingly more time. Great, very interesting!

I did a few tests re. speed of INSERTs to compare InnoDB, PBXT, MyISAM (and Archive and CSV). These were all single thread tests and I don’t dare to claim a general applicability of the test, but:

Although somewhat slower than MyISAM, PBXT was in all cases relatively very close as compared to InnoDB. Also, whereas the difference between PBXT and MyISAM remained quite constant as more rows where inserted (I went up to 4G rows) InnoDB seemed to take increasingly more time.

]]> By: peter http://www.mysqlperformanceblog.com/2007/04/08/pbxt-benchmarks/comment-page-1/#comment-105634 peter Mon, 09 Apr 2007 09:25:36 +0000 http://www.mysqlperformanceblog.com/2007/04/08/pbxt-benchmarks/#comment-105634 Right. We need to run both high volume (IO Bound) and Update benchmarks but we need proper server hardware to do so. These were done on loaner boxes which readers of these blog gave us access to. It was not long enough to get proper round of IO bound benchmarks. Also it is better to do these on systems with several hard drives in RAID so you can see how efficiently system can use these. Right. We need to run both high volume (IO Bound) and Update benchmarks but we need proper server hardware to do so. These were done on loaner boxes which readers of these blog gave us access to. It was not long enough to get proper round of IO bound benchmarks.

Also it is better to do these on systems with several hard drives in RAID so you can see how efficiently system can use these.

]]>