tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mark Eggers <>
Subject RE: Tomcat dies suddenly
Date Fri, 05 Feb 2010 00:10:48 GMT
--- On Thu, 2/4/10, Caldarale, Charles R <> wrote:

> > 6. Carl was using 32-bit Linux, which he isn't :(
> Correct, which made the whole point moot, so I'm not sure
> why Dan even brought it up.

I just mentioned the 32-bit Linux behavior for completeness. I did state that I realized 32-bit
Linux is not in play.

> > AFAIK, 64-bit Linux has a wide-open memory addressing
> scheme. Maybe it
> > considers everything under 17 billion GiB to be "low
> memory", now :)
> No, the hardware restrictions don't exist in 64-bit mode.

This is what I've read as well. If you use 64-bit Linux, this problem goes away. There are
also some ways to build the 32-bit kernel in order to reduce this problem.

All this is moot since a 64-bit Linux kernel is being used.

As to the copy-on-write behavior for fork()d processes, it would help if I read the man pages:

Under Linux, fork() is implemented using copy-on-write pages, so the only  penalty that it
incurs is the time and memory required to duplicate the parent’s page tables, and to create
a unique task structure for the child.

It turns out that things are a little bit more complicated than that, in that since version
2.3.3 fork is actually a wrapper to clone(2) with the appropriate flags to give the same result
as a traditional fork(2) call.

All of this is moot however if there is no Runtime.exec() call in the application.

I'm a bit curious though about several points:

1. The application runs fine on an older system. Do we have the glibc and kernel versions
for all systems?

2. Different usage patterns (?) seem to cause the outages at different rates (if I remember
an account of one Friday). What paths in the application were being exercised most heavily
during that time?

As for cache / buffer / free - I've seen cases where the cache did not go to 0, but swap was
in play (slow disk, small amount of memory).

Sorry for chasing down the rabbit hole . . .



To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message