CPU-IO-网络-内核参数调优

妖狐艹你老母 2021-11-16 13:34 399阅读 0赞

一、 有关使用CPU资源的调优  
1、 nice概述  
在LINUX系统中，Nice值的范围从-20到+19（不同系统的值范围是不一样的），正值表示低优先级，负值表示高优先级，值为零则表示不会调整该进程的优先级。具有最高优先级的程序，其nice值最低，所以在LINUX系统中，值-20使得一项任务变得非常重要；与之相反，如果任务的nice为+19，则表示它是一个高尚的、无私的任务，允许所有其他任务比自己享有宝贵的CPU时间的更大使用份额，这也就是nice的名称的来意。默认优先级是0

2、 调整命令运行优先级，让进城使用更多的CPU资源  
语法：nice -n 优先级数字 命令  
\[root@xuegod120 ~\]\# nice -n -5 vim a.txt  
另外终端查看vim的优先级  
\[root@xuegod120 ~\]\# ps -aux | grep vim  
root 23305 0.0 0.2 151264 4920 pts/0 S<+ 14:45 0:00 vim a.txt  
\[root@xuegod120 ~\]\# top -p 23305  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MTg0MzY5OQ_size_16_color_FFFFFF_t_70]

3、 使用renice修改正在运行进程的优先级  
\[root@xuegod120 ~\]\# renice -n 6 23305  
23305 (process ID) old priority -5, new priority 6  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MTg0MzY5OQ_size_16_color_FFFFFF_t_70 1]  
4、 进程先级不能超过-20到19  
会自动调整为最大和最小的优先级数值  
![在这里插入图片描述][20190728140850105.png]

5、 设置CPU的亲和力  
taskset 作用：在多核的情况下，可以认为指定一个进程在哪颗CPU上执行程序，减少进程在不同CPU之前切换的开销。  
5.1 安装taskset命令  
\[root@xuegod120 ~\]\# yum -y install util-linux

5.2 taskset的语法  
taskset -cp \[CPU ID号\] 命令或进程ID  
常用参数：  
\-p：pid 在已经存在的pid上操作  
\-c：cpu-list 以列表格式显示和指定CPU

例1：调整服务器核心是为4核心，指定vim命令在第一个cpu上运行  
使用top命令，按下数字1，可以看到是四核CPU  
![在这里插入图片描述][20190728140854774.png]

指定vim运行在第三个cpu上  
\[root@xuegod120 ~\]\# taskset -c 2 vim a.txt  
在另外一个终端执行  
\[root@xuegod120 ~\]\# ps -aux | grep vim  
root 1316 0.5 0.2 151228 4912 pts/0 S+ 14:56 0:00 vim a.txt  
\[root@xuegod120 ~\]\# taskset -cp 1316  
pid 1316’s current affinity list: 2  
![在这里插入图片描述][20190728140859654.png]

例2：查看sshd运行在哪个进程  
\[root@xuegod120 ~\]\# ps -axu | grep sshd  
root 1005 0.0 0.2 112800 4300 ? Ss 14:55 0:00 /usr/sbin/sshd -D  
\[root@xuegod120 ~\]\# taskset -cp 1005  
pid 1005’s current affinity list: 0-3 \#0-3，说明sshd可以使用四个cpu处理数据

例3：指定vim程序运行在第2和第4个cpu上运行  
\[root@xuegod120 ~\]\# taskset -c 1,3 vim b.txt  
\[root@xuegod120 ~\]\# ps -aux | grep vim  
root 1345 0.2 0.2 151236 4892 pts/0 S+ 15:01 0:00 vim b.txt  
\[root@xuegod120 ~\]\# taskset -cp 1345  
pid 1345’s current affinity list: 1,3 \#1,3表示第二个和第四个cpu运行  
![在这里插入图片描述][20190728140905598.png]

6、 使用vmstat找出系统中存在的瓶颈  
正常CPU利用率比例分配：  
如果一个cpu被充分利用，均衡的比率如下：  
65%  70% User Time \#用户态（通常指我们运行的服务和程序）。  
30%  35% System Time \#内核态。  
0%  5% Idle Time \#空闲。  
Context Switches  上下文切换的数目直接关系到CPU 的使用率，如果CPU 利用率保持在上述均衡状态时，有大量的上下文切换是正常的。  
上下文切换指的就是cpu中寄存器数据的写入和读出。每个进程在使用cpu时，都需要把自己的数据先写入cpu的缓存（寄存器）中，然后cpu才能根据缓存中的数据来计算。

