System resource usage

  • Thread starter Thread starter Niall
  • Start date Start date
N

Niall

I'm not quite sure which groups to post this to, so short of a massive
crosspost, I decided on these two.

I am running into troubles with resource usage of our app on Win2k and above
systems. In several places, I have seen it said that the WinNT model only
limits resources to available memory. However, I have seen errors caused by
running out of resources on a machine with over 1GB of free memory (running
Win2k server), as well as on my personal development machine (XP
professional).

On the terminal server machine, the crash appears to happen at exactly
10,000 user objects (as shown by task manager). On my system, it happens at
around 7,000 user objects. In this state, all of windows becomes unstable.
Some windows will not show up, others will disappear. It seems like after
some time, windows will decide to shut down the app hogging all the
resources. This took a very long time on the terminal server machine.

I have written a small test project, all it does is pop up a form with about
a hundred controls on it. Once you pop up about 30 of these forms, you can
see the problem. I can post the code here, if anyone wants it.

So what is the limit with resources? How are we supposed to handle this? At
a client site, when the error comes up, they see the JIT debugger error box.
Any help or references would be greatly appreciated.

Niall
 
Niall,

When you say 10000 user objects, do you mean 10000 simultaneous terminal
server sessions? If you have 10000 simultaneous windows sessions, even with
a few GB of memory, I can see why the machine would become extremely
unstable.

If you are speaking about just 10000 objects (as in a custom object you
wrote in .NET), then I don't see why you would have this problem, and
posting the code would be helpful in determining the cause.

Also, can you be more descriptive about the error that is popping up
when this situation occurs?
 
User objects are allocated from the desktop heap which has a system wide
size of 48MB on W2K, this heap consists of three sharedsections, the first
is common to all desktops, the second is per interactive deskto, and the
third is reserved for non interactive desktops.

The values for the three distinct heaps is taken from the registry when the
CSRSS process starts
(see:HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session
Manager\SubSystems\Windows), what you could do is paly a little bit with the
values found in there taking care that the sum of all heaps must fit into 48
MB!!!

Willy.
 
Nicholas,

Sorry, it appears my post was confusing. I was referring to Windows Resource
User Objects (which you can see in the task manager for a given process),
not objects on the managed heap or terminal server sessions. See Willy's
post for what I mean. This is a similar problem to the old Windows 95 stuff
where the computer became terribly unstable after you ran out of GDI or User
resources. I had read that these resources are "unlimited" in the NT model,
but Willy seems to be more in the know than the places I've been reading.

The test code I have just has a plain form which I just chucked a bunch of
controls onto with the designer. Opening up about 30 instances of that form
on my machine will cause resource problems, new windows won't be able to
show, etc, until I close the app and XP can reclaim all the resources.

Niall

Nicholas Paldino said:
Niall,

When you say 10000 user objects, do you mean 10000 simultaneous terminal
server sessions? If you have 10000 simultaneous windows sessions, even with
a few GB of memory, I can see why the machine would become extremely
unstable.

If you are speaking about just 10000 objects (as in a custom object you
wrote in .NET), then I don't see why you would have this problem, and
posting the code would be helpful in determining the cause.

Also, can you be more descriptive about the error that is popping up
when this situation occurs?


