You can also generally just use -client without the Xms/Xmx arguments. If you want to make all Java apps run with -client by default, which is what we opted for, you can easily effect this by making an unsupported change to /usr/java/jre/lib/i386/jvm.cfg so that the -client line reads "-client KNOWN" instead of "-client IF_SERVER_CLASS -server". This makes it match what is used on Windows (Java never defaults to the server VM on Windows 32-bit regardless of system specs).
This issue actually bit us hard and we struggled to fully understand it for about 4.5 years. We went from 30 users using pcGRASP/Java 1.4 on a 4GB Sun E450 to 30 users using jGRASP/Java 1.5 on a 24GB Sun X4150 and got "out of memory" messages on the latter but not the former. At the same time, the same number of users with jGRASP/Java 1.5 on Linux did not trigger this problem. It turned out this had to do with how Linux and Solaris manage memory overcommit; the short answer is increasing swap space is an option if you want to run many Java processes with -server, the long explanation is here: http://wyang0.blogspot.com/2010/01/virtual-memory-allocation.html. (SIZE is the amount of memory malloc'd, RSS is the amount of memory actually being used.) William Yang > -----Original Message----- > From: [email protected] [mailto:sunray-users- > [email protected]] On Behalf Of Craig Bender > Sent: Monday, July 26, 2010 1:14 PM > To: SunRay-Users mailing list > Subject: Re: [SunRay-Users] Java RAM HOG > > Yes, that's what it should look like. > > > Starting with Java 5 (1.5), anything that has more than 2 physical > processors or 2 GB of RAM is declared a server-class machine, and will > use the -Server option for the JIT compiler. If this is detected it > sets the min heap size to 1/64 available RAM up to 1GB and max of 1/4 > available RAM up to 1GB. > > Using the -client option uses a different JIT compiler resulting in a > smaller memory footprint and quicker operation of some applications that > don't need the advanced support of the server comiloer (i.e. at the end > of the day it loads less code). > > > > > > CJ Keist wrote: > > Craig, > > thanks for your reply. This is my current line: > > > > /usr/java/bin/java -jar /root/bin/dst/kiosk.jar > > > > So is this what it should look like?: > > > > /usr/java/bin/java -client -Xms16m -Xmx32m -jar /root/bin/dst/kiosk.jar > > > > I up'd the ram amount to be safe. > > > > > > > > > > On 7/26/10 10:43 AM, Craig Bender wrote: > >> You can also control the initial heap and max heap size with the > >> -Xms<size> and -Xmx<size> arguments > >> > >> For example if you wanted to set an initial of 8MB and a Max of 16MB > >> you'd do > >> > >> java -Xms8m -Xmx16m YourJava.app > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> Craig Bender wrote: > >>> Can you try adding -client argument to your java argument? > >>> > >>> > >>> > >>> CJ Keist wrote: > >>>> Looking to see if anyone else has seen this. Running SRSS 4.2 > >>>> latest patches installed on Solaris 10x86. I have a simple java gui > >>>> for our kiosk sessions. See attached pic. It was developed using > >>>> NetBeans 6.8. The entire Java jar file with libs is 156Kb in size. > >>>> But when I looking at the kiosk sessions this little java app is > >>>> chewing up 571MB of memory! > >>>> > >>>> PID USERNAME SIZE RSS STATE PRI NICE TIME CPU > PROCESS/NLWP > >>>> 4266 engr352 571M 60M sleep 59 0 0:00:04 0.0% java/31 > >>>> 4264 engr352 1452K 1000K sleep 59 0 0:00:00 0.0% > >>>> generic-session/1 > >>>> 4232 engr352 4540K 2240K sleep 59 0 0:00:00 0.0% utaudio/5 > >>>> 4260 engr352 1976K 968K sleep 59 0 0:00:00 0.0% > kioskcrit/1 > >>>> 4182 engr352 1664K 1168K sleep 59 0 0:00:00 0.0% Xsession/1 > >>>> 3953 engr352 22M 14M sleep 59 0 0:00:00 0.0% Xnewt/1 > >>>> 4237 engr352 3340K 1696K sleep 59 0 0:00:00 0.0% > utslaunch/1 > >>>> > >>>> Is this typical of Java? > >>>> > >>>> > >>>> --------------------------------------------------------------------- > --- > >>>> > >>>> > >>>> > >>>> --------------------------------------------------------------------- > --- > >>>> > >>>> > >>>> _______________________________________________ > >>>> SunRay-Users mailing list > >>>> [email protected] > >>>> http://www.filibeto.org/mailman/listinfo/sunray-users > >>> _______________________________________________ > >>> SunRay-Users mailing list > >>> [email protected] > >>> http://www.filibeto.org/mailman/listinfo/sunray-users > >> _______________________________________________ > >> SunRay-Users mailing list > >> [email protected] > >> http://www.filibeto.org/mailman/listinfo/sunray-users > > > _______________________________________________ > SunRay-Users mailing list > [email protected] > http://www.filibeto.org/mailman/listinfo/sunray-users _______________________________________________ SunRay-Users mailing list [email protected] http://www.filibeto.org/mailman/listinfo/sunray-users
