[THIN] Re: Memory optimisation conflicting with Resource Manager

  • From: "Andrew Wood" <andrew.wood@xxxxxxxxxxxxxxxx>
  • To: <thin@xxxxxxxxxxxxx>
  • Date: Fri, 9 May 2008 10:20:34 +0100

Ah, but  I *am* paranoid -  I don't trust computers at all, they're rubbish.

 

Its actually got stranger. While that appeared to fix the problem  - the RM
current information often goes AWOL - unless you stop and start the IMA
Service (or reboot the server ;) ) - then it (RM current information) comes
back but doesn't update.

 

Looks as if each IMA Service is not correctly getting its own RM information
- so the summary server doesn't stand a chance as the summary info is
goosed.

 

Still - I've discounted *another* thing it could have been - there can't be
that many more right  :p

 

From: thin-bounce@xxxxxxxxxxxxx [mailto:thin-bounce@xxxxxxxxxxxxx] On Behalf
Of Rick Mack
Sent: 09 May 2008 05:12
To: thin@xxxxxxxxxxxxx
Subject: [THIN] Re: Memory optimisation conflicting with Resource Manager

 

Hi Andrew,

 

ADSclean is unnecessary, as is a reboot.

 

The memory optimization works in 3 phases:

 

1. monitor operating system rebasing of DLLs to discover an optimized memory
address for a DLL. This can take a while depending on the frequency of use
of the DLL.

2. permanently rebase a copy of the DLL by a binary moficiation of the jump
tables and link the modified DLL to the original copy as an alternate data
stream (ADS).

3. hook the load library routine so that when a DLL has an ADS copy, load
the rebased ADS copy instead.

 

step 3 is carried out by the memory optimization service which uses an
registry based exclusion list of executables and DLLs that determine whether
an ADS copy of the DLL will be loaded or not.

 

ADS DLL loads are stopped immediately when you stop memeory optimization on
a per-server or per-farm basis. Executable exclusion lists are handled via
the management console and distributed to all farm servers. DLL exclusion
lists require a server-based registry hack and a modified reg file or
scripted registry update has to be distributed on a per-server basis. Citrix
donot propagate DLL exclusions, you do.

 

That's a really long roundabout way of telling you that you don't have to
run ADSclean unless you're paranoid or short on disk space, and a server
reboot is totally unnecessary :-)

 

But ADSclean is useful for finding out what has been rebased. 

 

RM performance data collection is one of the things done by the IMA service
via the RM*.dll modules but since IMASRV.EXE is one of the default excluded
executables, any DLL component of imasrv.exe would also be excluded.

 

IN any event if all the servers did stop recording RM information at around
the same I'd be tempted to suggest that the problem might be on the RM
summary server.

 

regards,

 

Rick

 

-- 
Ulrich Mack
Quest Software
Provision Networks Division 

 

On 5/7/08, Andrew Wood <andrew.wood@xxxxxxxxxxxxxxxx> wrote: 

Hi, 

 

I've had a customer come with an odd problem - they use RM for billing; but
April's report appeared broken - only some information was available.

 

Investigating the issue showed that the summary information wasn't being
recorded correctly in the databases - despite the server RM logs saying
everything was working fine. All the servers stopped recording information
about the same time.

 

What was very strange is that looking at the presentation server console
showed that local database and summary database information wasn't available
- just blank information - no users, no processes - only the server names.

 

Everything appeared in order, but no data was accessible.

 

I saw that Memory Optimisation was enabled - so I took one of their servers,
excluded it from memory optimisation and ran adsclean 2. Then I rebooted it.

 

When the server came back - I could look at user information, and a after
running a summary update - I could  see billing information again.

 

No one knows, by any chance, what processes run to gather/display the RM
information so I can test excluding it - at the moment I'm working on all
.dll files beginning with RM 

 

Tia.

 

a.

 

 

 

Andrew

 

 

Gilwood CS Ltd

Registered Office :  Mount Ashbrooke, Holmland Buildings, Tunstall Road,
Sunderland, UK, SR2 7RR. No. 6099397 England

 





Other related posts: