MySQL Forums
Forum List  »  NDB clusters

Re: Performance on Solaris 5.9
Posted by: Mikael Ronström
Date: March 01, 2005 10:20AM

Hello,
I am not sure of the reasons why you have worse performance on Sun than on
Opteron but here is at least something you can try out.

We did lots of tests on big Sun servers a couple of years ago and the performance
of the ndbd processes is greatly enhanced if the ndbd process is locked to a CPU.
By locking the process to a CPU one avoids that the process is wandering around on
different CPU's and getting lot of interconnect traffic in the server. Also much better
usage of the processor caches (which are fairly big I presume for a E 2900)

Rgrds Mikael

J�rg Nowak wrote:
> Hello,
>
> I tried first time MySQL Cluster 4.1.10 on two SUN
> E 2900 with 12 GB RAM , 4 CPU (dual core) on
> each.
>
> But we performed a really bad performance. We
> started some client which sends maximums of
> randomized Read / write requests. We started the
> clients step by step and it was strange to see
> that the performance on each client seems to be
> shared :
> with one client : 750 Request per second
> wtih two clients: 600 Request per second (each
> client)
> wtih three clients: 500 Request per second (each
> client)
> wtih four clients: 400 Request per second (each
> client)
> wtih four clients: 300 Request per second (each
> client)
> The load on the machines was 40 % 50 %
>
>
> Before we did the same on two Sun Fire VZ20
> Opterons with 4 GB on each maschine and we got a
> much better performance on each client. (1200
> Requests per sec)
>
> What could be the reason for it ?
>

Options: ReplyQuote


Subject
Views
Written By
Posted
2932
March 01, 2005 05:04AM
Re: Performance on Solaris 5.9
2319
March 01, 2005 10:20AM
1964
March 03, 2005 02:31AM
2047
March 03, 2005 03:02AM


Sorry, you can't reply to this topic. It has been closed.

Content reproduced on this site is the property of the respective copyright holders. It is not reviewed in advance by Oracle and does not necessarily represent the opinion of Oracle or any other party.