--
- Nicholas Paldino [.NET/C# MVP]
- (e-mail address removed)

Niall said:
I'm not quite sure which groups to post this to, so short of a massive
crosspost, I decided on these two.

I am running into troubles with resource usage of our app on Win2k and above
systems. In several places, I have seen it said that the WinNT model only
limits resources to available memory. However, I have seen errors caused by
running out of resources on a machine with over 1GB of free memory (running
Win2k server), as well as on my personal development machine (XP
professional).

On the terminal server machine, the crash appears to happen at exactly
10,000 user objects (as shown by task manager). On my system, it happens at
around 7,000 user objects. In this state, all of windows becomes unstable.
Some windows will not show up, others will disappear. It seems like after
some time, windows will decide to shut down the app hogging all the
resources. This took a very long time on the terminal server machine.

I have written a small test project, all it does is pop up a form with about
a hundred controls on it. Once you pop up about 30 of these forms, you can
see the problem. I can post the code here, if anyone wants it.

So what is the limit with resources? How are we supposed to handle this? At
a client site, when the error comes up, they see the JIT debugger error box.
Any help or references would be greatly appreciated.

Niall
 
Willy, thanks very much for your answer. Can I just clarify a couple of
things.

By "system wide", you mean 48MB shared by all users logged in on the
machine?

Is a "desktop" one user session?

Is this 48MB heap the same size on all NT based OS's (NT, XP, 2003, etc), or
do some have different sizes?

The reason why I'm asking is that our client is using Citrix on a Windows
2003 Server machine, with quite a large number of users logged in. I am
wondering whether the more users they have logged in, the less resources
(and hence the less of our app that can be run concurrently) will be
available for any one user. Thanks again,

Niall
 
See inline ***


Is a "desktop" one user session?
**** No, each user session is presented a virtual Winstation/desktop secured
environment (kind of a sandbox), from which WinSta0/default is the default
interactive pair.
Is this 48MB heap the same size on all NT based OS's (NT, XP, 2003, etc), or
do some have different sizes?
**** No, the same size except for TS where this is reduced to 36MB.

However, I've done some further research on the number of USER objects, and
unfortunately here you hit the ceiling.
The number of USER handles per process is max., you guessed 10.000 (W2K and
W2K3).
The value as found at :
HKLM/Software/Microsoft/Windows
NT/CurrentVersion/Windows/USERProcessHandleQuota



Is unfortunately also the maximum value.

So I.M.O it's time to inspect your application as it looks like you are
leaking USER object handles (objects to watch are menu's, Icons, Windows and
cursors).



Willy.
 
Willy, thanks very much for your posts, I've learned a lot from them. That
10,000 flat user object count seemed to be a bit too round a number to have
been chance.

In regards to user object leaks, I've inspected the behaviour and there
don't seem to be any leaks. The situation in which I was seeing this
behaviour was when I simultaneously opened a large number of one of the most
complex forms in the app. I wasn't aware that this kind of situation could
still be a problem in NT based OSs. So at the moment, I am wondering if we
should put in some way of managing the maximum number of windows that can be
opened at one time.

Trouble is that I don't know how to tell how much of the system resources
are still available. Ie: we can limit the app to a reasonable number of
forms, but if the user has a lot of other apps open, they still may be able
to get into trouble. Perhaps it's not a situation we should worry about too
much. My testing was a deliberate attempt to induce bad behaviour in the
app, and it took a fair bit of effort :P

Thanks again,

Niall
 
Niall,

Note that the number of User objects (10000 max.) is a per process limit,
this is a whole lot to consume and should never be reached, unless you're
leaking handles.
That means you can have a number of applications running, each consuming
several thousand UO's, in parallel. But on TS you will probably run into a
lack of GDI resource space (the famous 36MB vs. 48MB desktop heap).

I would suggest you read the guidelines for application development for
Terminal server environments, this can be found in the platform SDK docs .

Willy.
 
Willy Denoyette said:
Niall,

Note that the number of User objects (10000 max.) is a per process limit,
this is a whole lot to consume and should never be reached, unless you're
leaking handles.

We don't have a handle leak problem, as far as I'm aware. I was able to
create this behaviour by opening a lot of copies of a very large form (it
has a lot of tabs with subsections on them). I was a bit surprised at how
many objects were used by this form, even though it is very large. Each
instance uses around 800 user objects and around 300 GDI objects. There's
nothing amazing on the form, it's all just managed controls, so we're not
doing anything out of the ordinary. Small forms in our system are taking
around 20-30 user objects and around 5-10 GDI objects.

One thing I'm confused about is this: I thought window handles, brushes, etc
were all GDI objects. So how come our forms use more user objects than GDI
objects?

That means you can have a number of applications running, each consuming
several thousand UO's, in parallel. But on TS you will probably run into a
lack of GDI resource space (the famous 36MB vs. 48MB desktop heap).

I would suggest you read the guidelines for application development for
Terminal server environments, this can be found in the platform SDK docs .

Sounds like a good idea. Thanks again for your insight.

Niall
 
Hello,

I was wondering if 48mb is the heap sum limit in Windows 2003 Server
(Enterprise/Datacenter) as well.

If so is it changable?

In spite of the fact that this is a very old conversation, i'm hoping
for your asistance.

Thanks!

Eyal Weinreb
Israel
(e-mail address removed)
 
Back
Top