linux内核优化参数

2024-05-09

1. linux内核优化参数

作为高性能WEB服务器,只调整Nginx本身的参数是不行的,因为Nginx服务依赖于高性能的操作系统。
以下为常见的几个Linux内核参数优化方法。
net.ipv4.tcp_max_tw_buckets
对于tcp连接,服务端和客户端通信完后状态变为timewait,假如某台服务器非常忙,连接数特别多的话,那么这个timewait数量就会越来越大。毕竟它也是会占用一定的资源,所以应该有一个最大值,当超过这个值,系统就会删除最早的连接,这样始终保持在一个数量级。这个数值就是由net.ipv4.tcp_max_tw_buckets这个参数来决定的。CentOS7系统,你可以使用sysctl -a |grep tw_buckets来查看它的值,默认为32768,你可以适当把它调低,比如调整到8000,毕竟这个状态的连接太多也是会消耗资源的。但你不要把它调到几十、几百这样,因为这种状态的tcp连接也是有用的,如果同样的客户端再次和服务端通信,就不用再次建立新的连接了,用这个旧的通道,省时省力。
net.ipv4.tcp_tw_recycle = 1
该参数的作用是快速回收timewait状态的连接。上面虽然提到系统会自动删除掉timewait状态的连接,但如果把这样的连接重新利用起来岂不是更好。所以该参数设置为1就可以让timewait状态的连接快速回收,它需要和下面的参数配合一起使用。
net.ipv4.tcp_tw_reuse = 1
该参数设置为1,将timewait状态的连接重新用于新的TCP连接,要结合上面的参数一起使用。
net.ipv4.tcp_syncookies = 1
tcp三次握手中,客户端向服务端发起syn请求,服务端收到后,也会向客户端发起syn请求同时连带ack确认,假如客户端发送请求后直接断开和服务端的连接,不接收服务端发起的这个请求,服务端会重试多次,这个重试的过程会持续一段时间(通常高于30s),当这种状态的连接数量非常大时,服务器会消耗很大的资源,从而造成瘫痪,正常的连接进不来,这种恶意的半连接行为其实叫做syn flood攻击。设置为1,是开启SYN Cookies,开启后可以避免发生上述的syn flood攻击。开启该参数后,服务端接收客户端的ack后,再向客户端发送ack+syn之前会要求client在短时间内回应一个序号,如果客户端不能提供序号或者提供的序号不对则认为该客户端不合法,于是不会发ack+syn给客户端,更涉及不到重试。
net.ipv4.tcp_max_syn_backlog
该参数定义系统能接受的最大半连接状态的tcp连接数。客户端向服务端发送了syn包,服务端收到后,会记录一下,该参数决定最多能记录几个这样的连接。在CentOS7,默认是256,当有syn flood攻击时,这个数值太小则很容易导致服务器瘫痪,实际上此时服务器并没有消耗太多资源(cpu、内存等),所以可以适当调大它,比如调整到30000。
net.ipv4.tcp_syn_retries
该参数适用于客户端,它定义发起syn的最大重试次数,默认为6,建议改为2。
net.ipv4.tcp_synack_retries
该参数适用于服务端,它定义发起syn+ack的最大重试次数,默认为5,建议改为2,可以适当预防syn flood攻击。
net.ipv4.ip_local_port_range
该参数定义端口范围,系统默认保留端口为1024及以下,以上部分为自定义端口。这个参数适用于客户端,当客户端和服务端建立连接时,比如说访问服务端的80端口,客户端随机开启了一个端口和服务端发起连接,这个参数定义随机端口的范围。默认为32768 61000,建议调整为1025 61000。
net.ipv4.tcp_fin_timeout
tcp连接的状态中,客户端上有一个是FIN-WAIT-2状态,它是状态变迁为timewait前一个状态。该参数定义不属于任何进程的该连接状态的超时时间,默认值为60,建议调整为6。
net.ipv4.tcp_keepalive_time
tcp连接状态里,有一个是established状态,只有在这个状态下,客户端和服务端才能通信。正常情况下,当通信完毕,客户端或服务端会告诉对方要关闭连接,此时状态就会变为timewait,如果客户端没有告诉服务端,并且服务端也没有告诉客户端关闭的话(例如,客户端那边断网了),此时需要该参数来判定。比如客户端已经断网了,但服务端上本次连接的状态依然是established,服务端为了确认客户端是否断网,就需要每隔一段时间去发一个探测包去确认一下看看对方是否在线。这个时间就由该参数决定。它的默认值为7200秒,建议设置为30秒。
net.ipv4.tcp_keepalive_intvl
该参数和上面的参数是一起的,服务端在规定时间内发起了探测,查看客户端是否在线,如果客户端并没有确认,此时服务端还不能认定为对方不在线,而是要尝试多次。该参数定义重新发送探测的时间,即第一次发现对方有问题后,过多久再次发起探测。默认值为75秒,可以改为3秒。
net.ipv4.tcp_keepalive_probes
第10和第11个参数规定了何时发起探测和探测失败后再过多久再发起探测,但并没有定义一共探测几次才算结束。该参数定义发起探测的包的数量。默认为9,建议设置2。设置和范例在Linux下调整内核参数,可以直接编辑配置文件/etc/sysctl.conf,然后执行sysctl -p命令生效

