当前位置： 首页 > news >正文

安平网站建设培训,发任务做任务得网站,滨州正规网站建设价格,html5商城网站模板1、git数据结构 git 中存在四种数据结构#xff0c;即object包含四种#xff0c;分别是tree对象、blob对象、commit对象、tag对象 1.1 blob对象 存储文件内容#xff0c;内容是二进制的形式#xff0c;通过SHA-1算法对文件内容和头信息进行计算得到key(文件名)。 如果一…1、git数据结构 git 中存在四种数据结构即object包含四种分别是tree对象、blob对象、commit对象、tag对象 1.1 blob对象 存储文件内容内容是二进制的形式通过SHA-1算法对文件内容和头信息进行计算得到key(文件名)。 如果一个commitId为73c17abe44977ee82cd949f489996c2715335119则这个blob文件在.git/objects/73文件夹下名为c17abe44977ee82cd949f489996c2715335119也就是说hash值的前两位为objects目录下子目录的名字剩余38位为文件名。 1.2 tree对象 可以看作一个目录管理一些“tree”对象或是“blob”对象。它有一串指向“blob”对象或是其它“tree”对象的指针一般用来表示内容之间的目录层次关系(就像文件和子目录) 1.3 commit对象 commit对象指向一个“tree对象”并且带有相关的描述信息标记项目某一个特定时间点的状态。它包括一些关于时间点的元数据如时间戳、最近一次提交的作者、指向上次提交的指针等 commit、tree、blob关系可以总结如下 一个commit对应一个tree对应多个blob
1.4 tag对象 一个tag对象包括一个对象名(SHA1签名)、对象类型、标签名、标签创建人的名字(“tagger”), 还有一条可能包含有签名(signature)的消息。 通过 总结 git每次提交存储的都是整个文件而不是采用增量所以会导致存储数据量很大git针对此采用了zlib对数据进行压缩可以采用cat-file命令来查看 一旦将内容存储在了对象数据库中那么可以通过 cat-file 命令从 Git 那里取回数据。 为 cat-file 指定 -p 选项可指示该命令自动判断内容的类型并为我们显示大致的内容
2、git pack git向仓库中推送文件时存储使用的是“松散文件”如果有一个1.txt现在是10k下次推送增加了0.1k也就是说现在是10.1kname第二个版本就会重新产生一个1.1k的文件这样会产生磁盘浪费所以git会将这些文件打包成一个二进制类型的包文件(packfile)并生成对应的.idx索引文件以节省空间和提升效率。这些被打包的文件存储在.git/objects/pack目录下执行find .git/objects/ -type f命令如下 看到.git/objects目录下的文件详情包含了8个松散文件、一个pack文件、一个idx文件如果想查看更详细的内容可以执行 git count-objects -v命令 git count-objects -v命令结果的各个含义如下 count 松散对象数size松散对象占用的磁盘空间单位为KBin-pack在pack文件中的objects数量size-packpack文件占用的空间单位为KBprune-packable同时在松散对象和packs文件中都包含的objects数量这种objects可以执行git prune-packed命令修剪garbage对象数据库中既不是有效松散对象也不是有效包的文件数size-garbage垃圾文件占用的磁盘空间单位为KB 3、git repack 3.1 repack作用 用于将当前不驻留在“pack”中的所有对象合并到包中。它还可用于将现有包重新组织为一个更高效的包。pack文件是单独压缩的对象的集合应用了增量压缩存储在单个文件中并具有关联的索引文件。而且pack文件用于减少镜像系统、备份引擎、磁盘存储等上的负载。 3.2 单包与多包 3.2.1 单包 在重新打包时repack会有一些options可供选择如-d, -A如果加上了-A则重新打包时就会将新的松散文件与之前的pack共同打包成一个pack。 在单包时通常会将加上–write-bitmap-index来生成.bitmap文件(bitmap文件存储有关包文件或多包索引MIDX中对象集的可达性信息)此option会覆盖repack.writeBitmaps值当然如果不指定此option也可通过命令git config –global repack.writeBitmaps true然后通过git config -l查看是否成功设置此option。需要注意的是–write-bitmap-index option只在单包时才会生效也就是说只在与-a、-A或-m一起使用时有意义因为位图必须能够引用所有可访问的对象(多包如何设置bitmap后面会涉及)。 3.2.2 多包 随着文件数越来越多pack文件就会越来越大单包策略的缺点就暴露了出来如果使用单包包大小高达30g甚至更大当有新的松散文件时、或gc时触发的repack将会非常慢。 针对上述问题可以采用多包的方式为每个packfile设置一个限制(pack.packSizeLimit)超过这个限制就分包同时每次repack重新打包时将新的松散对象采用增量(git repack -d)打包然后在于之前的小于某个限制(git multi-pack-index repack –batch-sizesize)的所有pack重新打包看下如下命令

