我们有一台运行 Apache/php/postgres 的 Windows 7 Pro 计算机，在恒定负载（每秒几个）下处理 Ajax 请求。它还运行各种其他应用程序，执行大量磁盘写入操作。
通常情况下，Ajax 响应会在一秒内收到，但偶尔（约 24 小时内一次）最长 15 秒内没有发送任何响应，然后在最后发送所有响应，即服务器似乎被阻塞了 15 秒。这会导致客户端的 Ajax 超时。
Apache 和其他应用程序的日志支持了这一点。Perfmon 显示各种计数器降至零/接近零 - HD 活动、CPU 活动、网络活动等。httpd#1 似乎是唯一一个仍有一些 CPU 活动的进程，尽管有所减少。
我如何确定挂起的原因？perfmon 或其他工具能否告诉我阻塞的资源是什么？（“Windows 性能工具包”或“进程监视器”对此有用吗？）
NB Apache 有足够的线程，postgres 有足够的连接，CPU 和 RAM 没有达到最大值，并且我们已经尝试了电源选项、驱动程序、sfc /scannow、chkdsk /r、memtest 等。
更新时间：2013/03/22 10:26：
感谢您迄今为止的所有回复。更多信息：
硬件：
- 机箱：Westek 2U 机架式主板：Intel Q35 1333FSB（5xPCI、2xPCI-E、SATA II I/F、VGA I/F、2xRS232 等）
- RAM：2x 2GB DDR2 PC2-5300 非 ECC CL4 240 针内存模块（3GB 可用作 32 位操作系统）
- 处理器：Intel Core2 Quad Q9550.2.83GHz 1066FSB 12MB 缓存
- 存储：2x Hitachi 320GB SATA 16MB 缓存 7200 NCQ（SATA-II RAID 盒）- Intel Raid 1，NTFS
- 电源：2x 400W PSU - 双冗余
- 调制解调器：StarTech 外置 v.92 56k USB 传真调制解调器
- PCI 卡：电话卡
操作系统：
- Windows 7 Pro SP1 32 位
高级性能选项：
（系统属性 > 高级 > 性能 > 设置 > 高级）
- 处理器调度：程序的最佳性能
- 虚拟内存：自动管理所有驱动器的分页文件大小
- 所有驱动器的总分页大小：
- 最小允许值：16 MB
- 建议：4591 MB
- 当前已分配：3061 MB
更新时间：2013/03/22 11:46：
perfmon 的屏幕截图：
http://i46.tinypic.com/fndyit.png（我的声誉不足以将其嵌入到帖子中）
服务器无响应的时间段是 07:44:15 - 07:44:22 - 在此期间 CPU 下降到 20% 以下。（注意：这是另一台 CPU 较弱且软件较旧且未优化的服务器 - 通常 CPU 不会这么高！）
更新 2013/04/04 16:53：
我们找到了罪魁祸首——硬盘。仅用了一个月！
我们是如何实现这一目标的：
Process Monitor 确认，在事件发生期间，磁盘阻塞了所有写入操作。我们首先尝试更新 RAID 驱动程序。这有所改善 - CPU 等不会完全降至零，但磁盘仍然阻塞。然后我们尝试禁用 RAID - 这没有效果。我们尝试通过禁用各种日志记录来减少磁盘使用率，这很有帮助。然后我们尝试将硬盘换成另一个（规格较低），使用第一个硬盘的图像，问题完全消失了。
那么我们的硬盘出了什么问题？
我们使用的磁盘是“Hitachi TravelStar 7k500（增强可用性变体）”。看来，工作周期已被限制以确保此型号的“增强可用性”，这可能不适合特别繁忙的磁盘使用情况。根据资源监视器，我们的磁盘使用率约为 400KB/秒。
答案1
是的，Perfmon 可以监控几乎所有事物的性能。问题是你需要知道从哪里查看。默认设置是一个很好的起点，但对于真正的问题，你需要付出一些努力才能弄清楚。
假设是本地存储，请检查 PerfMon 中的 PhysicalDisk\Avg. Disk Queue Length。如果它高于您的主轴数，则您的存储系统是瓶颈。也请为我们描述一下您的硬件。
/edit 就是这样。您的磁盘队列长度经常会超过“2”（您拥有的慢速主轴的数量），并且在您指定的时间段内一直处于该水平。然后 CPU 使用率下降，可能是因为它正在等待 IO 并且无法执行任何操作，所以它等待。
潜在的改进：
天真地将存储移至更多和/或更快的磁盘。也许是 RAID 10。
更智能 - 对磁盘系统进行基准测试，并将它们分配到不同的主轴或完全不同的服务器上。通常，人们不希望网站或其他前端与 SQL 数据库后端共享太多资源；这两种类型的进程具有截然不同的性能特征。
答案2
这听起来确实像是存储问题。您为页面文件使用了哪种存储？
否则，我所知道的诊断此类问题的最佳工具是进程监控来自 sysinternals（现在是 MS）。它也能执行长时间会话，但您必须有一种方法来识别遇到问题的确切时间范围，特别是如果您要使用完整的系统监视器。如果不是页面文件问题，那么它很可能会让您找到罪魁祸首。