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 參數之前使用。
<iopath> 參數是 GridMix 的工作目錄。請注意，這可以是本機檔案系統或 HDFS，但強烈建議與原始工作組合相同，以便 GridMix 分別對本機檔案系統和 HDFS 施加相同的負載。
-generate 選項用於為合成工作產生輸入資料和分散式快取檔案。它接受標準的單位大小字尾，例如 100g 將產生 100 * 230 位元組作為輸入資料。壓縮格式輸入資料的最小大小（預設為 128MB）由 gridmix.min.file.size 定義。<iopath>/input 是產生輸入資料的目標目錄和/或將從中讀取輸入資料的目錄。HDFS 為基礎的分散式快取檔案產生在分散式快取目錄 <iopath>/distributedCache 下。如果一些需要的分散式快取檔案已經存在於分散式快取目錄中，則僅當指定 -generate 選項時，才會產生其餘不存在的分散式快取檔案。
-users 選項用於指向使用者清單檔案（請參閱 模擬使用者和佇列）。
<trace> 參數是 Rumen 產生的工作追蹤的路徑。這個追蹤可以是壓縮的（它必須可以使用叢集支援的其中一個壓縮編解碼器讀取）或未壓縮的。如果你想要透過 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.total.scan
|
輸入檔案的最大大小。預設限制為 100 TiB。 |
gridmix.task.jvm-options.enable
|
啟用 Gridmix 使用從原始工作取得的值 (即透過追蹤) 來設定模擬工作之最大堆積選項。 |
GridMix 以工作追蹤作為輸入，基本上是 JSON 編碼工作描述的串流。對於每個工作描述，提交用戶端會取得原始工作提交時間，以及該工作中每個工作的讀取和寫入位元組及記錄數目。根據這些資料，它會建構一個合成工作，其位元組和記錄模式與追蹤中記錄的相同。它會建構兩種類型的工作
| 工作類型 | 說明 |
|---|---|
LOADJOB
|
一個合成工作，模擬 Rumen 追蹤中提到的工作負載。在目前版本中，我們支援 I/O。它會在基準叢集中複製 I/O 工作負載。它會將每個 map 和 reduce 工作的詳細 I/O 資訊 (例如讀取和寫入的位元組和記錄數目) 嵌入到每個工作的輸入分割中。map 工作會進一步透過中間 map 輸出資料傳遞 reduce 工作的 I/O 模式。 |
SLEEPJOB
|
一個合成工作，其中每個工作只會「什麼都不做」，而僅在生產追蹤中觀察到的特定時間內處於休眠狀態。資源管理員的可擴充性通常會受到它每秒可以處理的心跳次數限制。(心跳是週期性訊息，由節點管理員傳送以更新其狀態，並從資源管理員取得新工作。) 由於基準叢集通常是生產叢集大小的一小部分，因此從屬節點產生的心跳流量遠低於生產叢集的流量。一個可能的解決方案是在每個從屬節點上執行多個節點管理員。這會導致一個明顯的問題，即合成工作產生的 I/O 工作負載會使從屬節點過載。因此需要這種工作。 |
下列組態參數會影響工作類型
| 參數 | 說明 |
|---|---|
gridmix.job.type
|
此金鑰的值可以是 LOADJOB 或 SLEEPJOB 之一。預設值為 LOADJOB。 |
gridmix.key.fraction
|
對於 LOADJOB 類型的工作，用於金鑰資料的記錄比例。預設值為 0.1。 |
gridmix.sleep.maptask-only
|
對於 SLEEPJOB 類型的工作，是否忽略工作的 reduce 工作。預設為 false。 |
gridmix.sleep.fake-locations
|
對於 SLEEPJOB 類型的工作，工作中 map 工作的虛假位置數目。預設為 0。 |
gridmix.sleep.max-map-time
|
對於 SLEEPJOB 類型的作業，作業中對應 map 任務的最大執行時間（以毫秒為單位）。預設為不限。 |
gridmix.sleep.max-reduce-time
|
對於 SLEEPJOB 類型的作業，作業中對應 reduce 任務的最大執行時間（以毫秒為單位）。預設為不限。 |
GridMix 控制作業提交的速率。此控制可以基於追蹤資訊，也可以基於它從 ResourceManager 收集的統計資料。根據使用者定義的提交政策，GridMix 使用對應的演算法來控制作業提交。目前有下列三種類型的政策
| 作業提交政策 | 說明 |
|---|---|
STRESS
|
持續提交作業，讓叢集保持在壓力狀態。在此模式中，我們透過監控叢集的即時負載來控制作業提交的速率，以便我們可以在叢集上維持穩定的工作負載壓力等級。根據我們收集的統計資料，我們定義叢集是否「負載不足」或「負載過重」。只有在符合下列三個條件時，我們才會認為叢集「負載不足」
|
REPLAY
|
在此模式中，我們忠實地重播作業追蹤。此模式會完全遵循實際作業追蹤中指定的時間間隔。 |
SERIAL
|
在此模式中，我們只會在先前提交的作業完成後才提交下一個作業。 |
下列設定參數會影響作業提交政策
| 參數 | 說明 |
|---|---|
gridmix.job-submission.policy
|
此金鑰的值可以是下列三個值之一：STRESS、REPLAY 或 SERIAL。在大部分情況下，金鑰的值會是 STRESS 或 REPLAY。預設值為 STRESS。 |
gridmix.throttle.jobs-to-tracker-ratio
|
在 STRESS 模式中，叢集中的正在執行作業與 NodeManager 的最小比例，以判斷叢集是否「負載過重」。這是前面提到的臨界值 TJ。預設值為 1.0。 |
gridmix.throttle.maps.task-to-slot-ratio
|
在 STRESS 模式中，叢集中待處理和正在執行的 map 任務（即未完成的 map 任務）與 map 槽數量的最小比例，以判斷叢集是否「負載過重」。這是前面提到的臨界值 TM。正在執行的 map 任務會部分計入。例如，一個已完成 40% 的 map 任務會計入 0.6 個 map 任務。預設值為 2.0。 |
gridmix.throttle.reduces.task-to-slot-ratio
|
在 STRESS 模式中，叢集中待處理和正在執行的 reduce 任務（即未完成的 reduce 任務）與 reduce 槽數量的最小比例，以判斷叢集是否「負載過重」。這是前面提到的臨界值 TR。正在執行的 reduce 任務會部分計入。例如，一個已完成 30% 的 reduce 任務會計入 0.7 個 reduce 任務。預設值為 2.5。 |
gridmix.throttle.maps.max-slot-share-per-job
|
在 STRESS 模式中，叢集的 map-slot 容量中可計入作業不完整的 map 任務以進行超載計算的最大比例。預設為 0.1。 |
gridmix.throttle.reducess.max-slot-share-per-job
|
在 STRESS 模式中，叢集的 reduce-slot 容量中可計入作業不完整的 reduce 任務以進行超載計算的最大比例。預設為 0.1。 |
典型的生產叢集通常與不同的使用者共用，而叢集容量則透過作業佇列在不同的部門之間分配。確保所有使用者的作業公平性、遵守佇列容量配置政策，以及避免行為不當的作業接管叢集，會在 Hadoop 軟體中增加顯著的複雜性。為了能夠充分測試並找出這些領域中的錯誤，GridMix 必須模擬來自不同使用者和/或提交至不同佇列的作業的競爭。
模擬多個佇列很簡單 - 我們只需設定基準叢集與生產叢集相同的佇列配置，並設定合成作業，以便它們提交至追蹤中記錄的相同佇列。但是，追蹤中顯示的並非所有使用者都在基準叢集上擁有帳戶。相反地，我們設定多個測試使用者帳戶，並以循環方式將追蹤中的每個唯一使用者關聯至測試使用者。
下列設定參數會影響使用者和佇列的模擬
| 參數 | 說明 |
|---|---|
gridmix.job-submission.use-queue-in-trace
|
設定為 true 時，它會使用與追蹤中提到的完全相同的佇列組。預設值為 false。 |
gridmix.job-submission.default-queue
|
指定所有作業將提交到的預設佇列。如果未指定此參數，GridMix 會使用叢集上為提交使用者定義的預設佇列。 |
gridmix.user.resolve.class
|
指定要使用的 UserResolver 實作。我們目前有三個實作
org.apache.hadoop.mapred.gridmix.SubmitterUserResolver。 |
如果參數 gridmix.user.resolve.class 設定為 org.apache.hadoop.mapred.gridmix.RoundRobinUserResolver，我們需要定義一個使用者清單檔案，其中包含測試使用者的清單。這是使用 -users 選項指定給 GridMix 的。
使用循環使用者解析器時，必須使用 -users 選項指定使用者清單檔案。其他使用者解析器會忽略此選項。
使用者清單檔案每行一個使用者，每行的格式為
<username>
例如
user1 user2 user3
在上述範例中，我們定義了三個使用者 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 產生分散式快取資料是由 -generate 選項驅動的，與此組態屬性無關。
如果符合下列條件，則會停用分散式快取檔案的產生和分散式快取載入的模擬
<iopath> 位於本機檔案系統上，或<iopath>/distributedCache（包括分布式快取目錄）都沒有其他人可執行的權限。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 允許使用者將工作定義為高記憶體工作。高記憶體工作的任務可以在任務處理程序中佔用較大比例的記憶體。模擬這種行為很重要，原因如下。
對排程器的影響：排程高記憶體工作的任務會影響排程行為，因為它可能導致資源保留和使用。
對節點的影響：由於高記憶體任務佔用較大的記憶體，因此 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 發布的值。GridMix 可以透過將 org.apache.hadoop.mapred.gridmix.emulators.resourceusage .CumulativeCpuUsageEmulatorPlugin 加入為 gridmix.emulators.resource-usage.plugins 參數組態的模擬器外掛程式清單中來組態以模擬累積 CPU 使用率。CPU 使用率模擬器是以一種方式設計的，它只會在任務的特定進度邊界處進行模擬。可以使用 gridmix.emulators.resource-usage.cpu.emulation-interval 來組態這個區間。此參數的預設值為 0.1，即 10%。
總堆積使用量模擬器：GridMix 使用 Rumen 發布的總堆積使用量值，並確保模擬任務的總堆積使用量接近 Rumen 發布的值。GridMix 可透過將 org.apache.hadoop.mapred.gridmix.emulators.resourceusage .TotalHeapUsageEmulatorPlugin 加入為 gridmix.emulators.resource-usage.plugins 參數所設定的模擬器外掛程式清單中，來設定模擬總堆積使用量。堆積使用量模擬器設計成僅在任務的特定進度界限中模擬。此區間可使用 gridmix.emulators.resource-usage.heap.emulation-interval 設定。此參數的預設值為 0.1，亦即 10% 進度區間。
請注意，GridMix 僅會模擬類型為LOADJOB 的工作資源使用量。
GridMix 將分階段開發，並納入社群的回饋和修補程式。目前，其目的是評估 MapReduce 和 HDFS 效能，而非其上層（亦即廣泛的程式庫和子專案空間）。由於這兩個限制，目前未在工作負載追蹤中擷取工作負載的下列特性，且無法在 GridMix 中準確重現
檔案系統屬性 - 不嘗試比對區塊大小、命名空間階層，或輸入、中間或輸出資料的任何屬性，除了從特定任務消耗和發出的位元組/記錄。這表示系統中使用最頻繁的部分（文字處理、串流等）無法使用目前的實作進行有意義的測試。
I/O 速率 - 消耗/發出記錄的速率假設僅受讀取器/寫入器的速度限制，且在整個任務中保持恆定。
記憶體剖析 - 沒有任務記憶體使用量隨時間變化的資料，但保留最大堆積大小。
傾斜 - 消耗和發出至/從特定任務的記錄假設遵循觀察到的平均值，亦即記錄將比實際看到的更規則。每個對應也為每個還原產生成比例的資料百分比，因此輸入不平衡的工作將會變平坦。
工作失敗 - 使用者程式碼假設正確。
工作獨立性 - 一個工作的輸出或結果不會影響後續工作是否執行或何時執行。
有 GridMix 工具的較舊版本。追蹤 GridMix1、GridMix2 和 GridMix3 原始實作的議題可在 Apache Hadoop MapReduce JIRA 中找到。追蹤 GridMix 目前開發進度的其他議題可在 Apache Hadoop MapReduce JIRA 中搜尋。