设置每个packfile的大小为3g-d表示采用增量的方式将新松散文件打包使用–write-midx 开启多包索引

git -c pack.threads4 -c pack.packSizeLimit3g -c repack.packKeptObjectstrue -c core.multiPackIndextrue repack -l -d -n –write-midx # git multi-pack-index repack –batch-sizesize,将小于size的packfile重新打包成一个或多个packfile如果两个packfile都小于size打小但是重新repack后生成的新packfile大于pack.packSizeLimit那么将不予合并打包 git -c pack.threads4 -c repack.packKeptObjectstrue -c pack.packSizeLimit3g -c core.multiPackIndextrue multi-pack-index repack –batch-size2g # 重新生成bitmap git multi-pack-index write –bitmap3.3 repack单包与多包性能对比 当测试repack相关功能时为了验证单包和多包性能问题需要保持每次松散对象数量是一致的因此当执行完单包命令之前需要将objects文件夹备份并在执行完单包命令之后将备份的objects重新复制回去并执行unpack命令流程如下 3.3.1 前置条件 已有40w个松散对象被打包成一个pack(约7.5g)以及10w个松散对象(约2g)。本次通过直接执行命令观看效果因此使用了root权限。
1、将.git/objects整个目录备份并将10w个文件产生的对应的pack(记为pack-d69d44271fc40005eed5c8e0d7ec82c15e80dddd.pack)文件备份2、执行cat pack-d69d44271fc40005eed5c8e0d7ec82c15e80dddd.pack | git unpack-objects将pack-d69d44271fc40005eed5c8e0d7ec82c15e80dddd.pack重新unpack成loose objects需要注意的是执行unpack-objects命令的pack需要从.git/objects目录下移走3、验证单包/多包命令4、回到步骤2循环执行 3.3.2 测试命令 测试时可参考下述命令 单包 gc git -c repack.writeBitmapstrue -c pack.writeBitmapHashCachetrue -c gc.writeCommitGraphfalse gc –prune30.minutes.agorepack git -c pack.threads16 -c repack.writeBitmapstrue repack -A -l -d -n多包 gc git -c pack.packSizeLimit3g -c repack.packKeptObjectstrue -c gc.writeCommitGraphfalse -c gc.bigPackThreshold2g gc –prune30.minutes.agogit multi-pack-index write –bitmaprepack git multi-pack-index expire git -c pack.threads16 -c pack.packSizeLimit3g -c repack.packKeptObjectstrue -c core.multiPackIndextrue repack -l -d -n –write-midx git -c pack.threads16 -c repack.packKeptObjectstrue -c pack.packSizeLimit3g -c core.multiPackIndextrue multi-pack-index repack –batch-size2g git multi-pack-index write –bitmap3.3.3 测试结果及分析 1、耗时分析 单包repack 多包repack 重写bitmap耗时约1m 18s 可以看到多包repack总耗时约在4m 42s 2、cpu分析 左边是单包右边是多包 可以看到单包时cpu使用超50%耗时约420s而多包则在140s 3、IO读写 总结 整理IO读写并进行估算后结果如下(旧逻辑即为单包新逻辑即为多包) 绘图如下
可以看到使用多包处理后资源占用明显降低耗时减少。 相关文档 1、Git-内部原理-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