Re: Fwd: Re: session lock table growth out of control

josh sent me his log file from the server, and added some more info 
about his particular setup.


from the looks of the sgvault.log file, there might be a problem with 
the continuous integration component for draco.net.

as i mentioned in my first reply, as a file lock is released, a row is 
added in the tblsessionrellocks for every logged on user (found in 
tblsessions).  so if 20 people are logged in, and 50 files are checked 
in, then 1000 rows are made in the released locks table.  when each of 
those user refreshes their client the rows for that given session are 
removed from the table.  additionally, if a user logs out or their 
session expires within iis, the rows for that given session are removed 
as well.

in josh's case, the draco.net user was logging in about every 20 seconds 
to do its work.  however, the server's log file did not contain any 
logout messages for those particular logins.  after about an hour, there 
were 180+ active sessions.  in the course of a day, there were 4320+ 
active sessions.  when you multiply the active sessions by a number of 
released locks, you can see how the table can grow rapidly.

as a short term fix, josh set his iis timeout to be about 15 - 20 
minutes, so the draco.net logins timeout in a more frequent manner.


- does anyone know if brian or ryan are still working on the draco.net / 
vault integration?  i don't have the code for this, so i'm hoping my 
analysis is correct (or someone can tell me i'm all wet)?

- perhaps there is something in draco.net that needs to be configured 
for logout?


jeff
sourcegear

*********** REPLY SEPARATOR  ***********
>>
>>On 4/20/2004 at 9:30 PM Josh Kewley wrote:
>>
>>
>>>Hello,
>>>
>>>With only a handful of developers working on our Vault server, we are
>>>running into a problem where hundreds of thousands of rows in the session
>>>lock table (tblsessionrellocks) are being created upon check-in that are
>>>not being deleted. This causes the size of our database to grow by
>>>gigabytes each week, and causes Vault to operate very, very slowly. I have
>>>seen mention of this problem with past versions of Vault, but apparently
>>>it was something that was fixed in recent versions.
>>>(http://support.sourcegear.com/viewtopic.php?t=285). Our hack to keep
>>>productive in the meantime has been to delete all records from this table
>>>when vault is not being used.
>>>
>>>We started with the 1.x version, and have been following the upgrade paths
>>>(without incident) to the current version that we run (2.0.2). We are
>>>running both our SQL server and web server on Windows Server 2003. We
>>>notice the same problem with the vault client, as well as with the VS.Net
>>>IDE. We do a lot of massive check-ins after generating base libraries,
>>>which is when the server really gets beat up.
>>>
>>>Assistance is appreciated.
>>>-Josh
>>>
>>>_______________________________________________
>>>vault-list mailing list
>>>[email protected]
>>>http://lists.sourcegear.com/cgi-bin/mailman/listinfo/vault-list
>>
>>
> 
> *********** END FORWARDED MESSAGE  ***********
>