使用托pipe服务器排除服务器性能故障

你为什么确定这是服务器负责这慢性能？

我最后一次向我报告这个“问题”，这是一个40 MB的Excel文件，其中有超过200个数据透视表（和十几个外部链接），每次打开时都必须在客户端计算机上计算。 转到工作站，下载Excel文件，打开任务pipe理器，并在打开文件时观察本地机器的CPU负载。

在我的情况下，该文件需要87秒才能打开，双CPU，四核i7系统上的全部处理器负载。 一旦我证实了这一点，我就把问题推回到了它所属的地方，那就是那个创build了一个电子表格的人，他有太多的条目和计算，可能会扼杀一台大型机。 我敢打赌，这个问题在你的情况下是一样的。 电子表格对于客户端电脑来说是及时处理的，这是当最终用户试图远程做任何事情时会发生的技术 – 他们不会远程做到这一点，每个人都会因此受到影响。

（你的意思是xlsb，而不是xslb？）

要快速查看“我的磁盘是否能够满足我的要求”：打开性能监视器并为该驱动器添加AverageDiskQueueLength计数器（逻辑或物理都可以）。 一般来说，它不应该超过10：总体概括，但会帮助你看到坏的东西。 磁盘队列长度通常应该是0到1，但是在真正劳累过度的服务器上，我已经看到它爬到了成千上万的数量并停留在那里。 这只是在磁盘I / O上等待多less个请求来接受它们进行处理的计数器。

但为什么看磁盘I / O呢？ 你知道事情是缓慢的，所以对于我来看perfmon是排除磁盘的问题。 磁盘延迟计数器应该保持在神奇的 20ms以下 。

为了更全面的观察，我会使用PAL（日志性能分析） ，一个非常棒的工具，运行它，告诉它运行的是什么types的“工作负载”，并且吐出一个用于性能监视器的configuration文件。 将该文件导入perfmon，在典型的一天运行24小时，然后取出日志输出并导入到PAL，这将使用MS最佳实践和真实世界的信息吐出一个很好的HTML总结报告，以帮助您追逐潜在的问题。 这里有更多的想法：

1. 把文件放在C：，这个“可能”在本地或不同的存储器上，然后是D :. 如果D：实际上位于SAN存储上，则存储的磁盘，控制器和NIC可能与其他客户/工作负载共享，因此很可能根本就不是您的工作。 我只是猜测在这里，但移动文件到不同的驱动器是一个简单的故障排除工具（再次，假设磁盘在不同的位置）。
2. 除了xslb以外的其他文件是否有问题？ 大词汇文件？
3. 如果保存并打开为xlsx，该怎么办？ 如果你在本地电脑上打开它呢？
4. 该文件是否拉动任何远程数据？ 这可能是一个原因。
5. Excel是否有任何加载项，请尝试从Excel选项中删除它们。
6. 对于大数据集，如果默认的32位（表中有数百万行），Excel可能会很慢。 你有没有试过64位Office？ （数字3将解决这个问题，如果它在32位本地快速打开，那么你知道这不是一个内存限制问题）。
7. 有没有一段时间，它打开一个25MB的电子表格非常快？ 如果有，自那以后有什么变
8. 离开墙壁，但是如果用户默认打开的位置是C：\（例如networking）以外的东西，即使没有select文件，我也看到办公应用的加载速度就像这样。 通常由AD中设置的用户configuration文件path引起。