1、git數(shù)據(jù)結(jié)構(gòu)

git 中存在四種數(shù)據(jù)結(jié)構(gòu)，即object包含四種，分別是tree對象、blob對象、commit對象、tag對象

1.1 blob對象

存儲文件內(nèi)容，內(nèi)容是二進制的形式，通過SHA-1算法對文件內(nèi)容和頭信息進行計算得到key(文件名)。
如果一個commitId為73c17abe44977ee82cd949f489996c2715335119，則這個blob文件在.git/objects/73文件夾下，名為c17abe44977ee82cd949f489996c2715335119，也就是說hash值的前兩位為objects目錄下子目錄的名字，剩余38位為文件名。

1.2 tree對象

可以看作一個目錄，管理一些“tree”對象或是“blob”對象。它有一串指向“blob”對象或是其它“tree”對象的指針，一般用來表示內(nèi)容之間的目錄層次關(guān)系(就像文件和子目錄)

1.3 commit對象：

commit對象指向一個“tree對象”，并且?guī)в邢嚓P(guān)的描述信息，標記項目某一個特定時間點的狀態(tài)。它包括一些關(guān)于時間點的元數(shù)據(jù)，如時間戳、最近一次提交的作者、指向上次提交的指針等

commit、tree、blob關(guān)系可以總結(jié)如下：
一個commit對應(yīng)一個tree對應(yīng)多個blob

1.4 tag對象：

一個tag對象包括一個對象名(SHA1簽名)、對象類型、標簽名、標簽創(chuàng)建人的名字(“tagger”), 還有一條可能包含有簽名(signature)的消息。
通過

總結(jié)

git每次提交存儲的都是整個文件，而不是采用增量，所以會導致存儲數(shù)據(jù)量很大，git針對此采用了zlib對數(shù)據(jù)進行壓縮，可以采用cat-file命令來查看

一旦將內(nèi)容存儲在了對象數(shù)據(jù)庫中，那么可以通過 cat-file 命令從 Git 那里取回數(shù)據(jù)。 為 cat-file 指定 -p 選項可指示該命令自動判斷內(nèi)容的類型，并為我們顯示大致的內(nèi)容：

2、git pack

git向倉庫中推送文件時存儲使用的是“松散文件”，如果有一個1.txt現(xiàn)在是10k，下次推送增加了0.1k，也就是說現(xiàn)在是10.1k，name第二個版本就會重新產(chǎn)生一個1.1k的文件，這樣會產(chǎn)生磁盤浪費，所以git會將這些文件打包成一個二進制類型的包文件(packfile)，并生成對應(yīng)的.idx索引文件，以節(jié)省空間和提升效率。這些被打包的文件存儲在.git/objects/pack目錄下，執(zhí)行find .git/objects/ -type f命令如下

看到.git/objects目錄下的文件詳情，包含了8個松散文件、一個pack文件、一個idx文件，如果想查看更詳細的內(nèi)容可以執(zhí)行
git count-objects -v命令

git count-objects -v命令結(jié)果的各個含義如下：

• count： 松散對象數(shù)
• size：松散對象占用的磁盤空間，單位為KB
• in-pack：在pack文件中的objects數(shù)量
• size-pack：pack文件占用的空間，單位為KB
• prune-packable：同時在松散對象和packs文件中都包含的objects數(shù)量，這種objects可以執(zhí)行g(shù)it prune-packed命令修剪
• garbage：對象數(shù)據(jù)庫中既不是有效松散對象也不是有效包的文件數(shù)
• size-garbage：垃圾文件占用的磁盤空間，單位為KB

3、git repack

3.1 repack作用

用于將當前不駐留在“pack”中的所有對象合并到包中。它還可用于將現(xiàn)有包重新組織為一個更高效的包。pack文件是單獨壓縮的對象的集合，應(yīng)用了增量壓縮，存儲在單個文件中，并具有關(guān)聯(lián)的索引文件。而且pack文件用于減少鏡像系統(tǒng)、備份引擎、磁盤存儲等上的負載。

3.2 單包與多包

3.2.1 單包

在重新打包時repack會有一些options可供選擇，如-d, -A，如果加上了-A，則重新打包時就會將新的松散文件與之前的pack共同打包成一個pack。

在單包時通常會將加上--write-bitmap-index來生成.bitmap文件(bitmap文件存儲有關(guān)包文件或多包索引（MIDX）中對象集的可達性信息)，此option會覆蓋repack.writeBitmaps值，當然如果不指定此option，也可通過命令git config --global repack.writeBitmaps true，然后通過git config -l查看是否成功設(shè)置此option。需要注意的是--write-bitmap-index option只在單包時才會生效，也就是說只在與-a、-A或-m一起使用時有意義，因為位圖必須能夠引用所有可訪問的對象(多包如何設(shè)置bitmap后面會涉及)。