扩展：  
1）Procs（进程）：  
r: The number of processes waiting for run time.  
等待运行的进程数。如果等待运行的进程数越多，意味着CPU非常繁忙。另外，如果该参数长期大于cpu核心数3倍，说明CPU资源可能存在较大的瓶颈。  
b: The number of processes in uninterruptible sleep.  
处在非中断睡眠状态的进程数。即等待IO的进程数量。  
2）Memory（内存）：  
swpd: the amount of virtual memory used.  
已使用的虚拟内存大小。如果虚拟内存使用较多，可能系统的物理内存比较吃紧，需要采取合适的方式来减少物理内存的使用。swapd不为0，并不意味物理内存吃紧，如果swapd没变化，si、so的值长期为0,这也是没有问题的 。  
free: the amount of idle memory.  
空闲的物理内存的大小  
buff: the amount of memory used as buffers.  
用来做buffer（缓存，主要用于块设备缓存）的内存数，单位：KB  
cache: the amount of memory used as cache.  
用作缓存的内存大小，如果cache的值大的时候，说明cache处的文件数多，如果频繁访问到的文件都能被cache处，那么磁盘的读IO bi会非常小。单位：KB  
3）Swap（交换分区）  
si: Amount of memory swapped in from disk (/s).  
从磁盘写入到swap虚拟内存的交换页数量，单位：KB/秒。如果这个值大于0，表示物理内存不够用或者内存泄露了。  
so: Amount of memory swapped to disk (/s).  
从swap虚拟内读出的数据。即从swap中的数据写入到磁盘的交换页数量，单位：KB/秒，如果这个值大于0，表示物理内存不够用或者内存泄露了。  
内存够用的时候，这2个值都是0，如果这2个值长期大于0时，系统性能会受到影响，磁盘IO和CPU资源都会被消耗。  
当看到空闲内存（free）很少的或接近于0时，就认为内存不够用了，这个是不正确的。不能光看这一点，还要结合si和so。如果free很少，但是si和so是0，那么不用担心，系统性能这时不会受到影响的。  
4）IO（这里指Input/Output Memery的数据，即bi：进入内存，bo：从内存中出去）  
bi: Blocks received from a block device (blocks/s).  
每秒从块设备接收到的块数，单位：块/秒 也就是读块设备。bi通常是读磁盘的数据  
bo: Blocks sent to a block device (blocks/s).  
每秒发送到块设备的块数，单位：块/秒 也就是写块设备。bo通常是写磁盘的数据  
5）System（系统）  
in: The number of interrupts per second, including the clock.  
每秒的中断数，包括时钟中断。  
cs: The number of context switches per second.  
每秒的环境（上下文）切换次数。比如我们调用系统函数，就要进行上下文切换，而过多的上下文切换会浪费较多的cpu资源，这个数值应该越小越好。  
6）CPU（使用cpu时间的百分比%，最大100%）  
us: Time spent running non-kernel code. (user time, including nice time)  
用户CPU时间(非内核进程占用时间)（单位为百分比）。 us的值比较高时，说明用户进程消耗的CPU时间多  
sy: Time spent running kernel code. (system time)  
系统使用的CPU时间（单位为百分比）。sy的值高时，说明系统内核消耗的CPU资源多，这并不是良性表现，我们应该检查原因。  
id: Time spent idle. Prior to Linux 2.5.41, this includes IO-wait time.  
空闲的CPU的时间(百分比)，在Linux 2.5.41之前，这部分包含IO等待时间。  
wa: Time spent waiting for IO. Prior to Linux 2.5.41, shown as zero.  
等待IO的CPU时间，这个值为0 .这个指标意味着CPU在等待硬盘读写操作的时间，用百分比表示。wait越大则机器io性能就越差。说明IO等待比较严重，这可能由于磁盘大量作随机访问造成，也有可能磁盘出现瓶颈（块操作）。  
st: 虚拟机占用cpu时间的百分比。如果centos系统上运行了kvm虚拟机，而kvm虚拟上又运行了几个虚拟机，那么这个值将显示这个几个正在运行的虚拟机从物理机中窃取CPU运行时间的百分比。

例1：一台4核心，2G内存的服务器，根据vmstat运行的结果，来分析系统中存在的问题。大家一定要认真学习这个4核心，2G内存查找系统瓶颈的思路。只要用心学会这个思路，后期就可以很轻松分析出8核心，16G或8核心，32G服务器的瓶颈。

