The problem is that most of the stuff that is loaded by the java
interpreter isn't shared (.class .jar files). Unless the application is
mission critical and / or shares a lot of static classes, it would be
better to run them in seperate threads like the others have said. It's
not so bad in java, because if one fails, it usually throws an exception
(which you can catch), and does not halt the process. Only in rare
instances have I ever seen the JVM seg fault and shut down the entire
process. I'm not sure but I think another case where the process gets
shut down is when a monitor dump gets shown.
Maksim Lin wrote:
>
> Thanks for the info, but I'm still confused - even if top is lying to me
> about individual jvm mem usage, I think it's telling the truth about
> totol mem usage (at least thats my rough assessment by comparing it's
> numbers to hearing the hard disk churn swapping mem in/out).
> So why do I get these results ?:
>
> 1 jvm:
> Mem: 47248K av, 44580K used, 2668K free, 21440K shrd, 160K buff
> Swap: 72572K av, 7116K used, 65456K free 14456K
> cached
>
> 2 jvm:
> Mem: 47248K av, 46280K used, 968K free, 21868K shrd, 100K buff
> Swap: 72572K av, 11584K used, 60988K free 12648K
> cached
>
> 3 jvm:
> Mem: 47248K av, 46288K used, 960K free, 19568K shrd, 92K buff
> Swap: 72572K av, 17828K used, 54744K free 11224K
> cached
>
> Now back to 2 jvm:
> Mem: 47248K av, 38992K used, 8256K free, 18116K shrd, 92K buff
> Swap: 72572K av, 17824K used, 54748K free 11472K
> cached
>
> Now 1 jvm:
> Mem: 47248K av, 32088K used, 15160K free, 16756K shrd, 92K buff
> Swap: 72572K av, 17160K used, 55412K free 11472K
> cached
>
> Now no jvm:
> Mem: 47248K av, 26052K used, 21196K free, 15496K shrd, 92K buff
> Swap: 72572K av, 14908K used, 57664K free 11472K
> cached
>
> According to this I am better off just running 1 vm and all apps as lots
> of threads.
>
> Thanks,
> Maksim
>
> > Linux automatically will share "code" memory. That is, the same physical
> > memory space will be used for all of the same physical code.
> >
> > Now, PS and TOP show you what each process would take but not how much
> > is actually shared in the code sections.
> >
> > Java has another thing that is not as easy to share: The classes.zip
> > class files. These are loaded by the JVM into each JVM. This is not
> > shared automatically. However, there is hack to the VM system called
> > MergeMem that addresses this type of shared data too. I, personally,
> > do not use it but I have seen it work. The web site is:
> > http://das.ist.org/mergemem/
> >
> > Michael Sinz -- Director of Research & Development, NextBus Inc.
> > mailto:[EMAIL PROTECTED] --------- http://www.nextbus.com
> > My place on the web ---> http://www.users.fast.net/~michael_sinz
> >
> > ----------------------------------------------------------------------
> > To UNSUBSCRIBE, email to [EMAIL PROTECTED]
> > with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
>
> --
> Remember Darwin; building a better mousetrap merely results in smarter
> mice.
>
> ----------------------------------------------------------------------
> To UNSUBSCRIBE, email to [EMAIL PROTECTED]
> with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
----------------------------------------------------------------------
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
