Performance after deleting Vault_1 folders?

Michael_Dorfman · Post by **Michael_Dorfman** » Fri Jan 21, 2005 11:28 am

Due to some problems that are probably not relevant here, I deleted my Vault_1 folders, as described in http://support.sourcegear.com/viewtopic.php?t=6

After doing so, I went into my repository, and did a "Get Latest".

I expected that this would be slower than usual, since the system had to rebuild the cache, but I had not expected it to take 4 hours and 4 minutes.

I know there are a lot of factors at play, but is this within normal limits? My repository has a tree-size of 950MB, and consists of 44000 files (and 53000 delete files).

Thanks,

Michael Dorfman

dan · Post by **dan** » Fri Jan 21, 2005 12:58 pm

Since all of your files went to Unknown status after deleting the status files, the client had to either resolve them (if you are using 3.0), or make backup copies (in you are using 2.0), so it would take longer than a normal get would.

Michael_Dorfman · Post by **Michael_Dorfman** » Fri Jan 21, 2005 2:52 pm

dan wrote:Since all of your files went to Unknown status after deleting the status files, the client had to either resolve them (if you are using 3.0), or make backup copies (in you are using 2.0), so it would take longer than a normal get would.

Naturally. My question is: should resolving 40,000 files take 4 hours? Obviously (in retrospect) it would have behooved me to just delete the working copies, since they were all unchanged, but that's not my concern-- I'm just wondering if the performance were a sign of something unusual going on. My users have complained that the Vault seems sluggish lately, but this was the most dramatic sign so far.

dan · Post by **dan** » Fri Jan 21, 2005 3:52 pm

Yes, 4 hours is long, but it really depends on the speed of your disk on the client side (if for instance it is a laptop, it might have a really slow disk), on the network connection, and on the server itself. It would be interesting to compare it to a Get to a non-working folder, or to a new working folder, and see how much shorter it takes, and also perhaps try it on another machine, to see whether the results are machine-specific.

If all operations seem slow, have you done any regular DB maintenance, like rebuilding indices, defragging, etc?

Also, if you are on 2.0.x, we did make strides in 3.0 with concurrency, if you have a lot of users.