我们有一台专用服务器，用于搭建网站（我们的测试服务器）。该服务器的性能变得非常糟糕，我们经常需要重启它。当性能不佳时，我会检查任务管理器中的进程和内存，但一切看起来都正常。
我们使用内容管理系统，并且总是在使用该 CMS 的管理部分时注意到性能下降，这使我认为这可能与 CMS 正在进行的 DB 调用有关。
这听起来可行吗？还有其他关于如何测试的建议吗？
提前致谢...
答案1
这听起来可行吗？
是的。
关于如何进行测试，还有其他建议吗？
性能检查。请注意，性能不仅仅是 CPU。如果您认为数据库是问题所在，那么它可能是 IO 限制 - 在这种情况下，磁盘延迟/活动百分比将飙升。检查磁盘性能计数器。特别是如果您是 IO 限制，CPU 会很低，因为 CPU 基本上不为进程提供服务，因为它在等待 IO 完成。
随着数据库变得越来越繁忙，通常需要大量的 IO 预算，这意味着需要相当多的磁盘。我这里的数据库现在使用 6 张 10k RPM 磁盘，很快就会升级到 8 张 - 仅用于数据。典型的廉价专用服务器通常具有非常糟糕的 IO 预算 - 速度慢的大型最终用户磁盘（其中很少）无法构成快速子系统。这在某些情况下效果很好，但最终可能会超载。
答案2
正如 TomTom 所说，这几乎肯定表明您的系统受 IO 限制，而不是受 CPU 限制。根本原因可能只是 CMS 后面的负载 DB 增加，也可能是其他原因，但无论如何，PerfMon 有一些有用的计数器可供查看，可以明确告诉您磁盘子系统是否是原因。
\LogicalDisk\Avg. 磁盘秒/读取和 \LogicalDisk\Avg. 磁盘秒/写入
这些是读写 IO 操作的基本延迟数字，越低越好。只要这些数字超过 15 毫秒左右，服务器的性能就会明显变差。
\LogicalDisk\Disk 字节数/秒和 \LogicalDisk\Disk 读取数/秒和 这将告诉您整体磁盘吞吐量。这些速率可能会因吞吐量本身或因为您已达到读写模式的 IOP 限制而达到磁盘子系统的最大容量。除非您 100% 确信您具有可预测的 IO 模式，否则很难从这些速率中推断出任何重要信息。这里没有真正有用的方法来提供任何需要注意的特定数字，但如果您看到单个 SATA 磁盘的速率为 50-100MBytes/秒或更高，那将是您期望看到的最好结果。更快的服务器磁盘（10k、15K、SSD）可以超过这个速度，并且 SAN 连接存储几乎可以提供您想要的任何数据，只要您支付足够的费用。对于较小的随机 IO（典型的数据库操作），这个数字将始终很低并且不会告诉您太多信息。
\LogicalDisk\Disk 写入次数/秒、\LogicalDisk\Disk 读取次数/秒和 \LogicalDisk\Disk 传输次数/秒 这些将告诉您每秒离散 IO 操作的数量和读取\写入比率。旋转磁盘在这方面相当有限 - 7.2K SATA 磁盘每秒可以维持大约 70-80 个 IO，10K 磁盘将其推高到 100-150 的范围，15K 将达到 200+。SSD 将高出一个或两个数量级。RAID 组会相当线性地增加读取次数，但写入将产生 2 到 5 之间的惩罚。例如，3 驱动器 RAID 5 包（写入惩罚为 4）支持的写入 IO 比单个驱动器少约 25%。
如果这个数字趋于增加，而延迟增加到危险范围（即> 15ms），则强烈表明您的磁盘正在达到 IOPs 限制，无论报告的具体数字是多少。
\LogicalDisk\Split IO/秒 这将告诉您有多少 IO 请求导致多个操作，并让您了解有多少碎片影响了 IO 活动。
PhysicalDisk：当前磁盘队列长度和PhysicalDisk：平均磁盘队列长度。 这会告诉您有多少未完成的 IO 正在物理磁盘级别等待完成。如果单个磁盘上的这个数字为 2 或更多，或者超过了构建磁盘的 RAID 组中的磁盘数量，那么您可能向磁盘推送了比它可以及时完成的更多的 IO。有些情况下这并不重要，但对于需要低延迟磁盘 IO 的系统（内存缓存无法弥补磁盘弱点的数据库）来说，这将是一个真正的杀手。第一个是瞬时读数，因此只有当它持续很高或与 %disk 时间计数器一致时才需要担心。如果平均磁盘队列长度太高，那么您肯定有问题。
PhysicalDisk：磁盘时间百分比 % 磁盘时间告诉您磁盘的繁忙程度。当它接近 100% 时，您将很难让系统执行依赖于该磁盘的任何其他操作，因为所有额外的 IO 都倾向于排队。即使数字远低于 100% 也可能表明存在问题，如果这个数字很高或不断上升，并且当前磁盘队列长度很高，这清楚地表明 IO 负载超出了磁盘的容量。这个数字实际上是以一种奇怪的方式计算的，因此在分析 RAID 性能时可能不是那么有用。
这篇 Technet 博客文章更深入地介绍其中一些计数器以及一些场景，您可以使用它们来识别问题并确定如何解决问题。
答案3
是否值得考虑配置你的 Web 应用程序池以频繁回收工作进程？