GridMix是一个针对Hadoop集群的基准测试工具。它会提交一系列模拟作业，这些作业基于从生产负载中挖掘出的特征进行建模。该版本工具将尝试模拟生产作业的资源使用特征，以识别瓶颈并指导开发工作。
要运行GridMix，您需要一个描述给定集群作业组合的MapReduce作业跟踪。这类跟踪通常由Rumen生成。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 [-generate <size>] [-users <users-list>] <iopath> <trace>
带配置参数的基本命令行用法：
$ hadoop gridmix \ -Dgridmix.client.submit.threads=10 -Dgridmix.output.directory=foo \ [-generate <size>] [-users <users-list>] <iopath> <trace>
像上面给出的配置参数
-Dgridmix.client.submit.threads=10和-Dgridmix.output.directory=foo应该在其他GridMix参数 之前 使用。
-generate 选项用于为合成作业生成输入数据和分布式缓存文件。它接受标准单位的大小后缀，例如 100g 将生成 100 * 230 字节的输入数据。压缩格式的输入数据最小大小（默认为128MB）由 gridmix.min.file.size 定义。-generate 选项时，仅生成剩余不存在的分布式缓存文件。
-users 选项用于指向用户列表文件（参见模拟用户和队列）。
支持的配置参数将在以下部分进行说明。
| 参数 | 描述 |
|---|---|
gridmix.output.directory
|
The directory into which output will be written. If specified,
iopath will be relative to this parameter. The
submitting user must have read/write access to this directory. The
user should also be mindful of any quota issues that may arise
during a run. The default is "gridmix". |
gridmix.client.submit.threads
|
The number of threads submitting jobs to the cluster. This also controls how many splits will be loaded into memory at a given time, pending the submit time in the trace. Splits are pre-generated to hit submission deadlines, so particularly dense traces may want more submitting threads. However, storing splits in memory is reasonably expensive, so you should raise this cautiously. The default is 1 for the SERIAL job-submission policy (see Job Submission Policies) and one more than the number of processors on the client machine for the other policies. |
gridmix.submit.multiplier
|
The multiplier to accelerate or decelerate the submission of jobs. The time separating two jobs is multiplied by this factor. The default value is 1.0. This is a crude mechanism to size a job trace to a cluster. |
gridmix.client.pending.queue.depth
|
The depth of the queue of job descriptions awaiting split generation. The jobs read from the trace occupy a queue of this depth before being processed by the submission threads. It is unusual to configure this. The default is 5. |
gridmix.gen.blocksize
|
The block-size of generated data. The default value is 256 MiB. |
gridmix.gen.bytes.per.file
|
The maximum bytes written per file. The default value is 1 GiB. |
gridmix.min.file.size
|
The minimum size of the input files. The default limit is 128 MiB. Tweak this parameter if you see an error-message like "Found no satisfactory file" while testing GridMix with a relatively-small input data-set. |
gridmix.max.total.scan
|
The maximum size of the input files. The default limit is 100 TiB. |
gridmix.task.jvm-options.enable
|
Enables Gridmix to configure the simulated task's max heap options using the values obtained from the original task (i.e via trace). |
GridMix以作业跟踪记录作为输入，本质上是一个JSON编码的作业描述流。对于每个作业描述，提交客户端会获取原始作业提交时间，并记录该作业中每个任务读取和写入的字节数和记录数。根据这些数据，它会构建一个合成作业，其字节和记录模式与跟踪记录中的相同。它构建两种类型的作业：
| 作业类型 | 描述 |
|---|---|
LOADJOB
|
A synthetic job that emulates the workload mentioned in Rumen trace. In the current version we are supporting I/O. It reproduces the I/O workload on the benchmark cluster. It does so by embedding the detailed I/O information for every map and reduce task, such as the number of bytes and records read and written, into each job's input splits. The map tasks further relay the I/O patterns of reduce tasks through the intermediate map output data. |
SLEEPJOB
|
A synthetic job where each task does *nothing* but sleep for a certain duration as observed in the production trace. The scalability of the ResourceManager is often limited by how many heartbeats it can handle every second. (Heartbeats are periodic messages sent from NodeManagers to update their status and grab new tasks from the ResourceManager.) Since a benchmark cluster is typically a fraction in size of a production cluster, the heartbeat traffic generated by the slave nodes is well below the level of the production cluster. One possible solution is to run multiple NodeManagers on each slave node. This leads to the obvious problem that the I/O workload generated by the synthetic jobs would thrash the slave nodes. Hence the need for such a job. |
以下配置参数会影响作业类型：
| 参数 | 描述 |
|---|---|
gridmix.job.type
|
The value for this key can be one of LOADJOB or SLEEPJOB. The default value is LOADJOB. |
gridmix.key.fraction
|
For a LOADJOB type of job, the fraction of a record used for the data for the key. The default value is 0.1. |
gridmix.sleep.maptask-only
|
For a SLEEPJOB type of job, whether to ignore the reduce
tasks for the job. The default is false. |
gridmix.sleep.fake-locations
|
For a SLEEPJOB type of job, the number of fake locations for map tasks for the job. The default is 0. |
gridmix.sleep.max-map-time
|
For a SLEEPJOB type of job, the maximum runtime for map tasks for the job in milliseconds. The default is unlimited. |
gridmix.sleep.max-reduce-time
|
For a SLEEPJOB type of job, the maximum runtime for reduce tasks for the job in milliseconds. The default is unlimited. |
GridMix控制作业提交的速率。这种控制可以基于追踪信息，也可以基于从ResourceManager收集的统计数据。根据用户定义的提交策略，GridMix使用相应的算法来控制作业提交。目前有三种类型的策略：
| 作业提交策略 | 描述 |
|---|---|
STRESS
|
Keep submitting jobs so that the cluster remains under stress.
In this mode we control the rate of job submission by monitoring
the real-time load of the cluster so that we can maintain a stable
stress level of workload on the cluster. Based on the statistics we
gather we define if a cluster is *underloaded* or
*overloaded* . We consider a cluster *underloaded* if
and only if the following three conditions are true:
|
REPLAY
|
In this mode we replay the job traces faithfully. This mode exactly follows the time-intervals given in the actual job trace. |
SERIAL
|
In this mode we submit the next job only once the job submitted earlier is completed. |
以下配置参数会影响作业提交策略：
| 参数 | 描述 |
|---|---|
gridmix.job-submission.policy
|
The value for this key would be one of the three: STRESS, REPLAY or SERIAL. In most of the cases the value of key would be STRESS or REPLAY. The default value is STRESS. |
gridmix.throttle.jobs-to-tracker-ratio
|
In STRESS mode, the minimum ratio of running jobs to NodeManagers in a cluster for the cluster to be considered *overloaded* . This is the threshold TJ referred to earlier. The default is 1.0. |
gridmix.throttle.maps.task-to-slot-ratio
|
In STRESS mode, the minimum ratio of pending and running map tasks (i.e. incomplete map tasks) to the number of map slots for a cluster for the cluster to be considered *overloaded* . This is the threshold TM referred to earlier. Running map tasks are counted partially. For example, a 40% complete map task is counted as 0.6 map tasks. The default is 2.0. |
gridmix.throttle.reduces.task-to-slot-ratio
|
In STRESS mode, the minimum ratio of pending and running reduce tasks (i.e. incomplete reduce tasks) to the number of reduce slots for a cluster for the cluster to be considered *overloaded* . This is the threshold TR referred to earlier. Running reduce tasks are counted partially. For example, a 30% complete reduce task is counted as 0.7 reduce tasks. The default is 2.5. |
gridmix.throttle.maps.max-slot-share-per-job
|
In STRESS mode, the maximum share of a cluster's map-slots capacity that can be counted toward a job's incomplete map tasks in overload calculation. The default is 0.1. |
gridmix.throttle.reducess.max-slot-share-per-job
|
In STRESS mode, the maximum share of a cluster's reduce-slots capacity that can be counted toward a job's incomplete reduce tasks in overload calculation. The default is 0.1. |
典型的生产集群通常由不同用户共享，集群容量通过作业队列分配给不同部门。确保所有用户作业之间的公平性、遵守队列容量分配策略以及防止行为异常的作业独占集群，这些都给Hadoop软件带来了显著的复杂性。为了能够充分测试并发现这些领域的缺陷，GridMix必须模拟来自不同用户和/或提交到不同队列的作业之间的资源争用情况。
模拟多个队列非常简单 - 我们只需在基准测试集群上设置与生产集群相同的队列配置，并配置合成作业，使它们被提交到跟踪记录中相同的队列。然而，并非跟踪中显示的所有用户在基准测试集群上都有账户。为此，我们设置了一些测试用户账户，并以轮询方式将跟踪中的每个唯一用户关联到测试用户。
以下配置参数会影响用户和队列的模拟：
| 参数 | 描述 |
|---|---|
gridmix.job-submission.use-queue-in-trace
|
When set to true it uses exactly the same set of
queues as those mentioned in the trace. The default value is
false. |
gridmix.job-submission.default-queue
|
Specifies the default queue to which all the jobs would be submitted. If this parameter is not specified, GridMix uses the default queue defined for the submitting user on the cluster. |
gridmix.user.resolve.class
|
Specifies which UserResolver implementation to use.
We currently have three implementations:
org.apache.hadoop.mapred.gridmix.SubmitterUserResolver. |
如果参数gridmix.user.resolve.class设置为org.apache.hadoop.mapred.gridmix.RoundRobinUserResolver，我们需要定义一个包含测试用户列表的用户列表文件。这可以通过GridMix的-users选项来指定。
使用轮询用户解析器时，必须通过-users选项指定用户列表文件。其他用户解析器会忽略此选项。
用户列表文件每行包含一个用户，每行的格式为：
<username>
例如：
user1 user2 user3
在上述示例中，我们定义了三个用户user1、user2和user3。现在我们将以轮询方式将跟踪中的每个唯一用户与上述定义的用户关联起来。例如，如果跟踪的用户是tuser1、tuser2、tuser3、tuser4和tuser5，那么映射关系将是：
tuser1 -> user1 tuser2 -> user2 tuser3 -> user3 tuser4 -> user1 tuser5 -> user2
出于向后兼容性的考虑，users-list文件中的每一行可以包含用户名后跟组名的形式，格式为username[,group]*。这些组名将被Gridmix忽略。
默认情况下，Gridmix通过LOADJOB类型作业模拟分布式缓存负载。这是通过预先为所有模拟作业创建所需的分布式缓存文件来实现的，该过程作为独立MapReduce作业的一部分完成。
可以通过将属性gridmix.distributed-cache-emulation.enable配置为false来禁用gridmix模拟作业中对分布式缓存加载的模拟。但gridmix生成分布式缓存数据是由-generate选项驱动的，与此配置属性无关。
在以下情况下，分布式缓存文件的生成和分布式缓存加载的模拟都将被禁用：
/distributedCache Gridmix3 在它提交的模拟作业中设置了一些配置属性，以便可以将它们映射回输入作业跟踪中对应的作业。这些配置参数包括：
| 参数 | 描述 |
|---|---|
gridmix.job.original-job-id
|
The job id of the original cluster's job corresponding to this simulated job. |
gridmix.job.original-job-name
|
The job name of the original cluster's job corresponding to this simulated job. |
MapReduce支持数据压缩和解压。MapReduce作业的输入可以被压缩。同样，Map和Reduce任务的输出也可以被压缩。在GridMix中模拟压缩/解压非常重要，因为模拟压缩/解压会影响任务的CPU和内存使用情况。模拟压缩/解压的任务会影响同一节点上运行的其他任务和守护进程。
如果gridmix.compression-emulation.enable设置为true，则启用压缩模拟功能。默认情况下，LOADJOB类型的作业会启用压缩模拟。启用压缩模拟后，GridMix将生成具有恒定压缩比的压缩文本数据。因此，无论实际作业中观察到的压缩比如何，模拟的GridMix作业现在都将使用可压缩文本数据（具有恒定压缩比）来模拟压缩/解压缩过程。
一个典型的MapReduce作业在以下阶段处理数据压缩/解压缩
Job input data decompression: 当启用压缩模拟时，GridMix会生成可压缩的输入数据。根据原始作业的配置，模拟的GridMix作业将使用解压缩器来读取压缩的输入数据。目前，GridMix使用mapreduce.input.fileinputformat.inputdir来判断原始作业是否使用了压缩输入数据。如果原始作业的输入文件未压缩，则模拟作业将在不使用解压缩器的情况下读取压缩的输入文件。
Intermediate data compression and decompression: 如果原始作业启用了map输出压缩，那么GridMix也会为模拟作业启用map输出压缩。相应地，reducers将使用解压缩器来读取map输出数据。
Job output data compression: 如果原始作业的输出是压缩的，那么GridMix也会为模拟作业启用作业输出压缩。
以下配置参数会影响压缩模拟
| 参数 | 描述 |
|---|---|
| gridmix.compression-emulation.enable | 在模拟的GridMix作业中启用压缩仿真功能。默认值为true。 |
开启压缩模拟后，GridMix将生成压缩的输入数据。因此输入数据的总大小将小于预期值。将gridmix.min.file.size设置为较小值（约为gridmix.gen.bytes.per.file的10%），以使GridMix能正确模拟压缩效果。
MapReduce允许用户将作业定义为高内存作业。高内存作业中的任务可以在任务进程中占用更大比例的内存。模拟这种行为非常重要，原因如下。
对调度器的影响： 高内存作业的任务调度会影响调度行为，因为这可能导致资源预留和利用率问题。
对节点的影响：由于高内存任务占用更多内存，NodeManager会进行一些簿记工作，为这些任务分配额外资源。因此这成为内存模拟的前兆，其中需要将高内存需求的任务视为高内存任务。
可以通过将
gridmix.highram-emulation.enable设置为false来禁用高内存特性模拟。
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性能，而非其上层架构（即广泛的库和子项目空间）。鉴于这两个限制条件，作业负载的以下特征目前未被作业跟踪捕获，也无法在GridMix中准确复现：
文件系统属性 - 当前实现不会尝试匹配块大小、命名空间层次结构，或输入/中间/输出数据的任何属性（除了给定任务消耗和产生的字节/记录）。这意味着系统中最常用的部分（如文本处理、流处理等）无法在当前实现中得到有意义的测试。
I/O速率 - 假设记录被消费/发射的速率仅受读取器/写入器速度的限制，并且在任务期间保持恒定。
内存分析 - 虽然保留了最大堆大小，但没有关于任务随时间变化的内存使用数据。
数据倾斜 - 假设从给定任务消费和发出的记录遵循观测到的平均值，即记录会比实际场景中更均匀。每个map任务还会为每个reduce任务生成按比例分配的数据量，因此输入不均衡的作业会被摊平处理。
作业失败 - 假设用户代码是正确的。
作业独立性 - 一个作业的输出或结果不会影响后续作业的运行时间或是否运行。
存在旧版本的GridMix工具。可以在Apache Hadoop MapReduce JIRA上找到跟踪GridMix1、GridMix2和GridMix3原始实现的问题。通过搜索the Apache Hadoop MapReduce JIRA可以找到跟踪GridMix当前开发的其他问题。