Re: MySQL 5.0.22 , FreeBSD 6.1-STABLE: Benchmark



The FreeBSD zookeepers politely request that visitors not feed the trolls.

-Kip

On 7/4/06, Danial Thom <danial_thom@xxxxxxxxx> wrote:


--- Hugo Silva <hugo@xxxxxxxxxxxxxx> wrote:

> Today I decided to benchmark MySQL 5
> performance on FreeBSD 6.1-STABLE.
> This server is a Dual Xeon 2.8GHz, 4GB of RAM
> and 2x73GB SCSI disks that
> do 320MB/s
>
> For all the tests, I restarted mysqld prior to
> starting the test,
> waited for about 1 minute for it to settle
> down, and ran super smack.
> For the consecutive runs, I executed
> super-smack right after the
> previous run ended.
>
> Switching from HTT to no HTT was achieved by
> machdep.hyperthreading_allowed, and switching
> from/to libpthread/libthr
> was done via libmap.conf.
>
> System:
>
> FreeBSD ?? 6.1-STABLE FreeBSD 6.1-STABLE #3:
> Mon Jul 3 03:10:35 UTC
> 2006 ??@??:/usr/obj/usr/src/sys/DATABASE
> i386
>
> Here are the results:
>
>
> MySQL 5.0.22, built with BUILD_OPTIMIZED=yes
> and WITH_PROC_SCOPE_PTH=yes
>
>
> === 4BSD + libthr + HTT on ===
>
> Run #1
> connect: max=4ms min=1ms avg= 3ms from 10
> clients
> Query_type num_queries max_time
> min_time q_per_s
> select_index 200000 0 0
> 20405.86
>
> Run #2
> connect: max=3ms min=1ms avg= 2ms from 10
> clients
> Query_type num_queries max_time
> min_time q_per_s
> select_index 200000 0 0
> 20253.53
>
> Run #3
> connect: max=4ms min=2ms avg= 2ms from 10
> clients
> Query_type num_queries max_time
> min_time q_per_s
> select_index 200000 0 0
> 20270.33
>
>
>
>
> === 4BSD + libthr + HTT off ===
>
> Run #1
> connect: max=5ms min=2ms avg= 3ms from 10
> clients
> Query_type num_queries max_time
> min_time q_per_s
> select_index 200000 0 0
> 18253.60
>
> Run #2
> connect: max=6ms min=1ms avg= 3ms from 10
> clients
> Query_type num_queries max_time
> min_time q_per_s
> select_index 200000 0 0
> 18350.27
>
> Run #3
> connect: max=4ms min=1ms avg= 2ms from 10
> clients
> Query_type num_queries max_time
> min_time q_per_s
> select_index 200000 0 0
> 18529.71
>
>
> === 4BSD + libpthread + HTT on ===
>
> Run #1:
> connect: max=17ms min=2ms avg= 7ms from 10
> clients
> Query_type num_queries max_time
> min_time q_per_s
> select_index 200000 5 0
> 3935.94
>
>
> Run #2:
> connect: max=18ms min=1ms avg= 8ms from 10
> clients
> Query_type num_queries max_time
> min_time q_per_s
> select_index 200000 2 0
> 3919.89
>
> Run #3:
> connect: max=22ms min=1ms avg= 13ms from 10
> clients
> Query_type num_queries max_time
> min_time q_per_s
> select_index 200000 2 0
> 3911.66
>
>
> === 4BSD + libpthread + HTT off ===
> connect: max=12ms min=1ms avg= 5ms from 10
> clients
>
> Run #1:
> Query_type num_queries max_time
> min_time q_per_s
> select_index 200000 0 0
> 11193.40
>
> Run #2:
> connect: max=6ms min=4ms avg= 5ms from 10
> clients
> Query_type num_queries max_time
> min_time q_per_s
> select_index 200000 0 0
> 11428.30
>
> Run #3:
> connect: max=7ms min=4ms avg= 5ms from 10
> clients
> Query_type num_queries max_time
> min_time q_per_s
> select_index 200000 1 0
> 13714.02
>
>
>
>
>
>
>
>
>
>
>
> === ULE + libthr + HTT on ===
> Run #1:
> connect: max=2ms min=0ms avg= 0ms from 10
> clients
> Query_type num_queries max_time
> min_time q_per_s
> select_index 200000 1 0
> 16179.09
>
> Run #2:
> connect: max=14ms min=0ms avg= 7ms from 10
> clients
> Query_type num_queries max_time
> min_time q_per_s
> select_index 200000 0 0
> 17451.31
>
> Run #3:
> connect: max=5ms min=1ms avg= 3ms from 10
> clients
> Query_type num_queries max_time
> min_time q_per_s
> select_index 200000 1 0
> 15787.02
>
>
> === ULE + libthr + HTT off ===
>
> Run #1:
> connect: max=6ms min=6ms avg= 6ms from 10
> clients
> Query_type num_queries max_time
> min_time q_per_s
> select_index 200000 0 0
> 11588.19
>
> Run #2:
> connect: max=220ms min=2ms avg= 46ms from 10
> clients
> Query_type num_queries max_time
> min_time q_per_s
> select_index 200000 0 0
> 10651.16
>
> Run #3:
> connect: max=10ms min=0ms avg= 5ms from 10
> clients
> Query_type num_queries max_time
> min_time
=== message truncated ===


