RE: Performance questions

Jeff:

Thanks for the response again.  One more point of clarification if you
could. I already have the vault mdf and ldf as you said, mdf on raid 5, ldf
on raid 10.  When you say place tempdb on raid 10, do you mean move both
tempdb's mdf and ldf files, or just move tempdb's ldf to raid 10?

Scott

-----Original Message-----
From: jeff clausius [mailto:[email protected]] 
Sent: Tuesday, March 16, 2004 12:07 PM
To: Scott LaFave
Cc: [email protected]
Subject: RE: [vault-list] Performance questions

scott:

assumption - when you say "raid" drives, the machine has two hardware raid
controllers.  with that said, let's start with the characteristics from the
raid drives:

raid 5 - very, very good read speeds, but medium write speeds
raid 10 - high read/write speeds


based on how vault's dependency on baselines, i would guess the server
probably reads something like 60-70% of the time.  so a good read speed is
required for the .mdf file.  either controller would meet this requirement.

now, table writes ( updates / deletes ) will take place quite a bit in the
.ldf file, and then eventually to the .mdf (on checkpoint).  so having
extremely good performance on the .ldf will help.  however, writes on the
.mdf, while important, are not as important as the .ldf.  based on this,
.ldf would best be served on the raid 10 controller and .mdf on either, but
raid 5 would suffice.

as for tempdb - performance for reads and writes is important.  raid 10 it
is.

so i guess i would recommend: 
1)  .mdf on the raid 5 controller
2)  .ldf on the raid 10 controller
3)  tempdb on the raid 10 controller

anyone else care to chime in?

jeff
sourcegear

*********** REPLY SEPARATOR  ***********

On 3/16/2004 at 11:36 AM Scott LaFave wrote:

>Jeff:
>
>Thx for the info. Extending my tempdb question:
>
>The server has already been built, so I don't actually have a dedicated
>place to put tempdb.  I have a few choices as I see it.  I wonder if you
>have an opinion about the choices.  I realize actual testing would give the
>proper answer, but I hope you can give me an "educated" gut feeling about
>which choice might be the best.
>
>I have 2 physical raid dirves for the SQL files (windows and sql program
>files are on a 3rd mirrored drive). One drive is RAID 10, the other RAID 5.
>All data files and logs reside on the RAID 5 drive except I plan to place
>the Vault transaction log on the RAID 10 drive.  For tempdb I could:
>
>- Leave both the mdf and ldf on the RAID 5 drive with everything else
>- Move just the ldf log file to the RAID 10 drive
>- Move both the ldf and mdf to the RAID 10 drive
>
>I guess it comes down to which seems like it would be worse - tempdb
>competing for disk i/o with the vault transaction log or the vault data
>file?
>
>Thx again
>
>Scott
>
>-----Original Message-----
>From: jeff clausius [mailto:[email protected]] 
>Sent: Tuesday, March 16, 2004 11:00 AM
>To: Scott LaFave
>Cc: [email protected]
>Subject: Re: [vault-list] Performance questions
>
>scott:
>
>restricting sql server might help some, but the answer really relies on how
>*your* vault database is structured.  i would recommend starting with no
>limit.  if you see sql server take more than 1GB, then put the clamps down
>to 512 to 768 MB.
>
>in regards to vault settings, the caching of trees used to keep people in
>synch is an important element in the vault 2.0.x server code.  as long as
>you keep your memory <= 2GB, you shouldn't have to do too much performance
>tuning in terms of vault.config.  however, you can tweak vault's memory
>usage, by changing the value for treemanagersize in vault.config to
>something along the lines of 100 to 150 - please remember to restart iis on
>such a change.  also note changing this value may affect overall vault
>performance on a client startup.  basically if a tree is not stored in
>vault's cache, the info must be calculated within the database.
>
>as for iis 6's application pool settings - we've done extensive testing,
>and
>have seen no memory leaks in relation to the usage of vault.  however,
>microsoft has set the defaults in iis 6 to recycle the asp.net process
>(w3pwp.exe in iis6) in a couple of different situations.  your best bet
>would be to disable these recycling options - based on time and/or memory
>usage.
>
>finally tempdb.  yes vault uses tempdb when building temporary trees,
>getting history, parsing xml based arrays, etc.  placing the tempdb on a
>different physical drive would improve performance a little.  on a side
>note
>- as a personal project, i've been trying to experiment by moving all
>vault's indices and unique constraints to a *third physical drive* to see
>what kind of impact that would have on performance.  however, i haven't had
>enough time to do any actual performance testing.
>
>hth
>jeff clausius
>sourcegear
>
>
>*********** REPLY SEPARATOR  ***********
>
>On 3/16/2004 at 10:36 AM Scott LaFave wrote:
>
>>Hi all-
>>
>> 
>>
>>We are setting up a new dedicated Vault server to run version 2.  It's
>>running Win 2003 and Sql 2000 SP3a.  I have 2 questions on performance
>>settings.
>> 
>>
>>1st, the box will be running both the Vault service and the Vault
>database.
>>The box has 2 gb of ram.  Does anyone recommend restricting the max memory
>>available to Sql Server so that the system and the Vault web site have
>>memory reserved for them?  If so, restricting sql max mem to what?
>>
>> 
>>
>>2nd, how much use does Vault make of tempdb?  Is there any benefit to
>>trying
>>to isolate tempdb on its own drive?  The Vault db itself already will have
>>its own dedicated transaction log drive.  If I do not isolate tempdb, it
>>will live on the same drive as the Vault mdf data file.  The transaction
>>log
>>drive is RAID 10, the data drive is RAID 5.
>>
>> 
>>
>>Thanks ahead of time for any suggestions!
>>
>> 
>>
>>Scott LaFave, MCSD
>>
>>Software Development Manager
>>
>>TReND
>>
>>660 American Avenue, Suite 203
>>
>>King of Prussia, PA 19406
>>
>>E-mail: [email protected] <mailto:[email protected]> 
>>
>>Phone: 610.783.4650 x3377
>>
>>Fax: 610.783.4695
>>
>>Web: www.trendmls.com <http://www.trendmls.com> 
>>
>> 
>>
>>
>>_______________________________________________
>>vault-list mailing list
>>[email protected]
>>http://lists.sourcegear.com/cgi-bin/mailman/listinfo/vault-list
>
>
>
>_______________________________________________
>vault-list mailing list
>[email protected]
>http://lists.sourcegear.com/cgi-bin/mailman/listinfo/vault-list
>_______________________________________________
>vault-list mailing list
>[email protected]
>http://lists.sourcegear.com/cgi-bin/mailman/listinfo/vault-list