Mailing-List: contact users-help@tomcat.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Tomcat Users List" <users@tomcat.apache.org>
Received-SPF: pass (nike.apache.org: local policy)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws;
  s=s1024; d=yahoo.com;
  h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:MIME-Version:Content-Type:Content-Transfer-Encoding;
  b=zZCpbliGOr0Rh/+ujZy8BIqc72KlYwK/9vDz5RFRWs0g8YsHVeOpdk5bFub/stPfH9KMwqEPqOtuVc7A+eDvZB61SQkbQfFPO8bBisW9WYmf/qL5EEKKq/4Pb3Py/m0ikHg04vCbcJwIlS+UgzdE5vNG0+Y+EQfxObziv73GkCg=;
Message-ID: <669934.30949.qm@web56605.mail.re3.yahoo.com>
Date: Thu, 4 Feb 2010 16:10:48 -0800 (PST)
From: Mark Eggers <its_toasted@yahoo.com>
Subject: RE: Tomcat dies suddenly
To: Tomcat Users List <users@tomcat.apache.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

--- On Thu, 2/4/10, Caldarale, Charles R <Chuck.Caldarale@unisys.com> wrote=
:=0A=0A> > 6. Carl was using 32-bit Linux, which he isn't :(=0A> =0A> Corre=
ct, which made the whole point moot, so I'm not sure=0A> why Dan even broug=
ht it up.=0A> =0A=0AI just mentioned the 32-bit Linux behavior for complete=
ness. I did state that I realized 32-bit Linux is not in play.=0A=0A> > AFA=
IK, 64-bit Linux has a wide-open memory addressing=0A> scheme. Maybe it=0A>=
 > considers everything under 17 billion GiB to be "low=0A> memory", now :)=
=0A> =0A> No, the hardware restrictions don't exist in 64-bit mode.=0A=0ATh=
is is what I've read as well. If you use 64-bit Linux, this problem goes aw=
ay. There are also some ways to build the 32-bit kernel in order to reduce =
this problem.=0A=0AAll this is moot since a 64-bit Linux kernel is being us=
ed.=0A=0AAs to the copy-on-write behavior for fork()d processes, it would h=
elp if I read the man pages:=0A=0AUnder Linux, fork() is implemented using =
copy-on-write pages, so the only  penalty that it incurs is the time and me=
mory required to duplicate the parent=E2=80=99s page tables, and to create =
a unique task structure for the child.=0A=0AIt 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.=0A=0AAll of this is moot however if t=
here is no Runtime.exec() call in the application.=0A=0AI'm a bit curious t=
hough about several points:=0A=0A1. The application runs fine on an older s=
ystem. Do we have the glibc and kernel versions for all systems?=0A=0A2. Di=
fferent usage patterns (?) seem to cause the outages at different rates (if=
 I remember an account of one Friday). What paths in the application were b=
eing exercised most heavily during that time?=0A=0AAs for cache / buffer / =
free - I've seen cases where the cache did not go to 0, but swap was in pla=
y (slow disk, small amount of memory).=0A=0ASorry for chasing down the rabb=
it hole . . .=0A=0A/mde/=0A=0A=0A      


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org