Increasing global thread count limit

[Sheldon Hearn]

Hi folks,

I've been tasked with installing a heavy-weight J2EE
application on a Windows 2000 Advanced Server (SP3) box.

The system is a dual-Xeon with 4GB of RAM. The /3G switch
has been added to boot.ini.

The application can't create more than about 130 threads to
service HTTP requests.

Java reports that it was unable to create a new native
thread. On my FreeBSD 5.1-CURRENT workstation, I can
create about 8,000 threads before getting this error.

I've tested Apache2, which isn't Java-based but also uses
threads, just to rule Java out as the source of the
problem. Apache2 also bombs out at about the 130 thread mark.

In addition, if I get two different applications to start
75 threads each, they _both_ fail.

So it seems like there's a limit that the operating system
is imposing on the global number of threads.

A limit of 130 threads is quite simply ridiculous on this
hardware. How do I raise or remove this limit?

A friend of mine was kind enough to let me try this out on
his testbed box, with Windows 2000 Advanced Server (no SP),
single-PIII and 768MB of RAM. On his box, I can create
about 8,000 threads before I hit a problem.

So perhaps this limit is a nasty side-effect of using
dual-CPUs? Perhaps the customer has a single-CPU license
instead of a dual-CPU license?

I have no idea. This is my first exposure to Windows in 6
years.

Any ideas?

 

[Sheldon Hearn]

So it seems like there's a limit that the operating system
is imposing on the global number of threads.

A limit of 130 threads is quite simply ridiculous on this
hardware. How do I raise or remove this limit?

A friend of mine was kind enough to let me try this out on
his testbed box, with Windows 2000 Advanced Server (no SP),
single-PIII and 768MB of RAM. On his box, I can create
about 8,000 threads before I hit a problem.

So perhaps this limit is a nasty side-effect of using
dual-CPUs? Perhaps the customer has a single-CPU license
instead of a dual-CPU license?

In fact, it seems related to the use of 2 x 2.6GHz Xeons.
Even with Hyperthreading disabled in the BIOS, I still
can't create more than 200 threads.

I've spent more than two days on this and I've managed to
convince the customer that we just can't afford to waste
more time, so we're installing FreeBSD, which is a known
commodity for us, and which doesn't have this problem.

What a frustrating experience. Worst of all is Microsoft
Support's refusal to offer support without payment, on
something that's quite obviously a bug in an operating
system my customer's already invested a significant amount
of money in.

Seems the only thing you get for your license fee is a
commitment to replace the physical media if defective.

All the same, thanks to those who replied privately and
offered suggestions.

 

[Sheldon Hearn]

You do get a refund of the charges if it is indeed a bug
in the O/S. If you are so sure it's a Microsoft fault go
right ahead and log the call, you've got nothing to lose.

I wish the guy at MS Support had told me that. I asked
directly, and he said no. If I'd known, I would have
pressed on with the call.

Anyway, it's a moot point now. The box is running FreeBSD.

Thanks for the clarification, though. Good to know.

Ciao,
Sheldon.

 

[Sheldon Hearn]

So I've finally managed to get Apache2 and JBoss-Tomcat
working on a dual-Xeon 4GB Windows 2000 server.

The problems are:

1) Use of the /3GB boot.ini switch radically reduces the
number of PTEs available. This results in a very low limit
on concurrent threads. If you don't need >2GB virtual
address space per process, don't enable /3GB. If you can't
live without it, see
http://support.microsoft.com/default.aspx?scid=kb;en-us;313707
for information on tuning SystemPages to increase available
PTEs.

2) The default Windows 2000 TCP connection backlog is
ridiculously low (20). This is a problem for when the
server is configured to ramp the number of connection
handlers up as load increases. See
http://support.microsoft.com/default.aspx?scid=kb;en-us;142641
for information on enabling dynamic backlog handling.

3) The default Windows 2000 local user socket limit is
ridiculously low (5000). This is a problem when the server
accesses resources (such as databases and application
containers) over the network. See
http://support.microsoft.com/default.aspx?scid=kb;en-us;319502
for information on increasing this limit to the defaults
found on most sensible server platforms.

4) [SPECULATION] Windows 2000 imposes an immutable limit on
the number of open files / handles allowed for a process
started from a CMD.EXE prompt. See
http://wrapper.tanukisoftware.org/doc/english/ for
information on installing JBoss-Tomcat as an NT service
using the Java Service Wapper.

5) [SPECULATION] Windows 2000 imposes a 48MB heap limit for
processes started via the desktop (22MB for Terminal
Services desktops). The solution for (4) above applies.

I don't have KB articles to support (4) and (5), but
running Jboss-Tomcat as an NT service was necessary to
avoid undiagnosed resource starvation problems not covered
in (1) through (3).

With these changes made, a Windows 2000 server can be made
to service a serious JBoss-Tomcat deployment configured to
operate under the kind of load that Unix-like operating
systems tend to handle out of the box. I'm able to service
at least 2,000 concurrent connections without application
server failure.

Ciao,
Sheldon.

PS: I don't plan to track this newsgroup any more. If you
have feedback that you'd like me to see, please email me.