On 16/01/2009, Thomas Johnson <[email protected]> wrote: > On Fri, Jan 16, 2009 at 4:21 AM, GeeTee <[email protected]> wrote: > > > > Hi sebb, > > > > Thanks for your response. Following are the details: > > > >>>What is the exact Java error message? > >>>AFAIK,"swap space" is an OS error rather than a JVM error > > Exception java.lang.OutOfMemoryError: requested 36052328 bytes for > > promotion. > > Out of swap space? > > > Out of curiousity, could you try opening up your jmeter.bat and > increasing the values in the HEAP variable. Sepecifically, change > -Xmx512m up to -Xmx2048m in hopes that you're running into a > limitation with the default memory settings.
Agreed. > Run "java -X" for more information on these, or open "bin/jmeter" in a > text editor > > On a hunch, maybe one of the samplers or its dependencies allocates > enough memory to hold the file, or the file upload process is > allocating a String/StringBuffer that temporarily holds a MIME-Encoded > version of the file. When you get enough threads on the same upload > step, you suddenly have 30 threads holding 30MB of data each. This > could be the reason that it rarely happens on the 10MB files -- the > chances of 60 threads being on the same sampler are much lower. This > is all idle speculation, though. > Could well be true. > > This is shown on the console launched by jmeter.bat. Please let me know how > > I can see the JVM error. > > > > The full exception details might be visible in jmeter.log Probably not, as running out of memory may well stop logging from working... > > >>>Ramp-up should not be set as low as this or JMeter may have problems > > starting. > > > > Okay. So what is the minimum ramp up that we should set? We had been asked > > to load test for 800 users accessing the online service simultaneously. As > > such we had set up 8 instances of JMeter on different systems and had 100 > > users with 1 sec. ramp up on each (Please note that this was one of the > > tests on which more than 10 MB of file upload would cause swap space error > > for 30 users or more). Please provide your inputs on how we should have > > proceeded. > > Ramp-up should be set to limit how quickly the threads are started. 5-10 per second should be fine, 100/s is almost certainly too high. > >>> What errors are these? > > These error are not of one common nature. But most of them were due to > > "Regular Expression Extractor" not being able to extract the data from > > previous response. This is presumably because the response was not as expected, which probably means that the server was returning different data. Either there are variations in the output that the test plan does not allow for, or the server is misbehaving under load. > > This happened on running 35 threads from 2 systems > > controlled by a single server. For heavier loads (70 users from 2 machines > > controlled by a single server) I did not see the response as I had disabled > > the "View Results Tree" listener as it is quite memory intensive, and > > instead used "Aggregate Graph" listener. I did not log the results. > > Aggregate Graph is also memory intensive. Use Summary Report instead. > > Just to add to my previous post, we have seen this problem only with > scripts > > that upload a file to the online service server. For other services, that > do > > not upload anything and rather just hit the various servlets / JSPs, we > have > > not seen this error. > > Which Http Sampler are you using? HttpClient or the default Java one? > > Thanks again for the help. > > Gaurav > > > > > > > > sebb-2-2 wrote: > >> > >> On 11/01/2009, GeeTee <[email protected]> wrote: > >>> > >>> Hi everyone, > >>> > >>> We wanted to load test our online services using JMeter but were unable > >>> to > >>> load test for heavy loads due to JMeter crashes with "swap space" error. > >>> I > >> > >> What is the exact Java error message? > >> AFAIK,"swap space" is an OS error rather than a JVM error. > >> > >>> had a look at other such threads over here and we have already tried out > >>> those suggestions with no success (e.g. setting heap correctly in > >>> jmeter.bat) > >>> > >>> I will give you some insight into out online application. It is actually > >>> a > >>> hybrid application, i.e. it is an online application embedded in a > >>> desktop > >>> client. It is basically a set of Servlets and JSPs and uses a custom > >>> "XML > >>> over HTTP" protocol for communication (please note that we do not use > >>> SOAP). > >>> Using these services a user can upload videos and stills to different > >>> websites (some of our own and some third-party). We have faced 2 issues > >>> that > >>> seem to be related to each other. > >>> > >>> PROBLEM1: > >>> We had been asked to test for total 200-800 simultaneous (i.e. ramp up = > >>> 1 > >>> sec) users. > >> > >> Ramp-up should not be set as low as this or JMeter may have problems > >> starting. > >> > >>> After reading a few documents we decided on running 50-75 > >>> threads from a single machine and have a central controller > >>> (jmeter-server.bat method). We were unsuccessful in our attempts. For > >>> example, at one instance we tried to run 35 threads from 2 machines > >>> (total > >>> 70 threads only) controlled by a JMeter server. We received 50-60% > >>> errors. > >> > >> What errors are these? > >> > >>> Then we ran 70 threads from 1 machine. Result - 0% error. Since the > >>> service > >>> was same in both the cases, it seems to be a problem related to JMeter. > >>> Even > >>> with 25 users per system from 2 systems, the problem exists. > >>> > >>> Machine config: Pentium Dual Core machines 2.8 GHz, 3 GB RAM, 320 GB > >>> Hard > >>> Disc, 10 GB Virtual Memory, Win XP Professional SP2. The systems had no > >>> other softwares installed. JMeter version was 2.3.1 (we also tried 2.3.2 > >>> but > >>> observed the same results) > >>> > >>> PROBLEM2: > >>> Due to Problem1, we decided that we will run the scripts from 8-10 > >>> separate > >>> systems by manually triggering them. And would later collate the > >>> response > >>> timings from each system. We wanted to upload files (present on hard > >>> disc) > >>> to the websites for which the service had been written. File size varied > >>> from 4MB to 60MB. Using file size = 4MB, I was able to run 100 threads > >>> from > >>> 1 system without problem. But with file size = 30MB or more, even 10 > >>> threads > >>> would cause JMeter to crash frequently. On Vista, the situation was > >>> slightly > >>> better but still I could not go beyond 20 users for 30 MB files. As such > >>> we > >>> have not been able to load test for heavy files. > >> > >> Which Http Sampler are you using? > >> > >>> Machine Config: Same as that for Problem1 > >>> > >>> Sorry for such a lengthy email. I wanted to provide all the information > >>> that > >>> I had with me. > >>> > >>> Thanks, > >>> Gaurav Tripathi > >>> > >>> -- > >>> View this message in context: > >>> > http://www.nabble.com/Jmeter-crashes-with-%22swap-space%22-error-for-us-tp21402014p21402014.html > >>> Sent from the JMeter - User mailing list archive at Nabble.com. > >>> > >>> > >>> --------------------------------------------------------------------- > >>> 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] > >> > >> > >> > > > > -- > > View this message in context: > http://www.nabble.com/Jmeter-crashes-with-%22swap-space%22-error-for-us-tp21402014p21491893.html > > Sent from the JMeter - User mailing list archive at Nabble.com. > > > > > > --------------------------------------------------------------------- > > 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]
