实时监控性能指标
启用性能指标收集,调整指标采样周期,并使用 badmin perfmon 视图来显示当前性能。
启用度量标准收集
在 lsb.params 文件中设置 SCHED_METRIC_ENABLE=Y 参数以启用性能指标收集。
动态启动性能指标收集:
badmin perfmon start sample_period(可选) 您可以设置采样周期 (以秒为单位)。 如果未指定采样周期,那么将使用 lsb.params 文件的 SCHED_METRIC_SAMPLE_PERIOD 参数中设置的缺省采样周期。
停止采样:
badmin perfmon stop可以单独指定 SCHED_METRIC_ENABLE 和 SCHED_METRIC_SAMPLE_PERIOD 。 即,可以指定 SCHED_METRIC_SAMPLE_PERIOD 而不指定 SCHED_METRIC_ENABLE。 在这种情况下,当您动态开启该功能 (使用 badmin perfmon start) 时,将使用 SCHED_METRIC_SAMPLE_PERIOD 中定义的采样周期值。
badmin perfmon start 和 badmin perfmon stop 将覆盖 lsb.params中的配置设置。 即使设置了 SCHED_METRIC_ENABLE ,如果运行 badmin perfmon start,也会启动性能指标收集。 如果运行 badmin perfmon stop,那么性能指标收集将停止。
调整度量采样周期
在 lsb.params 中设置 SCHED_METRIC_SAMPLE_PERIOD 以指定初始集群范围的性能指标采样周期。
设置新的采样周期 (以秒计):
badmin perfmon setperiod 采样周期
收集和记录性能指标数据可能会影响 LSF 的性能。 较小的采样周期将导致 lsb.streams 文件增长更快。
显示当前性能
使用 badmin perfmon view 命令可查看实时性能指标信息。
- mbatchd 处理的查询数
- 每个作业,队列和主机的查询数。 (bjobs, bqueues和 bhosts以及其他守护程序请求)
- 提交的作业数 (分为作业提交请求和实际提交的作业)
- 分派的作业数
- 重新排序的作业数,即复用已完成作业的资源分配的作业数 (在 lsb.params 或 lsb.queues中启用了RELAX_JOB_DISPATCH_ORDER )
- 已完成的作业数
- 发送到远程集群的作业数
- 从远程集群接受的作业数
- 调度程序性能指标:
- 较短的调度时间间隔意味着调度作业的速度更快
- 正在使用的可能导致不同候选主机组的作业的不同资源需求模式数。 需要的匹配主机越多,查找主机所需的时间越长,这意味着调度会话的时间越长。 随着集群中主机的数量增加,复杂性也会增加。
- 根据资源需求和不同调度策略将作业放入其中的 调度程序 存储区数。 更多 调度程序 存储区意味着调度会话的时间更长。
badmin perfmon view
Performance monitor start time: Fri Jan 19 15:07:54
End time of last sample period: Fri Jan 19 15:25:55
Sample period : 60 Seconds
------------------------------------------------------------------
Metrics Last Max Min Avg Total
------------------------------------------------------------------
Processed requests: mbatchd 0 25 0 8 159
Jobs information queries 0 13 0 2 46
Hosts information queries 0 0 0 0 0
Queue information queries 0 0 0 0 0
Job submission requests 0 10 0 0 10
Jobs submitted 0 100 0 5 100
Jobs dispatched 0 0 0 0 0
Jobs reordered 0 0 0 0 0
Jobs completed 0 13 0 5 100
Jobs sent to remote cluster 0 12 0 5 100
Jobs accepted from remote cluster 0 0 0 0 0
------------------------------------------------------------------
File Descriptor Metrics Free Used Total
------------------------------------------------------------------
MBD file descriptor usage 800 424 1024
------------------------------------------------------------------
Scheduler Metrics Last Max Min Avg
------------------------------------------------------------------
Scheduling interval in seconds(s) 5 12 5 8
Host matching criteria 5 5 0 5
Job buckets 5 5 0 5
调度程序度量值在每个调度会话结束时收集。
在每个采样周期结束时计算性能指标信息。 在采样周期结束前运行 badmin perfmon view 将显示从采样开始时间到上一个采样周期结束所收集的度量数据。
如果由于第一个采样周期尚未结束而未收集任何度量值,那么 badmin perfmon view 将显示:
badmin perfmon view
Performance monitor start time: Thu Jan 25 22:11:12
End time of last sample period: Thu Jan 25 22:11:12
Sample period : 120 Seconds
------------------------------------------------------------------
No performance metric data available. Please wait until first sample period ends.
badmin perfmon 输出
- 采样周期
- 当前采样周期
- 性能监视器开始时间
- 采样的开始时间
- 上次采样周期的结束时间
- 上次采样周期的结束时间
- 指标
- 度量值的名称
- 总计
- 这是每个度量的累积度量计数器值。 从性能监视器开始时间到上次采样周期的结束时间进行计数。
- 最后一个时间段
- 度量的上次采样值。 按采样周期计算。 它表示为每个周期的度量值,并通过以下公式进行规范化:
LastPeriod = (上一个周期/采样周期时间间隔的度量计数器值) * 采样周期
- 最大值
- 度量的最大采样值。 在每个采样周期中,将通过比较 "最大周期" 和 "最后一个周期" 对其进行重新评估。 它表示为每个周期的度量值。
- 最小值
- 度量的最小采样值。 在每个采样周期中,通过比较 "最小" 和 "最后一个周期" 对其进行重新评估。 它表示为每个周期的度量值。
- 平均
- 度量的平均采样值。 将在每个采样周期中重新计算该值。 它表示为每个周期的度量值,并通过以下公式进行规范化:
平均值 = (总计 / (最后PeriodEndTime-SamplingStartTime)) * 样本期
在启用性能指标采样的情况下重新配置集群
如果使用 badmin perfmon start动态启用性能指标采样,那么必须在运行 badmin mbdrestart之后再次启用此采样。
- 如果缺省情况下启用了性能指标采样,那么 StartTime 将重置为重新启动点 mbatchd 。
- 更改 SCHED_METRIC_ENABLE 和 SCHED_METRIC_SAMPLE_PERIOD 参数时,请使用 badmin mbdrestart 命令。 badmin reconfig 命令与此上下文中的 badmin mbdrestart 命令相同。
lsb.streams 中的性能指标日志记录
缺省情况下,收集的度量将写入 lsb.streams。
但是,即使定义了 ENABLE_EVENT_STREAM=N ,仍可以开启性能指标。 在这种情况下,将不会记录任何度量数据。
如果 EVENT_STREAM_FILE 已定义且有效,那么应将收集的度量值写入 EVENT_STREAM_FILE。
如果定义了 ENABLE_EVENT_STREAM=N ,那么将不会记录度量数据。
作业数组和作业包
在作业数组或作业包中提交的每个作业都将单独计数,但Job submission requests度量。
整个作业数组或作业包仅计为一个作业提交请求。
作业重新运行
当执行主机在作业运行时变为不可用时,将发生作业重新运行,并且将首先将该作业放入其原始队列,稍后将在合适的主机可用时分派该作业。
在这种情况下,仅计算一个提交请求,一个提交的作业和分派的 n 个作业, n 个已完成的作业 (n 表示作业在成功完成之前重新运行的次数)。
作业重新排队
由于反复发生一些特殊错误,可能会分派,运行和退出已重新排队的作业。 作业数据始终存在于内存中,因此 LSF 只计算一个作业提交请求和一个已提交的作业,并计算多个已分派的作业。
对于已完成的作业,如果使用 brequeue重新排队作业,那么 LSF 会计算两个已完成的作业,因为重新排队作业会首先杀死该作业,然后将该作业放入暂挂列表中。 如果自动重新排队该作业,那么当该作业成功完成时, LSF 将计算一个已完成的作业。
作业重放
当作业重放完成时,已提交的作业不会计入作业提交和已提交的作业,而是计入已分派的作业和已完成的作业。