系统刚开机后，vmstat的状态如下：  
\[root@xuegod120 ~\]\# vmstat 1 10  
![在这里插入图片描述][20190728140916157.png]  
第1列：有一个r，很多次0，说明当前系统中正在运行的程序不多，此值大于cpu核心数的3倍，就可以认为cpu是繁忙的，我们现在是4核，那么大于12，才能说是繁忙的  
第4列：free是物理内存剩余数，默认单位是KB，先剩余1786492KB，大约1.7G，总共2G，所有内存肯定是够用的  
第7/8列：swap是swap内存交换分区使用情况。如果这两列有数据，说明内存不够用了，已经开始使用swap的硬盘空间  
第9/10列：如果io组数据中bi比较大，说明从磁盘中读取内存的数据比较大，即读取磁盘数据多。反之bo比较大，说明从内存中写入到磁盘的数据比较多。  
第13/15列：us是用户太进程使用CPU时间的百分比，如果us列数据比较大，说明用户太进程使用的cpu较多，比如apache、mysql等。id这列是cpu空闲时间百分比，id列最大是100%  
第16列：wa表示等待IO所消耗的cpu百分比。如果wa列较大，达到40%，说明磁盘读写性能很慢了，io有瓶颈了。如果bi列值很大，说明进程在等待写入磁盘的数据时，占用了大量的cpu。

例2：向服务器上传一个大的文件，分析系统使用的资源情况  
![在这里插入图片描述][20190728140921609.png]  
因为我们是将文件上传到服务器，没有读取硬件，只有写入，所以bi的值基本为0；但是bo的值可以看到有明显的变化  
看其它列的数据变化不大，说明cpu、内存、io都可以，压力不大。

例3：拷贝刚刚上传的文件，模拟生产环境下的备份场景  
![在这里插入图片描述][20190728140935986.png]  
因为是复制文件，所以bi和bo的值都很大。即从硬盘到内存和从内存到硬盘的值都很大  
r列的数值不大，说明正在运行的程序不多；  
free列的数据不大，说明内存也是够用的；  
查看us列、sy列的数据也不大，说明使用的cpu占比也不大。单是wa列中间有等待的百分比，说明在复制数据的时候，有大量的进程在等待中，表示磁盘的IO可能不足。

例4：使用ab压测工具，测试服务器的处理性能  
\[root@xuegod120 ~\]\# yum -y install httpd  
\[root@xuegod120 ~\]\# systemctl start httpd  
\[root@xuegod120 ~\]\# cp /etc/passwd /var/www/html/index.html  
\[root@xuegod120 ~\]\# ab -n 500000 -c 200 [http://192.168.0.120/index.html][http_192.168.0.120_index.html]  
![在这里插入图片描述][20190728140943821.png]  
结论：  
r列的数值可以看到有很多已经超过12了，说明cpu的核心不够用。wa列为0，说明在读写磁盘在等待上没有占用cpu，这样情况就是服务器上运行了大量的进程，在消耗cpu。可以使用ps查看是哪个进程在大量消耗cpu资源。  
可以通过top命令，然后按下大写P，对cpu的使用占比进行排序，查看消耗大量cpu进程的名字  
也可以用ps -aux –sort -cpu 命令，直接查看cpu的使用百分比。

二、 有关磁盘I/O调优  
1、 ulimit资源限制  
通过修改配置文件/etc/security/limits.com，修改ulimit的值  
增加内容的格式如下：  
用户名/@用户组名 类型(软限制/硬限制) 选项 值

例1：修改配置文件  
\[root@xuegod120 ~\]\# vim /etc/security/limits.conf \#在文件的最后追加以下内容

*      soft   nofile            1024000
 *      hard   nofile           1024000            #重启系统后生效

注：soft是一个警告值，而hard则是一个真正意义的阀值，超过就会报错。一般把soft和hard都配置成一样的值。 最大打开的文件数以文件描叙符file descripter计数)。

例2：通过命令修改  
查看ulimint的值  
\[root@xuegod120 ~\]\# ulimit -n  
1024

修改ulimit的值  
\[root@xuegod120 ~\]\# ulimit -n 2048 \#临时生效，修改配置文件的是重启系统后永久生效

总结：两种修改ulimit的方式，修改配置的方式，需要重启系统后才能生效。通过命令修改的值，可以立即生效，但是重启系统后会自动丢失  
ulimit -n size ：表示打开进程数的个数限制；  
ulimit -u size ：表示用户启动进程数的限制

例3：查看系统的所有资源  
\[root@xuegod120 ~\]\# ulimit -a  
core file size (blocks, -c) 0 \#kdump转储功能开启后生成的core file文件大小限制  
data seg size (kbytes, -d) unlimited \#数据段大小显示  
scheduling priority (-e) 0  
file size (blocks, -f) unlimited \#文件大小限制  
pending signals (-i) 7834  
max locked memory (kbytes, -l) 64  
max memory size (kbytes, -m) unlimited  
open files (-n) 1024000 \#打开文件个数限制  
pipe size (512 bytes, -p) 8 \#管道文件大小限制  
POSIX message queues (bytes, -q) 819200 \#消息队列大小  
real-time priority (-r) 0  
stack size (kbytes, -s) 8192 \#栈大小  
cpu time (seconds, -t) unlimited \#CPU使用时间限制  
max user processes (-u) 7834 \#最大用户进程数限制  
virtual memory (kbytes, -v) unlimited \#虚拟内存限制  
file locks (-x) unlimited

