为什么Perforce填充命令速度慢？

情况：

• Performce服务器的网络带宽有限（我正在远程工作）

• 我想要分支的存储库包含很多二进制文件，大小有很多GB

• 文件数量很大（约500000个文件）

当我发出

p4 populate

命令来填充一个新的开发分支时，该操作需要1-2个小时才能完成，为什么

据我所知，populate会在适当的地方进行分支，不会通过网络拉整个回购协议，所以我认为这不是网络问题。 在数据库中创建一百万个条目也不会花费太长时间。 它是否将二进制文件复制到新的存储库中，而不仅仅是引用它们

在我使用-Ztrace再次分支后，编辑以下日志：

57055 files branched (change 2779417).
--- lapse 6408s
--- usage 3573+2619us 0+0io 0+0net 65672k 0pf 
--- rpc msgs/size in+out 2+57059/0mb+13mb himarks 785732/280100 snd/rcv 3.38s/.047s
--- db.counters
---   pages in+out+cached 11+16+2
---   locks read/write 0/4 rows get+pos+scan put+del 3+0+0 4+0
--- db.logger
---   pages in+out+cached 6+4+4
---   locks read/write 0/1 rows get+pos+scan put+del 0+0+0 2+0
--- db.user
---   pages in+out+cached 4+0+3
---   locks read/write 1/0 rows get+pos+scan put+del 1+0+0 0+0
--- db.group
---   pages in+out+cached 5+0+4
---   locks read/write 1/0 rows get+pos+scan put+del 0+3+5 0+0
--- db.domain
---   pages in+out+cached 7+0+5
---   locks read/write 2/0 rows get+pos+scan put+del 2+0+0 0+0
--- db.view
---   pages in+out+cached 7+0+7
---   locks read/write 4/0 rows get+pos+scan put+del 0+4+57 0+0
--- db.integed
---   pages in+out+cached 42486+51286+192
---   pages reordered internal+leaf 180+5972
---   pages split internal+leaf 182+4377
---   locks read/write 0/1 rows get+pos+scan put+del 0+0+0 114110+0
---   total lock wait+held read/write 0ms+0ms/0ms+5175ms
--- db.archmap
---   pages in+out+cached 28+47+26
---   pages split internal+leaf 1+12
---   locks read/write 0/1 rows get+pos+scan put+del 0+0+0 502+0
---   total lock wait+held read/write 0ms+0ms/0ms+1174ms
--- db.revdx
---   pages in+out+cached 3+0+1
---   locks read/write 0/1 rows get+pos+scan put+del 0+0+0 0+0
---   total lock wait+held read/write 0ms+0ms/0ms+1174ms
--- db.revhx
---   pages in+out+cached 2888+8526+96
---   pages split internal+leaf 85+2783
---   locks read/write 0/1 rows get+pos+scan put+del 0+0+0 57055+0
---   total lock wait+held read/write 0ms+0ms/0ms+1174ms
--- db.revpx
---   pages in+out+cached 233571+357872+96
---   pages split internal+leaf 79+2395
---   locks read/write 0/114110 rows get+pos+scan put+del 0+0+0 57055+57055
---   total lock wait+held read/write 0ms+0ms/5846ms+2128ms
---   max lock wait+held read/write 0ms+0ms/99ms+9ms
--- db.revcx
---   pages in+out+cached 1414+4160+96
---   pages split internal+leaf 43+1356
---   locks read/write 0/1 rows get+pos+scan put+del 0+0+0 57055+0
---   total lock wait+held read/write 0ms+0ms/0ms+1174ms
--- db.rev
---   pages in+out+cached 10977+7868+96
---   pages split internal+leaf 76+2570
---   locks read/write 2/1 rows get+pos+scan put+del 57055+7+184634 57055+0
---   total lock wait+held read/write 0ms+571ms/0ms+1174ms
---   max lock wait+held read/write 0ms+571ms/0ms+1174ms
---   peek count 1 wait+held total/max 0ms+0ms/0ms+0ms
--- db.trigger
---   pages in+out+cached 4+0+2
---   locks read/write 2/0 rows get+pos+scan put+del 0+2+35 0+0
--- db.change
---   pages in+out+cached 13+12+4
---   locks read/write 0/3 rows get+pos+scan put+del 3+0+0 2+1
---   total lock wait+held read/write 0ms+0ms/0ms+1175ms
---   max lock wait+held read/write 0ms+0ms/0ms+1175ms
--- db.changex
---   pages in+out+cached 11+8+3
---   locks read/write 0/3 rows get+pos+scan put+del 0+0+0 1+1
---   total lock wait+held read/write 0ms+0ms/0ms+1175ms
---   max lock wait+held read/write 0ms+0ms/0ms+1175ms
--- db.changeidx
---   pages in+out+cached 5+0+1
---   locks read/write 0/2 rows get+pos+scan put+del 0+0+0 0+0
---   total lock wait+held read/write 0ms+0ms/1ms+1174ms
---   max lock wait+held read/write 0ms+0ms/1ms+1174ms
--- db.desc
---   pages in+out+cached 13+12+4
---   locks read/write 0/3 rows get+pos+scan put+del 0+0+0 2+1
---   total lock wait+held read/write 0ms+0ms/0ms+1174ms
---   max lock wait+held read/write 0ms+0ms/0ms+1174ms
--- db.protect
---   pages in+out+cached 9+0+8
---   locks read/write 1/0 rows get+pos+scan put+del 0+1+410 0+0
--- db.monitor
---   pages in+out+cached 2+6+256
---   locks read/write 4/2 rows get+pos+scan put+del 4+0+0 1+1

---

如果运行带有全局标志-Ztrack的命令，例如：

p4 -Ztrack populate (args...)

您将获得一系列性能调试信息，其中包括服务器在何处花费时间。（如果您不想再次运行该命令，则此信息可能已存储在服务器日志中；您只需在其中跟踪即可。）

在一般情况下，

p4 populate

是一个仅元数据的命令（复制修订表中的行并添加整数行以连接它们），由于对同一基础归档文件有其他引用，所有实际文件内容都只是“延迟复制”

例外情况是，如果存在无法延迟复制的修订。在我脑海中，我能想到的两种情况是远程仓库和

+S

文件（可能是您提到的一些大型二进制文件）

---

在任何情况下，如果您可以获得性能跟踪信息，您可以看到服务器是否将所有时间都花在创建数据库条目上（在这种情况下，我会查看数据库所在的磁盘，看看是否有任何方法可以加快它的速度--它是否已安装在网络上，是否由一组其他进程共享，等等）或者，如果它正在复制归档文件（在这种情况下，您会想知道它为什么需要这样做，以及是否有任何方法可以避免这种情况——例如，我始终建议不要对将要分支的文件使用

+s

文件类型标志）。

如果二进制文件使用“+s”文件类型修饰符，则是，我认为它们必须被复制，因为它们的修订边界逻辑是每个分支，而不是整个回购协议。有关+SI刚用-Ztrack启动命令的信息，请参阅。。。还没有打印任何内容，我是否希望它在命令末尾这样做？在我用-Ztrace填充另一个分支后，向问题添加了日志。命令花了两个小时才返回。但我在日志中没有看到……总时间在顶部：

延时6408s

。但最长的db写入只需5秒。如果我是一个赌徒，我敢打赌你有一堆你没有提到的

+S

文件，而6403秒的差异是用来制作所有文件的额外副本的。：）为+S对

p4文件进行greping不会产生任何结果。请尝试在填充的路径上运行
p4 size-z
，查看它是否占用任何存档空间。如果是这样的话，请深入查看是哪些，以及原因。“正常”填充应该根本不创建存档。