Mark,
Since I don't understand what is causing the problem, all information is
helpful and I appreciate you taking time to think about what could be wrong.
1. The application runs fine on an older system. Do we have the glibc and
kernel versions for all systems?
The old system: P4. 1GB memory, 1.3GB swap. Uses swap on a regular basis.
kernel is 2.4.25. Java is 1.5.0_01-b08. Tomcat is 5.5.23. Glibc is version
2.3.1.
New systems: Server A (Dell T110) is a Xeon 3440, sever B (Dell T105) is an
AMD. A has 4GB memory and 19GB swap which is never used. B has 6GB memory and
10GB swap which is never used. A and B both use kernel version 2.6.29.6, Java
1.6.0_18-b07 and Tomcat 6.0.24. Glibc version is 4.3.3 for both A and B.
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?
The outages appear to be most frequent in times of heavy transaction
processing. This part of the application is basically a shopping cart although
the path from start to 'in the cart' has many variations depending on the type
of item being registered for, i.e., the registration process steps through 20+
classes each of which could request additional processing, display a screen for
user input, etc. It seems during periods of heavy transactions, the system
fails more frequently but it may be that the application requires a certain
cumulative amount of activity before it fails and that activity can be spread
over several hours or several days. However, since Tomcat is restarted once a
day (around 1:00AM after rolling out changes), it would seem that the
application would not be able to carry activity from one day into the next.
Therefore, it would seem that the failure is triggered by something on the day
it occurs.
Thanks for your help.
Carl
----- Original Message -----
From: "Mark Eggers" <its_toas...@yahoo.com>
To: "Tomcat Users List" <users@tomcat.apache.org>
Sent: Thursday, February 04, 2010 7:10 PM
Subject: RE: Tomcat dies suddenly
--- On Thu, 2/4/10, Caldarale, Charles R <chuck.caldar...@unisys.com> 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 . . .
/mde/
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
