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]
