Linux Best thread Count __linux

optimal number of threads:

Performance pressure test In the case, initially with the increase in the number of users, QPS will rise, when a certain threshold, the increase in the number of users QPS does not increase, or increase is not obvious, while the request response time is greatly increased. This threshold we consider to be the optimal number of threads.

why to find the best thread count

1. Too many threads can only cause more memory overhead and more CPU overhead, but it does not help upgrade QPS

2. After finding the best thread count, you can make the web system more stable with the highest and most stable QPS output by simple setting.

get the best number of threads:

1, through the user slowly increasing to perform performance pressure measurement, observation QPS, response time

2, according to the formula calculation: server-side optimal number of threads = ((thread wait time + Thread CPU time)/thread CPU Time) * Number of CPUs

3, single user pressure measurement, to see the CPU consumption, and then directly multiplied by the percentage, and then the pressure test, generally this value near the best number of threads.

The main factors that affect the optimal number of threads:

1, IO

2, CPU

By formula: server-side optimal number of threads = (thread wait time + Thread CPU time)/thread CPU Time) * Number of CPUs

Generally, IO and CPU. Io spends a lot of time applying its CPU thread to wait longer, so the number of threads can be more open, on the contrary, the number of threads is less, in fact, there are two extreme, pure IO applications, such as proxy, the number of threads can be very large (too large to consider the cost of threading switch), This application is basically the QPS of the backend (such as the proxy search), and how many proxies there are.

The other is CPU-intensive computing, which generally drives only the number of threads on the CPU. But it is not that the application of the QPS is not high, often this application of QPS can be very high.

relationship between QPS and number of threads

1, before the optimal number of threads, QPS and threads are increasing relationship, the number of threads to the best thread, QPS flat, not up, or even slightly down, while the corresponding time continues to rise.

2, the same system, the number of supported threads (the more optimal number of threads rather than the number of configured threads), the higher the QPS

the relationship between QPS and response time

1, for the general web system, response time generally has CPU execution time +io wait time composition

2, the CPU's execution time reduces, to QPS has the real promotion, the IO time reduces, to QPS ascension is not obvious. If you want to significantly improve the QPS, optimize the system to focus on optimizing the CPU consumer.

optimal number of threads and JVM heap memory:

The above are based on performance bottlenecks in the CPU situation, for Java applications There is also a full GC, we want to ensure that the best number of threads, does not occur frequent full GC

According to the formula:: (small gc interval/rt) * (Number of concurrent threads * tHM) <=young calculation of the number of concurrent threads if < The optimal number of threads can cause a full GC to be more frequent, this situation appears to be very rare on the web system. But it can be simulated.

So when we set up the JBoss thread, we can set the number of threads calculated by the memory formula, get the best number of threads through the pressure measurement and calculation, and then set the number of threads.

To set the number of threads:

Maximum number of threads to be measured < true set thread count < memory limit Threads

For example, by measuring the optimal number of threads to obtain a system is 10, then the number of threads calculated by memory is 20, then the number of threads set JBoss is 15 is feasible, if you set 10 directly, because the system itself will be affected by a number of dependent system changes and some changes, For example, the system relies on some IO response time will suddenly lengthen, because the number of threads or 10, in fact, this time the optimal number of threads has become 13, because we set dead 10, the result is to cause QPS drop, but if more than 20, it will cause a full GC very frequent, In turn affects the decline of QPS.

JBoss's number of threads set:

For JBoss, the number of threads to set depends on the kind of thread connection used, such as HTTP, AJP, etc.

The HTTP and AJP settings are exactly the same, very simple:

Take AJP For example, find Server.xml or Tomcat-server.xml:

The default number of threads is 200

<connector port= "8009" address= "${jboss.bind.address}" connectiontimeout= "15000" protocol= "AJP/1.3" maxthreads= "minsparethreads=" "maxsparethreads=" "maxpostsize=" 512000 "acceptcount=" "buffersize=" 16384 "emptysessionpath= false" enablelookups= "false" redirectport= "8443" usebodyencodingforuri= "true"/>

This changes the default number of threads to 20, with the corresponding minimum number of idle threads and the maximum number of idle threads adjusted:

<connector port= "8009" address= "${jboss.bind.address}" connectiontimeout= "15000" protocol= "AJP/1.3" maxthreads= "minsparethreads=" maxsparethreads= "maxpostsize=" 512000 "acceptcount=" "buffersize=" 16384 "emptysessionpath= false" enablelookups= "false" redirectport= "8443" usebodyencodingforuri= "true"/>