google論文二google文件系統(tǒng)下(編輯修改稿)
2025-06-12 19:36 本頁(yè)面
【文章內(nèi)容簡(jiǎn)介】 個(gè)具有 16000 個(gè) chunk，660GB 的數(shù)據(jù)。這次失敗使得 266 個(gè) chunk 降低到了一個(gè)副本，但是兩分鐘內(nèi)，它們就恢復(fù)到了至少 2 個(gè)副本，這樣就讓集群能夠容忍另一個(gè) chunkserver 發(fā)生失敗，而不產(chǎn)生數(shù)據(jù)丟失。 工作負(fù)載剖析 在這一節(jié)，我們將繼續(xù)在兩個(gè)新的集群上對(duì)工作負(fù)載進(jìn)行細(xì)致的對(duì)比分析。集群 X 是用于研究開(kāi)發(fā)的，集群 Y 是用于產(chǎn)品數(shù)據(jù)處理。 方法和說(shuō)明 這些結(jié)果只包含了客戶端產(chǎn)生的請(qǐng)求，因此它們反映了應(yīng)用程序的對(duì)整個(gè)文件系統(tǒng)的工作負(fù)載。并不包含為了執(zhí)行客戶端的請(qǐng)求進(jìn)行的 server 間的請(qǐng)求，或者是內(nèi)部的后臺(tái)活動(dòng)，比如寫(xiě)推送或者是重平衡。 對(duì)于 IO 操 作的統(tǒng)計(jì)是從 GFS 的 server 的 PRC 請(qǐng)求日志中重新構(gòu)建出來(lái)的。比如為了增加并行性， GFS 客戶端代碼可能將一個(gè)讀操作拆分為多個(gè) RPC 請(qǐng)求，我們通過(guò)它們推斷出原始請(qǐng)求。因?yàn)槲覀兊脑L問(wèn)模式高度的程式化，希望每個(gè)錯(cuò)誤都可以出現(xiàn)在日志中。應(yīng)用程序顯式的記錄可以提供更精確的數(shù)據(jù)，但是重新編譯以及重啟正在運(yùn)行中的客戶端在邏輯上是不可能這樣做的。而且由于機(jī)器數(shù)很多，收集這些數(shù)據(jù)也會(huì)變得很笨重。 需要注意的是，不能將我們的工作負(fù)載過(guò)于一般化。因?yàn)?GFS 和應(yīng)用程序是由 google 完全控制的，應(yīng)用程序都是針對(duì) GFS 進(jìn)行專門優(yōu) 化的，同時(shí) GFS 也是專門為這些應(yīng)用而設(shè)計(jì)的。這種相互的影響可能也存在于一般的文件系統(tǒng)及其應(yīng)用程序中，但是這種影響可能并不像我們上面所描述的那樣。 chunkserver 負(fù)載 表 4 展示了操作根據(jù)大小的分布。讀操作的大小表現(xiàn)出雙峰分布，小型讀操作 (小于 64kb)來(lái)自于那些在大量文件中查找小片數(shù)據(jù)的隨機(jī)讀客戶端，大型讀操作 (超過(guò) 512kb)來(lái)自于穿越整個(gè)文件的線性讀操作。 集群 Y 中大量的讀操作沒(méi)有返回?cái)?shù)據(jù)。我們應(yīng)用程序，尤其是在產(chǎn)品系統(tǒng)中，經(jīng)常使用文件作為生產(chǎn)者消費(fèi)者隊(duì)列。生產(chǎn)者并行的往文件中 append 數(shù)據(jù)，而消費(fèi)者則從文件尾部讀數(shù)據(jù)。有時(shí)候，如果消費(fèi)者超過(guò)了生產(chǎn)者，就沒(méi)有數(shù)據(jù)返回。集群 X 很少出現(xiàn)這種情況，因?yàn)樗饕怯脕?lái)進(jìn)行短期數(shù)據(jù)分析，而不是長(zhǎng)期的分布式應(yīng)用。 寫(xiě)操作的大小也表現(xiàn)出雙峰分布。大型的寫(xiě)操作 (超過(guò) 256KB)通常來(lái)自于寫(xiě)操作者的緩沖。那些緩沖更少數(shù)據(jù)的寫(xiě)操作者，檢查點(diǎn)或者經(jīng)常性的同步或者簡(jiǎn)單的數(shù)據(jù)生成組成了小型的寫(xiě)操作 (低于 64KB)。 對(duì)于記錄的 append， Y 集群比 X 集群可以看到更大的大 record append 比率。因?yàn)槭褂?Y 集群的產(chǎn)品系統(tǒng)，針對(duì) GFS 進(jìn)行了更多的優(yōu)化。 表 5 展示 了不同大小的數(shù)據(jù)傳輸總量。對(duì)于各種操作來(lái)說(shuō)，大型的操作 (超過(guò) 256KB)構(gòu)成了大部分的數(shù)據(jù)傳輸。但是小型 (低于 64KB)的讀操作雖然傳輸了比較少的數(shù)據(jù)但是在數(shù)據(jù)讀中也占據(jù)了相當(dāng)?shù)囊徊糠?，主要是由于隨機(jī) seek 造成的。 append 與 write 記錄 append 操作被大量的應(yīng)用尤其是在我們的產(chǎn)品系統(tǒng)中。對(duì)于集群 X 來(lái)說(shuō)，按字節(jié)傳輸來(lái)算， write 與 append 的比例是 108： 1，根據(jù)操作數(shù)來(lái)算它們的比例是 8： 1。對(duì)于集群 Y，比例變成了 ： 1 和 ： 1。對(duì)于這兩個(gè)集群來(lái)說(shuō)，它們的 append 操作 都要比 write 操作大一些 {操作數(shù)的比要遠(yuǎn)大于字節(jié)數(shù)的比，說(shuō)明單個(gè)的 append 操作的字節(jié)數(shù)要大于 write}。對(duì)于集群 X 來(lái)說(shuō)，在測(cè)量期間的記錄 append 操作要低一些，這可能是由其中具有特殊緩沖大小設(shè)置的應(yīng)用程序造成的。 正如期望的，我們的數(shù)據(jù)變更操作處于支配地位的是追加而不是重寫(xiě){write 也可能是追加 }。我們測(cè)量了在主副本上的數(shù)據(jù)重寫(xiě)數(shù)量。對(duì)于集群 X來(lái)說(shuō)，以字節(jié)大小計(jì)算的話重寫(xiě)大概占了整個(gè)數(shù)據(jù)變更的 %，以操作個(gè)數(shù)計(jì)算，大概小于 %。對(duì)于 Y 集群來(lái)說(shuō)，這兩個(gè)數(shù)字都是 %，盡管這也不算大，但是還是要高于我們的期望。結(jié)果顯示，大部分的重寫(xiě)是由于錯(cuò)誤或者超時(shí)導(dǎo)致的客戶端重寫(xiě)而產(chǎn)生的。它們并不是工作負(fù)載的一部分，而是屬于重試機(jī)制。 master 負(fù)載 表 6 展示了對(duì)于 master 各種請(qǐng)求類型的剖析。大部分請(qǐng)
高考資料相關(guān)推薦
鄂ICP備17016276號(hào)-1