win8仅仅是个试验品

装完win8后出现了硬盘卡死的现象，尤其是在vmware虚拟机挂起，和系统从休眠中唤醒的时候。

 

卡得还比较严重。折腾一个多月，并记录下其中的现象和改进方法，得出的结论就是 win8仅仅是个试验品，太多东西还处于不成熟的状态。

 

其中比较肯定的一点，就是繁多复杂的优化任务本身对系统的可用性造成了较大的负面影响。

不能绝对判定但很多因素指向的另一点，就是win8的4k对齐处理逻辑存在缺陷，从而导致了硬盘效率低下。

 

原始的讨论话题在微软的论坛上：

http://answers.microsoft/zh-hans/windows/forum/windows_8-performance/%E7%B3%BB%E7%BB%9F%E5%8D%A1%E6%AD%BB%E7%A3%81/5fac7749-f897-4e66-9726-bd01fcbbf1ee

 

为方便懒得跳转的同学，我将最后的总结段落搬运到下面，有点长，如果不是碰到类似问题就不必细读了：

------------------------------------------------------------------------------------------------------------------------------------------------

 

这已经过去一个月了，经过这段时间的观察和尝试，可以确定确实是win8的问题。

 

当然中间采取了各种措施，也都起到了一定程度的缓解或者改善，但并没有解决问题。我把我这段时间的观察整理下吧，希望能对以后看贴的人有所帮助。

 

1. vmware是否存在问题。

答案是yes。有一部分用户的 vmware的软件在suspend时发生类似的硬盘几十分钟甚至若干小时都卡死的状况。社区里N年前就有人抱怨了，但是vmware得支持人员甚至开发人员赌咒发誓他们的软件在那个时候的操作没有任何的异常之处，就是简单的内存映射，也反复测试过。 不过有些能折腾的人发现关闭一些优化选项能解决这个问题---比如默认是只写入修改的部分，会导致卡死；关闭后不论修改都整块写入，反而解决了问题。 但是这些方法也并不都是百分百的有效。  注意关键点：零碎的写入会卡死，整块的写入反而很快。dsfsd

这一点在我的电脑上不起作用。在我的pc和笔记本上，vmware 9都表现出了同样的卡死问题。并且迫使我将pc上的win8退到了win7.---注：退到win7就好了。

但是无意中的一个尝试发现有个办法可以较大的改善这个问题：就是将虚拟机的格式升级到vmware 9版本。以前都只是升级vmware的软件版本，升级后没有升级虚拟机的格式版本。倒是vmware8创建的虚拟机运行在vmware9上。

vmware9在他的发行注释里有提到改善了win8的兼容性。因此各种设置尝试（包括禁止虚拟,nx等），终于找到这个比较有效的方法。

升级虚拟机的格式能很大程度的改善卡死的现象，但并不是消除了。只是几率低些，卡得不是完全死掉，卡的时间短些（数分钟）。

再次注意一个关键点：vmware平时的使用（启动，运行，日常操作）都很正常，哪怕是大量的硬盘读写操作，也都很快；仅仅是在suspend的时候，也就是关闭内存映射，将内存内容保存到硬盘的时候。

2. 那是不是vmware引起的问题？

答案是NO。

同样的vmware软件，同样的虚拟机，同样的硬件pc配置，win8下有问题，降级到win7就没问题了。

而且 vmware是需要用到大容量的内存映象文件机制，所以才容易触雷，其他软件一般不会有这个需求，并不表示这个问题不存在。

在我这段时间的有意观察中，发现很多零散的卡死---最严重的时候死机的现象，有时候跟vmware一点关系都没有，只不过有vmware时出现几率更高些。

主要问题都发生在休眠唤醒的时候。

如果休眠后短时间内就唤醒（比如外出就餐回来），系统恢复得很快，且很少几率卡死。

但如果隔了很长一段时间在唤醒（比如隔天），系统几乎八九成要卡死很长一段时间才能恢复，有两会直接死掉。

我特地的在休眠前打开任务管理器，打开性能监视器。然后在唤醒卡死的过程中艰难的操作查看性能监视器，发现系统在频繁的整系统扫描文件。

首先能看到的是windows defender的进程，在每次系统唤醒时必定全盘扫描。不论如何设定，都阻止不了它，哪怕把schedule里几十上百项都逐个检查过来，都没办法禁止这个唤醒时的扫描操作。最后只能禁止windows defender，才最终去掉了。

但是问题并没有因此而解决，系统唤醒时仍然有全系统盘的扫描读取操作，而且是服务进程再做这个操作。经过无数次的尝试后，发现是superfetch服务的原因。禁止后效果改善很多。