2、 测试硬盘速度  
hdparm命令是测试磁盘顺序读的速度，dd命令用来测试磁盘顺序写的速度  
hdparm命令常用参数：  
\-t perform device read timings \#不使用预先的数据缓冲, 标示了Linux下没有任何文件系统开销时磁盘可以支持多快的连续数据读取. perform \[pəˈfɔ:m\] \#执行  
–direct Use O\_DIRECT to bypass page cache for timings \#直接绕过缓存进行统计数据  
例1：测试硬盘读速度  
\[root@xuegod120 ~\]\# hdparm -t --direct /dev/sda  
/dev/sda:  
Timing O\_DIRECT disk reads: 3080 MB in 3.08 seconds = 1000.82 MB/sec  
注： 弹出的含意是3.08秒中从硬盘缓存中读3080M，平均每秒读1000.82MB。

例2：测试硬盘写的速度  
\[root@xuegod120 ~\]\# dd if=/dev/zero of=a.txt bs=10M count=100 oflag=direct,nonblock  
100+0 records in  
100+0 records out  
1048576000 bytes (1.0 GB) copied, 9.22881 s, 114 MB/s  
注：在大约9.3S的时间里，生成了1G的数据，IO的写速度为114MB/S，这个值可以多测试几次，取平均值为准。

3、 time命令测试进程运行时间  
例1： 测试dd 命令使用时间和开销  
\[root@xuegod120 ~\]\# time dd if=/dev/zero of=/test.dbf bs=1M count=200  
记录了200+0 的读入  
记录了200+0 的写出  
209715200字节(210 MB)已复制，3.79592 秒，55.2 MB/秒  
real 0m4.225s  
user 0m0.002s  
sys 0m2.624s  
注释：  
1)实际时间(real time): 从command命令行开始执行到运行终止的消逝时间；  
2)用户CPU时间(user CPU time): 命令执行完成花费的用户CPU时间，即命令在用户态中执行时间总和；  
3)系统CPU时间(system CPU time): 命令执行完成花费的系统CPU时间，即命令在核心态中执行时间总和。  
其中，用户CPU时间和系统CPU时间之和为CPU时间，即命令占用CPU执行的时间总和。实际时间要大于CPU时间，因为Linux是多任务操作系统，往往在执行一条命令时，系统还要处理其它任务。排队时间没有算在里面。  
另一个需要注意的问题是即使每次执行相同命令，但所花费的时间也是不一样，其花费时间是与系统运行相关的。

三、 网络相关调优  
1、 网卡绑定技术  
网卡绑定概述：网卡绑定也称作"网卡捆绑"，就是使用多块物理网卡虚拟成为一块网卡，以提供负载均衡或者冗余，增加带宽的作用。当一个网卡坏掉时，不会影响业务。这个聚合起来的设备看起来是一个单独的以太网接口设备，也就是这几块网卡具有相同的IP地址而并行链接聚合成一个逻辑链路工作。这种技术在Cisco等网络公司中，被称为Trunking和Etherchannel 技术，在Linux的内核中把这种技术称为bonding。

2、 bonding技术分类  
2.1 负载均衡  
对于bonding的网络负载均衡是我们在文件服务器中常用到的，比如把三块网卡，当做一块来用，解决一个IP地址，流量过大，服务器网络压力过大的问题。为了解决同一个IP地址，突破流量的限制，毕竟网线和网卡对数据的吞吐量是有限制的。如果在有限的资源的情况下，实现网络负载均衡，最好的办法就是 bonding。

2.2 网络冗余  
对于服务器来说，网络设备的稳定也是比较重要的，特别是网卡。在生产型的系统中，网卡的可靠性就更为重要了。在生产型的系统中，大多通过硬件设备的冗余来提供服务器的可靠性和安全性，比如电源。bonding 也能为网卡提供冗余的支持。把多块网卡绑定到一个IP地址，当一块网卡发生物理性损坏的情况下，另一块网卡自动启用，并提供正常的服务，即：默认情况下只有一块网卡工作，其它网卡做备份。

3、 配置多网卡绑定  
环境准备，给服务器添加两块网卡，并且都配置桥接模式  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MTg0MzY5OQ_size_16_color_FFFFFF_t_70 2]  
实验目标：实现active-backup主备模式，即一个网卡处于活跃状态，另一个处于备份状态，当活跃网卡down掉时，启用备份网卡。绑定网卡：ens33+ens38=bond0。  
设置网卡ens33为主网卡(优先处于活跃状态)，ens38为辅网卡(备份状态，主网卡链路正常时，辅网卡处于备份状态)。

