[THIN] Re: redirecting appdata

  • From: Michael Pardee <pardeemp.list@xxxxxxxxx>
  • To: Michael Pardee <pardeemp.list@xxxxxxxxx>, <thin@xxxxxxxxxxxxx>
  • Date: Mon, 21 Aug 2006 15:14:29 -0400

I had mentioned there were some others that we were still rounding up.  I
sent an email earlier about the possibility of the ms06-040 patch biting us
with large file once the file clusters were in production for 1.5 hours.  We
are still working with Microsoft on determining if that is the root cause or
not, but we definitely missed some important changes that may be the root of
our issue instead.

"HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\Session Manager\Memory
Management"

PagedPoolSize       REG_DWORD    0xffffffff
PoolUsageMaximum    REG_DWORD    0x28



From: Michael Pardee <pardeemp.list@xxxxxxxxx>
Date: Thu, 17 Aug 2006 10:22:31 -0400
To: <thin@xxxxxxxxxxxxx>
Subject: Re: [THIN] Re: redirecting appdata

There were some others that I am still rounding up, but I'm told these were
the ones that made the biggest difference in our environment.  I would
recommend that people know what each of these settings does before they do
anything with them, and as always, test first!

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\lanmanserver\parameter
s]
"MaxWorkItems"=dword:0000ffff
"MaxRawWorkItems"=dword:00000200
"MaxFreeConnections"=dword:00000064
"MinFreeConnections"=dword:00000064
"MaxMpxCt"=dword:0000000a
"SizReqBuf"=dword:00001104

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\lanmanworkstation\para
meters]
"MaxCmds"=dword:00000400

We use McAfee for AV.  We discovered a huge performance issue with their TDI
drive; it was basically sitting on each processor and causing huge (5
second) wait states for everything.  Once we eliminated this driver via a
registry change (I can find that as well if anyone needs it) our performance
skyrocketed.  I do not know if this is resolved in Patch 13 or not.  But,
Patch 13 has not hurt us and our PagePool memory issues are now gone as
well.  We also only do scanning on write to disk I beleive, something I
think we picked up from Mr. Kenzig a long time ago.

On 8/17/06, Michael Pardee <pardeemp.list@xxxxxxxxx> wrote:
> Let me talk with my team as we are just about to introduce 2 new cluster
> servers and are going through the tuning right now.  The timing is good.  It
> is much less with Windows2003 than it used to be.  I will find what I can and
> report back.
> 
> On 8/17/06, Jeff Pitsch < jepitsch@xxxxxxxxx <mailto:jepitsch@xxxxxxxxx> >
> wrote:
>> Mike,
>>  
>> Do you have any doco as to what you tuned?  That would be great information
>> for people to have.
>>  
>> 
>> 
>> Jeff Pitsch
>> Microsoft MVP - Terminal Server
>> 
>> Forums not enough?
>> Get support from the experts at your business
>> http://jeffpitschconsulting.com <http://jeffpitschconsulting.com/>
>> 
>>  
>> On 8/17/06, Michael Pardee <pardeemp.list@xxxxxxxxx
>> <mailto:pardeemp.list@xxxxxxxxx> > wrote:
>>> We redirect it for over 4000 people.  Doesn't make it right, but it does
>>> work.  If you do this you will learn more about tuning the backend servers
>>> that you redirect to than you you ever cared to.
>>> 
>>> It was a nightmare originally as our backend servers are Windows clusters.
>>> Started with NT4, then 2000 (just a little better), then Windows2003 (much
>>> better but still not perfect).  As long as that backend is running well and
>>> has fast connectivity to it this will work.  I would doubt it could ever be
>>> as fast as having AppData local to the Citrix server, but it does work under
>>> the right conditions.
>>> 
>>> Having said that, when we were having backend cluster performance issues we
>>> were considering bringing the AppData back down inside the profile so it
>>> would be local to get the speed/reliability back up but we ended up tuning
>>> the performance issue away with Microsoft.
>>> 
>>> We are doing some testing with Flex Profiles and the Tricerat poducts and
>>> they are opening our eyes to much better ways of dealing with profiles and
>>> folder redirection.  Not sure where we'll end up yet.
>>> 
>>> 
>>> On 8/17/06, Michel Roth <mrdizzz@xxxxxxxxx> wrote:
>>>> Hi Jon,
>>>> 
>>>> If you do not want to take any chances in regards to performance, the
>>>> answer is simple: don't.
>>>> However it has some benefits in terms of administration. If you need to
>>>> look out for performance then be afraid, be very afraid.
>>>> 
>>>> Regards,
>>>>  
>>>> Michel Roth.
>>>> 
>>>> 
>>>> On 8/17/06, Jeff Pitsch < jepitsch@xxxxxxxxx <mailto:jepitsch@xxxxxxxxx> >
>>>> wrote: 
>>>>> It all dependson your applications.  As with anything else, you must know
>>>>> your applications.  I always tell my customers to test it first, see what
>>>>> happens, then implement or not based on the test results.  In a few
>>>>> places, it works find redirected.  In most others, not a chance.
>>>>>  
>>>>> Jeff Pitsch
>>>>> Microsoft MVP - Terminal Server
>>>>> 
>>>>> Forums not enough?
>>>>> Get support from the experts at your business
>>>>> http://jeffpitschconsulting.com <http://jeffpitschconsulting.com/>
>>>>> 
>>>>> 
>>>>>  
>>>>> On 8/17/06, Luchette, Jon <JLuchette@xxxxxxxxxxxxxxx
>>>>> <mailto:JLuchette@xxxxxxxxxxxxxxx> > wrote:
>>>>>> Hello,
>>>>>>  
>>>>>> What is the consensus out there on redirecting the appdata folder?  I
>>>>>> know in the past there have been discussions on this list and people have
>>>>>> said generally that "it will decrease performance."  Is this a 100%
>>>>>> definite No-No for performance reasons, or is anyone out there doing it
>>>>>> and having good results?  I just want to find out more about why or why
>>>>>> not... 
>>>>>>  
>>>>>> Thanks.
>>>>>>  
>>>>>>  
>>>>>> _______________________________________________
>>>>>> Jon Luchette
>>>>>> Emerson Hospital
>>>>>> Technology Specialist III
>>>>>> Work: 978-287-3369
>>>>>> Cell:  978-360-1379
>>>>>> jluchette@xxxxxxxxxxxxxxx  <mailto:jluchette@xxxxxxxxxxxxxxx>
>>>>>> _______________________________________________
>>>>>> 
>>>>>>  
>>>>>>  
>>>>> 
>>>> 
>>> 
>>> 
>>> 
>>> -- 
>>> 
>>> Michael Pardee
>>> www.blindsquirrel.org <http://www.blindsquirrel.org/>
>> 
> 
> 
> 
> -- 
> 
> Michael Pardee
> www.blindsquirrel.org <http://www.blindsquirrel.org>



-- 

Michael Pardee
www.blindsquirrel.org <http://www.blindsquirrel.org> 


************************************************
For Archives, RSS, to Unsubscribe, Subscribe or 
set Digest or Vacation mode use the below link:
//www.freelists.org/list/thin
************************************************

Other related posts: