Linux multi-core CPU performance tuning

Often feel that the system resources are not enough, a machine ran on less than 3 more important services, but every day we have to do a backup compression, such as processing, the network for a long time transmission, which is very influential in this is not enough to use the system resources;

At this point, we can limit some of the less important things, such as copy/Backup/synchronization, to one CPU or one core of a multicore CPU, although this is not necessarily the most efficient approach, but it can be used to the greatest extent possible with efficient resources, reducing the CPU resources of less important processes ；

View CPU information under System: Cat/proc/cpuinfo

Taskset can help us do the work, and the operation is very simple;

With Taskset, you can take advantage of the benefits of multicore CPUs by allowing a program or script to run on a specific CPU.

This tool system may not be installed by default:, RPM package name Util-linux

#taskset --help
taskset (util-linux 2.13-pre7)
usage: taskset [options] [mask | cpu-list] [pid | cmd [args...]]
set or get the affinity of a process

-p,–pid operate on existing given PID
-c,–cpu-list display and specify CPUs in list format
-h,–help Display this Help
-v,–version Output Version Information

View the PID and which CPU affinity:

TASKSET-PC PID

Example:

TASKSET-PC 3687

Return PID 3687 ' s current affinity list:0,1,2,3

TASKSET-PC 0-1 3687 or taskset-pc 0,1 3687

Set threads 3678 and 0, 12 CPU cores affinity

1) shows the CPU the process is running on

Command Taskset-p 21184

Show Results:

PID 21184 ' s current affinity mask:ffffff

Note: 21184 is redis-server running PID

The ffffff of the result is actually a binary 24 low 1 bitmask, each 1 corresponds to 1 CPUs, indicating that the process runs on 24 CPUs

1: Let a program run on a specific CPU

Taskset-c 0 SH wade.sh

2: Switch a process to a specific CPU.

TASKSET-PC 0 12345

Like you have a CPU that's 4 core you can write your script like this

#！ /bin/bash

Taskset-c 0 sh a.sh &

Taskset-c 1 sh b.sh &

Taskset-c 2 sh c.sh &

Taskset-c 3 sh d.sh &

You should be able to make the most of your CPU.

For a running process, the document says you can use the following command to #2 the cpu#1 #3分配给PID为2345的进程:

# TASKSET-CP 2345

But I tried not to work, so I turned off MySQL and started it with Taskset:

# taskset-c 1,2,3/etc/init.d/mysql Start

Second, configure Nginx bound CPU

Just said Nginx is the exception, because Nginx provides more precise control.

in the conf/nginx.conf , as in the following line:

Worker_processes 1;

This is used to configure Nginx to boot several worker processes, the default is 1. Nginx also supports a configuration item named Worker_cpu_affinity, which means that nginx can bind the CPU for each worker process. I made the following configuration:

Worker_processes 3;
Worker_cpu_affinity 0010 0100 1000;

Here 0010 0100 1000 is a mask that represents the 2nd, 3, and 4 CPU cores, respectively.

After restarting Nginx, 3 working processes can be used on their respective CPUs.

Application Examples:

On a multi-core CPU Web server, there is a load imbalance, in which the load of CPU0 is significantly higher than other cpux, further investigation indicates that the PHP-FPM suspicion is very large. I have previously documented a similar problem with soft interrupts, but in this case we can exclude suspects.
Let's sample the data on a four-core server to see if there is a load imbalance problem:
Shell> mpstat-p all 1 10

CPU%usr%nice%sys%iowait%irq%soft ...%idle
All 17.57 0.03 1.78 0.00 0.35 0.23 ... 80.04
0 43.17 0.00 4.12 0.00 1.41 1.00 ... 50.30
1 9.80 0.00 0.81 0.00 0.00 0.00 ... 89.39
2 9.31 0.00 1.20 0.00 0.00 0.00 ... 89.49
3 7.94 0.10 0.80 0.00 0.00 0.00 ... 91.16

If the meaning of the above command is to run once per second Mpstat, a total of 10 times to take the average, it can be seen that the idle CPU0 is significantly smaller than the other cpux, and most of them are consumed in the user-state usr above.
Let's check Pidstat to see if the PHP-FPM is causing the CPU0 load problem:
Shell> Pidstat | grep php-fpm | awk ' {print $ (NF-1)} ' | Sort | Uniq-c

157 0
34 1
34 2
32 3

It is visible that the PHP-FPM process assigned to CPU0 is more than the sum of the other three cpux. Why is most of the process allocated to CPU0? I have a vague impression that the operating system prefers to use CPU0, but I haven't found any real clues to prove it, if anyone knows, please tell me.
The problem is always solved, since PHP-FPM does not have a CPU affinity (affinity) binding directive like Nginx, then we can use Taskset binding php-fpm process to fixed cpux to solve the problem:
#!/bin/bash

cpus=$ (grep-c processor/proc/cpuinfo)
pids=$ (ps aux | grep "php-fpm[:] Pool" | awk ' {print $} ')

Let I=0
For PID in $PIDs; Do
Cpu=$ (echo "$i% $CPUs" | BC)
Let i++

TASKSET-PC $CPU $PID
Done

Once the script is running, let's take a look at how each CPU load is distributed:
Shell> mpstat-p all 1 10

CPU%usr%nice%sys%iowait%irq%soft ...%idle
All 15.73 0.03 1.61 0.00 0.20 0.23 ... 82.20
0 16.28 0.10 1.62 0.10 0.81 0.91 ... 80.18
1 16.16 0.10 1.51 0.00 0.00 0.10 ... 82.13
2 14.46 0.10 1.71 0.00 0.00 0.00 ... 83.73
3 15.95 0.00 1.71 0.00 0.00 0.00 ... 82.35

Finally average, but it should be reminded that once the number of requests processed by PHP-FPM exceeds the max_requests setting, then the corresponding process will be restarted automatically, and the previous Taskset settings will be invalidated, so we need to add the Taskset script to the CRON in order to remain valid. Configuration, such as auto-set every minute!
In this paper, the PHP-FPM process evenly distributed to the 0,1,2,3 four CPUs, the actual operation can be more flexible, such as we mentioned earlier, the operating system is always preferred to use CPU0, if the CPU0 load is already high, then we might as well the PHP-FPM process allocated to 1, 2, 33 CPUs.

This article is from the "Dream to Reality" blog, please be sure to keep this source http://lookingdream.blog.51cto.com/5177800/1949456

Linux multi-core CPU performance tuning