3.1 移除网卡配置文件  
因为两块网卡是绑定在一起使用的，绑定后的使用的配置文件是bond0文件，所以需要移除两块网卡的配置文件  
\[root@xuegod120 ~\]\# cd /etc/sysconfig/network-scripts/  
\[root@xuegod120 network-scripts\]\# mv ifcfg-ens\* /tmp/

3.2 使用nmcli命令配置生成bond0配置文件  
\[root@xuegod120 network-scripts\]\# nmcli connection add type bond ifname bond0 con-name bond0 miimon 100 mode active-backup primary ens33 ipv4.addresses 172.20.10.4/24  
Connection ‘bond0’ (7f8975ab-2b43-45d1-8de2-58eed88be450) successfully added.  
参数说明：  
add type bond ifname bond0 \#添加一个类型为bond，网卡名为bond0的设备  
con-name bond0 miimon 100 \#配置name为bond0的链路监控的频率为100毫秒。  
mode active-backup \#指定bond0模式为active-backup（主动备份）  
primary ens33 \#指定主网卡为ens33  
ipv4.addresses \#指定IP地址为172.20.10.4  
配置完成后，会在网卡配置文件目录下生成一个ifcfg-bond0的配置文件  
\[root@xuegod120 network-scripts\]\# ll ifcfg-bond0  
\-rw-r–r-- 1 root root 383 Jul 27 18:34 ifcfg-bond0

3.3 修改配置文件，增加网关和DNS  
\[root@xuegod63 network-scripts\]\# vim ifcfg-bond0 \#在文件的最后插入网关和DNS  
在第9行之后：  
8 IPADDR=172.20.10.4  
9 PREFIX=24  
插入：  
GATEWAY=172.20.10.1  
DNS1=114.114.114.114

3.4 将网卡ens33绑定到bond0,  
\[root@xuegod120 ~\]\# nmcli connection add type bond-slave ifname ens33 master bond0  
Connection ‘bond-slave-ens33’ (3ed5c762-343b-45e9-9c94-6702e07947ca) successfully added.  
\[root@xuegod120 ~\]\# nmcli connection add type bond-slave ifname ens38 master bond0  
Connection ‘bond-slave-ens38’ (87ffa332-f3ce-4cb8-b088-31b5a98d47cd) successfully added.

3.5 查看配置文件  
\[root@xuegod120 ~\]\# ll /etc/sysconfig/network-scripts/ifcfg-bond\*  
\-rw-r–r-- 1 root root 424 Jul 27 18:40 /etc/sysconfig/network-scripts/ifcfg-bond0  
\-rw-r–r-- 1 root root 125 Jul 27 18:41 /etc/sysconfig/network-scripts/ifcfg-bond-slave-ens33  
\-rw-r–r-- 1 root root 125 Jul 27 18:41 /etc/sysconfig/network-scripts/ifcfg-bond-slave-ens38  
\[root@xuegod120 ~\]\# systemctl restart network

3.6 查看已激活的网络接口  
\[root@xuegod120 ~\]\# nmcli connection show –active  
![在这里插入图片描述][20190728141006820.png]

3.7 查看当前bond0的状态  
\[root@xuegod120 ~\]\# cat /proc/net/bonding/bond0  
Ethernet Channel Bonding Driver: v3.7.1 (April 27, 2011)

Bonding Mode: fault-tolerance (active-backup)  
Primary Slave: ens33 (primary\_reselect always)  
Currently Active Slave: ens33 \#当前使用的端口，状态是active  
MII Status: up  
MII Polling Interval (ms): 100  
Up Delay (ms): 0  
Down Delay (ms): 0

Slave Interface: ens33 \#从接口  
MII Status: up \#链接状态  
Speed: 1000 Mbps  
Duplex: full  
Link Failure Count: 0  
Permanent HW addr: 00:0c:29:8f:23:87  
Slave queue ID: 0

Slave Interface: ens38 \#从接口  
MII Status: up \#链接状态  
Speed: 1000 Mbps  
Duplex: full  
Link Failure Count: 0  
Permanent HW addr: 00:0c:29:8f:23:91  
Slave queue ID: 0  
\[root@xuegod120 ~\]\#

4、 测试bonding主备高可用切换  
持续ping网关，然后断掉其中一块网卡，测试网络是否正常  
![在这里插入图片描述][20190728141015414.png]![在这里插入图片描述][20190728141018866.png]  
如果端口后，发现网络还是正常的，就说明网卡绑定配置成功

5、 查看网卡连接  
\[root@xuegod120 ~\]\# cat /proc/net/bonding/bond0  
Ethernet Channel Bonding Driver: v3.7.1 (April 27, 2011)  
Bonding Mode: fault-tolerance (active-backup)  
Primary Slave: ens33 (primary\_reselect always)  
Currently Active Slave: ens38 \#原来的接口为ens33，目前变为ens38  
。。。  
Slave Interface: ens38  
MII Status: up  
。。。  
Slave Interface: ens33  
MII Status: down \#已经down了

