GridMix是Hadoop集群的基准。它提交混合的综合作业，对从生产负荷中提取的配置文件进行建模。该工具的该版本将尝试对生产作业的资源档案进行建模，以识别瓶颈，指导开发。
要运行GridMix，您需要一个MapReduce作业跟踪，该跟踪描述给定集群的作业组合。这种痕迹通常是由瘤胃产生的。GridMix还需要输入数据，合成作业将从中读取字节。输入数据不需要采用任何特定格式，因为合成作业当前是二进制读取器。如果在新群集上运行，则可以在运行之前执行生成输入数据的可选步骤。为了模拟来自相同或另一个群集上给定群集的生产作业负载，请按照下列步骤操作：
在生产集群上找到作业历史记录文件。该位置由集群的mapreduce.jobhistory.done-dir或mapreduce.jobhistory.intermediate-done-dir配置属性指定。（MapReduce historyserver将作业历史记录文件从mapreduce.jobhistory.done-dir移动到mapreduce.jobhistory.intermediate-done-dir。）
运行Rumen为所有或选择的作业构建JSON格式的作业跟踪。
将GridMix与基准群集上的作业跟踪配合使用。
GridMix提交的作业的名称形式为“ GRIDMIXnnnnnn ”，其中“ nnnnnn ”是填充有前导零的序列号。
Gridmix作为hadoop子命令提供。不带配置参数的基本命令行用法：
$ hadoop gridmix [-生成<大小>] [-用户<用户列表>] <iopath> <跟踪>
带有配置参数的基本命令行用法：
$ hadoop gridmix \ -Dgridmix.client.submit.threads = 10 -Dgridmix.output.directory = foo \ [-生成<大小>] [-用户<用户列表>] <iopath> <跟踪>
像上面给定的-Dgridmix.client.submit.threads = 10和-Dgridmix.output.directory = foo这样的配置参数应该在 其他GridMix参数之前使用 。
所述<iopath>参数是用于GridMix的工作目录。请注意，它既可以位于本地文件系统上，也可以位于HDFS上，但是强烈建议它与原始作业组合的文件名相同，以便GridMix分别对本地文件系统和HDFS施加相同的负载。
该-generate选项用于生成合成作业输入数据和分布式缓存文件。它接受大小后缀的标准单位，例如100g将生成100 * 2 30字节作为输入数据。压缩格式的输入数据的最小大小（默认为128MB）由gridmix.min.file.size定义。<iopath> / input是生成的输入数据的目标目录和/或将从中读取输入数据的目录。基于HDFS的分布式缓存文件在分布式缓存目录<iopath> / distributedCache下生成。如果某些所需的分布式缓存文件已存在于分布式缓存目录中，则在指定-generate选项时，仅生成其余不存在的分布式缓存文件。
该-Users选项用来指向一个用户列表文件（见仿真进用户和队列）。
所述<跟踪>参数是由瘤胃生成的作业跟踪的路径。可以压缩此跟踪（必须使用群集支持的压缩编解码器之一读取该跟踪）或不对其进行压缩。如果要通过 GridMix的标准输入流传递未压缩的跟踪，请使用“-”作为此参数的值 。
以下各节说明了受支持的配置参数。
| 参数 | 描述 |
|---|---|
| gridmix.output.directory | 将输出写入其中的目录。如果指定，则 iopath将相对于此参数。提交用户必须对此目录具有读/写权限。用户还应注意运行期间可能出现的任何配额问题。默认值为“ gridmix ”。 |
| gridmix.client.submit.threads | 向集群提交作业的线程数。这也控制在给定时间将多少个拆分加载到内存中，以等待跟踪中的提交时间。拆分是预先生成的，以达到提交截止日期，因此特别密集的跟踪可能需要更多的提交线程。但是，将拆分存储在内存中相当昂贵，因此您应谨慎提出。SERIAL作业提交策略的默认值为1（请参阅作业提交策略），其他策略的默认值 比客户端计算机上的处理器数多一。 |
| gridmix.submit.multiplier | 乘以加速或减速提交作业。将两个作业分开的时间乘以该系数。默认值为1.0。这是将作业跟踪的大小确定为集群的粗略机制。 |
| gridmix.client.pending.queue.depth | 等待拆分生成的作业描述队列的深度。从跟踪读取的作业在提交线程进行处理之前会占据此深度的队列。配置它是不寻常的。默认值为5。 |
| gridmix.gen.blocksize | 生成数据的块大小。默认值为256 MiB。 |
| gridmix.gen.bytes.per.file | 每个文件写入的最大字节数。默认值为1 GiB。 |
| gridmix.min.file.size | 输入文件的最小大小。默认限制为128 MiB。如果在使用相对较小的输入数据集测试GridMix时看到诸如“找不到满意的文件”之类的错误消息，请调整此参数。 |
| gridmix.max。总扫描 | 输入文件的最大大小。默认限制为100 TiB。 |
| gridmix.task.jvm-options.enable | 使Gridmix使用从原始任务获得的值（即通过跟踪）配置模拟任务的最大堆选项。 |
GridMix将作业跟踪作为输入，本质上是JSON编码的作业描述流。对于每个作业描述，提交客户端获得原始作业提交时间，对于该作业中的每个任务，读取和写入的字节和记录计数。给定此数据后，它将构造一个合成作业，该作业具有与跟踪中记录的字节和记录模式相同的字节。它构造两种类型的作业：
| 工作类型 | 描述 |
|---|---|
| 加载作业 | 模拟Rumen跟踪中提到的工作负载的合成作业。在当前版本中，我们支持I / O。它在基准群集上重现I / O工作负载。它通过将每个映射的详细I / O信息嵌入到每个作业的输入拆分中，并减少任务（例如读取和写入的字节数和记录）来实现。映射任务还通过中间映射输出数据中继中继任务的I / O模式。 |
| 睡眠作业 | 一项合成工作，其中的每项任务“什么都不做”，而是在生产跟踪中观察到一定的睡眠时间。ResourceManager的可伸缩性通常受每秒可处理多少个心跳的限制。（心跳是从NodeManager发送的定期消息，以更新其状态并从ResourceManager抓取新任务。）由于基准群集通常仅占生产群集的一小部分，因此从节点生成的心跳流量远低于生产集群的水平。生产集群。一种可能的解决方案是在每个从属节点上运行多个NodeManager。这导致了一个明显的问题，即由合成作业生成的I / O工作负载将影响从节点。因此，需要这样的工作。 |
以下配置参数影响作业类型：
| 参数 | 描述 |
|---|---|
| gridmix.job.type | 该键的值可以是LOADJOB或SLEEPJOB之一。默认值为LOADJOB。 |
| gridmix.key.fraction | 对于LOADJOB类型的作业，是记录的一部分，用于键的数据。默认值为0.1。 |
| 仅gridmix.sleep.maptask | 对于SLEEPJOB类型的作业，是否忽略该作业的化简任务。默认值为false。 |
| gridmix.sleep.fake-locations | 对于SLEEPJOB类型的作业，该作业的地图任务的伪造位置数。默认值为0。 |
| gridmix.sleep.max-map-time | 对于SLEEPJOB类型的作业，该作业的地图任务的最大运行时间（以毫秒为单位）。默认值为无限制。 |
| gridmix.sleep.max减少时间 | 对于SLEEPJOB类型的作业，用于减少该作业的任务的最大运行时间（以毫秒为单位）。默认值为无限制。 |
GridMix控制作业提交的速度。该控件可以基于跟踪信息，也可以基于从ResourceManager收集的统计信息。根据用户定义的提交策略，GridMix使用相应的算法来控制作业提交。当前有三种类型的策略：
| 职位提交政策 | 描述 |
|---|---|
| 强调 | 继续提交作业，以便集群保持压力。在这种模式下，我们通过监视集群的实时负载来控制作业提交的速率，以便我们可以在集群上维持稳定的工作压力水平。基于收集的统计信息，我们定义集群是* underloaded *还是* overloaded *。当且仅当以下三个条件为真时，我们才考虑集群“欠载”：
|
| 重播 | 在这种模式下，我们忠实地重播作业痕迹。此模式完全遵循实际作业跟踪中给定的时间间隔。 |
| 序列号 | 在这种模式下，我们仅在较早提交的作业完成后才提交下一个作业。 |
以下配置参数影响作业提交策略：
| 参数 | 描述 |
|---|---|
| gridmix.job-submission.policy | 该键的值将是以下三个值之一：STRESS，REPLAY或SERIAL。在大多数情况下，键的值为STRESS或REPLAY。默认值为STRESS。 |
| gridmix.throttle.jobs-tracker-ratio | 在STRESS模式下，集群中正在运行的作业与NodeManagers的最小比率被认为是* overloaded *。这是前面提到的阈值TJ。默认值为1.0。 |
| gridmix.throttle.maps。任务到插槽比率 | 在STRESS模式下，待处理和正在运行的地图任务（即，不完整的地图任务）与该集群的映射槽位数量的最小比率被认为是*超载*。这是前面提到的阈值TM。正在运行的地图任务被部分计入。例如，完成40％的地图任务计为0.6地图任务。默认值为2.0。 |
| gridmix.throttle.reduce.task-slot-ratio | 在STRESS模式下，待处理集群和正在运行的缩减任务（即，不完全的缩减任务）与该集群的缩减插槽数量的最小比率，即该集群被视为*过载*。这是前面提到的阈值TR。运行reduce任务被部分计算。例如，将完成的30％缩小任务计为0.7缩小任务。默认值为2.5。 |
| gridmix.throttle.maps.max-slot-share-per-job | 在“应力”（STRESS）模式下，集群的映射插槽容量的最大份额可以在过载计算中计入作业的不完整映射任务。默认值为0.1。 |
| gridmix.throttle.reducess.max-slot-share-per-job | 在“应力”（STRESS）模式下，集群的减少插槽容量的最大份额可计入作业在过载计算中不完全的减少任务。默认值为0.1。 |
典型的生产集群通常与不同的用户共享，集群的容量通过作业队列在不同部门之间分配。确保所有用户的作业之间的公平性，遵守队列容量分配策略并避免不良行为的作业接管集群，会增加Hadoop软件的复杂性。为了能够充分测试和发现这些区域中的错误，GridMix必须模拟来自不同用户和/或提交到不同队列的作业的争用。
模拟多个队列很容易-我们只需使用与生产集群相同的队列配置来设置基准集群，然后配置合成作业，以便将它们提交到与跟踪记录相同的队列。但是，并非跟踪中显示的所有用户都在基准群集上拥有帐户。相反，我们设置了许多测试用户帐户，并将跟踪中的每个唯一用户以循环方式关联到测试用户。
以下配置参数影响用户和队列的仿真：
| 参数 | 描述 |
|---|---|
| gridmix.job-submission.use-queue在跟踪中 | 设置为true时，它将使用与跟踪中提到的队列完全相同的队列集。默认值为 false。 |
| gridmix.job-submission.default-queue | 指定所有作业将提交到的默认队列。如果未指定此参数，则GridMix使用为集群上的提交用户定义的默认队列。 |
| gridmix.user.resolve.class | 指定要使用的UserResolver实现。我们目前有三种实现：
|
如果参数gridmix.user.resolve.class设置为org.apache.hadoop.mapred.gridmix.RoundRobinUserResolver，我们需要定义一个带有测试用户列表的用户列表文件。这是使用GridMix的-users选项指定的。
使用循环用户解析器时，必须使用-users选项指定用户列表文件。其他用户解析器忽略此选项。用户列表文件每行有一个用户，每行的格式为：
<用户名>
例如：
用户1 用户2 用户3
在上面的示例中，我们定义了三个用户user1，user2和user3。现在，我们将跟踪中的每个唯一用户与上述以循环方式定义的用户相关联。例如，如果跟踪的用户是tuser1，tuser2，tuser3，tuser4和tuser5，则映射将为：
tuser1-> user1 tuser2-> user2 tuser3-> user3 tuser4-> user1 tuser5-> user2
出于向后兼容的原因，用户列表文件的每一行都可以包含用户名，后跟组名，格式为username [，group] *。Gridmix将忽略组名。
Gridmix默认为LOADJOB类型的作业模拟分布式缓存加载。这是通过为所有模拟作业预创建所需的分布式缓存文件作为单独的MapReduce作业的一部分来完成的。
可以通过将属性gridmix.distributed-cache-emulation.enable配置为false来禁用gridmix模拟作业中的分布式缓存负载仿真。但是，通过gridmix生成Distributed Cache数据是由-generate选项驱动的，并且与该配置属性无关。
在以下情况下，将禁用分布式缓存文件的生成和分布式缓存负载的仿真：
Gridmix3在它提交的模拟作业中设置一些配置属性，以便可以将它们映射回输入作业跟踪中的相应作业。这些配置参数包括：
| 参数 | 描述 |
|---|---|
| gridmix.job.original-job-id | 与该模拟作业对应的原始集群作业的作业ID。 |
| gridmix.job.original-job-name | 与该模拟作业相对应的原始集群作业的作业名称。 |
MapReduce支持数据压缩和解压缩。可以压缩MapReduce作业的输入。同样，也可以压缩Map和Reduce任务的输出。GridMix中的压缩/解压缩仿真非常重要，因为模拟压缩/解压缩将影响任务的CPU和内存使用情况。模拟压缩/解压缩的任务将影响在同一节点上运行的其他任务和守护程序。
如果将gridmix.compression-emulation.enable设置为true，则启用压缩仿真。默认情况下，对LOADJOB类型的作业启用压缩仿真 。启用压缩仿真后，GridMix现在将以恒定的压缩率生成压缩的文本数据。因此，模拟的GridMix作业现在将使用可压缩文本数据（具有恒定的压缩率）来模拟压缩/解压缩，而与实际作业中观察到的压缩率无关。
典型的MapReduce作业在以下阶段处理数据压缩/解压缩
作业输入数据解压缩：启用压缩仿真后，GridMix会生成可压缩的输入数据。基于原始作业的配置，模拟的GridMix作业将使用解压缩器读取压缩的输入数据。当前，GridMix使用mapreduce.input.fileinputformat.inputdir来确定原始作业是否使用了压缩的输入数据。如果原始作业的输入文件未压缩，则模拟作业将在不使用解压缩器的情况下读取压缩的输入文件。
中间数据压缩和解压缩：如果原始作业已启用地图输出压缩，则GridMix也将为模拟作业启用地图输出压缩。因此，减速器将使用解压缩器来读取映射输出数据。
作业输出数据压缩：如果原始作业的输出被压缩，则GridMix也将为模拟作业启用作业输出压缩。
以下配置参数影响压缩仿真
| 参数 | 描述 |
|---|---|
| gridmix.compression-emulation.enable | 在模拟的GridMix作业中启用压缩仿真。默认为true。 |
打开压缩仿真后，GridMix将生成压缩的输入数据。因此，输入数据的总大小将小于预期大小。将gridmix.min.file.size设置为较小的值（大约为gridmix.gen.bytes.per.file的 10％），以使GridMix正确模拟压缩。
MapReduce允许用户将作业定义为高任务作业。高任务作业中的任务会在任务进程中占用更大的内存。由于以下原因，模拟此行为很重要。
对调度程序的影响：高任务作业中的任务调度会影响调度行为，因为它可能导致资源保留和利用。
对节点的影响：由于High-Ram任务占用更大的内存，因此NodeManager会做一些簿记工作，以便为这些任务分配额外的资源。因此，这成为内存仿真的先驱，在内存仿真中，具有高内存需求的任务需要被视为高内存任务。
可以通过将
gridmix.highram-emulation.enable设置为false来禁用High-Ram功能仿真。
MapReduce使用其任务计数器记录了CPU，物理内存，虚拟内存，JVM堆等资源的使用情况。GridMix使用此信息来模拟模拟任务中的资源使用情况。模拟资源使用情况将有助于GridMix在测试集群上施加与实际集群类似的负载。
MapReduce任务在其整个生命周期内都会消耗资源。GridMix还尝试通过在模拟任务的整个生命周期内扩展资源使用情况仿真来模仿此行为。每个要仿真的资源都应具有 与其关联的 仿真器。每个此类 模拟器 都应实现org.apache.hadoop.mapred.gridmix.emulators.resourceusage .ResourceUsageEmulatorPlugin接口。 GridMix中的 资源仿真器 是可以在每次运行之前进行配置（插入或拔出）的插件。GridMix用户可以 通过将逗号分隔的仿真器列表 作为值传递给仿真器，从而配置多个仿真器 插件。 gridmix.emulators.resource-usage.plugins参数。
GridMix随附的仿真器列表 ：
累积CPU使用率 模拟器：GridMix使用Rumen发布的累积CPU使用率值，并确保模拟任务的总累积CPU使用率接近Rumen发布的值。通过将org.apache.hadoop.mapred.gridmix.emulators.resourceusage .CumulativeCpuUsageEmulatorPlugin添加到 为gridmix.emulators.resource-usage.plugins参数配置的模拟器插件列表中，可以将GridMix配置为模拟累积CPU使用量。CPU使用情况仿真器的设计方式是仅在任务的特定进度边界上进行仿真。可以使用gridmix.emulators.resource-usage.cpu.emulation-interval配置此间隔。此参数的默认值为0.1，即10％。
总堆使用情况 模拟器：GridMix使用Rumen发布的总堆使用情况值，并确保模拟任务的总堆使用情况与Rumen发布的值接近。通过将org.apache.hadoop.mapred.gridmix.emulators.resourceusage .TotalHeapUsageEmulatorPlugin添加到 为gridmix.emulators.resource-usage.plugins参数配置的模拟器插件列表中，可以将GridMix配置为模拟总堆使用情况。堆使用情况仿真器的设计方式是仅在任务的特定进度边界上进行仿真。可以使用gridmix.emulators.resource-usage.heap.emulation-interval配置此间隔。此参数的默认值为0.1即进度间隔为10％。
请注意，GridMix仅会模拟LOADJOB类型的作业的资源使用情况。
GridMix将分阶段开发，并结合社区的反馈和补丁。当前，其目的是评估MapReduce和HDFS的性能，而不是评估它们之上的层（即广泛的lib和子项目空间）。鉴于这两个限制，作业跟踪的以下特征当前未捕获在作业跟踪中，并且无法在GridMix中准确再现：
文件系统属性 -除给定任务消耗和发出的字节/记录外，不尝试匹配块大小，名称空间层次结构或输入，中间或输出数据的任何属性。这意味着系统的一些最常用的部分（文本处理，流式传输等）无法用当前的实现进行有意义的测试。
I / O速率 -消耗/发射记录的速率被假定为仅受读取器/写入器的速度限制，并且在整个任务中保持不变。
内存配置文件 -尽管保留了最大堆大小，但没有关于任务随时间使用的内存的数据。
偏斜 -假定消耗/发出给定任务或从给定任务发出的记录遵循观察到的平均值，即记录将比在野外看到的记录更规则。每个映射还会为每个缩减生成比例的数据，因此输入不平衡的作业将被展平。
作业失败 -假定用户代码正确。
作业独立性 -一项作业的输出或结果不影响下一个作业何时或是否运行。
存在较旧版本的GridMix工具。可以在Apache Hadoop MapReduce JIRA上找到跟踪GridMix1，GridMix2和GridMix3的原始实现的问题。可以通过搜索Apache Hadoop MapReduce JIRA找到跟踪GridMix当前开发的其他问题。