New TPC-H Results


Last week Unisys posted their latest 10TB TPC-H results for their 16 socket Xeon X7460.

TPC

There are a number of things that I find interesting about these results, beside the fact that they have set a record for price/performance. The first is that the X7460 has six Xeon cores per socket however Unisys only enabled four cores per socket  primarily because the current release of Windows and SQL Server only support a maximum of 64 cores according to the full disclosure report . Secondly this is the first real demonstration in my mind that the Xeon based machines can hold their own a the top end of the server market against Itanium based machines.

This too perhaps, at least in part, may have contributed to Unisys’s thinking around dropping Itanium support based on the CNet News article. Does this spell the end of the Itanium, I will leave that for you to decide. I am no expert in these matters but in my mind the 2005 announcement by Dell to drop Itanium support signaled Itaniums move out of the commodity server market and with increasing pressure from the Xeon based machines I am not sure that the arrival of Intel’s quad-core Tukwila, expected in the second half of the year, with its 2 billion transistors on board will be able to put Itanium back to the top of the price/performance results at the top end of the market.

With the release of Windows Server 2008 R2 the constraint on the number processor cores available to do the required heavy lifting will be significantly increased (up to 256 cores) and bearing in mind the cost of all cores (including the disabled cores) were included in the current record setting price/performance results, I would expect to see these numbers come down further in the coming months based on exactly the same configuration machine.

The other area that always interests me when TPC results are posed, is that the deployments in terms of both infrastructure and configuration tend to be highly optimized and you often get insight into some configuration options that may never have come to light otherwise (a full disclosure report is always required for these tests). For example the SQL Server 2008 Enterprise Edition (64-bit) instance for this test was was started with the following parameters:

SQLSERVR -c -x -E -T834 -T2301 -T8040 –T661

Where:

  • -c Start SQL Server independently of the Windows Service Control Manager
  • -x Disable the keeping of CPU time and cache-hit ratio statistics
  • -E increase the number of consecutive extents allocated per file to 64
  • -T834 On systems with 8GB or more, this traceflag causes the buffer pool to use large pages. These are allocated at startup and are kept throughout the lifetime of the process. This trace flag can only be set on 64-bit installations of SQL Server.
  • -T2301 Trace flag to enable more accurate query run-time behavior modeling in the SQL Server query optimizer typically only needed for large data set decision support processing
  • -T8040 Turn off the Resource Governor
  • -T661 Turn off the ghost thread
  • -T8743 Turn off Merge Joins – used only during the load phase

Let me be clear: it is not my recommendation that you use these parameters and trace flags on your production systems as they often have tradeoffs associated with them that need to be properly understood and are selected based on the specific machine and workload under test. The -T8743 trace flag for instance will definitely hurt a typical production workload’s performance and in the case of this test was actually only used during one part of the test. Stopping and restarting servers with different parameters is not something we can afford to do in production and I would not recommend it.

<Gary>

Comments (0)

Skip to main content