6、 网卡绑定的几种模式  
常用的模式mode是0、1、4、6这几种模式。具体如下：  
balance-rr (0) –轮询模式，负载均衡（bond默认的模式）  
active-backup (1) –主备模式（常用）  
balance-xor (2)  
broadcast (3）  
802.3ad (4) –聚合模式  
balance-tlb (5)  
balance-alb (6)  
详情如下：  
mode=0 \#默认是mode=0, 有高可用 (容错) 和负载均衡的功能, 需要交换机的配置，每块网卡轮询发包 (流量分发比较均衡)，mode 0下bond所绑定的网卡的IP都被修改成相同的mac地址，如果这些网卡都被接在同一个交换机，那么交换机的arp表里这个mac地址对应的端口就有多个，那么交换机接受到发往这个mac地址的包应该往哪个端口转发呢？正常情况下mac地址是全球唯一的，一个mac地址对应多个端口肯定使交换机迷惑了。所以 mode0下的bond如果连接到交换机，交换机这几个端口应该采取聚合方式（cisco称为ethernetchannel），因为交换机做了聚合后，聚合下的几个端口也被捆绑成一个mac地址。若我们不配置，我们的解 决办法是，两个网卡接入不同的交换机即可。  
mode=1 \#只有一个设备处于活动状态，当一个宕掉另一个马上由备份转换为主设备。mac地址是外部可见得，从外面看来，bond的MAC地址是唯一的，以避免switch(交换机)发生混乱。此模式只提供了容错能力；由此可见此算法的优点是可以提供高网络连接的可用性，但是它的资源利用率较低，只有一个接口处于工作状态，在有 N 个网络接口的情况下，资源利用率为1/N  
mode=2 \#基于指定的传输HASH策略传输数据包。缺省的策略是：(源MAC地址 XOR 目标MAC地址) % slave数量。其他的传输策略可以通过xmit\_hash\_policy选项指定，此模式提供负载平衡和容错能力。  
mode=3 \#在每个slave接口上传输每个数据包，此模式提供了容错能力，非常不常用  
mode=4 \#创建一个聚合组，它们共享同样的速率和双工设定。根据802.3ad规范将多个slave工作在同一个激活的聚合体下。外出流量的slave选举是基于传输hash策略，该策略可以通过xmit\_hash\_policy选项从缺省的XOR策略改变到其他策略。需要几个必要条件：  
ethtool支持获取每个slave的速率和双工设定  
switch(交换机)支持IEEE 802.3ad Dynamic link aggregation  
大多数switch(交换机)需要经过特定配置才能支持802.3ad模式  
mode=5 \#不需要任何特别的switch(交换机)支持的通道bonding。在每个slave上根据当前的负载（根据速度计算）分配外出流量。如果正在接受数据的slave出故障了，另一个slave接管失败的slave的MAC地址。该模式的必要条件：ethtool支持获取每个slave的速率  
mode=6 \#模式包含了balance-tlb模式，同时加上针对IPV4流量的接收负载均衡(receive load  
balance, rlb)，而且不需要任何switch(交换机)的支持。接收负载均衡是通过ARP协商实现的。bonding驱动截获本机发送的ARP应答，并把源硬件地址改写为bond中某个slave的唯一硬件地址，从而使得不同的对端使用不同的硬件地址进行通信。来自服务器端的接收流量也会被均衡。当本机发送ARP请求时，bonding驱动把对端的IP信息从ARP包中复制并保存下来。当ARP应答从对端到达 时，bonding驱动把它的硬件地址提取出来，并发起一个ARP应答给bond中的某个slave。使用ARP协商进行负载均衡的一个问题是：每次广播 ARP请求时都会使用bond的硬件地址，因此对端学习到这个硬件地址后，接收流量将会全部流向当前的slave。这个问题可以通过给所有的对端发送更新 （ARP应答）来解决，应答中包含他们独一无二的硬件地址，从而导致流量重新分布。当新的slave加入到bond中时，或者某个未激活的slave重新 激活时，接收流量也要重新分布。接收的负载被顺序地分布（round robin）在bond中最高速的slave上当某个链路被重新接上，或者一个新的slave加入到bond中，接收流量在所有当前激活的slave中全部重新分配，通过使用指定的MAC地址给每个 client起ARP应答。下面介绍的updelay参数必须被设置为某个大于等于switch(交换机)转发延时的值，从而保证发往对端的ARP应答 不会被switch(交换机)阻截。

四、 系统内核相关参数调优  
1、 SYN洪水攻击  
SYN攻击是利用TCP/IP协议3次握手的原理，发送大量的建立连接的网络包，但不实际建立连接，最终导致被攻击服务器的网络队列被占满，无法被正常用户访问。

