--- 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
