超线程会导致系统不稳定吗？
我正在构建一台配备全新 Intel I7 四核处理器的 PC。 打开超线程后，它将在任务管理器中报告 8 个核心。
我的一些同事说超线程会使系统不可靠并建议将其关闭。
你们中的任何好心人可以启发我和其他 stockoverflow 用户吗？
继续：我一直在使用超线程，而且它的效果非常好。 没有任何不稳定的情况。 我正在使用：
- Microsoft Server 2008 64 位
- Microsoft SQL Server 2008 64 位
- Microsoft Visual Studio 2008
- Diskeeper Server
- 许多控件（Telerik、Dundas、Rebex、Resharper）
I'm building a PC with the new Intel I7 quad core processor. With hyperthreading turned on it will report 8 cores in Task Manager.
Some of my colleagues are saying that hyperthreading will make the system unreliable and suggest turning it off.
Can any of you good people enlighten me and the rest of the stockoverflow users.
Follow on: I've been using hyperthreading constantly, and its been spot on. No instability whatsoever. I'm using:
- Microsoft Server 2008 64 bit
- Microsoft SQL Server 2008 64 bit
- Microsoft Visual Studio 2008
- Diskeeper Server
- Lots of controls (Telerik, Dundas, Rebex, Resharper)
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（16）
稳定性不太可能受到影响，因为抽象级别非常低，操作系统只是将其视为另一个为其提供工作的 CPU。 然而，性能是另一回事。
老实说，我不能说情况是否仍然如此，但至少在支持 HT 的 CPU 首次推出时，至少某些应用程序存在已知问题。 例如，众所周知，MySQL 和多线程应用程序（例如我日常工作中支持的 Java 应用程序）在启用 HT 时性能会下降。 我们始终建议将其删除，至少对于我们服务器端企业应用程序的特定用例而言。
这可能不再是问题，并且在桌面环境中，对于大多数用例而言，这不太可能成为问题。 当 CPU 被大量使用时，在 CPU 上分割工作的能力通常会导致应用程序响应更快。 但是，当应用程序已经是大量线程和 CPU 密集型（例如数据库服务器）时，上下文切换和开销可能会产生不利影响。
Stability isn't likely to be affected, since the abstraction is very low level and the OS just sees it as another CPU to provide work to. However, performance is another matter.
In all honesty I can't say if this is still the case, but at least when the HT-enabled CPUs first came out, there were known problems with at least some applications. For example, MySQL, and multi-threaded apps like the Java application I support for my day job were known to have decreased performance when HT was enabled. We always recommended it be removed, at least for our particular use case of a server-side enterprise application.
It's possible that this is no longer an issue, and in a desktop environment this is less likely to be a problem for most use cases. The ability to split work on the CPU generally would lead to more responsive applications when the CPU is heavily utilized. However, the context switching and overhead could be a detrement when the app is already heavily threaded and CPU-intensive such as in the case of a database server.
我突然想到你的同事可能会这么说的几个原因。
多篇关于超线程下 SQL 性能受到影响的文章。 我相信它最终会进行太多的上下文切换或缓存抖动。 记不太清了。
早期从单进程到多进程，或者对于大多数人来说更可能是超线程进程，带来了许多线程问题。 他们以前从未见过的竞争条件、死锁等。 尽管这是一个代码问题，但有些人将其归咎于过程。
他们对多核/多进程或只是对超线程做出相同的主张吗？
对于我来说，我已经在超线程盒子上进行了 4 年的开发，唯一的问题是我自己造成的 UI 死锁问题。
Off the top of my head I can think of a few reasons your colleagues might say this.
Several articles about SQL performance suffering under hyperthreading. I believe it winds up doing too much context switchings or cache thrashing. can't remember exactly.
Early on going from single proc to multi-proc or more likely for most people hyperthreaded procs, brought many threading issues into the open. Race conditions, deadlocks, etc, that they never saw before. Even though its a code problem some people blamed the procs.
Are they making the same claims about multi-core/multi-proc or just about hyperthreaded?
As for me, I've been developing on a hyperthreaded box for 4 years now, only problem has been a UI deadlock issue of my own making.
当将线程分派到同一 CPU 而不是不同的 CPU 时，超线程主要会影响调度程序的行为/性能...
它会显示在编码错误的应用程序中，该应用程序不处理线程之间的竞争条件...
所以它通常是糟糕的设计/代码......突然发现故障模式条件
Hyperthreading will mainly make a difference in the scheduler behaviour/performance when dispatching threads to the same CPU as opposed to different CPU...
It will show in a badly coded application that does not handle race conditions between threads...
So it is usually bad design/code.... that suddendly find a failure mode condition
不可靠？ 我怀疑是这样。 我能想到的超线程的唯一缺点是，如果操作系统没有意识到这一点，当其他物理处理器空闲时，它可能会在一个物理处理器上调度两个线程，这会降低性能。
Unreliable? I doubt so. The only disadvantage of hyperthreading that I can think of is the fact that if the OS is not aware of it, it might schedule two threads on one physical processor when other physical processors are idle which will degrade performance.
SQL Server 和某些查询的超线程存在问题，因为 SQL Server 有自己的调度程序，maxdop 1 可以解决该问题
There was a problem with SQL server and hyperthreading for some queries because SQL server has its own scheduler, maxdop 1 would solve that
无论 Windows 的不稳定程度如何，超线程都不太可能做出重大贡献（否则它现在就已经成为重大新闻了。）
To whatever degree Windows is unstable, it's highly unlikely that hyperthreading contributes significantly (or it would have made big news by now.)
我拥有一台超线程电脑已经好几年了。 核心数不多，但对我来说效果很好。
希望我有测试数据来证明你的同事是错的，但听起来这只是我的观点与他们的观点不同。 ;)
I've had a hyperthreading PC for a couple years now. Not that many cores, but it's worked fine for me.
Wish I had test data to prove your colleagues wrong, but it sounds like it's just my opinion versus theirs at this point. ;)
据我所知，从操作系统的角度来看，它并不认为超线程与实际的多核有任何不同。 从操作系统的角度来看，没有什么区别——它是孤立的。
因此，除了超线程的“额外核心”不是“真实的”（严格的技术意义上）并且不具备“真实”CPU 核心的全部性能这一事实之外，我看不出它会是任何不太可靠的。 在某些极少数情况下，速度可能会慢一些，但可靠性也不会降低。
当然，这取决于您正在运行的内容 - 我认为某些应用程序可能会因 CPU 而“崩溃并变脏”，而超线程可能会使它们感到困惑，但这可能非常罕见。
我自己已经运行具有超线程的 PC 好几年了，而且我没有发现任何稳定性问题。
抱歉我没有更具体的数据！
As far as I know, from the OS's point of view, it doesn't see hyperthreading as any different from having actual multiple cores. From the OS's point of view, there is no difference - it's isolated.
So, aside from the fact that hyperthreading's "extra cores" aren't "real" (in the strictly technical sense) and don't have the full performance of "real" CPU cores, I can't see that it'd be any less reliable. Slower, perhaps, in some rare instances, but not less reliable.
Of course, it depends on what you're running - I suppose some applications might get "down & dirty" with the CPU and hyperthreading might confuse them, but that's probably pretty rare.
I myself have been running a PC with hyperthreading for several years now, and I have seen no stability problems.
Sorry I don't have more concrete data!
我有一个i7系统，没有任何问题。
如果它适用于多核，则它适用于超线程。
I own an i7 system, and I haven't had any issues.
If it works w/ multiple cores, it works with hyperthreading.
简短的回答：是的。
与几乎所有问题一样，长答案是“视情况而定”。 取决于操作系统、软件、CPU 版本等。我个人曾两次禁用超线程才能使软件正常工作（一次是使用 Synergy 应用程序，两次是使用 Windows NT 4.0 安装程序），但是您的里程可能会有所不同。
只要您安装的 Windows 从一开始就检测多个 HT 核心（它加载一些相关的驱动程序等），您就可以“事后”禁用（并重新启用）HT。 如果您遇到无法解决的特定软件的奇怪稳定性问题，那么禁用 HT 来查看它是否有任何影响并不困难。
我不会一开始就禁用它，因为坦率地说，它可能在 99.99% 的日常使用中都能正常工作。 但请注意，是的，它偶尔会导致奇怪的行为，因此，如果您碰巧正在解决一些非常奇怪的问题，请不要排除它。
The short answer: yes.
The long answer, as with almost every question, is "it depends". Depends on the OS, the software, the CPU revision, etc. I have personally had to disable hyperthreading on two occasions to get software working properly (one, with the Synergy application, and two, with the Windows NT 4.0 installer), but your mileage may vary.
As long as you get windows installed detecting multiple HT cores from the beginning (it loads some relevant drivers and such), you can always disable (and re-enable) HT "after the fact". If you have bizarre stability issues with specific software that you can't resolve, it's not hard to disable HT to see if it has any impact.
I wouldn't disable it to start with because, frankly, it will probably work fine in 99.99% of your daily use. But be aware that yes, it can occasionally cause bizarre behaviors, so don't rule it out if you happen to be troubleshooting something very odd down the road.
超线程 CPU 中的线程共享相同的缓存，因此不会遇到多 CPU 架构可能出现的缓存一致性问题。 不过，如果一个软件的开发人员在考虑多个 cpu 的情况下进行编程，他们将（或应该）使用读取语义（iirc，这个术语）进行编写。 即所有写入都会立即从缓存中刷新。
The threads in a hyperthreaded CPU share the same cache, and as such don't suffer from the cache consistency problems that a multiple cpu architecture can. Though, if the developer of a piece of software is programming with multiple cpus in mind, they will (or should) be writing with read semantics (iirc, that's the term). i.e. all writes are flushed from the cache immediately.
就我个人而言，我发现超线程虽然不会造成任何问题，但实际上也没有多大帮助。 这可能就像拥有一个额外的 .1 处理器。 在我工作的 HT 机器上，我很少看到我的 CPU 超过 50%。 我不知道 HT 是否在 i7 等较新的处理器上变得更好，但我并不乐观。
Personally, I've found that hyperthreading, while not causing any problems, doesn't actually help all that much either. It might be like having an extra .1 of a processor. On my HT machine at work, I only very seldomly see my CPU go above 50%. I don't know if HT has gotten any better with newer processors like the i7, but I'm not optimistic.
除了听到一些有关 SQL Server 的报道外，我所能报道的都是正面的。 在启用 HT 的情况下，我在重型多线程应用程序上的性能提高了约 25%。 从来没有遇到过问题，而且我使用的是第一代 HT 处理器......
Other than hearing a few reports about SQL Server, all I can report is positive. I get about 25% better performance on heavy multi-threaded apps with HT on. Have never run into a problem with it, and I'm using a first generation HT processor...
聚会迟到了，但供以后参考；
我目前在 SQLServer 上遇到了一个问题。 基本上，我的理解是同一处理器上的超线程共享相同的 L1 和 L1。 L2 缓存，这可能会导致两者之间出现问题。 从我读到的内容来看，Citrix 似乎也存在这个问题。
Slava Ok 就此写了一篇不错的博文。
Late to the party, but for future referrence;
I'm currently having an issue with this with SQLServer. Basically, my understanding is Hyperthreading on the same processor shares the same L1 & L2 cache, which can cause issues between the two. Citrix also appears to have this problem from what I'm reading.
Slava Ok wrote a good blog post on it.
我来得很晚，但是通过 Google 找到了这个页面。 我可能发现了一个非常微妙的问题。 我有一台运行 2003 Server 的 i7 950，它非常棒。 最初，我在 BIOS 中保留了超线程，但在一些测试和推动过程中，我运行了 Carrette 的一个名为“crashme”的程序。 该程序试图通过生成一个进程并向其提供垃圾来尝试运行来使操作系统崩溃。 我的双 Opteron 设置一直运行没有问题，但 950 在一小时内就崩溃了。 除非我做了一些愚蠢的事情，否则它不会因为其他任何事情而崩溃，所以这非常令人惊讶。 我一时兴起关闭了 HT 并再次运行该程序。 它运行整夜，甚至运行多个实例。 一件轶事并没有多大意义，但尝试一下，看看会发生什么。 此外，如果关闭 HT，处理器在任何给定负载下的温度似乎都会稍低一些。 YMMV。
I'm here very late but found this page via Google. I may have discovered a very subtle problem. I have a i7 950 running 2003 Server and it's great. Initially I left hyperthreading on in the BIOS, but during some testing and pushing things hard, I ran a program called "crashme" by Carrette. This program tries to crash an OS by spawning a process and feeding it garbage to try and run. My dual Opteron setup ran it forever without a problem, but the 950 crashed within the hour. It didn't crash for anything else unless I did something stupid, so it was very surprising. On a whim I turned off HT and ran the program again. It runs all night, even multiple instances of it. One anecdote doesn't mean much, but try it and see what happens. Also, it seems that the processor is slightly cooler at any given load if HT is turned off. YMMV.
时间快进到 2024 年。我在配备 i3 处理器的 Intel NUC8 上运行服务器。 自 2020 年购买该设备以来，我一直在这样做。 2021 年，我用它为朋友托管游戏服务器和网站，它做得很好，包括运行 ARK 服务器。 如果您对游戏服务器有所了解，那么 ARK 是您可以运行的要求最高、资源最密集的游戏服务器之一，而且它还不是一个成熟的 MMO。
然后我们都厌倦了游戏，继续我们的生活，我开始开发一些旧软件，并在该服务器上托管该软件的多个实例。 那就是问题开始的时候。 该软件对硬件资源要求不高。 我托管了该软件的多达 16 个实例，所有这些实例的资源密集程度远不及单个 ARK 服务器实例。
但突然间系统不稳定了。 该软件的更新涉及运行 Python 脚本的十几个并发实例。 即使总的来说，这些脚本也不是资源密集型的，也不应该给服务器带来问题。 他们托管的域没有吸引大量流量，带宽没有问题，但服务器会随机停止响应、锁定、重新启动。
热不是问题。 没有内存错误。 我使用的是最新版本的 BIOS。 我变得绝望了。 我想我必须更换服务器盒子。 它在 Linux 上运行，我最后检查了 dmesg，它报告了 SMT 的问题。 我追查并发现了一个禁用超线程的建议。
我这样做了，突然间这个小盒子就坚如磐石。 不再有锁定，不再有随机崩溃，不再有随机重新启动，软件的更新脚本开始和完成都没有问题。 自从我进行更改以来，没有发生过一次崩溃或系统故障。 不可靠的“眼睛测试”似乎也表明网页加载速度更快，延迟更短。
所有这些都表明，仅仅因为一项技术的问题是一个老问题，并不意味着该问题已经得到解决。 现在是 2024 年，我似乎遇到了不可靠、不稳定的英特尔超线程问题，而且性能不佳。
编辑：导致不稳定的具体用例是多个并发 PHP 和/或 Python 脚本，所有脚本都与 MySQL/MariaDB 交互。 即使总的来说，脚本没有使用大量资源或造成系统压力，触发因素似乎只是有多个脚本同时运行。
Fast forward to 2024. I'm running a server box on an Intel NUC8 with an i3 processor. I've been doing this since 2020 when I purchased the unit. In 2021 I used it to host game servers and a website for friends and it did that job well, up to and including running an ARK server. If you know anything about game servers, ARK was one of the most demanding and resource intensive game servers you could run that wasn't a full blown MMO.
Then we all got tired of the games, moved on with our lives and I started working on some old software and hosting multiple instances of that software on that server box. That's when the problems started. The software wasn't demanding in terms of hardware resources. I hosted up to 16 instances of that software, and all those instances were nowhere near as resource intensive as the single ARK server instance.
But suddenly the system wasn't stable. The updates for that software involved running a dozen concurrent instances of a python script. Even in the aggregate, those scripts weren't resource intensive and shouldn't have presented problems for the server box. The domain they were hosted on didn't attract heavy traffic, there were no issues with bandwidth, but the server would randomly stop responding, lock up, reboot.
Heat wasn't the issue. There were no memory errors. I was using the latest available version of the bios. I was getting desperate. I was thinking I was going to have to replace the server box. It runs on Linux and I finally checked dmesg which reported an issue with SMT. I chased that down and found a suggestion that I disable hyperthreading.
I did that, and suddenly the little box was rock solid stable. No more lockups, no more random crashes, no more random reboots, the update scripts for the software started and finished with no issues. Not a single crash or system failure since I made that change. The unreliable "eye test" also seems to indicate that web pages are loading faster with less latency.
All this to say that just because a problem with a technology is an old problem, it doesn't automatically follow that the problem has been solved. This is 2024 and I appear to have run into issues with unreliable, flaky Intel hyperthreading, that doesn't perform well.
edit: The specific use case that caused the instability was multiple concurrent PHP and/or Python scripts, all interacting with MySQL/MariaDB. Even in the aggregate, the scripts weren't using a lot of resources or causing system stress, the trigger simply appeared to be that there were multiple scripts running concurrently.