原理图：  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MTg0MzY5OQ_size_16_color_FFFFFF_t_70 3]  
SYN Flood是当前最流行的DoS（拒绝服务攻击）与DDoS（分布式拒绝服务攻击）的方式之一，这是一种利用TCP协议缺陷，发送大量伪造的TCP连接请求，常用假冒的IP或IP号段发来的海量请求连接的第一个握手包（SYN包），被攻击服务器回应第二个握手包（SYN+ACK包），因为对方是假冒IP，对方永远收不到包且不会回应第三个握手包。导致被攻击服务器保持大量SYN\_RECV状态的“半连接”，并且会重试默认5次回应第二个握手包，塞满TCP等待连接队列，资源耗尽（CPU满负荷或内存不足），让正常的业务请求连接不进来。  
解决：  
\[root@xuegod120 ~\]\# vim /etc/sysctl.conf \#在文件最后添加以下内容  
net.ipv4.tcp\_synack\_retries = 0  
net.ipv4.tcp\_syn\_retries = 1  
net.ipv4.tcp\_max\_syn\_backlog = 20480  
net.ipv4.tcp\_syncookies = 1  
net.ipv4.tcp\_tw\_reuse = 1  
net.ipv4.tcp\_tw\_recycle = 1  
net.ipv4.tcp\_fin\_timeout = 10  
fs.file-max = 819200  
net.core.somaxconn = 65535  
net.core.rmem\_max = 1024123000  
net.core.wmem\_max = 16777216  
net.core.netdev\_max\_backlog = 165536  
net.ipv4.ip\_local\_port\_range = 10000 65535  
注：每台服务器上线之前，都应该配置以上内核参数。

2、 内核重要参数解说  
\[root@xuegod120 ~\]\# cat /proc/sys/net/ipv4/tcp\_synack\_retries \#最关键参数，默认为5，修改为0 表示不要重发  
net.ipv4.tcp\_synack\_retries = 0  
\#表示回应第二个握手包（SYN+ACK包）给客户端IP后，如果收不到第三次握手包（ACK包）后，不进行重试，加快回收“半连接”，不要耗光资源。  
\#作为服务端。回应时，如果连接失败，达到对应的失败数后，停止发送synack包  
第一个参数tcp\_synack\_retries = 0是关键，表示回应第二个握手包（SYN+ACK包）给客户端IP后，如果收不到第三次握手包（ACK包）后，不进行重试，加快回收“半连接”，不要耗光资源。  
不修改这个参数，模拟攻击，10秒后被攻击的80端口即无法服务，机器难以ssh登录； 用命令netstat -na |grep SYN\_RECV检测“半连接”hold住180秒；  
修改这个参数为0，再模拟攻击，持续10分钟后被攻击的80端口都可以服务，响应稍慢些而已，只是ssh有时也登录不上；检测“半连接”只hold住3秒即释放掉。  
修改这个参数为0的副作用：网络状况很差时，如果对方没收到第二个握手包，可能连接服务器失败，但对于一般网站，用户刷新一次页面即可。这些可以在高峰期或网络状况不好时tcpdump抓包验证下。  
根据以前的抓包经验，这种情况很少，但为了保险起见，可以只在被tcp洪水攻击时临时启用这个参数。  
tcp\_synack\_retries默认为5，表示重发5次，每次等待30~40秒，即“半连接”默认hold住大约180秒。  
我们之所以可以把tcp\_synack\_retries改为0，因为客户端还有tcp\_syn\_retries参数，默认是5，即使服务器端没有重发SYN+ACK包，客户端也会重发SYN握手包。  
\[root@xuegod63 ~\]\# cat /proc/sys/net/ipv4/tcp\_syn\_retries  
1  
\#tcp\_syn\_retries参数，默认是5，当没有收到服务器端的SYN+ACK包时，客户端重发SYN握手包的次数。  
\[root@xuegod63 ~\]\# cat /proc/sys/net/ipv4/tcp\_max\_syn\_backlog  
20480  
\#\#半连接队列长度，增加SYN队列长度到2048：加大SYN队列长度可以容纳更多等待连接的网络连接数，具体多少数值受限于内存。

