Google Trace统计分析
发布网友
发布时间：2024-09-26 07:41
共1个回答
热心网友
时间：2024-10-04 02:02
此外，在scheduler处收集的信息具有sub second级别的收集粒度，包括用户、作业、任务、优先级、约束和请求以及授权。
node处收集的任务资源使用信息主要包括CPU和内存，每5分钟收集一次。
收集到这些信息后，可以进行trace分析。首先，可以分析整体资源申请和使用状况，包括CPU、内存的申请量和利用率，以及按priority class、user等分类的使用信息。这些信息有助于判断集群负载状况和集群的超卖程度。
接下来，可以对workload进行分析。整个系统包含多个实体和维度，可以单独绘制CDF图来观察分布，或者进行关联分析以找到强关联。通过统计所有维度的信息，可以得到分布，并寻找显著的现象和特征，针对这些显著的特征进行优化。
典型的维度包括job、task、user、priority、资源request、资源usage和run time等。以下是一些典型分析示例：
各维度单独分析，多维度叉乘以观察联合分布。虽然建模对于认知来说可能没有太大帮助，但从预测资源使用和协助调度的角度来看，可能仍然有一定价值。然而，鉴于软硬件环境的频繁变化，模型的时效性可能存在问题，调度算法的时效性也可能有问题。这本质上可能是一个机器学习的问题，需要不断收集集群数据，观察结果，调整模型和参数。
总体来说，trace分析的创新性不多，只需参考文章并按照套路进行分析即可。关键是从数据中找到关键的insight，并根据系统设计实现进行相应的改动。
有许多论文分析了Google的trace，得到了许多观察。其中一些观察太细节，除非真的需要去做，否则记住也没啥意义。真正有用的观察包括引用最高的一篇论文《Heterogeneity and Dynamicity of Clouds at Scale: Google Trace Analysis》，它提到的insight包括大规模、异构的硬件环境、异常多的软件workload以及复杂多变的使用需求与使用pattern。这导致调度变得困难。
还有一篇LANL出的ATC文章《On the diversity of cluster workloads and its impact on research results》，主要目的是揭示先前工作对Google trace特征的过度拟合。这篇论文的两个贡献是重新在新的集群上收集trace，并重新进行分析，比较与Google trace的相同点和不同点。
这篇文章的最大启示是，根据硬件、软件以及业务的不同，你的集群的trace特征可能与Google的trace大不相同。Google的trace的通用性可能并不好，因此许多被提出的调度方法和策略可能需要重新考虑。
此外，这篇文章的分析metrics和分析对比方法也非常值得学习，尤其是其中的figure 1列举了常用的trace characteristics。
热心网友
时间：2024-10-04 02:06
此外，在scheduler处收集的信息具有sub second级别的收集粒度，包括用户、作业、任务、优先级、约束和请求以及授权。
node处收集的任务资源使用信息主要包括CPU和内存，每5分钟收集一次。
收集到这些信息后，可以进行trace分析。首先，可以分析整体资源申请和使用状况，包括CPU、内存的申请量和利用率，以及按priority class、user等分类的使用信息。这些信息有助于判断集群负载状况和集群的超卖程度。
接下来，可以对workload进行分析。整个系统包含多个实体和维度，可以单独绘制CDF图来观察分布，或者进行关联分析以找到强关联。通过统计所有维度的信息，可以得到分布，并寻找显著的现象和特征，针对这些显著的特征进行优化。
典型的维度包括job、task、user、priority、资源request、资源usage和run time等。以下是一些典型分析示例：
各维度单独分析，多维度叉乘以观察联合分布。虽然建模对于认知来说可能没有太大帮助，但从预测资源使用和协助调度的角度来看，可能仍然有一定价值。然而，鉴于软硬件环境的频繁变化，模型的时效性可能存在问题，调度算法的时效性也可能有问题。这本质上可能是一个机器学习的问题，需要不断收集集群数据，观察结果，调整模型和参数。
总体来说，trace分析的创新性不多，只需参考文章并按照套路进行分析即可。关键是从数据中找到关键的insight，并根据系统设计实现进行相应的改动。
有许多论文分析了Google的trace，得到了许多观察。其中一些观察太细节，除非真的需要去做，否则记住也没啥意义。真正有用的观察包括引用最高的一篇论文《Heterogeneity and Dynamicity of Clouds at Scale: Google Trace Analysis》，它提到的insight包括大规模、异构的硬件环境、异常多的软件workload以及复杂多变的使用需求与使用pattern。这导致调度变得困难。
还有一篇LANL出的ATC文章《On the diversity of cluster workloads and its impact on research results》，主要目的是揭示先前工作对Google trace特征的过度拟合。这篇论文的两个贡献是重新在新的集群上收集trace，并重新进行分析，比较与Google trace的相同点和不同点。
这篇文章的最大启示是，根据硬件、软件以及业务的不同，你的集群的trace特征可能与Google的trace大不相同。Google的trace的通用性可能并不好，因此许多被提出的调度方法和策略可能需要重新考虑。
此外，这篇文章的分析metrics和分析对比方法也非常值得学习，尤其是其中的figure 1列举了常用的trace characteristics。
