Hi,
We are currently using Vault 3.0.7. We have several large repositories that have tapped out the available memory for the vault service causing it to hang. I have followed all of the suggested tips and we have been able to keep vault from hanging but at the expence of performance. We have over 30 developers and as you can imagine this is becomming very costly to us.
We are considering having multiple services that hit different repositories in the database. However, I can't find any information on this or even if the licensing model would allow it. Ideally we want to be able to have one service per repository. We believe this would help us over the performance and stability issues we are dealing with. Is this possible?
thanks,
Earl
Multiple Services
Moderator: SourceGear
When you say tapped all the available memory, do you mean RAM or hard disk space?
You won't be able to make what you described work with multiple services and hitting different repositories.
How many developers are accessing your database?
What is the size of the sgvault.mdf and sgvault_log.ldf files?
What is your RAM on the server and the available disk space?
You won't be able to make what you described work with multiple services and hitting different repositories.
How many developers are accessing your database?
What is the size of the sgvault.mdf and sgvault_log.ldf files?
What is your RAM on the server and the available disk space?
Hi Beth,
Thanks for the quick response.
The service runs on its own server:
2 Gigs RAM
74 Gig HD 57 Gigs free.
Pentium 4 2.8 ghz
We have 30 developers hitting the service, along with at least 8 continuous build processes running in CCNET.
In one repository we have over 17,000 folders. And in another we have over 15,000 folders. We have several other repositories as well that are not close to this size.
The worker thread for the service hits around 1.2 - 1.4 gigs and freezes when retrieving the repository structure. The database seems to be fine. Its the service that appears to have difficulties handling the load. I have adjusted the various settings such as setting the tree cache, etc. and it no longer crashes but it is painfully slow. I've had reports of it taking 20 minutes to do a simple file check in. When I look at the worker threads on the server the memory is no longer peaking but the service seems to be locked, possibly overloaded.
thanks,
Earl
Thanks for the quick response.
The service runs on its own server:
2 Gigs RAM
74 Gig HD 57 Gigs free.
Pentium 4 2.8 ghz
We have 30 developers hitting the service, along with at least 8 continuous build processes running in CCNET.
In one repository we have over 17,000 folders. And in another we have over 15,000 folders. We have several other repositories as well that are not close to this size.
The worker thread for the service hits around 1.2 - 1.4 gigs and freezes when retrieving the repository structure. The database seems to be fine. Its the service that appears to have difficulties handling the load. I have adjusted the various settings such as setting the tree cache, etc. and it no longer crashes but it is painfully slow. I've had reports of it taking 20 minutes to do a simple file check in. When I look at the worker threads on the server the memory is no longer peaking but the service seems to be locked, possibly overloaded.
thanks,
Earl
Some things you can do here...
1) Upgrade to Vault 3.5.2. It's a major upgrade, free to those with Gold Support. Make sure you create a backup first. There were some performance improvements in Vault 3.5.2 that
will allow you to *lower* TreeManagerSize to save memory.
2) Also, look at .NET Framework's machine.config (if using IIS 5.0). You can find the <processModel ... /> XML element in the
%windir%\Microsoft.NET\Framework\vX.X.XXX\config\machine.config).
In there, you will find a memoryLimit attribute. By default, it is configured to shut down when IIS hits 60% of 2 GB memory. If you change that number to 80% or 90%, then that should give some more headroom when dealing with memory.
1) Upgrade to Vault 3.5.2. It's a major upgrade, free to those with Gold Support. Make sure you create a backup first. There were some performance improvements in Vault 3.5.2 that
will allow you to *lower* TreeManagerSize to save memory.
2) Also, look at .NET Framework's machine.config (if using IIS 5.0). You can find the <processModel ... /> XML element in the
%windir%\Microsoft.NET\Framework\vX.X.XXX\config\machine.config).
In there, you will find a memoryLimit attribute. By default, it is configured to shut down when IIS hits 60% of 2 GB memory. If you change that number to 80% or 90%, then that should give some more headroom when dealing with memory.