3、 辅助参数  
\#系统允许的文件句柄的最大数目，因为连接需要占用文件句柄  
fs.file-max = 819200  
\#用来应对突发的大并发connect 请求  
net.core.somaxconn = 65535  
\#最大的TCP 数据接收缓冲（字节）  
net.core.rmem\_max = 1024123000  
\#最大的TCP 数据发送缓冲（字节）  
net.core.wmem\_max = 16777216  
\#网络设备接收数据包的速率比内核处理这些包的速率快时，允许送到队列的数据包的最大数目  
net.core.netdev\_max\_backlog = 165536  
\#本机主动连接其他机器时的端口分配范围，比如说，在vsftpd主动模式会用到  
net.ipv4.ip\_local\_port\_range = 10000 65535  
注：如果只是开启22端口，是不会使用到ip\_local\_port\_range这个功能  
\[root@xuegod120 ~\]\# netstat -antup | grep :22  
tcp 0 0 0.0.0.0:22 0.0.0.0:\* LISTEN 1993/sshd  
tcp 0 0 192.168.1.63:22 192.168.1.23:51855 ESTABLISHED 9316/sshd  
tcp 0 0 192.168.1.63:22 192.168.1.23:51861 ESTABLISHED 10878/sshd  
为了处理大量连接，还需改大另外两个参数：  
限制用户资源配置文件：/etc/security/limits.conf  
\[root@xuegod120 ~\]\#vim /etc/security/limits.conf \#在最添加：

*      soft   nofile            1024000
 *      hard   nofile           1024000

例2：nproc \#用户可以打开的最大进程数  
\[root@xuegod120 ~\]\# vim /etc/security/limits.d/90-nproc.conf \#RHEL6 必须这个文件中配置  
改：

*      soft    nproc     10240

为：

*      soft    nproc     66666
 *      hard    nproc     66666

\[root@xuegod120 ~\]\# reboot \#最好重启一下

4、 次要辅助参数  
以上还无法解决syn洪水攻击，把以下内核参数关闭：  
注意，以下参数面对外网时，不要打开。因为副作用很明显。  
\#当出现 半连接 队列溢出时向对方发送syncookies，调大 半连接 队列后没必要  
net.ipv4.tcp\_syncookies = 0  
\#TIME\_WAIT状态的连接重用功能  
net.ipv4.tcp\_tw\_reuse = 0  
\#时间戳选项，与前面net.ipv4.tcp\_tw\_reuse参数配合  
net.ipv4.tcp\_timestamps = 0  
\#TIME\_WAIT状态的连接回收功能  
net.ipv4.tcp\_tw\_recycle = 0  
\[root@xuegod120 ~\]\# cat /proc/sys/net/ipv4/tcp\_syncookies  
1  
\#表示开启SYN Cookies。当出现SYN等待队列溢出时，启用cookies来处理，可防范少量SYN攻击，默认为0，表示关闭；  
\[root@xuegod120 ~\]\# cat /proc/sys/net/ipv4/tcp\_tw\_reuse  
1  
\#表示开启重用。允许将TIME-WAIT sockets重新用于新的TCP连接，默认为0，表示关闭，现在开启，改为1  
\[root@xuegod120 ~\]\# cat /proc/sys/net/ipv4/tcp\_tw\_recycle  
1  
\#表示开启TCP连接中TIME-WAIT sockets的快速回收，默认为0，表示关闭。现在改为1，表示开启  
\[root@xuegod120 ~\]\# cat /proc/sys/net/ipv4/tcp\_fin\_timeout  
30  
\#默认值是 60，对于本端断开的socket连接，TCP保持在FIN\_WAIT\_2状态的时间。

[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MTg0MzY5OQ_size_16_color_FFFFFF_t_70]: /images/20211116/118a397956704c1dbd6cebef8488622b.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MTg0MzY5OQ_size_16_color_FFFFFF_t_70 1]: /images/20211116/636c89ad9e954f1b844007f250471578.png
[20190728140850105.png]: /images/20211116/e3abff4f70a0422d9a53c8a75b20d0c1.png
[20190728140854774.png]: /images/20211116/d0e24793e43948d3a893df66aedcb046.png
[20190728140859654.png]: /images/20211116/f82b997ff7cf48acaa5bc4af32a2c46f.png
[20190728140905598.png]: /images/20211116/2171ce4ddfcc4426b4b06e1a8e10a851.png
[20190728140916157.png]: /images/20211116/554229b31b0c4b62a0604ca85fb198fe.png
[20190728140921609.png]: /images/20211116/44ac76f41d474e5d8c719745de86fca8.png
[20190728140935986.png]: /images/20211116/442995a8e51f49348c8bd99a761bdbda.png
[http_192.168.0.120_index.html]: http://192.168.0.120/index.html
[20190728140943821.png]: /images/20211116/c48e2a79e1314a1e81b0115af046b92e.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MTg0MzY5OQ_size_16_color_FFFFFF_t_70 2]: /images/20211116/0159bdb7f32c41e1b0f6032034e38ce1.png
[20190728141006820.png]: /images/20211116/a101fa723c704f7896a76b772c16ed7c.png
[20190728141015414.png]: https://img-blog.csdnimg.cn/20190728141015414.png
[20190728141018866.png]: /images/20211116/ac77e9e251684faf971ad534e7a85acd.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MTg0MzY5OQ_size_16_color_FFFFFF_t_70 3]: /images/20211116/737d8df65a2c449b8dd404d9c86114cf.png