The Sun X4600 appeared to be an ideal machine for studying the Opteron's scaling behaviour. The blade design allows for processors to be physically removed from the system, making it seem possible to make configurations of one to eight sockets by incrementing the number of sockets. Unfortunately this isn't so simple in practise, since each socket functions as a node in a network of HyperTransport links. This network is not constructed in a stepwise fashion but has two specific configurations. As the figure below shows, the connections for a 4-way and an 8-way system are largely different. Alternative configurations are unfortunately not supported, although a BIOS update for the newer M2 is in the making, in order to add support for six processors.
We did manage to get the system running on two sockets, but the performance was clearly inferior compared to what might be expected from a standard server with double Opteron. Presumably, this is caused by the fact that the two sockets in the X4600 can only talk to each other in a roundabout way. Unfortunately, the consequence is that there is no sensible data on the scaling behaviour from one socket upwards, but we do have information with four and eight processors.
A few interesting things can be discerned in the graph below. MySQL 4.1.22 does not do very well on four processors in any case, but working with sixteen cores is clearly too much. The transition comes at the price of a 41% drop, which is the level which may normally be expected from a single socket system. MySQL 5.0.32 does somewhat better, but a 4% gain when the theoretical computing power is doubled, isn't too impressive. In any case, it is clear that the developers have improved their skills in working with multiple threads in the new version. Still, the score with four sockets (eight cores), is only marginally better than that of a single quadcore Xeon.
Loyal readers will know by now that PostgreSQL is a fine piece of software as far as scaling is concerned, but as we saw on the previous page, this doesn't hold on the X4600. The final version makes for a humble improvement of 6%, but the figure shows an effect that we have so far only seen in MySQL: increased crowdedness translates into a worse instead of a constant performance. The development version gives more favourable results: with scale gains of 44% it yields a new record of 950 requests per second.
