[THIN] Re: Memory Usage

  • From: "Rick Mack" <Rick.Mack@xxxxxxxxxxxxxx>
  • To: <thin@xxxxxxxxxxxxx>
  • Date: Fri, 28 Apr 2006 16:37:15 +1000

Hi Geoff,
 
Office XP will show some savings, office 2003 is generally fairly well 
optimised already.
 
There's really no magic about DLL remapping. A utility as simple as listdlls 
from www.sysinternals.com will show you what DLLs have been remapped 
(candidates for DLL remapping/rebasing/memory optimization). I have to stress 
that the DLL remapping is variable depending on what else is loaded into memory 
by you and other users but it'll give you a rough idea. Listdlls run as an 
admin will give a listing of all dlls used by an application and if you look 
for the "relocated" messages that'll give you an idea of how many DLLs "could" 
be remapped to save memory.
 
Have a look at the Appsense performance suite. One of the nice features is the 
ability to minimise an application's working set size when minimised or 
disconnected. This can really make a difference.
 
regards,
 
Rick
 
Ulrich Mack 
Volante Systems 


________________________________

From: thin-bounce@xxxxxxxxxxxxx on behalf of Geoff Cridland
Sent: Fri 28/04/2006 14:33
To: thin@xxxxxxxxxxxxx
Subject: [THIN] Re: Memory Usage


Rick,
 
Thanks for the feedback.  
 
We stuck with Office XP for the upgrade.  Do you happen to know if it has any 
memory savings with DLL remapping turned on?  I have turned on the memory 
optimization however the memory usage for each user seems to vary so much that 
it is hard to say what improvements I'm actually getting.  I've seen Office 
applications taking up to 50MB while they are open (without even having focus), 
but drop down to 1-2MB when minimised.  If there was some program that would 
run in the background and minimise all applications which weren't being used we 
could get heaps more users on each of our servers!!  However that problem is 
seen in the old farm as well as the new one.
 
Thanks,
 
Geoff.

        -----Original Message-----
        From: thin-bounce@xxxxxxxxxxxxx [mailto:thin -bounce@xxxxxxxxxxxxx] On 
Behalf Of Rick Mack
        Sent: Friday, 28 April 2006 14:09
        To: thin@xxxxxxxxxxxxx
        Subject: RE: [THIN] Memory Usage
        
        
        Hi Geoff,
         
        The scalability comments have to be put into perspective.
         
        On Microsoft's side, Windows Server 2003 upped many of the memory 
limitations that were inherent in Windows 2000 such as the maximum registry 
size. The base operating system image is also fairly lean and stuff like 
garbage collection has improved markedly compared to 2000. If your users 
numbers were limited on WIndows 2000 because of kernel memory constraints, 2003 
is going to be heaps more scalable.
         
        From a straight application platform viewpoint, Server 2003 is 
generally more scalable that 2000 server, things like a bloated exporer.exe 
aside. However what has to be added into the mix is that most people upgrade 
all their application versions when they upgrade the o.s. If for example you've 
upgraded to Office 2003 etc things are bigger and uglier, period.
         
        There's also the small matter that many of the scalability benchmarks 
