Re: MySQL Cluster is slow - Brendan Bouffler - com.mysql.lists.cluster

23 messages in com.mysql.lists.clusterRe: MySQL Cluster is slow

From	Sent On	Attachments
Mindaugas	18 Oct 2006 23:23
Jon Stephens	18 Oct 2006 23:49
Mindaugas	19 Oct 2006 02:50
Hartmut Holzgraefe	19 Oct 2006 02:54
Einar Rustad	19 Oct 2006 04:47
Mindaugas	19 Oct 2006 05:44
Hartmut Holzgraefe	19 Oct 2006 05:55
Stewart Smith	19 Oct 2006 06:09
Mikael Ronström	20 Oct 2006 05:28
JM	20 Oct 2006 05:31
Mindaugas	20 Oct 2006 06:49
Kevin Burton	23 Oct 2006 00:08
Kevin Burton	23 Oct 2006 00:12
Einar Rustad	24 Oct 2006 12:06
Dirk Dunger	25 Oct 2006 07:02
Mindaugas	25 Oct 2006 07:16
Dirk Dunger	26 Oct 2006 05:45
Brendan Bouffler	26 Oct 2006 18:10
Mikael Ronström	26 Oct 2006 21:35
Mikael Ronström	26 Oct 2006 21:52
Stewart Smith	26 Oct 2006 22:45
Mikael Ronström	27 Oct 2006 06:34
Dirk Dunger	28 Oct 2006 03:05

Subject:	Re: MySQL Cluster is slow
From:	Brendan Bouffler (bren...@hp.com)
Date:	10/26/2006 06:10:28 PM
List:	com.mysql.lists.cluster

On Wed, 2006-10-25 at 17:17 +0300, Mindaugas wrote:

Can't really remember how IPoIB compared to SCI, but if you're interested, I might try to find the numbers.

I did some testing here in the Lab with IPoIB on Voltaire IB cards. It was a good apples-to-apples comparison because I used the same hardware and then just switched to dedicated gigE NICs to compare the throughput.

In a 2 or 4 node cluster (a node in my case being a multi-core box with one ndbd process running on each core), the IPoIB performed about 4% better on transactions/sec throughput.

I used dbt2 and flexbench to load the cluster up in a variety of ways, but 4% better than gigE was about as good as it got. The real limitation here is the TCP-stack latency in the kernel. Bandwidth is almost never the issue, and physical transport latency (which is where IB gets its reputation - ~6 us) is only marginal compared to the whole TCP stack latency of around 40-50us.

IMHO, don't spend any money on IB for this stuff until there's an NDB transporter for IB that bypasses TCP/IP and uses something like uDAPL ...

Dirk's people were/are working on this, but I don't know what the state is ... Dirk: how can we find out the status of this? Can I get a copy to play with?