linux内核优化参数

2. linux 内核参数优化

作为高性能WEB服务器,只调整Nginx本身的参数是不行的,因为Nginx服务依赖于高性能的操作系统。
以下为常见的几个Linux内核参数优化方法。
net.ipv4.tcp_max_tw_buckets
对于tcp连接,服务端和客户端通信完后状态变为timewait,假如某台服务器非常忙,连接数特别多的话,那么这个timewait数量就会越来越大。毕竟它也是会占用一定的资源,所以应该有一个最大值,当超过这个值,系统就会删除最早的连接,这样始终保持在一个数量级。这个数值就是由net.ipv4.tcp_max_tw_buckets这个参数来决定的。CentOS7系统,你可以使用sysctl -a |grep tw_buckets来查看它的值,默认为32768,你可以适当把它调低,比如调整到8000,毕竟这个状态的连接太多也是会消耗资源的。但你不要把它调到几十、几百这样,因为这种状态的tcp连接也是有用的,如果同样的客户端再次和服务端通信,就不用再次建立新的连接了,用这个旧的通道,省时省力。
net.ipv4.tcp_tw_recycle = 1
该参数的作用是快速回收timewait状态的连接。上面虽然提到系统会自动删除掉timewait状态的连接,但如果把这样的连接重新利用起来岂不是更好。所以该参数设置为1就可以让timewait状态的连接快速回收,它需要和下面的参数配合一起使用。
net.ipv4.tcp_tw_reuse = 1
该参数设置为1,将timewait状态的连接重新用于新的TCP连接,要结合上面的参数一起使用。
net.ipv4.tcp_syncookies = 1
tcp三次握手中,客户端向服务端发起syn请求,服务端收到后,也会向客户端发起syn请求同时连带ack确认,假如客户端发送请求后直接断开和服务端的连接,不接收服务端发起的这个请求,服务端会重试多次,这个重试的过程会持续一段时间(通常高于30s),当这种状态的连接数量非常大时,服务器会消耗很大的资源,从而造成瘫痪,正常的连接进不来,这种恶意的半连接行为其实叫做syn flood攻击。设置为1,是开启SYN Cookies,开启后可以避免发生上述的syn flood攻击。开启该参数后,服务端接收客户端的ack后,再向客户端发送ack+syn之前会要求client在短时间内回应一个序号,如果客户端不能提供序号或者提供的序号不对则认为该客户端不合法,于是不会发ack+syn给客户端,更涉及不到重试。
net.ipv4.tcp_max_syn_backlog
该参数定义系统能接受的最大半连接状态的tcp连接数。客户端向服务端发送了syn包,服务端收到后,会记录一下,该参数决定最多能记录几个这样的连接。在CentOS7,默认是256,当有syn flood攻击时,这个数值太小则很容易导致服务器瘫痪,实际上此时服务器并没有消耗太多资源(cpu、内存等),所以可以适当调大它,比如调整到30000。
net.ipv4.tcp_syn_retries
该参数适用于客户端,它定义发起syn的最大重试次数,默认为6,建议改为2。
net.ipv4.tcp_synack_retries
该参数适用于服务端,它定义发起syn+ack的最大重试次数,默认为5,建议改为2,可以适当预防syn flood攻击。
net.ipv4.ip_local_port_range
该参数定义端口范围,系统默认保留端口为1024及以下,以上部分为自定义端口。这个参数适用于客户端,当客户端和服务端建立连接时,比如说访问服务端的80端口,客户端随机开启了一个端口和服务端发起连接,这个参数定义随机端口的范围。默认为32768 61000,建议调整为1025 61000。
net.ipv4.tcp_fin_timeout
tcp连接的状态中,客户端上有一个是FIN-WAIT-2状态,它是状态变迁为timewait前一个状态。该参数定义不属于任何进程的该连接状态的超时时间,默认值为60,建议调整为6。
net.ipv4.tcp_keepalive_time
tcp连接状态里,有一个是established状态,只有在这个状态下,客户端和服务端才能通信。正常情况下,当通信完毕,客户端或服务端会告诉对方要关闭连接,此时状态就会变为timewait,如果客户端没有告诉服务端,并且服务端也没有告诉客户端关闭的话(例如,客户端那边断网了),此时需要该参数来判定。比如客户端已经断网了,但服务端上本次连接的状态依然是established,服务端为了确认客户端是否断网,就需要每隔一段时间去发一个探测包去确认一下看看对方是否在线。这个时间就由该参数决定。它的默认值为7200秒,建议设置为30秒。
net.ipv4.tcp_keepalive_intvl
该参数和上面的参数是一起的,服务端在规定时间内发起了探测,查看客户端是否在线,如果客户端并没有确认,此时服务端还不能认定为对方不在线,而是要尝试多次。该参数定义重新发送探测的时间,即第一次发现对方有问题后,过多久再次发起探测。默认值为75秒,可以改为3秒。
net.ipv4.tcp_keepalive_probes
第10和第11个参数规定了何时发起探测和探测失败后再过多久再发起探测,但并没有定义一共探测几次才算结束。该参数定义发起探测的包的数量。默认为9,建议设置2。设置和范例在Linux下调整内核参数,可以直接编辑配置文件/etc/sysctl.conf,然后执行sysctl -p命令生效。

