InterSystems 数据平台和性能 – 第 2篇
部分 在上个帖子中，我们安排了使用 pButtons 进行 24 小时的性能指标收集。 在本帖中，我们将研究几个收集到的关键指标，以及它们与底层系统硬件的关系。 我们还将开始探索 Caché（或任一 InterSystems 数据平台）指标与系统指标之间的关系。 以及如何使用这些指标来了解系统的每日节拍率并诊断性能问题。
2016 年 10 月编辑... 用于将 pButtons 数据提取到 .csv 文件的脚本示例。 2018 年 3 月编辑... 图片消失，重新添加它们。
硬件食物群
您将会看到，随着本系列帖子的不断深入，影响性能的服务器组件可以逐项列出：
- CPU
- 内存
- 存储 IO
- 网络 IO
如果这些组件中的任何一个承受压力，那么系统性能和用户体验很可能会受到影响。 这些组件也都相互关联，对一个组件进行更改可能会影响另一个组件，有时会产生意外的后果。 我见过这样一个例子：修复某个存储阵列中的 IO 瓶颈使 CPU 的使用率跳增至 100%，导致用户体验更差，原因是系统突然可以做更多工作，但没有 CPU 资源来为增加的用户活动和吞吐量提供服务。
我们还将了解 Caché 系统活动如何直接影响服务器组件。 如果存储 IO 资源有限，那么可以做出的积极改变是增加系统内存，并增加 Caché global 缓冲区的内存，从而降低系统存储读取 IO（但可能会增加 CPU 使用率！）。
要定期监视或在用户报告问题时要检查的一个最明显的系统指标是 CPU 使用率。 在 Linux 或 AIX 中查看 top 或 nmon，或在 Windows 中查看性能监视器。 由于大多数系统管理员会定期查看 CPU 数据，特别是当数据以图形方式呈现时，快速浏览一下就可以很好地了解系统当前的运行状况 - 正常情况或出现活动激增，后者可能是异常情况或表示出现问题。 在本帖中，我们将快速查看 CPU 指标，但会重点关注 Caché 指标，我们首先将查看 mgstat 数据，了解以图形方式表示的数据如何让系统运行状况一目了然。
mgstat 简介
mgstat 是 pButtons 中包含并在其中运行的一个 Caché 命令。 mgstat 是一个非常好的工具，可收集基本性能指标，帮助您了解系统运行状况。 我们将查看从 24 小时 pButtons 收集的 mgstat 数据，但是，如果您希望捕获 pButtons 之外的数据，也可以根据需要以交互方式运行 mgstat，或者从 Caché 终端将其作为后台作业运行。
要从 %SYS 命名空间按需运行 mgstat，一般格式是：
do mgstat(sample_time,number_of_samples,"/file_path/file.csv",page_length)
例如，运行一小时后台作业，采样周期为 5 秒，然后输出为 csv 文件：
job ^mgstat(5,720,"/data/mgstat_todays_date_and_time.csv")
要显示到屏幕，但丢弃几个列，则输入 dsp132。 给您留个作业，去查看一下输出以了解差异。
do dsp132^mgstat(5,720,"",60)
mgstat 中的列的详细信息可以在最新的 Caché 文档（InterSystems 在线文档）中的 Caché 监视指南中找到
查看 mgstat 数据
pButtons 已设计为整理成一个 HTML 文件，以便导航和打包发送给 WRC 支持专家来诊断性能问题。 不过，当您自己运行 pButtons 并想以图形方式显示数据时，可以再次将其拆分为 csv 文件以处理成图形，例如可以使用 Excel、通过命令行脚本或简单的剪切和粘贴来完成。
在本帖中，我们将深入研究几个 mgstat 指标，来说明即使是快速浏览数据，也能让您感觉到系统是否运行良好，或者是否存在会影响用户体验的现有或潜在问题。
Gloref 和 CPU
下图显示了一个以高事务处理速率运行医院应用程序的站点的数据库服务器 CPU 使用率。 注意活动的高峰期在上午，此时有许多门诊病人，而在午餐时间，活动大幅下降，在下午和晚上则逐渐消失。 此例中的数据来自于 Windows 性能监视器 (_Total)\% Processor Time - 图形的形状符合工作日的情况 - 没有异常的峰值或低谷，所以对这个站点来说是正常的。 通过对您的站点执行相同分析，您可以开始获取“正常”情况的基准。 如果出现大的尖峰，尤其是延长的尖峰，可能说明出现了问题。将来会有一个帖子以 CPU 为重点。
作为参考，该数据库服务器是具有两个 E5-2670 8 核处理器的戴尔 R720，服务器的内存为 128 GB，global 缓冲区为 48 GB。
下图显示了来自 mgstat 的更多数据 — 与 CPU 图形同一天的 Gloref（Global 引用数）或数据库访问量。 Gloref 指示正在发生的工作量，代表当前工作负载；虽然 global 引用会消耗 CPU 时间，但由于 Caché 使用 global 内存缓冲池的方式，这些引用并不始终消耗物理读取等其他系统资源。
在典型的 Caché 应用程序中，Gloref 与 CPU 使用率之间有非常强的相关性。
这些 CPU 数据和 gloref 数据所展示出的另一方面是减少 gloref 将降低 CPU 使用率，从而可以在核心数较少的服务器上部署或在现有系统上进一步扩展。 还可以通过提高应用程序效率来减少 global 引用，我们将在以后的帖子中重新讨论这个概念。
PhyRds 和 Rdratio
根据 mgstat 数据 PhyRds（物理读取数）和 Rdratio（读取比）绘制的图形的形状也可以深入了解系统性能的预期水平，帮助您制定容量计划。 我们将在以后的帖子中深入探讨 Caché 的存储 IO。
PhyRds 只是从磁盘到 Caché 数据库的物理读取 IOPS，您应该看到逻辑磁盘和物理磁盘的操作系统指标中反映了相同的值。 注意，查看操作系统 IOPS 可能还会显示来自非 Caché 应用程序的 IOPS。 不考虑预期的 IOPS 就调整存储大小会导致灾难，您需要了解系统在高峰时段的 IOPS 是多少，才能制定适当的容量计划。 下图显示了午夜零点到 15:30 之间的 PhyRds。
注意 05:30 到 10:00 之间的读取数激增。 其他较短的峰值在 11:00 以及 14:00 之前。 您认为这些峰值是由什么引起的？ 您的服务器有这些类型的峰值吗？
Rdratio 更有趣一点，它是逻辑块读取数与物理块读取数的比值。 也就是内存中的 global 缓冲区（逻辑）的读取次数与磁盘的读取次数之比，后者的读取速度要慢几个数量级。 Rdratio 高是好事情，但长时间降至接近于零就不好了。
注意读取数高的同时，Rdratio 降至接近于零。 我曾被要求调查过这个站点，当时 IT 部门接到用户电话，报告系统长时间运行缓慢。 当我被要求查看系统时，这种情况已在几个星期内看似随机地出现。
_**由于 pButtons 已设定为每天 24 小时运行，因此可以相对简单地回溯几周的数据，以查看与支持电话相关的高 _PhyRds_ 和低 _Rdratio_ 的模式。***
经过进一步分析后，原因追溯到一名新的轮班员工身上，他当时运行了多个报告，输入了“错误”参数，加上写得不好的查询，并且没有适当的索引，导致数据库读取数很高。 这就解释了看似随机的缓慢。 由于这些长时间运行的报告将数据读取到 global 缓冲区中，结果是交互用户的数据从物理存储中获取，而不是从内存以及用于为读取提供服务的存储中获取。
监视 PhyRds 和 Rdratio 将让您了解系统的节拍率，也许还可以追踪不良报告或查询。 高 PhyRds 可能有合理的原因 - 也许必须在某个时间运行报告。 使用现代 64 位操作系统和具有大容量物理内存的服务器，您应该能够将生产系统上的 PhyRds 降到最低。
如果您在系统上看到高 PhyRds，可以考虑以下几种策略： - 通过增加数据库 (global) 缓冲区（和系统内存）的数量来提高性能。 - 可以将长时间运行的报告或提取移出办公时间。 - 可以在单独的影子服务器或异步镜像上运行长时间运行的只读报告、批处理作业或数据提取，以最大限度地降低对交互用户的影响，并减少对 CPU 和 IOPS 等系统资源的使用。
通常，低 PhyRds 是好事情，这也是我们在确定系统规模时的目标。 然而，如果您的 PhyRds 较低，而用户正在抱怨性能，仍然可以进行一些检查以确保存储不是瓶颈 - 读数低的原因可能是系统无法再提供服务。 我们将在以后的帖子中进一步探讨存储。
总结
在本帖中，我们研究了将 pButtons 中收集的指标图形化如何让运行状况检查可以一目了然地进行。 在接下来的帖子中，我将深入探讨系统和 Caché 指标之间的关系，以及如何利用这些指标来规划未来。