On Linux, it's /proc/sys/fs/file-max You may have to run uname -n to increase the max filehandles per process.
Here's a somewhat dated FAQ: http://www.faqs.org/docs/securing/chap6sec72.html :) Kind regards, Sonam Chauhan -- Corporate Express Australia Ltd. Phone: +61-2-93350725, Email: [EMAIL PROTECTED] -----Original Message----- From: Oliver Erlewein (DSLWN) [mailto:[EMAIL PROTECTED] Sent: Saturday, 12 May 2007 9:26 PM To: JMeter Users List Subject: RE: maximum number of threads per JMeter instance Hello That's excellent news! As I said I hadn't followed it up in detail (might have been another thread). This might just save me the work. Thank you! Now where was that setting in Linux..... ;-) Cheers Oliver -----Original Message----- From: iblavins [mailto:[EMAIL PROTECTED] Sent: Fri 5/11/2007 9:30 PM To: 'JMeter Users List' Subject: RE: maximum number of threads per JMeter instance G'day I've got doubts that it is as black and white as a 2,000 socket limit in all circumstances. I ran into a 'too many files open' limit on AIX when opening my 2,000th odd socket - AIX considered my Java socket connections to be open files. I had the number of open files limit changed in AIX and was able to go above 2,000 open sockets (as I recall, memory gets a big vague). I've since implemented connection pooling on all my connections so I can't test this. But you are certainly right in general terms - JVM, operating system, and machine impose limits to consider when running large benchmarks. In fact the process of ramping up to a target load in a big benchmark includes finding and knocking over each of the various limits. Ian Blavins Contract Performance Engineer Temenos -----Original Message----- From: Oliver Erlewein (DSLWN) [mailto:[EMAIL PROTECTED] Sent: 11 May 2007 05:24 To: JMeter Users List Subject: RE: maximum number of threads per JMeter instance Hello Sonam, >From what we saw in our test it does include non active states. I did not do any analysis on the subject and don't know if the 2000 is a fixed number or depends on ram, OS, Java/JMeter version... Maybe you can have a look out for that behaviour (I saw it on Linux) and confirm or correct me if that is not the case. Cheers Oliver -----Original Message----- From: Sonam Chauhan [mailto:[EMAIL PROTECTED] Sent: Friday, 11 May 2007 12:38 To: JMeter Users List Subject: RE: maximum number of threads per JMeter instance Thanks Oliver, I didn't know about this limit. However in our case, the JVM is unlikely to have 2000 sockets open at a time as the network connection requests are pretty short (tens of milliseconds) and are spread out by a ramp. So this may not impact us ... unless the 2000 limit includes TCP connections in non-ACTIVE status (eg: CLOSE_WAIT). Kind regards, Sonam Chauhan -- Corporate Express Australia Ltd. Phone: +61-2-93350725, Email: [EMAIL PROTECTED] -----Original Message----- From: Oliver Erlewein (DSLWN) [mailto:[EMAIL PROTECTED] Sent: Friday, 11 May 2007 9:48 AM To: JMeter Users List Subject: RE: maximum number of threads per JMeter instance Just an aside on that, it seems that Java can only open 2000 sockets so you will be limited there. That doesn't depend on available hardware. I get around that by executing multiple JVM's on the same machine. It works like a charm. Cheers Oliver -----Original Message----- From: sebb [mailto:[EMAIL PROTECTED] Sent: Wednesday, 9 May 2007 21:52 To: JMeter Users List Subject: Re: maximum number of threads per JMeter instance There is no documentation, because there is no fixed limit - it depends on the test plan, OS, JVM, hardware, network etc.. The only way to determine the limit is to try. For example, if it works OK for a particular scenario with 10 threads but not with 15, then the limit is somewhere between 10 and 15. Having said that, 2000 or more threads is a pretty large number, so I'm not entirely surprised that there are memory problems. Some OSes have limits to the number of open sockets, even if memory is not a problem. That number of threads is also potentially a huge load on whatever server is under test - do you really need to run with 7000 threads? As a work-round: - use non-GUI mode - remove all but one listener - use CSV output - minimise assertions - use multiple independent jobs, and combine the results. On 09/05/07, Sonam Chauhan <[EMAIL PROTECTED]> wrote: > Hi - > > > > Can someone point me to documentation on the maximum number of threads > a single JMeter instance can handle? (I cannot find this information > on Google or the wiki.) > > > > I have a problem with a testcase that has a large number of threads - > it has 2 thread groups with 2000 and 5000 threads each. On a Windows > XP SP2 system with 2GB of RAM, java.exe grows to about 350MB before > throwing this exception: > > ------------------------- > > Exception in thread "Thread-1" java.lang.OutOfMemoryError: unable to > create new native thread > > at java.lang.Thread.start0(Native Method) > > at java.lang.Thread.start(Thread.java:574) > > at > org.apache.jmeter.engine.StandardJMeterEngine.run(StandardJMeterEngine > .j > ava:387) > > at java.lang.Thread.run(Thread.java:595) > > ------------------------- > > > > The JMeter version is 2.1.1 and the Java version is "1.5.0_10" > > ------------------------- > > Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_10-b03) > > Java HotSpot(TM) Client VM (build 1.5.0_10-b03, mixed mode) > > ------------------------- > > > > I tried tweaking two JMeter run script settings: HEAP and NEW. I > started small, and increased the numbers proportionally up until > Xmx=1024m but it was little use - the more I increased HEAP size, the > faster I got the outOfMemory errors. > > > > I also came across some interesting information here about the maximum > number of threads per process: > > > http://blogs.msdn.com/oldnewthing/archive/2005/07/29/444912.aspx > > I tried using '-Xss128k' to reduce stack size per Java thread, but > that did not help either. > > > > Kind regards, > > Sonam Chauhan > > -- > > Corporate Express Australia Ltd. > > Phone: +61-2-93350725, Email: [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] This email (and any attachments) contains confidential information, and is intended only for the named recipient. Distribution or copying of this email by anyone other than the named recipient is prohibited. If you are not the named or intended recipient, please notify TEMENOS or the sender immediately and permanently destroy this email (and any attachments) and all copies of it. No member of TEMENOS Group AG or any of its associated or affiliated companies is liable for any errors or omissions in the content or transmission of this email. Any opinions contained in this email are solely those of the author and, unless clearly indicated otherwise in writing, are not endorsed by any member of TEMENOS Group AG or any of its associated and affiliated companies. --------------------------------------------------------------------- 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]