3. Linux安全优化和内核参数优化方案有那些?

入口安全优化
ssh配置优化
修改之前,需要将/etc/ssh/sshd_config备份一个,比如/etc/ssh/sshd_config.old, 主要优化如下参数:
Port 12011PermitRootLogin noUseDNS no#防止ssh客户端超时#ClientAliveInterval 30ClientAliveCountMax 99GSSAuthentication no
主要目的更改ssh远程端口、禁用root远程登录(本地还是可以root登录的)、禁用dns、防止ssh超时、解决ssh慢,当然也可以启用密钥登录,这个根据公司需求。
注意:修改以后需重启ssh生效,另外需要iptables放行最新ssh端口。
iptables优化
原则:用到哪些放行哪些,不用的一律禁止。
举下简单的例子:敏感服务比如mysql这种3306控制,默认禁止远程,确实有必要可以放行自己指定IP连接或者通过vpn拨号做跳板连接,不可直接放置于公网; 如单位有自己的公网IP或固定IP,那只允许自己的公网IP进行连接ssh或者指定服务端口就更好了。
用户权限以及系统安全优化
非root用户添加以及sudo权限控制
用户配置文件锁定
服务控制
默认无关服务都禁止运行并chkconfig xxx off,只保留有用服务。这种如果是云计算厂商提供的,一般都是优化过。如果是自己安装的虚拟机或者托管的机器,那就需要优化下,默认只保留network、sshd、iptables、crond、以及rsyslog等必要服务,一些无关紧要的服务就可以off掉了,
内核参数优化
进程级文件以及系统级文件句柄数量参数优化
默认ulinit -n看到的是1024,这种如果系统文件开销量非常大,那么就会遇到各种报错比如:
localhost kernel: VFS: file-max limit 65535 reached 或者too many open files 等等,那就是文件句柄打开数量已经超过系统限制,就需要优化了。
这个参数我们进程级优化文件如下:
vim /etc/security/limits.conf# End of file* soft nofile 65535* hard nofile 65535* soft nproc 65535* hard nproc 65535
好了,退出当前终端以后重新登录可以看到ulimit -n已经改成了65535。另外需要注意,进程级参数优化还需要修改文件:
/etc/security/limits.d/90-nproc.conf 这个会影响到参数。查看某一个进程的limits可以通过cat /proc/pid/limits查看。默认这个文件参数推荐设置:
[root@21yunwei 9001]# cat    /etc/security/limits.d/90-nproc.conf*          soft    nproc     65535root       soft    nproc     unlimited
系统级文件句柄优化
修改/etc/sysctl.conf添加如下参数:
fs.file-max=65535
内核参数优化(这个是非常重要的)。具体优化的文件为/etc/sysctl.conf,后尾追加优化参数:
net.ipv4.neigh.default.gc_stale_time=120net.ipv4.conf.all.rp_filter=0net.ipv4.conf.default.rp_filter=0net.ipv4.conf.default.arp_announce = 2net.ipv4.conf.all.arp_announce=2net.core.netdev_max_backlog =  32768net.core.somaxconn = 32768net.core.wmem_default = 8388608net.core.rmem_default = 8388608net.core.rmem_max = 16777216net.core.wmem_max = 16777216net.ipv4.conf.lo.arp_announce=2net.ipv4.tcp_synack_retries = 2  
#参数的值决定了内核放弃连接之前发送SYN+ACK包的数量。
net.ipv4.tcp_syn_retries = 1 
#表示在内核放弃建立连接之前发送SYN包的数量。
net.ipv4.tcp_max_syn_backlog = 262144
#这个参数表示TCP三次握手建立阶段接受SYN请求列队的最大长度,默认1024,将其设置的大一些可以使出现Nginx繁忙来不及accept新连接的情况时,Linux不至于丢失客户端发起的链接请求。
设置完以后执行命令sysctl -p使得配置新配置的内核参数生效。系统优化这个内核对系统本身安全以及高并发都非常的有效(可以解决大量TIME_WAIT带来的无法访问使用、系统文件句柄数量超出等等)。
net.ipv4.tcp_timestamps = 1  #开启时间戳,配合tcp复用。如遇到局域网内的其他机器由于时间戳不同导致无法连接服务器,有可能是这个参数导致。注:阿里的slb会清理掉tcp_timestampsnet.ipv4.tcp_tw_recycle = 1 #这个参数用于设置启用timewait快速回收net.ipv4.tcp_max_tw_buckets = 6000 #参数设置为 1 ,表示允许将TIME_WAIT状态的socket重新用于新的TCP链接,该参数默认为180000,过多的TIME_WAIT套接字会使Web服务器变慢。net.ipv4.tcp_mem = 94500000 915000000 927000000 net.ipv4.tcp_fin_timeout = 1 #当服务器主动关闭链接时,选项决定了套接字保持在FIN-WAIT-2状态的时间。默认值是60秒。net.ipv4.tcp_keepalive_time = 600 #当keepalive启动时,TCP发送keepalive消息的频度;默认是2小时,将其设置为10分钟,可以更快的清理无效链接。net.ipv4.ip_local_port_range = 1024 65000#定义UDP和TCP链接的本地端口的取值范围。fs.file-max=65535  #表示最大可以打开的句柄数;
设置完以后执行命令sysctl -p使得配置新配置的内核参数生效。这个内核对系统本身安全以及高并发都非常的有效(可以解决大量TIME_WAIT带来的无法访问使用、系统文件句柄数量超出等等)。

