> > I'm thinking that it's something to do with the fact that the 'distant' > machine is on a different subnet. Perhaps, it can't offload it's numbers to > my Master machine quick enough. I mean, it works in standalone. It's doing > the same thing as a slave, only reporting the numbers back to the Master, > no?
That's possible too. It's only possible on a multi-processor machine, because the result queue ups it's thread priority if it gets too full. On a multi-processor machine, that may not be enough. If this is so, I'm guessing you'd never see this on a single processor machine. I'm trying to think how this situation could be handled, but I'm drawing a blank. The only thing coming to mind is that one would have to create one queue thread for each processor the machine has. That wouldn't be an easy thing to do in the code. > > >The stack is normally 1MB, I think. You can increase it similarly to the > way you increased the > >heap size to 512 (read the java documentation - I haven't got it > memorized). > > I read the following, although quite what they mean is beyond me : > > -Xmx<size> Set maximum Java heap size > -Xoss<size> Set maximum Java stack size for any thread > -Xss<size> Set maximum native stack size for any thread > > So.. I edited my jmeter.bat and inserted this : > > java -Xmx512m -Xoss384m -Xss384m Oh no, you'd only increase the stack to, say, 2MB. Sorry I didn't make that clear. I doubt this is the problem. I think you're guess is better. -Mike > > And it complains that it can't create a native thread. I did > > java -Xmx512m -Xoss64m -Xss64m > > And it starts but continues to give me the same out of memory errors, > although it's memory size (according to perfmon) never gets above 20 meg. > > I'm out of my depth here. I have no idea what these heap sizes / stack sizes > are, or what the difference between a Java stack size, or a Native stack > size is. Or indeed which Jmeter uses. > > Steve. > > -Mike > > On 21 Jan 2003 at 15:35, Lawrence, Steve wrote: > > > Hi all, > > > > I'm seeing some very strange behaviour when running Jmeter in 'distributed > > mode'. > > I've successfully gotten my client / server set up, running on Windows 2k. > > (Still can't get it working under Linux, but that's another story). > > > > I've recorded a very small script which hits a couple of urls on my > > webserver. The entire script comes in at 39k. > > > > I have my Master machine, a local slave machine, a distant slave machine, > > and a webserver which is on my local subnet. > > > > Master Machine - NT4, 256Mb Memory. > > Local slave - NT4, 256Mb Memory > > Distant slave - 4 processor NT2k, 2 gig memory. (I'll call him Waldo) > > Webserver - Linux, 4 gig.. > > > > I've set up my test for 50 threads, 10 loops, 1 second ramp. > > > > I can run it locally on the Master machine fine. > > I can remote start it on my local slave (256Mb machine). It maxes the > > processor and ends up using between 50 and 80 meg of memory for the app - > It > > finished the script fine. > > > > If I remote run it on Waldo it gets about halfway through the threads > (it's > > done about 500 counts) and then hangs. It first stops reporting back to my > > master machine, and eventually it gives me java.lang.out of memory error > on > > the console. It's used about 80 meg of memory at this point. > > > > If I load up the gui, and run the script locally on Waldo it runs fine. > Its > > memory usage runs between 89 meg and 50 meg, often with large drops > followed > > by smaller incrementals up. > > > > I've tried setting the switch -Xmx512m in the jmeter.bat file, but that > > seems to make no difference. > > > > Can anyone clue me in to why this doesn't work remotely? This certainly > > isn't a lack of memory issue. :( > > > > Thanks in advance, and thanks in retrospect to Scott Eade for posting his > > ENV scripts for Windoze. > > Steve. > > > > > ---------------------------------------------------------------------------- > -- > > Notice: This e-mail message, together with any attachments, contains > information of Merck & Co., Inc. (Whitehouse Station, New Jersey, USA) that > may be confidential, proprietary copyrighted and/or legally privileged, and > is intended solely for the use of the individual or entity named on this > message. If you are not the intended recipient, and have received this > message in error, please immediately return this by e-mail and then delete > it. > > > > > ============================================================================ > == > > > > > > -- > > To unsubscribe, e-mail: > <mailto:[EMAIL PROTECTED]> > > For additional commands, e-mail: > <mailto:[EMAIL PROTECTED]> > > > > > > -- > Michael Stover > [EMAIL PROTECTED] > Yahoo IM: mstover_ya > ICQ: 152975688 > AIM: mstover777 > > -- > To unsubscribe, e-mail: > <mailto:[EMAIL PROTECTED]> > For additional commands, e-mail: > <mailto:[EMAIL PROTECTED]> > > > ------------------------------------------------------------------------------ > Notice: This e-mail message, together with any attachments, contains information of >Merck & Co., Inc. (Whitehouse Station, New Jersey, USA) that may be confidential, >proprietary copyrighted and/or legally privileged, and is intended solely for the use >of the individual or entity named on this message. If you are not the intended recipient, and have received this message in error, please immediately return this by e-mail and then delete it. > > ============================================================================== > > > -- > To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> > For additional commands, e-mail: <mailto:[EMAIL PROTECTED]> > -- Michael Stover [EMAIL PROTECTED] Yahoo IM: mstover_ya ICQ: 152975688 AIM: mstover777 -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