Instead of wasting your time with BS benchmarks,
why not write a little script that does actual
queries that you might be doing on a real, fully
populated database? And make sure you test with 1
cpu. I don't see any "scaling" from 1 cpu to 2,
so I can't get too excited about supersmack's
miniscule scaling. The only scaling I see going
from 1 cpu to 2 is about 300 extra dollars for
the dual-core cpu.

Besides, HTT will slow everything else on the
system down, so its not practical to turn it on.
For every benchmark that shows a tiny bit of
improvement there are 5 that show degradation.

DT

__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
_______________________________________________
freebsd-performance@xxxxxxxxxxx mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-performance
To unsubscribe, send any mail to "freebsd-performance-unsubscribe@xxxxxxxxxxx"

_______________________________________________
freebsd-performance@xxxxxxxxxxx mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-performance
To unsubscribe, send any mail to "freebsd-performance-unsubscribe@xxxxxxxxxxx"



Relevant Pages

  • Scheduler Economy prototype patch for CFS
    ... X should get more CPU time simply ... the clients, not relative to any client individually. ... today i've implemented a quick prototype of this "Scheduler Economy" ... * Scheduler work account object: it consists of the price, ...
    (Linux-Kernel)
  • Re: [REPORT] cfs-v4 vs sd-0.44
    ... So it would only accumulate "scheduling points" while multiuple clients are actively waiting for it, which actually sounds like exactly the right thing. ... There are subtle semantics with these kinds of things: especially if the scheduling points are only awarded when a process goes to sleep, if X is busy and continues to use the CPU, it wouldn't give any scheduling points back to clients and they really do accumulate with the server. ... The exceptions to this are the various terminal emulators (e.g. xterm, gnome-terminal, etc.) when being ...
    (Linux-Kernel)
  • Re: OSDL Bug 3770
    ... one CPU caused all lower priority tasks on that CPU to be starved, ... > is an environment whose tasks scheduling follow a specific ... > you can proceed in two ways to serve the clients: ... > make an unique FIFO queue for all servers. ...
    (Linux-Kernel)
  • Re: server is using 100% cpu
    ... WAS a cmd process at clients login that looped or something. ... Your SBS server is vastly underpowered!!! ... Sent via Windows Mail on Vista Ultimate connected to SBS R2 ... manager is telling me that system is eating cpu. ...
    (microsoft.public.windows.server.sbs)
  • Re: After Lightening Storm - Computer Will Not Turn on
    ... i'm not about to take a working computer apart to swap a cpu. ... And apparently a whole lot of unused time to repair a failed system. ... a system is down and it needs to be turned around ASAP - especially for business clients - and they don't give a flying shiite how you get it fixed except fast and right - the first time. ...
    (alt.sys.pc-clone.dell)