Martin Nilsson wrote:
Steve Roome wrote:
Sorry, good point, here's the my.cnf we're using. Please note however
that although the configuration may not be optimal, we have been using
the same config for benchmarking on Linux also. No matter how broken
this my.cnf is we still shouldn't find MySQL running half the speed on
an "identical" setups only switching from Linux to FreeBSD.
Hi,
Have you tested some more real-world queries on Linux vs. FreeBSD?
The select-key.smack is a very simple test, a very small table (5.3MB
on disk, 90k rows), no joins/sorts and only selects from index. Maybe
the performance difference just affects the
connect/communication/thread syncronistaion and thus this simple test
is a worst case test of performance between Linux & FreeBSD.
I'll try to set up something here so I can make some tests too...
How does a P4/Xeon compare to Athlon64/Opteron on these tests (Linux
vs FreeBSD) the long pipeline in the P4 (Prescott/Nocona) is difficult
to optimize for, SMP syncronisation is also much more expensive on
netburst, maybe the are better at doing this in Linux?
Regards,
Martin
it's better to have several tests that use different functions. for
example, testing inserts, then joins and inserts or just joins, selects
only, maybe some more complicated queries with math functions involved.
perhaps we should come up with a test bed that will specifically test
all of these areas on their own and then come up with some real world
queries for an all-encompassing overview.
and as far as Xeon/P4 goes... it's not very practical. AMDs are far and
away the better performing processor right now and the Intel part will
only introduce bottlenecks in the testing... don't even get me started
on EM64T...
_______________________________________________
freebsd-performance@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-performance
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
