Repository size

tjruska · Post by **tjruska** » Wed Jul 09, 2008 9:38 am

I am just wondering if there is threshold or best practice in keeping a single repository size managable? I did a check on 2 of our largest ones via the Admin tool and here are the sizes:

Repository ABC
Folders: 13897 (+8629 deleted)
Files: 223631 (+132647 deleted)
Tree size: 12.74 GB
Disk Space Needed: 25.48 GB
Database Size: 3.82 GB

Repository XYZ
Folders: 1429 (+583 deleted)
Files: 21185 (+9158 deleted)
Tree size: 1.85 GB
Disk Space Needed: 3.7 GB
Database Size: 1.3 GB

In you estimation, are these too big? Should some sort of cleanup be performed such as exporting old branches and then deleting them? I am starting to receive complaints from the developers regarding performance when trying to open these repositories.

We are using 3.5.0 currently with a SQL Server 2000 SP4 backend.

I would appreciate any suggestions/tips/etc.

TIA, Tom

lbauer · Post by **lbauer** » Thu Jul 10, 2008 10:13 am

Your repositories are not unusually large. Usually users are concerned about the database or repository size because they are having performance issues.

If you have adequate system resources and disk space, repository size itself should not cause a performance problem.

There other reasons that performance can be affected.

Do you have a large number of checkouts in your repositories?

Are there a large number of shares?

Are other operations slow, or just the first login of the day?

tjruska · Post by **tjruska** » Fri Jul 11, 2008 7:04 am

Now why would you think we are having performance issues?

The use of shares is limited. 2 folders in that project. Just opening the one large repository takes minutes from the client (5 - 10 minutes).

The one developer who handles branching/merging of the code says it takes him anywhere from 20 min to an hour or more to branch the ABC repository. And he does this off hours at night to ensure no one else is in it.

Please define "adequate" system resources. I know the server is not taxed at all and it is dedicated to Vault only with a SQL backend on another one.
Now since Vault runs as a web service and I know that this server has been up and running for months (no reboot), should we be forcing an iisreset at some interval? Anytime we have issues, that is the first thing our support people do is an iisreset and that usually does the trick.

If you feel I should open a ticket for further assistance I can or we can continue in this thread for others too.

Tom

lbauer · Post by **lbauer** » Fri Jul 11, 2008 8:21 am

Just opening the one large repository takes minutes from the client (5 - 10 minutes).

What happens after they open the repository, close the client and then reopen the repository? Does it still take 5 - 10 minutes? This information will help us diagnose the bottleneck better.

Before we go much further, though:

You're on an older version of Vault, and we have improved performance since then.

We'd recommend database maintenance:

http://support.sourcegear.com/viewtopic.php?t=2924

Better yet, upgrade to Vault 4.1.3, due out in a few weeks. Then if performance issues continue, we have a better chance to troubleshoot and fix them.

tjruska · Post by **tjruska** » Mon Jul 14, 2008 5:52 am

I just tried and opened our largest repository and it took about 8 minutes. Then I closed the client and reopened it and it took just seconds. So the first hit will always be "painful"? Are there some settings I can check to improve this?

I will forward the article regarding DB maintenance to our DBA group.
We are on v3.5.0 and I have been trying to convince management and the developers that we need to at least apply some patches to bring us up to at least v3.5.3 if not 4.x.x. I think the former would be at least a step in the right direction. Going to 4.x would be a major effort here. But at least if I can stabilize things first, then I can push for a 4.x upgrade.

Tom

lbauer · Post by **lbauer** » Tue Jul 15, 2008 4:01 pm

Login with a GUI Client, and look under Help->Technical Support. Could you copy the info here?

Does the CPU on the client side show heavy usage during this login delay?

tjruska · Post by **tjruska** » Wed Jul 16, 2008 5:31 am

Client Information
Vault Client Version: 3.5.0.4741
.Net Framework Version: 1.1.4322.2407
Operating System: Microsoft Windows XP Professional
Service Pack: 2.0
OS Version: 5.1.2600
Total Physical Memory: 1.97 GB
Time Zone: (GMT-06:00) Central Time (US & Canada)

Server Information
Vault Server Version: 3.5.0.4741
.Net Framework Version: 1.1.4322.2300
Operating System: Microsoft(R) Windows(R) Server 2003, Enterprise Edition
Service Pack: 1.0
OS Version: 5.2.3790
Timezone: (GMT-06:00) Central Time (US & Canada)
SQL Version: Microsoft SQL Server 2000 - 8.00.2187 (Intel X86)
Mar 9 2006 11:38:51
Copyright (c) 1988-2003 Microsoft Corporation
Enterprise Edition on Windows NT 5.2 (Build 3790: Service Pack 2)

CPU usage is running 50% and the client displays "Retrieving repository information from the server...."

But I did notice that in that first access, that the \Local Settings\Application Data\SourceGear\Vault_1\Client\<guid> folder gets created if it isn't already there. Upon successive access, it is quicker.

lbauer · Post by **lbauer** » Thu Jul 17, 2008 9:44 am

If you there have been a lot of transactions since you accessed Vault, or if you don't have the client side cache file already, it will take longer to log into the repository.

Have you done the database maintenance mentioned earlier in this thread?

http://support.sourcegear.com/viewtopic.php?t=2924

You could also try deleting branches that you aren't using. I wouldn't recommend obliterating, as that could cause problems if you ever want to export from the repository. Just keeping them out of the tree should help, plus you can always undelete later.

Let me know if this does not resolve the problem.

robe070 · Post by **robe070** » Thu Jul 17, 2008 4:46 pm

Good tip to delete a branch as you can always bring it back.

But can you explain your comment about obliterating causing problems with export?

lbauer · Post by **lbauer** » Fri Jul 18, 2008 2:04 pm

Obliterate removes history. So you might be just exporting FolderA, but perhaps that folder was, at one time a subfolder that was moved from one parent folder to another. And FolderA's original parent folder was deleted and obliterated.

You can't export FolderA because there's a chunk missing from it's history.

We hope to address this in a future release by making the Export tool more tolerant of missing history.

So if you think you might Export at some point, we'd recommend refraining from obliterating.