Linux安全优化和内核参数优化方案有那些?

4. linux性能调优都有哪几种方法?

1、为磁盘I/O调整Linux内核电梯算法
在选择文件系统后,有一些内核和挂载选项可能会影响到它的性能表现,其中一个内核设置是电梯算法,通过此算法,系统可以平衡低延迟需求,收集足够的数据,从而有效地组织对磁盘的读和写请求。
2、禁用不必要的守护进程
服务器上有很多守护进程或服务不是必需的,这些服务不但没有发挥作用,还消耗了一定的内存和CPU,因此,需要将它们从服务器移除,这一步最大的好处就是可以加快启动时间,释放内存。
3、关掉GUI
一般来说,Linux服务器是不需要GUI的,所以管理任务都可以在命令行下完成,因此最好关掉GUI。
4、清理不需要的模块或功能
在服务器软件包中有太多被启动的功能或模块实际上是不需要的,仔细看看Apache配置文件,确定FrontPage支持或其它额外的模块是否真的要用到,如果不需要,应该毫不犹豫地从服务器禁用掉,这样有助于提高系统内存可用量,腾出更多资源给那些真正需要的软件,让它们运行得更快。
5、禁用控制面板
在Linux中,有许多流行的控制面板,如Cpanel,Plesk,Webmin和phpMyAdmin等,但是,禁用掉这些软件包可以释放出大约120MB内存,它们可以通过PHP脚本(尽管有些不安全),或命令行命令启用,这样做后,内存使用量大约可以下降30-40%。
6、改善Linux Exim服务器性能
7、使用AES256增强gpg文件加密安全
为了提高备份文件或敏感信息的安全,许多Linux系统管理员都会使用gpg进行加密,它是一个开放的加密算法,没有什么比它更安全的了。
8、远程备份服务安全
安全是选择远程备份服务最重要的因素,大多数系统管理员都害怕两件事:(黑客)可以删除备份文件,不能从备份恢复系统。为了保证备份文件100%的安全,备份服务公司提供远程备份服务器,使用scp脚本或RSYNC通过SSH传输数据,这样,没有人可以直接进入和访问远程系统,因此,也没有人可以从备份服务删除数据。在选择远程备份服务提供商时,最好从多个方面了解其服务强壮性,如果可以,可以亲自测试一下。

