Hyperthreading hurts server performance, say developers

Hyperthreading hurts server performance, say developers

Summary: Intel had stated that hyperthreading's performance advantages would show once threaded software became available, but it appears that in some cases the opposite is true

SHARE:
TOPICS: Processors
10

Intel's Hyperthreading Technology (HT) is being blamed for server performance problems.

With both SQL Server and Citrix Terminal Server installations, HT-enabled motherboards show markedly degraded performance under heavy load. Disabling HT restores expected levels, according to reports from within the IT industry.

"Our customers were complaining about much worse performance than expected when running Citrix Terminal Server and our software on the same machine," said Peter Ibbotson, technical director of UK accounting software company Lakeview Computers.

"We've had fun and games in the past when we've enabled hyperthreading for testing and we'd seen that motherboards had started to arrive with it enabled. When we disabled hyperthreading, performance went back to normal," Ibbotson added.

Hyperthreading allows different elements of a processor to run different code at the same time, which Intel has claimed will boost chip performance and allow a CPU to process nearly twice as much information as one without hyperthreading.

Slava Ocks, a developer working on SQL Server 2005 within Microsoft, reported similar problems in a blog posting earlier this month.

"Our customers observed very interesting behaviour on high-end HT-enabled hardware. They noticed that in some cases when high load is applied SQL Server CPU usage increases significantly but SQL Server performance degrades," wrote Ocks.

Ocks then detailed testing which showed this behaviour where a system thread — in this case one cleaning out blocks of disk cache memory — is running at the same time as worker threads. "With Intel HT technology, logical processors share L1 & L2 caches. As you would guess [this] behaviour can potentially trash L1 & L2 caches," he said.

The on-chip cache exists to speed operation by keeping copies of recently accessed data where it can be accessed without recourse to main system memory — which is much slower by comparison. Where multiple threads access different parts of memory but are simultaneously processed by the chip's Hyperthreading Technology, the shared cache cannot keep up with their alternate demands and performance falls dramatically, according to analysis by Ocks and Ibbotson.

"It's ironic," said Ibbotson. "Intel had sold hyperthreading as something that gave performance gains to heavily threaded software. SQL Server is very thread-intensive, but it suffers. In fact, I've never seen performance improvement on server software with hyperthreading enabled. We recommend customers disable it when running Citrix and our software on the same server."

At the time of writing, Intel had not responded to requests for comment on these claims.

Earlier this year, Intel hyperthreading was revealed to have a security flaw where threads could find information from each other through the shared cache despite having no access to each other's memory space.

Topic: Processors

Rupert Goodwins

About Rupert Goodwins

Rupert started off as a nerdy lad expecting to be an electronics engineer, but having tried it for a while discovered that journalism was more fun. He ended up on PC Magazine in the early '90s, before that evolved into ZDNet UK - and Rupert evolved with them into an online journalist.

Kick off your day with ZDNet's daily email newsletter. It's the freshest tech news and opinion, served hot. Get it.

Talkback

10 comments
Log in or register to join the discussion
  • Intel sucks!
    anonymous
  • INTEL Sossaman will suffer from cache thrashing and be slower than single core

    http://sharikou.blogspot.com
    anonymous
  • Has anyone else tried turning HyperThreading off as they gear up for the explosive traffic next week?
    anonymous
  • This is not a new discovery. Hyperthreading causes unexpected table deadlocks and SQL rollbacks on IBM DB2 when running on Linux (tested on RHES 3 and 2.1). True dual processors do not cause the problem, only why hyperthreading is enabled. IBM support recommended to us to disable hyperthreading, which we in turn recommend to our customers that run our product.
    anonymous
  • I think you meant, "Thrash" the L1 & L2 cache... not, "Trash".
    anonymous
  • Why are they running a communication program like Citrix on their database server.
    anonymous
  • I believe the description of "trash" was accurate if one thread was clearing shared cache while another was using the cache. We'll be turning off hyperthreading on our dual cpu servers.
    anonymous
  • This tecnology also hurts application performance such as OpenOffice.org suite. We installed OOo in our Window XP workstations and we were having problems with soffice.bin allocating 100% of CPU usage since we disable the hyperthreading. Our problems were solved.
    anonymous
  • When hyperthreading first came out, I found a 2 proc hyperthread machine, (4 virtual), to spec close to 100% of a real 4 proc machine.
    The application used was a highly threaded isap ext, written in c++, running on IIS 5.0.

    At the time I was very impressed, and concidered hyper threading to be the real deal.

    I haven't ran any recent tests though.
    I wonder if the problems people are seeing is runing multiple threads on a single hyper threaded proc machine, with out much latency between threads. I can theorize that performance would degrade because all the simultanous processing is infact virtualized. If, on the other hand, there is latency between the threads, a system like hyper threading can exploit the latency to execute another thread on a virutal proc.

    Its been my experice too many threads are a killer ( thread polls are the way to go).
    anonymous
  • I got a 10% boost from hyperthreading...see my test results here: http://rentacoder.com/CS/blogs/real_life_it/archive/2006/04/18/SQL_Server_2005_performance_testing_with_hyperthreading_and_MAX_DOP.aspx
    anonymous