3.2.2 多包

隨著文件數(shù)越來越多，pack文件就會越來越大，單包策略的缺點就暴露了出來，如果使用單包，包大小高達30g甚至更大，當有新的松散文件時、或gc時，觸發(fā)的repack將會非常慢。

針對上述問題，可以采用多包的方式，為每個packfile設(shè)置一個限制(pack.packSizeLimit)，超過這個限制就分包，同時每次repack重新打包時將新的松散對象采用增量(git repack -d)打包，然后在于之前的小于某個限制(git multi-pack-index repack --batch-size=<size>)的所有pack重新打包，看下如下命令：

# 設(shè)置每個packfile的大小為3g，-d表示采用增量的方式將新松散文件打包，使用--write-midx 開啟多包索引 git -c pack.threads=4 -c pack.packSizeLimit=3g -c repack.packKeptObjects=true -c core.multiPackIndex=true repack -l -d -n --write-midx # git multi-pack-index repack --batch-size=<size>,將小于size的packfile重新打包成一個或多個packfile，如果兩個packfile都小于size打小，但是重新repack后生成的新packfile大于pack.packSizeLimit，那么將不予合并打包 git -c pack.threads=4 -c repack.packKeptObjects=true -c pack.packSizeLimit=3g -c core.multiPackIndex=true multi-pack-index repack --batch-size=2g # 重新生成bitmap git multi-pack-index write --bitmap

3.3 repack單包與多包性能對比

當測試repack相關(guān)功能時，為了驗證單包和多包性能問題，需要保持每次松散對象數(shù)量是一致的，因此當執(zhí)行完單包命令之前需要將objects文件夾備份，并在執(zhí)行完單包命令之后將備份的objects重新復制回去并執(zhí)行unpack命令，流程如下：

3.3.1 前置條件：

已有40w個松散對象被打包成一個pack(約7.5g)，以及10w個松散對象(約2g)。本次通過直接執(zhí)行命令觀看效果，因此使用了root權(quán)限。

• 1、將.git/objects整個目錄備份，并將10w個文件產(chǎn)生的對應(yīng)的pack(記為pack-d69d44271fc40005eed5c8e0d7ec82c15e80dddd.pack)文件備份
• 2、執(zhí)行cat pack-d69d44271fc40005eed5c8e0d7ec82c15e80dddd.pack | git unpack-objects，將pack-d69d44271fc40005eed5c8e0d7ec82c15e80dddd.pack重新unpack成loose objects，需要注意的是執(zhí)行unpack-objects命令的pack需要從.git/objects目錄下移走
• 3、驗證單包/多包命令
• 4、回到步驟2循環(huán)執(zhí)行

3.3.2 測試命令

測試時可參考下述命令
單包

• gc：

git -c repack.writeBitmaps=true -c pack.writeBitmapHashCache=true -c gc.writeCommitGraph=false gc --prune=30.minutes.ago

• repack

git -c pack.threads=16 -c repack.writeBitmaps=true repack -A -l -d -n

多包

• gc

git -c pack.packSizeLimit=3g -c repack.packKeptObjects=true -c gc.writeCommitGraph=false -c gc.bigPackThreshold=2g gc --prune=30.minutes.agogit multi-pack-index write --bitmap

• repack

git multi-pack-index expire git -c pack.threads=16 -c pack.packSizeLimit=3g -c repack.packKeptObjects=true -c core.multiPackIndex=true repack -l -d -n --write-midx git -c pack.threads=16 -c repack.packKeptObjects=true -c pack.packSizeLimit=3g -c core.multiPackIndex=true multi-pack-index repack --batch-size=2g git multi-pack-index write --bitmap

3.3.3 測試結(jié)果及分析

1、耗時分析

• 單包repack
  
• 多包repack
  
  重寫bitmap耗時約1m 18s
  
  可以看到多包repack總耗時約在4m 42s

2、cpu分析

左邊是單包，右邊是多包

可以看到單包時cpu使用超50%耗時約420s，而多包則在140s

3、IO讀寫

總結(jié)

整理IO讀寫并進行估算后，結(jié)果如下(舊邏輯即為單包，新邏輯即為多包)

繪圖如下

可以看到使用多包處理后資源占用明顯降低，耗時減少。

相關(guān)文檔

1、Git-內(nèi)部原理-Git-對象
2、git-gc
3、git-config
4、git-pack-objects
5、git-multi-pack-index
6、git-repack
7、git-count-objects
8、bitmap
9、Git數(shù)據(jù)存儲的原理淺析

總結(jié)

以上是生活随笔為你收集整理的git repack多包使用及相关性能测试的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。