5. Linux性能优化实战(一)

 系统变慢首先想到的两个命令top和uptime
    平均负载 :简单来说就是单位时间内系统处于 可运行状态 和 不可中断状态 的平均进程数,也就是 平均活跃进程数 。
    可运行状态     处于Runable状态的进程,进程状态标志为R
    不可中断状态   一般是等待I/O的进程,进程状态标志位D
   平均负载理想的情况为cpu的核数,查询cpu核数通过top命令或者从/proc/cpuinfo中读取。
    平均负载与CPU使用率 
   CPU使用率是指单位时间内CPU繁忙情况的统计,而平均负载还包含了不可中断的进程(实际并未使用CPU)
    工具篇 
   stress是一个linux系统压力测试工具,可以用来模拟系统负载升高的场景
   sysstat包含了linux常用的性能监控分析工具
    背景 
   Linux是个多任务操作系统,在执行远大于CPU核数的任务时,任务并不是同时进行的,而是操作系统根据调度算法将CPU轮流分配给多个任务执行。
    由此任务从哪里开始加载,又从哪里开始执行? 
    这就需要引入  CPU 寄存器和程序计数器(Program Counter,PC) 
    CPU寄存器: CUP内容量小速度极快的内存
    程序计数器: 用于存储正在执行的指令位置或者即将执行的下一条指令位置
   CPU寄存器和程序计数器是CPU运行任何任务前必须依赖的环境因此也叫 CPU上下文    
                                           
   先把前一个任务的CPU上下文(也就是CPU寄存器和程序计数器)保存起来,然后加载新任务的上下文并跳转到新任务程序计数器所指位置开始执行新任务的过程。
    Linux权限等级 
   ​       拥有最高的权限等级,可以访问系统内所有资源
   ​       只能访问受限资源,不能直接访问硬件设备,需要通过系统调用才能间访问特权设备   
                                           
   进程既可能在用户空间运行,此时称作 用户态 ,又可能在在内核空间运行此时称作 内核态 ,进程一旦发生 系统调用 就需要从用户态切换到内核态,调用完成后又要从内核态切换回用户态。所以一次系统调用会  至少发生两次CPU上下文切换  
   系统调用发生的上下文切换实际上还是在同一个进程内,所以不会涉及到虚拟内存等进程资源的切换,因此也叫 特权模式切换 注意与进程上下文切换区分
    CPU上下文切换类型 
                                            怎么查看CPU上下文切换? 
   VMSTAT是一款常用的系统性能分析工具,主要用来分析系统的内存使用情况、也常用来分析CPU上下文切换和中断的次数。下面为使用示例:
   重点关注以下4列
   cs(context switch)是每秒上下文切换的次数。
   in(interrupt)则是每秒中断的次数。
   r(Running or Runnable)是就绪队列的长度,也就是正在运行和等待CPU的进程数。
   b(Blocked)则是处于不可中断睡眠状态的进程数。
   VMSTAT只能给出系统总体的上下文切换情况,想要查看每个进程的详细切换情况,就要使用pidstat命令了,加上-w选项。
   cswch ,表示每秒自愿上下文切换(voluntary context switches)的次数
   nvcswch ,表示每秒非自愿上下文切换(non voluntary context switches)的次数
    自愿上下文切换 指进程无法获取到资源导致的切换,如等待IO、内存等系统资源时
    非自愿上下文切换 指大量进程争抢CPU时,由于时间片已到等原因,被迫发生的切换
    pidstat使用举例 
    如何查看中断次数? 
   因为中断发生在内核态,所以不能通过pidstat查看,需要从/proc/interrupts 这个只读文件中读取。/proc 实际上是 Linux 的一个虚拟文件系统,用于内核空间与用户空间之间的通信。/proc/interrupts就是这种通信机制的一部分,提供了一个只读的中断使用情况。
    此为个人笔记,不涉及其他,仅做参考 