are totally inappropriate or inapplicable to real life, but I guess that's all 
marketting :-(
         
        On the Citrix front, PS4 has a larger system footprint than Metaframe 
XP. However if you've got PS4 enterprise you've also got DLL remapping (memory 
optimization) which, depending on the application mix, can significantly reduce 
the total memory used by applications. However this is application dependent, 
some apps give you a huge saving, some none at all, and some will break with 
DLL remapping turned on.
         
        You mileage will vary and if you've upgraded your application software 
as well, it's likely that if your systems were memory limited you'll be 
supporting less users because of a larger total per-user memory footprint.
         
        It's a bit like the x64 story. If the only bottleneck you've got is 
kernel memory limitations with lots of everything else then x64 will scale much 
further than 32 bit Windows. But if physical memory as opposed to memory 
addressing capability is your problem, then the larger memory footprint of x64 
applications will ensure you get less rather than more users on a box.
         
        regards,
         
        Rick
         
        
        Ulrich Mack 
        Volante Systems 
        

________________________________

        From: thin-bounce@xxxxxxxxxxxxx on behalf of Geoff Cridland
        Sent: Fri 28/04/2006 13:22
        To: thin@xxxxxxxxxxxxx
        Subject: [THIN] Memory Usage
        
        

        Hi All, 

        Sorry about the last post, I must have hit the wrong button!! 

        We have been running a small Citrix farm with Windows 2000 SP3 and 
Metaframe XP FR3.  Finally we are making the conversion to Windows 2003 SP1 and 
Presentation Server 4.0.  After hearing all of the hype from both Microsoft and 
Citrix about their relevant upgrades being able to increase the number of users 
we should be able to now get on each server I was looking forward to the change.

        However, to say I am disappointed with the memory usage results of the 
upgrade is an understatement.  I now find that I am not even getting as many 
users on each server let alone an increase of 25% or more as stated by some 
sources.  We are running the same applications (including versions) on the new 
setup as we were previously.  I have turned on memory optimization which may 
have made a little improvement to the applications, but the problem seems to be 
related to the new operating system and the new version of Citrix themselves 
not the applications.

        On an old server I would get 40 users while consuming only 2.5 GB RAM, 
but on the new servers I get only 30 users and I'm already consuming more than 
3 GB RAM.  It appears that the main consumers of the extra RAM are operating 
system/Citrix processes rather than the applications.  For example, on the old 
server explorer.exe consumes around 5MB and on the new version around 15MB.  
crss.exe was 2MB and is now 5MB, winlogon.exe was 3MB and is now 6MB, wfshell 
was 3MB and is now 5.5MB.

        By the time you multiply the extra memory usage by the number of users 
it is easy to see why we don't get the same amount of users logging onto each 
server before running out of RAM.  We mostly publish a full desktop (hence the 
reason why explorer.exe is using the extra RAM) with only a few PC users using 
published applications.  

        Has anyone had similar experiences with this type of upgrade?  Is there 
some tuning options etc. I can look at or is there something really obvious 
which I've missed?

        Thanks in advance, 

        Geoff. 


        This e-mail and any file transmitted with it are confidential and 
intended solely for the use of the individual or entity to whom they are 
addressed. If you received this e-mail in error, please notify the Century 
Yuasa Service Desk, servicedesk@xxxxxxxxxxx
        
        This footnote also confirms that this message has been swept to the 
best of our current abilities for the presence of computer viruses. You should 
NOT take this as a guarantee or warrant that such material is Virus free. 
Therefore, BEFORE using any material attached to this message, you should apply 
Virus detection techniques appropriate to your security requirements.
        
        _____________________________________________________________________ 
        This e-mail has been scanned for viruses by MCI's Internet Managed 
        Scanning Services - powered by MessageLabs. For further information 
        visit http://www.mci.com
        

        
#####################################################################################

        This e-mail, including all attachments, may be confidential or 
privileged. Confidentiality or privilege is not waived or lost because this 
e-mail has been sent to you in error. If you are not the intended recipient any 
use, disclosure or copying of this e-mail is prohibited. If you have received 
it in error please notify the sender immediately by reply e-mail and destroy 
all copies of this e-mail and any attachments. All liability for direct and 
indirect loss arising from this e-mail and any attachments is hereby disclaimed 
to the extent permitted by law.

        
#####################################################################################


This e-mail and any file transmitted with it are confidential and intended 
solely for the use of the individual or entity to whom they are addressed. If 
you received this e-mail in error, please notify the Century Yuasa Service 
Desk, servicedesk@xxxxxxxxxxx

This footnote also confirms that this message has been swept to the best of our 
current abilities for the presence of computer viruses. You should NOT take 
this as a guarantee or warrant that such material is Virus free. Therefore, 
BEFORE using any material attached to this message, you should apply Virus 
detection techniques appropriate to your security requirements.

_____________________________________________________________________ 
This e-mail has been scanned for viruses by MCI's Internet Managed 
Scanning Services - powered by MessageLabs. For further information 
visit http://www.mci.com


#####################################################################################
This e-mail, including all attachments, may be confidential or privileged.  
Confidentiality or privilege is not waived or lost because this e-mail has been 
sent to you in error.  If you are not the intended recipient any use, 
disclosure or copying of this e-mail is prohibited.  If you have received it in 
error please notify the sender immediately by reply e-mail and destroy all 
copies of this e-mail and any attachments.  All liability for direct and 
indirect loss arising from this e-mail and any attachments is hereby disclaimed 
to the extent permitted by law.
#####################################################################################

Other related posts: