Structure changes are extremely slow using Vault v4

GilbertG · Post by **GilbertG** » Wed Jun 27, 2007 9:39 am

Hello,

Have recently upgraded from v3 to v4 and structure changes like move, delete and rename are very slow (like 5 minutes for a single rename or delete). I have tried the auto-commit option on and off - no difference except with the option off the slowness comes when you commit the action.
Is this a known issue or should i be looking at our server more carefully.

Regards,
Gilbert

ian_sg · Post by **ian_sg** » Wed Jun 27, 2007 11:17 am

The server-side changes related to move/rename/delete in 4.0 were insignificant in terms of performance impact. If just committing one simple rename is taking minutes, something is amiss on the server.

Are other things running on the server that need to be looked at?

http://support.sourcegear.com/viewtopic.php?t=2924 has information about database maintenance which sometimes vastly improves performance.

GilbertG · Post by **GilbertG** » Wed Jun 27, 2007 11:44 am

Some more info on this:

Between beginning transaction and ending transaction time is relatively. The slow parts are "Working" and "Retrieving repository structure information from the server". During which the client processor goes up to 100% and there is almost no disk activity. Using P4 3.4GHz. So, seems there is something hectic going on on the client side.
Regards,
Gilbert

ian_sg · Post by **ian_sg** » Wed Jun 27, 2007 12:08 pm

If you have a very large number of pending move/rename/deletes, that could slow things down as you describe, though it still shouldn't be minutes of delay.

If you want to turn on client side logging for the Windows client, perform a slow operation, and email me the results (using the button below), I could take a look and possibly better identify the culprit.

GilbertG · Post by **GilbertG** » Wed Jun 27, 2007 1:33 pm

Ian,
I have sent you a log of a simple operation - i have another with a move of multiple files that takes much longer - attached to this post.
Regards,
Gilbert

ian_sg · Post by **ian_sg** » Wed Jun 27, 2007 1:56 pm

Thanks for the detailed information, Gilbert.

I notice at the end of the second log (the one posted here) you commit all the deletes you had pending. Are moves/renames substantially faster now, after that commit?

GilbertG · Post by **GilbertG** » Thu Jun 28, 2007 5:13 am

Ian,
Sorry for the delay - in south africa with a time difference.

No, the performance did not change, i just forgot to zip the log before starting the delete post.

GilbertG · Post by **GilbertG** » Wed Jul 04, 2007 1:26 am

Hello Ian,

You get any further on this issue? People are getting really frustrated here.

Gilbert

ian_sg · Post by **ian_sg** » Thu Jul 05, 2007 7:47 am

Gilbert,

Sorry for the delay, I've been out of the office several days. I can see the delay in your log, but we've had no success reproducing it under similar circumstances here. We have identified a number of optimizations that will be made in a future release, but it would still be good to understand why they problem is so pronounced for you.

It sounds like more than one person in your organization is experiencing the slowdown. Can you provide rough specs on those machines?

GilbertG · Post by **GilbertG** » Fri Jul 06, 2007 6:10 am

Hi Ian,

Yes, we have roughly 30 vault users here and as far as i have asked, every one is having similar problems. The main complaint is deleting and undoing a checkout. Undoing is implicit if no changes are made. I usually wait a while, end task vault then re-open it and all the undo's have been resolved.
Anyway, the machines here vary, but average at 2GHz Intel Centrino duo laptops with 1 to 2 Gb memory. The server is AMD 2.17GHz opteron with 1Gb. There server show no activity when undoing checkouts.

Regards,
Gilbert

GregM · Post by **GregM** » Fri Jul 06, 2007 8:21 am

I have also seen really long times for undoing a modification from the pending change set. I'm not requiring checkouts, so there is no checkout to undo. All it needs to do is replace the file. I've also seen really long times for undoing a delete of a file that had been modified before I deleted it.

Client and server are 4.0.1

ian_sg · Post by **ian_sg** » Fri Jul 06, 2007 8:36 am

Greg,

So that I have another data point would you be willing to turn on client logging and send me a log that includes a long-running undo delete? There's some additional useful information logged when the client first starts up, so it would be ideal if that were also in the log. You can email it to ian at sourcegear dot com.

Thanks.

ian_sg · Post by **ian_sg** » Fri Jul 06, 2007 10:30 am

We've been able to reproduce some pretty dismal performance along these lines. I'll post info about a fix/workaround here as soon as I know more.

GregM · Post by **GregM** » Fri Jul 06, 2007 12:26 pm

I already had the client open, so I just used the shortcut to start logging. I picked a modified file from my pending change set, deleted it, and then undid that deletion. The undo took about 5 minutes.

ian_sg · Post by **ian_sg** » Mon Jul 09, 2007 2:13 pm

Thank you both for your help in tracking this down. We have a fix for the issue that makes these operations perform in just a few seconds, as you'd expect, that will be included in 4.0.3.

At present I can't give an accurate estimate for the release of 4.0.3, but I can provide a pre-release build (which is essentially just 4.0.2 plus this fix) for folks who experience this issue. Email me (ian at sourcegear dot com) and I'll reply with a client-only installer attached.

SourceGear Support

Structure changes are extremely slow using Vault v4

Structure changes are extremely slow using Vault v4

client-side

App log

Hello

Specs