Vault slowness

[rgkeefer]

We recently upgraded to version 2.0.1 of Vault hoping that it would be much faster. However, that has not been the case. It consistently takes about 3-4 minutes for our developers to check out and check in files. Recently it took 5 minutes to undo check-out on a file that was not even mofified.

We moved the server to a Dell 2650 with dual zeon processors and 1GB of RAM so it cant be a slow machine. As you can imagine, the developers have been getting very frustrated. We loase about an hour of productivity each day due to Vault. When the developers in India are working in Vault at the same time as us, it gets even worse. We usually have to reboot the server a few times each day...

I dont believe that Vault is this slow for everyone since at times it is unusable for us and I dont see very many posts like this. Is there anything you can think of that will help? If you need more information please let me know. We are getting desperate.

Thanks

[jclausius]

lets look at one of your exact problems -> undo checkout.

1) how many checkouts do you happen to have in your repository? SELECT COUNT(*) FROM sgvault.dbo.ufngetlockedfiles( A ) -- WHERE A is an integer number for one of your repository ids. You can get this number from here SELECT repid, name FROM sgvault.dbo.tblrepositories.

the checkout list is generated on refreshes of the clients. vault tries to reduce as much network traffic by sending only changes to the checkout list since a client last checked. however, if the checkout list is quite large, this might be the source of the problem. in these cases, i would recommend only checking out what will be modified.

2) do you run database maintenance on the statistics and indices? if you've never run any maintenance this could be the cause.

3) Do you run with folder security enabled? Can try to disable folder security and run an undo checkout? Did this help? If it did, how many users / folders / security rights assignments would you estimate you use?

4) One other possibility, can you provide the results for SELECT COUNT(*) FROM sgvault.dbo.tblsessionrellocks

[jclausius]

Two other things ---

5) You mention you are using Vault 2.0.1. Can you run this statement against the database SELECT schemaversion FROM sgvault.dbo.tblsechemaversions?

6) Can you run this query as well? SELECT SERVERPROPERTY(N'EngineEdition'), SERVERPROPERTY(N'Edition')


Thanks, again.

[rgkeefer]

1) I ran the query for the number of files checked out and got 105. Is this a lot?

2) We do run regular maintenance on the sgvault database

3) I disabled folder security but we havent noticed much of a difference yet...

4) I ran this query and the number that came back was 9. Should I kill these?

5) 2.0.0.9

6) 3, Enterprise Edition

Also, I was recently adding labels into Vault and was surprised to see that I could add the same label twice. This seems like it could cause some potentially big problems...is it supposed to work that way?

[jclausius]

your data all seems to be just fine. there is something definitely wrong here, as your reports are not normal speeds for vault.

it could be various number of things:

1) sos collab story -

here's a story from about 2 years ago. during the development of sos collab, we started having SEVERE problems during the execution of simple, simple queries. the queries (for the message board within collab) were taking 3 minutes on something that should take 30 ms. the queries were triple checked they were optimized for index seeks. we opened up a support ticket with microsoft, and they were not able to help either.

here's where things got worse. we backed up/restored (not detached / attached) the database onto a different machine, and tried the same query... guess what 30ms query times.

so we went back to the original machine. removed sql server, deleted all temp data, sos collab database files, etc. then we looked at the machine's hard drive - it was badly fragmented.

we ran defrag enough times until the drive was < 1% fragmented, and re-installed sql server. additionally, we disabled all network protocols for sql server except for named pipes, and ran the sql server client utilities to make sure named pipes were the only network protocol, and restored the database. after all of this, the performance problems vanished.

now, this is a lot of work, and i'm not suggesting you go through the same steps. however, if you have a spare machine, perhaps you could temporarily install sql server and test a copy of the vault database on the other machine. if it behaves significantly better on the other machine, then you may want to look at the hardware.

2) other processes on the machine (active virus scanners, file server, mail, etc.) an active virus scanner might impact performance.

3) some sort of configuration issue b/w the sql client stored within vault and sql server itself -- see named pipes example from #1.

Also, I was recently adding labels into Vault and was surprised to see that I could add the same label twice. This seems like it could cause some potentially big problems...is it supposed to work that way?

You can apply the same label name to an object AS LONG AS the version for that object does not change. In other words, there is no harm in labeling version 25 of foo.asm to "My Label" 100 times, as each of those 100 unique labels will reference version 25 of the file.

[jclausius]

one other thing to check...

this might be a red-herring, but it won't hurt to ask. can you run / report the following query:

sp_configure N'priority boost'