时间戳

首页 > 解决方案 > 为什么 Perforce 填充命令很慢？

perforce - 为什么 Perforce 填充命令很慢？

问题描述

情况：

当我发出p4 populate命令来填充新的 dev 分支时，操作需要 1-2 小时才能完成，为什么？

据我所知，populate 会进行适当的分支并且不会通过网络拉动整个 repo，所以我认为这不是网络问题。在数据库中创建一百万个条目也不应该花很长时间。它是否将二进制文件复制到新的存储库中，而不仅仅是引用它们？

编辑这里是我使用 -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

标签： perforce

解决方案

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

p4 -Ztrack populate (args...)

你会得到一堆性能调试信息，包括服务器花费时间的地方。（如果您不想再次运行该命令，此信息可能已经存储在服务器日志中；您只需要在那里跟踪它。）

在一般情况下，p4 populate是一个仅元数据的命令（复制修订表中的行并添加整数行以连接它们），并且所有实际文件内容都简单地“延迟复制”，因为具有对相同底层的附加引用档案。

例外情况是存在无法延迟复制的修订。在我的脑海中，我能想到的两种情况是远程仓库和+S文件（可能是你提到的一些大型二进制文件）。

无论如何，如果您可以获得性能跟踪信息，您可以查看服务器是否将所有时间都花在创建数据库条目上（在这种情况下，我会查看数据库所在的磁盘，看看是否有任何加速它的方法——它是网络安装的，它是由一堆其他进程共享的，等等）还是它正在复制档案（在这种情况下，你会想弄清楚它为什么需要这样做，并且如果有任何方法可以避免它——例如，我总是建议不要对+S将要分支的文件使用文件类型标志）。

推荐阅读