I’m not sure what point are you trying to make ? Many customers will buy what they are sold and there are multiple ways to make things work. The point is whenever it is the optimal choice and if customer has implemented does not say anything about how optimal this solution was.

I think you’re right about using large SMP as multiple boxes, however I think for medium-large scale applications this happens because we have to because of limited single instance scalability and operational issues. Even in this case we would like to see some relatively small number of instances running. For example running 2 instances on 16 core box, not 16.

Now about performance/memory/disks – the balance here is highly application specific. Some people are able to saturate multiple cores with 2GB worth of data some would have much more data per shard to saturate CPU. When memory is the great factor – some people are running databases which pretty much fit in memory and have very little IO, others have workloads which require much more IO capacity. In many cases there is some optimal ratio between the IO system capacity and memory though you can’t always freely trade things here.

And of course we should not forget about operational pains

Let me explain.

First – Sharding which is the most common architecture for MySQL is a pain. You shard when you have to and if you would be able to stay away from it (while having performance/cost etc where it should be you would not do so). In fact because of problem with MySQL single instance scalability and operational problems (backups, alter table etc) people have to shard sooner than they would have and if MySQL would be more scalable.

Second – when sharding number of boxes (and really instances) matter because of operational complexity etc. Performance optimization and management is more complicated with multiple instances on one server than running on the different servers because of shared hardware. People sharding on middle end will much rather have less MySQL instances. For example 5 shards is much easier to deal with than 50. On the higher end – dealing with 100 shards or with 1000 does not really matter because you have to have it automated.

In the end scaling Single instance applies to all segments while being able to get scalability with multiple instances only to some of them.

But what really is a show stopper for me on Sun T1/T2 architectures is the “single thread performance” – if I would see that even 50% of what you get from recent Opterons/Xeons I would praise it for many apps.

I can see by your comments that you are used to large scale MySQL deployments.
You are right on your sizing note and my initial intent was to have 128GB of RAM on the T5440 but I could not make it happen. My article [http://blogs.sun.com/MrBenchmark] is a first attempt on the T5440 and I am convinced that many other experts will publish on this topic in the near future.

You can enjoy picking on the language. English is not my native and I do not expect to use it perfectly. Speaking about Performance and Scalability in the casual life you use them more broadly You can be speaking for example about the peak performance attained at certain configuration which could mean peak throughput.

The scalability is basically a comparison – you can look at scalability in terms of various hardware configuration, number of disks, database size, number of connections.

Speaking about 24 instances on any Linux machine as I mentioned I do not know – I have not seen such configurations so I can’t comment how it works.

SSD can make the box more interesting. It should be possible to get 56,000 IOPs from direct attached SSD and by the 5 minute rule (http://www.acmqueue.com/modules.php?name=Content&pa=showpage&pid=549&page=1) the box won’t need as much RAM when SSD is used.

You say …

“I can’t tell you about scaling to 24 instances on Linux server because there is really little need for that. Single instance perfectly works with several cores and there are no x86 systems with same amount of cores as there are threads in Sun systems.”

Are you saying that scale-out to multiple instances is not important ? I thought this was the preferred architecture for MySQL database scaling ?
Or are you saying you rarely see need to scale-out as far as 24 instances ?

The reason for asking is that the benefit I see from this performance demonstration/workload from Sun is the ability to run in a scale-out fashion but with the benefits of consolidation which may (and likely do include) space,power and cost savings.

thanks
Tom

No. Depending on workload MySQL can work efficiently with significantly more than one core though it is very load specific. I would say 4 cores is what works reasonably well, some workloads scan scale to 8+ cores (considering x86 Intel/AMD cores).

Sure numbers are not comparable. My point is simply showing the numbers without having any baseline to compare is not very helpful.

The MultiCore scalability of MySQL in my view is scalability of the single instance… though of course can define it differently.

I can’t tell you about scaling to 24 instances on Linux server because there is really little need for that. Single instance perfectly works with several cores and there are no x86 systems with same amount of cores as there are threads in Sun systems.

My main point is – the numbers shown in this case are barely relevant because running so many MySQL instances is highly artificial.