Why is MySQL nearly twice as fast on Linux/AMD64 Vs.FreeBSD/AMD64?

[JG]

At 05:55 PM 5/21/2004 +0100, you wrote:
>As the benchmark is still looking network dependent 0 -> 6ms RR times
>I'd try the bge tweak Andrew suggested:
><quote>
>Without adding an interface, I'd just suggest doing something
>like changing sc->bge_rx_max_coal_bds from 64 to 1 around like 2350 of
>dev/bge/if_bge.c, rebuilding the driver, and seeing what changes.  I'm
>betting that will turn off recv interrupt coalescing and reduce your
>latency some.
></quote>
>It may be the source of your issue.

Doesn't look like it.

Changing it from 64 to 1 seems to have decreased performance:



--------------------------------------------------------------------
SERVER CONFIG:

** FreeBSD AMD64 **
amd64f# uname -a
FreeBSD 5.2-CURRENT FreeBSD 5.2-CURRENT #0: Wed May 19 03:37:58 PDT 2004
Without -CURRENT debugging in kernel.

MySQL: Ver 4.0.20 for portbld-freebsd5.2 on amd64 (FreeBSD port: 
mysql-server-4.0.20)
With mysql-server40.diffs
With libpthreads
BUILD_OPTIMIZED=yes
BUILD_STATIC=yes




---------------------------------------------------------------------
Each benchmark ran 4 times and highest was shown.
---------------------------------------------------------------------

Benchmark results:


REMOTE (Over 100mbit LAN dc0 to bge0):



- Using default mysql config settings (empty/missing my.cnf)
- Using SCHED_4BSD
- With if_bge.c sc->bge_rx_max_coal_bds 64 to 1 test hack


devbox# super-smack update-select.smack 30 10000
Query Barrel Report for client smacker
connect: max=38ms  min=1ms avg= 16ms from 30 clients
Query_type      num_queries     max_time        min_time        q_per_s
select_index    300000  2       0       2356.21
update_index    300000  11      0       2356.21


Vs. same, without if_bge.c hack...


- Using default mysql config settings (empty/missing my.cnf)
- Using SCHED_4BSD

devbox# super-smack update-select.smack 30 10000
Query Barrel Report for client smacker
connect: max=28ms  min=2ms avg= 16ms from 30 clients
Query_type      num_queries     max_time        min_time        q_per_s
select_index    300000  7       0       2685.53
update_index    300000  5       0       2685.53


- Using my-huge.cnf
- Using SCHED_4BSD kernel
- With if_bge.c sc->bge_rx_max_coal_bds 64 to 1 test hack


devbox# super-smack update-select.smack 30 10000
Query Barrel Report for client smacker
connect: max=33ms  min=1ms avg= 21ms from 30 clients
Query_type      num_queries     max_time        min_time        q_per_s
select_index    300000  2       0       2350.52
update_index    300000  11      0       2350.52

Vs. same, without if_bge.c hack...

- Using my-huge.cnf
- Using SCHED_4BSD kernel


devbox# super-smack update-select.smack 30 10000
Query Barrel Report for client smacker
connect: max=34ms  min=1ms avg= 16ms from 30 clients
Query_type      num_queries     max_time        min_time        q_per_s
select_index    300000  4       0       3229.12
update_index    300000  8       0       3229.12




>Also compare local to local and see how that shapes up, as it will
>give an indication of where any issue lies i.e. threading / process
>or network.


Various local tests up next.