不幸的是问题仍然没有因此而解决，系统唤醒时仍然有一定的几率导致一段时间的卡死，而这个时候忙碌的扫描读取文件则是tiworker.exe这个进程。可惜的是这个是系统进程，不能禁止了，明知它没有理由没有必要扫描读取我的硬盘也拿他没办法了。

好在到此已经改善很多了，差不多卡死个一分钟左右，忍忍算了。

另外发现个更搞笑的现象，有时候发现系统以一个固定的周期卡一下（如两个半小时硬盘就狂转一段时间），查日志发现貌似是错误报告收集整理并上传的操作。但是错误报告不应该这么频繁，而且我禁止了错误报告和用户体验改进。他还是这么频繁的卡一下，深入的查看日志发现：系统确实有错误信息，出错虽然用户看不到，但是会导致错误收集程序启动，然后这个错误收集程序执行过程中出错退出，出错又导致了下一次的错误收集程序的启动......如此不停的循环折腾我的硬盘。

 

3. 哪些措施可以改进这个现象。

3.1. 驱动升级到最新版，包括intel的sata storage管理程序。

结果：似乎刚装完的时候有感觉有一点点改善，很快就发现这是个错觉。或许以后的驱动有可能改善，但是目前的驱动都没啥大的改善。

3.2. 硬盘firm固件的更新。

结果：有一定的改善作用。最重要的感觉就是原来一卡就是100%占用，完全死掉的样子。更新固件后，卡还是卡，不过偶尔也有98%,99%的样子，不再是完全的死掉，硬要操作还是可以艰难的一点点操作的。

3.3. 对于vmware。

升价到 vmware9,且升级虚拟机的格式到9，对vmware有较大的改善作用。不能避免卡，但卡的时间短了，卡得也不那么严重了。

3.4 禁止superfetch和windows defender。

能避免从休眠中唤醒时的硬盘扫描操作，缓解卡死现象。算是治标没治本。

 

-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

最后动用了磁盘检查软件---也许早该动用了。

 

用hdtune测速的结果，简直让人瞠目结舌。普通读取和连续读取，都在80M/s左右。但是随机的4k读取，一下子就跌倒了不可思议的 0.2M/s左右。 难怪vmware的零碎写入方式会卡死勒。

 

但硬盘本身各种测试没有问题，在安装win8之前，还安装使用过过其他多种系统，都表现很正常，只有win8出现这种问题。

 

网上很多人说，4k没对齐可能会导致性能下降。

但是win8没有4k对其问题，而且我是全新格式化，全部用默认值安装的。4k已经对得很齐了。

进一步的发现，或许正是因为win8进行了4k对齐，才导致性能的急剧下降。

根据hdtune分区块大小的读写性能测试结果，发现区块越小，读取速度越低。在读1M以上的区块时，这个降低还处于正常范围内，低于1M时性能急剧降低到接近于0的程度。

而查看硬盘的参数发现，在win8进行了4k对其后，簇的大小已经达到了8M（又或者是1M，记录没保存，但肯定是这两个数之一）。 这意味着不论你是读写1个字节，还是256K字节，还是8M，硬件都需要实际读写8M内容。 这就很好地解释了为什么整块的大量读取写入反而很快，零碎的小量写入反而导致卡死了。

 

4k对其作为一个先进的规范定义，应该不会犯这种低级的错误。那就只可能是win8在4K对齐的处理上存在缺陷，加之与硬盘的配合兼容或许也不是很全，导致这一缺陷被迅速放大，导致某种情况下小区块的读写陷入卡死状态。 ------猜测是两个因素叠加式因为win8系统本身很多dll文件大小也很小，但是启动仍是很快的。

 

---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

ps:win8的另一个设计也导致了这个缺陷被放大。

 

这个设计就是win8的性能优化。

 

win8对性能优化的考虑几乎到了变态的程度，打开一下定时任务计划，看看win8安排了多少的定时执行的后台任务就能感受到了。

 

如此繁多复杂的优化任务，在微软自己设定的场景中，或许能保持系统的一个较优的状态。但一旦用户的使用场景与微软测试时设定的不一致，那么能不能保持一个较优的状态，就不一定了。糟糕的情况下，这些繁多复杂的优化任务，本身就对系统的可用性造成了极大的负面影响（就如同我碰到的案例）。 这里就不提反复的任务对硬件的损耗了。

 

用户的使用场景会不会与微软测试时设定的不一致呢？ 我想这个问题没必要回答了吧。。。。。。

 

 

 

pps:

我上面举过一个典型的例证：错误收集程序出错，出错导致错误收集程序启动，错误收集程序出错，......，如此周而复始，生生不息。。。。。

 

总结：看来win8还是没有逃脱历史规律的诅咒，仅仅是个试验品而已。