Linux性能优化实战(一)

6. linux 性能优化-- cpu 切换以及cpu过高

 本文先介绍了cpu上下文切换的基础知识,以及上下文切换的类型(进程,线程等切换)。然后介绍了如何查看cpu切换次数的工具和指标的解释。同时对日常分析种cpu过高的情况下如何分析和定位的方法做了一定的介绍,使用一个简单的案例进行分析,先用top,pidstat等工具找出占用过高的进程id,然后通过分析到底是用户态cpu过高,还是内核态cpu过高,并用perf 定位到具体的调用函数。(来自极客时间课程学习笔记)
   1、多任务竞争CPU,cpu变换任务的时候进行CPU上下文切换(context switch)。CPU执行任务有4种方式:进程、线程、或者硬件通过触发信号导致中断的调用。
   2、当切换任务的时候,需要记录任务当前的状态和获取下一任务的信息和地址(指针),这就是上下文的内容。因此,上下文是指某一时间点CPU寄存器(CPU register)和程序计数器(PC)的内容, 广义上还包括内存中进程的虚拟地址映射信息.
   3、上下文切换的过程:
   4、根据任务的执行形式,相应的下上文切换,有进程上下文切换、线程上下文切换、以及中断上下文切换三类。
   5、进程和线程的区别:   进程是资源分配和执行的基本单位;线程是任务调度和运行的基本单位。线程没有资源,进程给指针提供虚拟内存、栈、变量等共享资源,而线程可以共享进程的资源。
   6、进程上下文切换:是指从一个进程切换到另一个进程。
   (1)进程运行态为内核运行态和进程运行态。内核空间态资源包括内核的堆栈、寄存器等;用户空间态资源包括虚拟内存、栈、变量、正文、数据等
   (2)系统调用(软中断)在内核态完成的,需要进行2次CPU上下文切换(用户空间-->内核空间-->用户空间),不涉及用户态资源,也不会切换进程。
   (3)进程是由内核来管理和调度的,进程的切换只能发生在内核态。所以,进程的上下文不仅包括了用户空间的资源,也包括内核空间资源。
   (4)进程的上下文切换过程:
   (5)、下列将会触发进程上下文切换的场景:
   7、线程上下文切换:
   8、中断上下文切换   快速响应硬件的事件,中断处理会打断进程的正常调度和执行。同一CPU内,硬件中断优先级高于进程。切换过程类似于系统调用的时候,不涉及到用户运行态资源。但大量的中断上下文切换同样可能引发性能问题。
   重点关注信息:
   系统的就绪队列过长,也就是正在运行和等待 CPU 的进程数过多,导致了大量的上下文切换,而上下文切换又导致了系统 CPU 的占用率升高。
   这个结果中有两列内容是我们的重点关注对象。一个是   cswch   ,表示每秒自愿上下文切换(voluntary context switches)的次数,另一个则是   nvcswch   ,表示每秒非自愿上下文切换(non voluntary context switches)的次数。
   linux的中断使用情况可以从 /proc/interrupts 这个只读文件中读取。/proc 实际上是 Linux 的一个虚拟文件系统,用于内核空间与用户空间之间的通信。/proc/interrupts 就是这种通信机制的一部分,提供了一个只读的中断使用情况。
   重调度中断(RES),这个中断类型表示,唤醒空闲状态的 CPU 来调度新的任务运行。这是多处理器系统(SMP)中,调度器用来分散任务到不同 CPU 的机制,通常也被称为处理器间中断(Inter-Processor Interrupts,IPI)。
   这个数值其实取决于系统本身的 CPU 性能。如果系统的上下文切换次数比较稳定,那么从数百到一万以内,都应该算是正常的。但当上下文切换次数超过一万次,或者切换次数出现数量级的增长时,就很可能已经出现了性能问题。这时,需要根据上下文切换的类型,再做具体分析。
   比方说:
   首先通过uptime查看系统负载,然后使用mpstat结合pidstat来初步判断到底是cpu计算量大还是进程争抢过大或者是io过多,接着使用vmstat分析切换次数,以及切换类型,来进一步判断到底是io过多导致问题还是进程争抢激烈导致问题。
   CPU 使用率相关的重要指标:
   性能分析工具给出的都是间隔一段时间的平均 CPU 使用率,所以要注意间隔时间的设置,特别是用多个工具对比分析时,你一定要保证它们用的是相同的间隔时间。比如,对比一下 top 和 ps 这两个工具报告的 CPU 使用率,默认的结果很可能不一样,因为 top 默认使用 3 秒时间间隔,而 ps 使用的却是进程的整个生命周期。
   top 和 ps 是最常用的性能分析工具:
   这个输出结果中,第三行 %Cpu 就是系统的 CPU 使用率,top 默认显示的是所有 CPU 的平均值,这个时候你只需要按下数字 1 ,就可以切换到每个 CPU 的使用率了。继续往下看,空白行之后是进程的实时信息,每个进程都有一个 %CPU 列,表示进程的 CPU 使用率。它是用户态和内核态 CPU 使用率的总和,包括进程用户空间使用的 CPU、通过系统调用执行的内核空间 CPU 、以及在就绪队列等待运行的 CPU。在虚拟化环境中,它还包括了运行虚拟机占用的 CPU。
   预先安装 stress 和 sysstat 包,如 apt install stress sysstat。
   stress 是一个 Linux 系统压力测试工具,这里我们用作异常进程模拟平均负载升高的场景。而 sysstat 包含了常用的 Linux 性能工具,用来监控和分析系统的性能。我们的案例会用到这个包的两个命令 mpstat 和 pidstat。
   下面的 pidstat 命令,就间隔 1 秒展示了进程的 5 组 CPU 使用率,
   包括:
   perf 是 Linux 2.6.31 以后内置的性能分析工具。它以性能事件采样为基础,不仅可以分析系统的各种事件和内核性能,还可以用来分析指定应用程序的性能问题。
   第一种常见用法是 perf top,类似于 top,它能够实时显示占用 CPU 时钟最多的函数或者指令,因此可以用来查找热点函数,使用界面如下所示:
   输出结果中,第一行包含三个数据,分别是采样数(Samples)如2K、事件类型(event)如cpu-clock:pppH和事件总数量(Event count)如:371909314。
   第二种常见用法,也就是 perf record 和 perf report。 perf top 虽然实时展示了系统的性能信息,但它的缺点是并不保存数据,也就无法用于离线或者后续的分析。而 perf record 则提供了保存数据的功能,保存后的数据,需要你用 perf report 解析展示。
   1.启动docker 运行进程:
   2.ab工具测试服务器性能   ab(apache bench)是一个常用的 HTTP 服务性能测试工具,这里用来模拟 Ngnix 的客户端。
   3.分析过程
   CPU 使用率是最直观和最常用的系统性能指标,在排查性能问题时,通常会关注的第一个指标。所以更要熟悉它的含义,尤其要弄清楚:
   这几种不同 CPU 的使用率。比如说:
   碰到 CPU 使用率升高的问题,你可以借助 top、pidstat 等工具,确认引发 CPU 性能问题的来源;再使用 perf 等工具,排查出引起性能问题的具体函数.