Labeling and Branching (performance)

[Thomas Linder Puls]

Labeling and branching is extremely resource demanding.

Labeling or branching a tree with 15000 files can take 20 minutes or more. And during that time nobody else seems to be able to get access to the repositories.

I believe the problem with labeling came when you added the "promotion" feature. I am not sure if the branching problem came at the same time.

[Tonya]

What version of Vault are you using?

After performing a branch/label that takes a long time, you might want to look in the Vault Server log to see if you anything stands out.

Perhaps maintenance on the Vault Server might help:

viewtopic.php?t=2924

Thanks,

Tonya

[Hans Olav Nymand]

>What version of Vault are you using?

We are using version 10.0.2.858

>After performing a branch/label that takes a long time, you might want to look in the Vault Server log to see
>if you anything stands out.

We have done so, and there are no extra or particular errors that don't also occur when there are no big performance issues. So nothing special stands out during this problem.

However, the last time we had this problem, we noticed on the SQL server a lot of waiting tasks - all waiting due to a lock induced by sgVault.dbo.ufngetusersecurityrights()

>Perhaps maintenance on the Vault Server might help:

We do regular (automatic) maintenance as you have previously suggested. This, however, has not had any noticable effect. A dbcc check also says that there ar no particular problems, no indexes that need rebuilding or anything like that.

As Thomas mentioned in the original post we believe there is some kind of design flaw here. We started experiencing this problem when the "label promotion" feature was introduced, I think with Vault 8.0. Before that setting a label was always a matter of a few seconds (or less), even on a big folder in a big repository. Now setting a label is usually a matter of minutes (or more).

We have conducted extensive monitoring of the "health" of both the SQL Server and the Vault service host (they are on different machines). As you know we have frequently some problems with the Vault service host, however there are no additional problems when we experience this particular problem with label-setting.

Also the SQL Server does not report any problem. But - when experiencing this particular problem - we notice a lot of locking. Locking to an extent so that also users in other repositories are denied processing! We think this is weird. Setting a label in one repository should not block operations in other repositories.

I am sorry in a way we did not report this particular problem earlier, but it has taken a long time understanding what was the problem and convincing ourselves that our server operations was otherwise ok.

Best regards,
Hans Olav Nymand

[Tonya]

Hi Hans,

Thank you for all the details. We don't believe the issue is related to label promotion. Promoting items within a label is a feature that was available in a very early release of Vault.

However, you noted that in the past some significant time being taken in ufngetusersecurityrights. We'd like to look into this a bit more. Would you be willing to try a few things to help trouble shoot the issue by allowing us to run SQL Server's Activity Monitor during an operation? We'd use this information along with information from SQL Server Profiler to try to determine exactly where the performance issue lies.

Can you please email us at support@sourcegear.com and reference this forum post? We can go over more details offline and hopefully setup a remote session.

Thanks,

Tonya

[Hans Olav Nymand]

Hi Tonya,

Yes, maybe it is not related to label promotion, but the problem appears in relation to setting labels and the problem did not exist until some major version was released - either Vault 7.0 or vault 8.0. So something was changed in the way labels are handled internally with one of those versions.

I'll have to get back yo you on setting up a remote session.

Best regards,
Hans Olav

[Tonya]

We received your response in regards to the remote session. I will respond via the support ticket.

Thanks,

Tonya