Thanks, useful to know that the problem was not purely because of running JMeter on Linux.
Maybe adding the second CPU gives more resources for the JVM to do garbage collection? I wonder what would happen if Windows were restricted to one CPU? S On 05/10/2007, Sonam Chauhan <[EMAIL PROTECTED]> wrote: > Hi - Just an update on this issue... > > The VMWare image of my PC was setup yesterday. My PC is a hyperthreaded > 3.2 GHz P4 that presents 2 CPUs in Windows task manager (due to > hyperthreading). The VMWare P2V (physical to virtual) process > transferred it across to ESX Server as a dual 4GHz Xeon (since that ESX > server runs on Xeons). The load test then ran successfully on the > Windows VMWare image within the normal time (an hour) and with no > out-of-memory memory errors. > > The VMWare system admin then informed me that the previous two Linux > virtuals I tried this load tests on had a single virtual CPU each. After > he 'added' a virtual 4GHz Xeon to the tst1app27 virtual, I could > successfully run the same load tests that always failed earlier with out > of memory errors (see emails below). > > I really don't have conclusions about this, but apparently, adding the > second virtual CPU turned failure into success on VMware. > > Kind regards, > Sonam Chauhan > -- > Corporate Express Australia Ltd. > Phone: +61-2-93350725, Email: [EMAIL PROTECTED] > > -----Original Message----- > From: Sonam Chauhan [mailto:[EMAIL PROTECTED] > Sent: Friday, 28 September 2007 8:37 PM > To: JMeter Users List > Subject: RE: OutOfMemoryError with stacktrace. > > Yes, it's not an apples to apples comparison. If I get a chance to test > with XP on ESX or RHEL on real hardware, I'll let youse know. > > Kind regards, > Sonam Chauhan > -- > Corporate Express Australia Ltd. > Phone: +61-2-93350725, Email: [EMAIL PROTECTED] > > -----Original Message----- > From: sebb [mailto:[EMAIL PROTECTED] > Sent: Friday, 28 September 2007 8:32 PM > To: JMeter Users List > Subject: Re: OutOfMemoryError with stacktrace. > > However, the comparison is not just about VMWare. > > It would be interesting to see what happened if you ran Windows XP in > VMWare. > Or RHEL on real hardware. But those might take a lot of effort to set > up. > > The GC flags are mentioned in the jmeter.bat file. > > On 28/09/2007, Sonam Chauhan <[EMAIL PROTECTED]> wrote: > > Thanks Sebb. I'll look into JVM 1.6 on XP and maybe GC tracing on the > > JVMs (I am not much of an expert in that, I'm afraid). > > > > My gut feel is this level of load testing simply is too much for > VMWare > > to handle. > > > > I now run multiple load tests on two different Redhat/VMWare virtuals > - > > one with JVM 1.5 and the other with JVM 1.6. On both systems, the load > > tests took 2 + hours (compared to less than an hour on real hardware), > > and threw out of memory errors even after increasing JVM heap memory > (to > > 1536 MB). The same load tests ran fine on my Windows XP 'real' > hardware > > box. > > > > This is after increasing the ESX server 'RAM' and 'CPU MHz' > allocations > > to match my 'real' box. > > > > > > Kind regards, > > Sonam Chauhan > > -- > > Corporate Express Australia Ltd. > > Phone: +61-2-93350725, Email: [EMAIL PROTECTED] > > > > -----Original Message----- > > From: sebb [mailto:[EMAIL PROTECTED] > > Sent: Friday, 28 September 2007 8:12 PM > > To: JMeter Users List > > Subject: Re: OutOfMemoryError with stacktrace. > > > > On 28/09/2007, Sonam Chauhan <[EMAIL PROTECTED]> wrote: > > > Hello - > > > > > > > > > > > > I'm currently running JMeter 2.1.1 with Sun JVM 1.6 on RHEL ES 4 > Linux > > > on VMWare ESX server, and am struggling with out of memory errors > > > running JMeter. > > > > > > > Might be a garbage collection issue? > > > > Perhaps you could enable GC tracing on the JVMs, and compare the two > > systems. > > > > > > > > The same tests running on a Windows XP box (Sun JVM 1.5) don't throw > > out > > > of memory errors. > > > > What about JVM 1.6 on XP? > > > > > > > > Here's 'top' output of the process : > > > > > > PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND > > > > > > > > > 24733 metatest 25 0 977m 150m 6320 S 99.2 4.0 16:20.65 java > > > > > > > > > > > > Normally I get errors with no stacktrace: > > > > > > java.lang.OutOfMemoryError: Java heap space > > > > > > > > > > > > However, upping the JVM max. heap memory to 1.5 GB, gave of memory > > error > > > with a stacktrace (see end of email). Is this significant or useful? > > > > > > > I don't think so. > > > > It just shows that the JVM ran out of memory trying to log a message. > > > > This was just "the straw that broke the camel's back", The rest of the > > straw was loaded previously by other parts of the test. > > > > > > > > Kind regards, > > > > > > Sonam Chauhan > > > > > > -- > > > > > > Corporate Express Australia Ltd. > > > > > > Phone: +61-2-93350725, Email: [EMAIL PROTECTED] > > > > > > > > > > > > > > > > > > > > > > > > STACKTRACE > > > > > > > > > > > > java.lang.OutOfMemoryError: Java heap space > > > > > > at java.util.Arrays.copyOf(Arrays.java:2882) > > > > > > at > > > > > > java.lang.AbstractStringBuilder.expandCapacity(AbstractStringBuilder.jav > > > a: > > > > > > 100) > > > > > > at > > > > java.lang.AbstractStringBuilder.append(AbstractStringBuilder.java:390) > > > > > > at java.lang.StringBuffer.append(StringBuffer.java:224) > > > > > > at java.io.StringWriter.write(StringWriter.java:95) > > > > > > at java.io.PrintWriter.write(PrintWriter.java:412) > > > > > > at java.io.PrintWriter.write(PrintWriter.java:429) > > > > > > at java.io.PrintWriter.print(PrintWriter.java:559) > > > > > > at java.io.PrintWriter.println(PrintWriter.java:695) > > > > > > at java.lang.Throwable.printStackTrace(Throwable.java:512) > > > > > > at > > > > > > org.apache.log.format.PatternFormatter.getStackTrace(PatternFormatter.ja > > > va > > > > > > :638) > > > > > > at > > > > > > org.apache.log.format.PatternFormatter.formatPatternRun(PatternFormatter > > > .j > > > > > > ava:519) > > > > > > at > > > > > > org.apache.log.format.PatternFormatter.format(PatternFormatter.java:493) > > > > > > at > > > > > > org.apache.log.output.AbstractOutputTarget.format(AbstractOutputTarget.j > > > av > > > > > > a:189) > > > > > > at > > > > > > org.apache.log.output.AbstractOutputTarget.doProcessEvent(AbstractOutput > > > Ta > > > > > > rget.java:148) > > > > > > at > > > > > > org.apache.log.output.AbstractTarget.processEvent(AbstractTarget.java:14 > > > 5) > > > > > > at org.apache.log.Logger.fireEvent(Logger.java:708) > > > > > > at org.apache.log.Logger.output(Logger.java:683) > > > > > > at org.apache.log.Logger.output(Logger.java:666) > > > > > > at org.apache.log.Logger.error(Logger.java:267) > > > > > > at > > > org.apache.jmeter.threads.JMeterThread.run(JMeterThread.java:298) > > > > > > at java.lang.Thread.run(Thread.java:619) > > > > > > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
