Linux性能优化实战

这篇具有很好参考价值的文章主要介绍了Linux性能优化实战。希望对大家有所帮助。如果存在错误或未考虑完全的地方,请大家不吝赐教,您也可以点击"举报违法"按钮提交疑问。

1. TCP/IP报文详解

  • TCP/IP 定义了电子设备如何连入因特网,以及数据如何在它们之间传输的标准。协议采用了4层的层级结构,每一层都呼叫它的下一层所提供的协议来完成自己的需求。
  • TCP负责发现传输的问题,一有问题就发出信号,要求重新传输,直到所有数据安全正确地传输到目的地,而IP是给因特网的每台联网设备规定一个地址。TCP/IP 协议数据封装的过程包括:用户数据经过应用层协议封装后传递给传输层,传输层封装TCP头部,交给网络层,网络层封装IP头部后,再交给数据链路层,数据链路层封装Ethernet帧头和帧尾,交给物理层,物理层以比特流的形式将数据发送到物理线路上
  • 一般而言,不同的协议层对数据包有不同的称谓,数据包在传输层叫做段(segment),在网络层叫做数据报(datagram),在链路层叫做帧(frame)。数据封装成帧后发到传输介质上,到达目的主机后每层协议再剥掉相应的首部,最后将应用层数据交给应用程序处理,如图所示:
    Linux性能优化实战
  • 优化Linux服务器,需要了解TCP协议相关信息,例如TCP/IP数据报文的内容及如何传输的,如图所示为IP数据包报文详细结构图:
    Linux性能优化实战
  • IP数据包详解如下:
名称 解释
Source Port和Destination Port 分别占用16位,表示源端口号和目的端口号;用于区别主机中的不同进程,而IP地址是用来区分不同的主机的,源端口号和目的端口号配合上IP首部中的源IP地址和目的IP地址就能唯一的确定一个TCP连接
Sequence Number 用来标识从TCP发端向TCP收端发送的数据字节流,它表示在这个报文段中的的第一个数据字节在数据流中的序号;主要用来解决网络报乱序的问题
Acknowledgment Number 32位确认序列号包含发送确认的一端所期望收到的下一个序号,因此,确认序号应当是上次已成功收到数据字节序号Seq加1。不过,只有当标志位中的ACK标志(下面介绍)为1时该确认序列号的字段才有效。主要用来解决不丢包的问题;ACK= seq + 1
Offset 给出首部中32 bit字的数目,需要这个值是因为任选字段的长度是可变的。这个字段占4bit(最多能表示15个32bit的的字,即4*15=60个字节的首部长度),因此TCP最多有60字节的首部。然而,没有任选字段,正常的长度是20字节
TCP Flags TCP首部中有6个标志比特,它们中的多个可同时被设置为1,主要是用于操控TCP的状态机的,依次为URG,ACK,PSH,RST,SYN,FIN
URG 此标志表示TCP包的紧急指针域(后面马上就要说到)有效,用来保证TCP连接不被中断,并且督促中间层设备要尽快处理这些数据
ACK 此标志表示应答域有效,就是说前面所说的TCP应答号将会包含在TCP数据包中;有两个取值:0和1,为1的时候表示应答域有效,反之为0
PSH 这个标志位表示Push操作所谓Push操作就是指在数据包到达接收端以后,立即传送给应用程序,而不是在缓冲区中排队
RST 这个标志表示连接复位请求用来复位那些产生错误的连接,也被用来拒绝错误和非法的数据包
SYN 表示同步序号,用来建立连接。SYN标志位和ACK标志位搭配使用,当连接请求的时候,SYN=1,ACK=0;连接被响应的时候,SYN=1,ACK=1;这个标志的数据包经常被用来进行端口扫描。扫描者发送一个只有SYN的数据包,如果对方主机响应了一个数据包回来 ,就表明这台主机存在这个端口;但是由于这种扫描方式只是进行TCP三次握手的第一次握手,因此这种扫描的成功表示被扫描的机器不很安全,一台安全的主机将会强制要求一个连接严格的进行TCP的三次握手
FIN 表示发送端已经达到数据末尾,也就是说双方的数据传送完成,没有数据可以传送了,发送FIN标志位的TCP数据包后,连接将被断开。这个标志的数据包也经常被用于进行端口扫描
Window: 窗口大小,也就是有名的滑动窗口,用来进行流量控制

2. TCP三次握手及四次断开

  • TCP是面向连接的,无论哪一方向另一方发送数据之前,都必须先在双方之间建立一条连接。在TCP/IP协议中,TCP协议提供可靠的连接服务,连接是通过三次握手进行初始化的。三次握手的目的是同步连接双方的序列号和确认号并交换TCP窗口大小信息。如图所示:
    Linux性能优化实战

2.1. TCP三次握手原理

  • 第一次握手:建立连接。客户端发送连接请求报文段,将SYN位置为1,Sequence Number为x;然后客户端进入SYN_SENT状态,等待服务器的确认;
  • 第二次握手:服务器收到SYN报文段。服务器收到客户端的SYN报文段,需要对这个SYN报文段进行确认,设置Acknowledgment Number为x+1(Sequence Number+1);同时,自己自己还要发送SYN请求信息,将SYN位置为1,Sequence Number为y;服务器端将上述所有信息放到一个报文段(即SYN+ACK报文段)中,一并发送给客户端,此时服务器进入SYN_RECV状态;
  • 第三次握手:客户端收到服务器的SYN+ACK报文段。然后将Acknowledgment Number设置为y+1或者1,向服务器发送ACK报文段,这个报文段发送完毕以后,客户端和服务器端都进入ESTABLISHED状态,完成TCP三次握手
  • 如图所示为基于tcpdump抓取TCP/IP三次握手及数据包传输过程:

Linux性能优化实战

2.2. TCP四次挥手原理

  • 第一次挥手:主机A(可以使客户端,可以是服务器端),设置Sequence Number和Acknowledgment Number,向主机B发送一个FIN报文段;此时,主机A进入FIN_WAIT_1状态;这表示主机A没有数据要发送给主机B;
  • 第二次挥手:主机B收到了主机A发送的FIN报文段,向主机A回一个ACK报文段,Acknowledgment Number为Sequence Number加1;主机A进入FIN_WAIT_2状态;主机B告诉主机A,我“同意”你的关闭请求;
  • 第三次挥手:主机B向主机A发送FIN报文段,请求关闭连接,同时主机B进入LAST_ACK状态;
  • 第四次挥手:主机A收到主机B发送的FIN报文段,向主机B发送ACK报文段,然后主机A进入TIME_WAIT状态;主机B收到主机A的ACK报文段以后,就关闭连接;此时,主机A等待2MSL后依然没有收到回复,则证明Server端已正常关闭,那好,主机A也可以关闭连接。
  • 如图所示为基于tcpdump抓取TCP/IP四次挥手及数据包传输过程:

Linux性能优化实战

3. 优化Linux文件打开最大数

  • 为了防止失控的进程破坏系统的性能,Unix和Linux会跟踪进程使用的大部分资源,并允许用户和系统管理员使用对进程的资源限制,例如控制某个进程打开的系统文件数、对某个用户打开系统进程数进行限制等,一般限制手段包括:软限制和硬限制。
  • 软限制(soft limit)是内核实际执行的限制,任何进程都可以将软限制设置为任意小于等于对进程限制的硬限制的值,(noproc)最大线程数和(nofile)文件数;
  • 硬限制(hard limit)是可以在任何时候任何进程中设置,但硬限制只能由超级用户修改。
  • Linux系统一切皆文件,对Linux进行各种操作,其实是对文件进行操作,文件可分为:普通文件、目录文件、链接文件和设备文件。而文件描述符(file descriptor)是Linux系统为了高效管理已被打开的文件所创建的索引,其值一个非负整数(通常是小整数),用于指代被打开的文件,所有执行I/O操作的系统调用都通过文件描述符。
  • Linux系统默认已经打开的文件描述符包括:STDIN_FILENO 0表示标准输入、STDOUT_FILENO 1表示标准输出、STDERR_FILENO 2表示标准错误输出,默认打开一个新文件,它的文件描述符为3。
  • 每个文件描述符与一个打开文件相对应,不同的文件描述符可以指向同一个文件。相同的文件可以被不同的进程打开,也可以在同一个进程中被多次打开。
  • Linux系统为每个进程维护了一个文件描述符表,该表的值都从0开始的,在不同的进程中你会看到相同的文件描述符,相同文件描述符有可能指向同一个文件,也有可能指向不同的文件。Linux内核对文件操作,维护了3个数据结构概念如下:
  1. 进程级的文件描述符表;
  2. 系统级的打开文件描述符表;
  3. 文件系统的i-node表;
  • 其中进程级的描述符表的每一个条目记录了单个文件描述符的相关信息,例如控制文件描述符操作的一组标志及对打开文件句柄的引用。Linux内核对所有打开的文件都维护了一个系统级的描述符表(open file description table)。将描述符表中的记录行称为打开文件句柄(open file handle),一个打开文件句柄存储了与一个打开文件相关的全部信息,详细信息如下:
  1. 当前文件偏移量
  2. 打开文件时所使用的状态标识
  3. 文件访问模式
  4. 与信号驱动相关的设置
  5. 对该文件i-node对象的引用
  6. 文件类型和访问权限
  7. 指针,指向该文件所持有的锁列表
  8. 文件的各种属性
  • 默认Linux内核对每个用户设置了打开文件最大数为1024,对于高并发网站,是远远不够的,需要将默认值调整到更大,调整方法有两种:
  • Linux每个用户打开文件最大数临时设置方法,重启服务器该参数无效,命令行终端执行如下命令:
[root@node1 ~]# ulimit   -SHn  65535
[root@node1 ~]# ulimit -n
65535
  • inux每个用户打开文件最大数永久设置方法,将如下代码加入内核限制文件/etc/security/limits.conf的末尾:
[root@node1 ~]# vim /etc/security/limits.conf
在末尾添加下面内容
* 	soft 	noproc			65535
* 	hard 	noproc			65535
* 	soft 	nofile			65535
* 	hard 	nofile			65535

  • 如上设置为对每个用户分别设置nofile、noproc最大数,如果需要对Linux整个系统设置文件最大数限制,需要修改/proc/sys/fs/file-max中的值,该值为Linux总文件打开数,例如设置为:
echo 3865161233 >/proc/sys/fs/file-max

4. 内核参数的优化

  • Linux /proc/sys目录下存放着多数内核的参数,并且可以在系统运行时进行更改,一般重新启动机器就会失效。而/etc/sysctl.conf是一个允许改变正在运行中的Linux系统的接口,它包含一些TCP/IP堆栈和虚拟内存系统的高级选项,修改内核参数永久生效。
  • /proc/sys下内核文件与配置文件sysctl.conf中变量存在着对应关系,即修改sysct.conf配置文件,其实是修改/proc/sys相关参数,所以对Linux内核优化只需修改/etc/sysctl.conf文件即可。如下为BAT企业生产环境
/etc/sysct.conf内核完整参数:
net.ipv4.ip_forward = 0
net.ipv4.conf.default.rp_filter = 1
net.ipv4.conf.default.accept_source_route = 0
kernel.sysrq = 0
kernel.core_uses_pid = 1
net.ipv4.tcp_syncookies = 1
kernel.msgmnb = 65536
kernel.msgmax = 65536
kernel.shmmax = 68719476736
kernel.shmall = 4294967296
net.ipv4.tcp_max_tw_buckets = 10000
net.ipv4.tcp_sack = 1
net.ipv4.tcp_window_scaling = 1
net.ipv4.tcp_rmem = 4096 87380 4194304
net.ipv4.tcp_wmem = 4096 16384 4194304
net.core.wmem_default = 8388608
net.core.rmem_default = 8388608
net.core.rmem_max = 16777216
net.core.wmem_max = 16777216
net.core.netdev_max_backlog = 262144
net.core.somaxconn = 262144
net.ipv4.tcp_max_orphans = 3276800
net.ipv4.tcp_max_syn_backlog = 262144
net.ipv4.tcp_timestamps = 0
net.ipv4.tcp_synack_retries = 1
net.ipv4.tcp_syn_retries = 1
net.ipv4.tcp_tw_recycle = 1
net.ipv4.tcp_tw_reuse = 1
net.ipv4.tcp_mem = 94500000 915000000 927000000
net.ipv4.tcp_fin_timeout = 1
net.ipv4.tcp_keepalive_time = 30
net.ipv4.ip_local_port_range = 1024 65535

4.1. Linux内核常见参数详解

参数 解释
net.ipv4.tcp_timestamps = 1 控制RFC 1323 时间戳与窗口缩放选项
net.ipv4.tcp_sack = 1 选择性应答(SACK)是 TCP 的一项可选特性,可以提高某些网络中所有可用带宽的使用效率
net.ipv4.tcp_fack = 1 打开FACK(Forward ACK) 拥塞避免和快速重传功能
net.ipv4.tcp_retrans_collapse = 1 打开重传重组包功能,为0的时候关闭重传重组包功能
net.ipv4.tcp_syn_retries = 5 对于一个新建连接,内核要发送多少个SYN 连接请求才决定放弃
net.ipv4.tcp_synack_retries = 5 tcp_synack_retries显示或设定Linux在回应SYN要求时尝试多少次重新发送初始SYN,ACK封包后才决定放弃
net.ipv4.tcp_max_orphans = 131072 系统所能处理不属于任何进程的TCP sockets最大数量
net.ipv4.tcp_max_tw_buckets = 5000 系统同时保持TIME_WAIT套接字的最大数量,如果超过这个数字,TIME_WAIT套接字将立刻被清除并打印警告信息;默认为180000,设为较小数值此项参数可以控制TIME_WAIT套接字的最大数量,避免服务器被大量的TIME_WAIT套接字拖死;
net.ipv4.tcp_keepalive_time = 30,net.ipv4.tcp_keepalive_probes = 3,net.ipv4.tcp_keepalive_intvl = 3 如果某个TCP连接在空闲30秒后,内核才发起probe(探查),如果probe 3次(每次3秒既tcp_keepalive_intvl值)不成功,内核才彻底放弃,认为该连接已失效
net.ipv4.tcp_retries1 = 1 放弃回应一个TCP 连接请求前﹐需要进行多少次重试
net.ipv4.tcp_retries2 = 1 在丢弃激活(已建立通讯状况)的TCP连接之前﹐需要进行多少次重试
net.ipv4.tcp_fin_timeout = 1 表示如果套接字由本端要求关闭,这个参数决定了它保持在 FIN-WAIT-2状态的时间
net.ipv4.tcp_tw_recycle = 1 表示开启TCP连接中TIME-WAIT sockets的快速回收,默认为0,表示关闭
net.ipv4.tcp_max_syn_backlog = 40000 表示SYN队列的长度,默认为1024,加大队列长度为8192,可以容纳更多等待连接的网络连接数
net.ipv4.tcp_syncookies = 1 TCP建立连接的 3 次握手过程中,当服务端收到最初的 SYN 请求时,会检查应用程序的syn_backlog队列是否已满,启用syncookie,可以解决超高并发时的Can’t Connect` 问题。但是会导致 TIME_WAIT 状态fallback为保持2MSL时间,高峰期时会导致客户端无可复用连接而无法连接服务器
net.ipv4.tcp_orphan_retries = 0 关闭TCP连接之前重试多少次
net.ipv4.tcp_mem = 178368 237824 356736 net.ipv4.tcp_mem[0]: 低于此值,TCP没有内存压力,net.ipv4.tcp_mem[1]: 在此值下,进入内存压力阶段,net.ipv4.tcp_mem[2]: 高于此值,TCP拒绝分配socket
net.ipv4.tcp_tw_reuse = 1 表示开启重用,允许将TIME-WAIT sockets重新用于新的TCP连接
net.ipv4.ip_local_port_range = 1024 65000 表示用于向外连接的端口范围
net.ipv4.ip_conntrack_max = 655360 在内核内存中netfilter可以同时处理的“任务”(连接跟踪条目)
net.ipv4.icmp_ignore_bogus_error_responses = 1 开启恶意icmp错误消息保护
net.ipv4.tcp_syncookies = 1 开启SYN洪水攻击保护

5. Linux内核报错剖析

  • 企业生产环境Linux服务器正常运行,由于某种原因会导致内核报错或者抛出很多信息,根据系统SA可以快速定位Linux服务器故障,Linux内核日志一般存在messages日志中,可以通过命令tail -fn 100 /var/log/messages查看Linux内核日志,如下为Linux内核常见报错日志及生产环境解决报错的方案:

5.1. Linux内核抛出net.ipv4.tcp_max_tw_buckets错误

Sep 23 04:45:55 localhost kernel: TCP: time wait bucket table overflow
Sep 23 04:45:55 localhost kernel: TCP: time wait bucket table overflow
Sep 23 04:45:55 localhost kernel: TCP: time wait bucket table overflow
Sep 23 04:45:55 localhost kernel: TCP: time wait bucket table overflow
Sep 23 04:45:55 localhost kernel: TCP: time wait bucket table overflow
Sep 23 04:45:55 localhost kernel: TCP: time wait bucket table overflow
Sep 23 04:45:55 localhost kernel: TCP: time wait bucket table overflow
Sep 23 04:45:55 localhost kernel: TCP: time wait bucket table overflow
Sep 23 04:45:55 localhost kernel: TCP: time wait bucket table overflow
Sep 23 04:45:55 localhost kernel: TCP: time wait bucket table overflow

  • 根据TCP协议定义的3次握手及四次断开连接规定,发起socket主动关闭的一方Socket将进入TIME_WAIT状态,TIME_WAIT状态将持续2个MSL(Max Segment Lifetime)
  • 如果该值设置过小导致,当系统Time wait数量超过默认设置的值,即会抛出如上的警告信息,需要增加net.ipv4.tcp_max_tw_buckets的值,警告信息消除。
  • 当然也不能设置过大,对于一个处理大量短连接的服务器,如果是由服务器主动关闭客户端的连接,将导致服务器端存在大量的处于TIME_WAIT状态的Socket,甚至比处于Established状态下的Socket多的多,严重影响服务器的处理能力,甚至耗尽可用的Socket而停止服务,TIME_WAIT是TCP协议用以保证被重新分配的Socket不会受到之前残留的延迟重发报文影响的机制,是TCP传输必要的逻辑保证。

5.2. Linux内核抛出Too many open files错误:

Benchmarking localhost (be patient)
socket: Too many open files (24)
socket: Too many open files (24)
socket: Too many open files (24)
socket: Too many open files (24)
socket: Too many open files (24)

  • 每个文件描述符与一个打开文件相对应,不同的文件描述符可以指向同一个文件。相同的文件可以被不同的进程打开,也可以在同一个进程中被多次打开。Linux内核对应每个用户打开的文件最大数一般为1024,需要将该值调高满足大并发网站的访问。
  • Linux每个用户打开文件最大数永久设置方法,将如下代码加入内核限制文件/etc/security/limits.conf的末尾,Exit退出终端,重新登录即生效:
* 	soft 	noproc			65535
* 	hard 	noproc			65535
* 	soft 	nofile			65535
* 	hard 	nofile			65535

5.3. Linux内核抛出possible SYN flooding on port 80. Sending cookies错误:

May 31 14:20:14 localhost kernel: possible SYN flooding on port 80. Sending cookies.
May 31 14:21:28 localhost kernel: possible SYN flooding on port 80. Sending cookies.
May 31 14:22:44 localhost kernel: possible SYN flooding on port 80. Sending cookies.
May 31 14:25:33 localhost kernel: possible SYN flooding on port 80. Sending cookies.
May 31 14:27:06 localhost kernel: possible SYN flooding on port 80. Sending cookies.
May 31 14:28:44 localhost kernel: possible SYN flooding on port 80. Sending cookies.
May 31 14:28:51 localhost kernel: possible SYN flooding on port 80. Sending cookies.
May 31 14:31:01 localhost kernel: possible SYN flooding on port 80. Sending cookies.

  • 此问题是由于SYN 队列已满,而触发SYN cookies,一般是由于大量的访问,或者恶意访问导致,也称之为SYN Flooding洪水攻击,与DDOS攻击类似。
  • 完整的TCP连接的三次握手,假设一个用户A向服务器发送了SYN报文后突然死机或掉线,那么服务器在发出SYN+ACK应答报文后是无法收到客户端的ACK报文的(第三次握手无法完成),这种情况下服务器端一般会重试(再次发送SYN+ACK给客户端)并等待一段时间后丢弃这个未完成的连接,这段时间的长度我们称为SYN Timeout,一般来说这个时间是分钟的数量级(大约为30秒-2分钟)。
  • 一个用户出现异常导致服务器的一个线程等待1分钟并不是什么很大的问题,但如果有一个恶意的攻击者大量模拟这种情况,服务器端将为了维护一个非常大的半连接列表而消耗非常多的资源,数以万计的半连接,即使是简单的保存并遍历也会消耗非常多的CPU时间和内存,何况还要不断对这个列表中的IP进行SYN+ACK的重试。
  • 实际上如果服务器的TCP/IP栈不够强大,最后的结果往往是堆栈溢出崩溃,即使服务器端的系统足够强大,服务器端也将忙于处理攻击者伪造的TCP连接请求而无暇理睬客户的正常请求(毕竟客户端的正常请求比率非常之小),此时从正常客户的角度看来,服务器失去响应,服务器拒绝提供服务,服务器受到了DDOS攻击,这里攻击的手段为DDOS中SYN Flood攻击(SYN洪水攻击)。
  • 防护DDOS攻击有两种手段,一是基于硬件专业防火墙、二是基于Linux内核简单防护,如果攻击流量特别大,单纯配置内核参数是无法抵挡的,还得依靠专业级硬件防火墙,如下为Linux内核防护DDOS优化参数,加入如下代码即可:
net.ipv4.tcp_fin_timeout = 30 
net.ipv4.tcp_keepalive_time = 1200 
net.ipv4.tcp_syncookies = 1 
net.ipv4.tcp_tw_reuse = 1 
net.ipv4.tcp_tw_recycle = 1 
net.ipv4.ip_local_port_range = 1024 65000 
net.ipv4.tcp_max_syn_backlog = 8192 
net.ipv4.tcp_max_tw_buckets = 8000 
net.ipv4.tcp_synack_retries = 2 
net.ipv4.tcp_syn_retries = 2

5.4. Linux内核抛出ip_conntrack: table full, dropping packet.错误:

May  6 11:15:07 localhost kernel: nf_conntrack:table full, dropping packet.
May  6 11:19:13 localhost kernel: nf_conntrack:table full, dropping packet.
May  6 11:20:34 localhost kernel: nf_conntrack:table full, dropping packet.
May  6 11:23:12 localhost kernel: nf_conntrack:table full, dropping packet.
May  6 11:24:07 localhost kernel: nf_conntrack:table full, dropping packet.
May  6 11:24:13 localhost kernel: nf_conntrack:table full, dropping packet.
May  6 11:25:11 localhost kernel: nf_conntrack:table full, dropping packet.
May  6 11:26:25 localhost kernel: nf_conntrack:table full, dropping packet. 

  • 由于该服务器开启了iptables防火墙,WEB服务器收到了大量的连接,iptables会把所有的连接都做链接跟踪处理,这样iptables就会有一个链接跟踪表,当这个表满的时候,就会出现上面的错误。ip_conntrack是linux NAT的一个跟踪连接条目的模块,ip_conntrack模块会使用一个哈希表记录 tcp 通讯协议的established connection记录。
  • 如果是CentOS6.x系统,需执行:modprobe nf_conntrack命令,然后在内核优化文件中(/etc/sysctl.conf)加入如下代码,sysctl –p使其内核文件生效,即可解决该报错:
net.nf_conntrack_max = 655360
net.netfilter.nf_conntrack_tcp_timeout_established = 36000

  • 如果是CentOS5.x系统,需执行:modprobe ip_conntrack命令,然后在内核优化文件中加入如下代码,sysctl –p使其内核文件生效,即可解决该报错:
net.ipv4.ip_conntrack_max = 655350
net.ipv4.netfilter.ip_conntrack_tcp_timeout_established = 10800

6. 影响务器性能因素

  • 影响企业生产环境Linux服务器性能的因素有很多,一般分为两大类,分别为操作系统层级和应用程序级别。如下为各级别影响性能的具体项及性能评估的标准:
  1. 操作系统级别
  • 内存;
  • CPU;
  • 磁盘I/O;
  • 网络I/O带宽;
  • Linux内核参数;
  1. 应用程序及软件
  • Nginx;
  • Mysql;
  • Tomcat;
  • PHP;
  • Redis;
  • Zabbix;
  • Jenkins;
  • ELK;
  • 应用程序代码;
  • Linux系统性能评估标准如图所示:
    Linux性能优化实战

6.1. Linux系统性能分析工具

  • 常用系统性能分析命令
vmstat、sar、iostat、netstat、free、ps、top、iftop等;
  • 常用系统性能组合分析命令
  • top、uptime 检查系统整体的负载、承受能力;
  • vmstat、sar、iostat 、top 检测是否是CPU瓶颈;
  • free、vmstat 检测是否是内存瓶颈;
  • iostat 检测是否是磁盘I/O瓶颈;
  • netstat、iftop 检测是否是网络带宽瓶颈。

7. Linux服务器性能评估与优化

  • Linux服务器性能评估与优化是一项长期的工作,需要随时关注网站服务器的运行状态,及时作出相应的调整,如下为Linux服务器性能评估及优化方案:

7.1. Linux系统整体性能评估

  • uptime命令主要用于查看当前服务器整体性能,例如CPU、负载、内存等值的总览,如下为uptime命令应用案例及详解:
[root@web1 ~]# uptime
13:38:00 up 112 days,  14:01,  5 users,  load average: 6.22, 1.02, 0.91

  • Load average负载有三个值,分别表示:最近1分钟、5分钟、15分钟系统的负载,三个值的大小一般不能大于系统逻辑CPU核数的2倍,例如Linux操作系统有4个逻辑CPU,如果load average的三个值长期大于8时,说明CPU很繁忙,负载很高,可能会影响系统性能,但是偶尔大于8时,可以不用担心,一般不会影响系统性能。
  • 如果load average的输出值小于CPU逻辑个数的2倍,则表示CPU还有空闲的时间片,例如案例中CPU负载为6.22,表示CPU或者服务器是比较空闲的。基于此参数不能完全确认服务器的性能瓶颈,需要借助其他工具进一步判断。

7.2. CPU性能评估

  • 利用vmstat命令监控系统CPU,该命令可以显示关于系统各种资源之间相关性能的简要信息,主要用它来查看CPU负载及队列情况。
[root@manager ~]# vmstat  2 10
procs -----------memory---------- ---swap-- -----io---- -system-- ------cpu-----
 r  b   swpd   free   buff  cache   si   so    bi    bo   in   cs us sy id wa st
 1  0      0 1406844   2088 267504    0    0     2     0   71  116  0  0 100  0  0
 0  0      0 1406828   2088 267536    0    0     0     0  129  219  0  0 100  0  0
 0  0      0 1406828   2088 267536    0    0     0     0  122  211  0  0 100  0  0
 0  0      0 1406828   2088 267536    0    0     0     0  123  206  0  0 100  0  0
 0  0      0 1406828   2088 267536    0    0     0     0  127  225  0  0 100  0  0
 0  0      0 1406432   2088 267536    0    0     0     0  165  268  0  0 100  0  0
 2  0      0 1405896   2088 267536    0    0     0     1  139  236  0  0 100  0  0
 0  0      0 1405896   2088 267536    0    0     0     0  121  213  0  0 100  0  0
 2  0      0 1405864   2088 267536    0    0     0     2  131  217  0  0 100  0  0
 0  0      0 1405864   2088 267536    0    0     0     0  136  241  0  0 100  0  0
  • Vmstat输出结果详解如下:
r 列表示运行和等待cpu时间片的进程数,这个值如果长期大于系统CPU的个数,说明CPU不足,需要增加CPU
b 列表示在等待资源的进程数,比如正在等待I/O、或者内存交换等
us 列显示了用户进程消耗的CPU 时间百分比。us的值比较高时,说明用户进程消耗的cpu时间多,但是如果长期大于50%,就需要考虑优化程序或算法;
sy 列显示了内核进程消耗的CPU时间百分比。Sy的值较高时,说明内核消耗的CPU资源很多;
  • us+sy的参考值为80%,如果us+sy大于80%说明可能存在CPU资源不足。
  • 利用sar命令监控系统CPU,sar功能很强大,可以对系统的每个方面进行单独的统计,但是使用sar命令会增加系统开销,不过这些开销是可以评估的,对系统的统计结果不会有很大影响。为sar命令对某个系统的CPU统计输出:
[root@manager ~]# sar -u 2 10
Linux 3.10.0-1160.el7.x86_64 (manager)  2023年04月18日  _x86_64_        (2 CPU)

15时08分33秒     CPU     %user     %nice   %system   %iowait    %steal     %idle
15时08分35秒     all      0.00      0.00      0.25      0.00      0.00     99.75
15时08分37秒     all      0.00      0.00      0.00      0.00      0.00    100.00
15时08分39秒     all      0.25      0.00      0.25      0.00      0.00     99.50
15时08分41秒     all      0.00      0.00      0.00      0.00      0.00    100.00
15时08分43秒     all      0.00      0.00      0.25      0.00      0.00     99.75
15时08分45秒     all      0.00      0.00      0.25      0.00      0.00     99.75
15时08分47秒     all      0.00      0.00      0.00      0.00      0.00    100.00
15时08分49秒     all      0.00      0.00      0.25      0.00      0.00     99.75
15时08分51秒     all      0.25      0.00      0.00      0.00      0.00     99.75
15时08分53秒     all      0.00      0.00      0.25      0.00      0.00     99.75
平均时间:     all      0.05      0.00      0.15      0.00      0.00     99.80
  • Sar输出结果详解如下:
%user 列显示了用户进程消耗的CPU 时间百分比
%nice 列显示了运行正常进程所消耗的CPU 时间百分比
%system 列显示了系统进程消耗的CPU时间百分比
%iowait 列显示了IO等待所占用的CPU时间百分比
%idle 列显示了CPU处在空闲状态的时间百分比
%steal 列显示了在内存相对紧张的环境下page in强制对不同的页面进行的steal操作

7.3. 内存性能评估

  • 利用free指令监控内存,free是监控linux内存使用状况最常用的指令:
[root@manager ~]# free -m
              total        used        free      shared  buff/cache   available
Mem:           1980         349        1180           9         450        1473
Swap:             0           0           0

  • 一般而言,服务器内存可以通过如下方法判断是否空余:
  • 应用程序可用内存/系统物理内存>70%时,表示系统内存资源非常充足,不影响系统性能。
  • 应用程序可用内存/系统物理内存<20%时,表示系统内存资源紧缺,需要增加系统内存,20%<应用程序可用内存/系统物理内存<70%时,表示系统内存资源基本能满足应用需求,暂时不影响系统性能。

7.4. 磁盘I/O性能评估

  • 利用iostat评估磁盘性能,监控磁盘IO读写及带宽
[root@manager ~]# iostat -d  1 5
Linux 3.10.0-1160.el7.x86_64 (manager)  2023年04月18日  _x86_64_        (2 CPU)

Device:            tps    kB_read/s    kB_wrtn/s    kB_read    kB_wrtn
sda               0.20         5.27         0.67     435152      55670
scd0              0.00         0.01         0.00       1046          0

Device:            tps    kB_read/s    kB_wrtn/s    kB_read    kB_wrtn
sda               0.00         0.00         0.00          0          0
scd0              0.00         0.00         0.00          0          0

Device:            tps    kB_read/s    kB_wrtn/s    kB_read    kB_wrtn
sda               0.00         0.00         0.00          0          0
scd0              0.00         0.00         0.00          0          0

Device:            tps    kB_read/s    kB_wrtn/s    kB_read    kB_wrtn
sda               0.00         0.00         0.00          0          0
scd0              0.00         0.00         0.00          0          0

Device:            tps    kB_read/s    kB_wrtn/s    kB_read    kB_wrtn
sda               0.00         0.00         0.00          0          0
scd0              0.00         0.00         0.00          0          0

  • iostat输出结果详解如下:
Device 磁盘设备名
tps 每秒钟传输的 I/O 请求次数
kB_read/s 每秒钟读取的数据量,以 KB/s 为单位
kB_wrtn/s 每秒钟写入的数据量,以 KB/s 为单位
kB_read 读取的总数据量,以 KB 为单位
kB_wrtn 写入的总数据量,以 KB 为单位
  • 可以通过kB_read/s和kB_wrtn/s的值对磁盘的读写性能有一个基本的了解,如果Blk_wrtn/s值很大,表示磁盘的写操作很频繁,可以考虑优化磁盘或者优化程序,如果Blk_read/s值很大,表示磁盘直接读取操作很多,可以将读取的数据放入内存中进行操作。

  • 利用sar评估磁盘性能,通过sar -d组合,可以对系统的磁盘IO做一个基本的统计

[root@manager ~]# sar -d 1 5
Linux 3.10.0-1160.el7.x86_64 (manager)  2023年04月18日  _x86_64_        (2 CPU)

15时46分11秒       DEV       tps  rd_sec/s  wr_sec/s  avgrq-sz  avgqu-sz     await     svctm     %util
15时46分12秒    dev8-0      0.00      0.00      0.00      0.00      0.00      0.00      0.00      0.00
15时46分12秒   dev11-0      0.00      0.00      0.00      0.00      0.00      0.00      0.00      0.00

15时46分12秒       DEV       tps  rd_sec/s  wr_sec/s  avgrq-sz  avgqu-sz     await     svctm     %util
15时46分13秒    dev8-0      0.00      0.00      0.00      0.00      0.00      0.00      0.00      0.00
15时46分13秒   dev11-0      0.00      0.00      0.00      0.00      0.00      0.00      0.00      0.00

15时46分13秒       DEV       tps  rd_sec/s  wr_sec/s  avgrq-sz  avgqu-sz     await     svctm     %util
15时46分14秒    dev8-0      0.00      0.00      0.00      0.00      0.00      0.00      0.00      0.00
15时46分14秒   dev11-0      0.00      0.00      0.00      0.00      0.00      0.00      0.00      0.00

15时46分14秒       DEV       tps  rd_sec/s  wr_sec/s  avgrq-sz  avgqu-sz     await     svctm     %util
15时46分15秒    dev8-0      0.00      0.00      0.00      0.00      0.00      0.00      0.00      0.00
15时46分15秒   dev11-0      0.00      0.00      0.00      0.00      0.00      0.00      0.00      0.00

15时46分15秒       DEV       tps  rd_sec/s  wr_sec/s  avgrq-sz  avgqu-sz     await     svctm     %util
15时46分16秒    dev8-0      0.00      0.00      0.00      0.00      0.00      0.00      0.00      0.00
15时46分16秒   dev11-0      0.00      0.00      0.00      0.00      0.00      0.00      0.00      0.00

平均时间:       DEV       tps  rd_sec/s  wr_sec/s  avgrq-sz  avgqu-sz     await     svctm     %util
平均时间:    dev8-0      0.00      0.00      0.00      0.00      0.00      0.00      0.00      0.00
平均时间:   dev11-0      0.00      0.00      0.00      0.00      0.00      0.00      0.00      0.00
  • Sar输出结果详解如下:
DEV 设备名
tps 每秒从物理磁盘I/O的次数,多个逻辑请求会被合并为一个I/O磁盘请求,一次传输的大小是不确定的
rd_sec/s 每秒读扇区的次数
wr_sec/s 每秒写扇区的次数
avgrq-sz 平均每次设备I/O操作的数据大小(扇区)
avgqu-sz 磁盘请求队列的平均长度
await 从请求磁盘操作到系统完成处理,每次请求的平均消耗时间,包括请求队列等待时间,单位是毫秒(1秒=1000毫秒)
svctm 系统处理每次请求的平均时间,不包括在请求队列中消耗的时间
%util I/O请求占CPU的百分比,比率越大,说明越饱和

1. avgqu-sz 的值较低时,设备的利用率较高。
2. %util I/O请求占用的CPU百分比,值越高,说明I/O越慢。
文章来源地址https://www.toymoban.com/news/detail-421122.html

  • 磁盘IO性能,评判标准:正常情况下svctm应该是小于await值的,而svctm的大小和磁盘性能有关,CPU、内存的负荷也会对svctm值造成影响,过多的请求也会间接的导致svctm值的增加。
  • await值的大小一般取决与svctm的值和I/O队列长度以及I/O请求模式,如果svctm的值与await很接近,表示几乎没有I/O等待,磁盘性能很好,如果await的值远高于svctm的值,则表示I/O队列等待太长,系统上运行的应用程序将变慢,此时可以通过更换更快的硬盘来解决问题。
  • %util项的值也是衡量磁盘I/O的一个重要指标,如果%util接近100%,表示磁盘产生的I/O请求太多,I/O系统已经满负荷的在工作,该磁盘可能存在瓶颈。长期下去,势必影响系统的性能,可以通过优化程序或者通过更换更高、更快的磁盘来解决此问题。

到了这里,关于Linux性能优化实战的文章就介绍完了。如果您还想了解更多内容,请在右上角搜索TOY模板网以前的文章或继续浏览下面的相关文章,希望大家以后多多支持TOY模板网!

本文来自互联网用户投稿,该文观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如若转载,请注明出处: 如若内容造成侵权/违法违规/事实不符,请点击违法举报进行投诉反馈,一经查实,立即删除!

领支付宝红包 赞助服务器费用

相关文章

  • Autosar通信实战系列02-CAN报文发送周期测试脚本开发及周期不准优化

    在本系列笔者将结合工作中对通信实战部分的应用经验进一步介绍常用,包括但不限于通信各模块的开发教程,代码逻辑分析,调测试方法及典型问题分析。 项目通信部分开发中,会接收到客户这样一条需求: 对于本节点发送报文的周期需要稳定发送,前后两帧时间差波动

    2024年02月15日
    浏览(50)
  • Linux性能学习(4.6):网络_孤儿连接、半连接状态、RTS复位报文简述

    在前面《TCP三次握手内核参数优化》和《TCP四次挥手内核参数优化》章节了解了一些概念:孤儿连接、半连接状态、RTS复位报文,在本文简单介绍下这些概念。 主动调用close一方的进程,调用之后,相关句柄已经释放,此连接已经和进程无关,由内核和另一方进行四次挥手交

    2024年02月09日
    浏览(36)
  • 高性能MySQL实战(三):性能优化

    大家好,我是 方圆 。这篇主要介绍对慢 SQL 优化的一些手段,而在讲解具体的优化措施之前,我想先对 EXPLAIN 进行介绍,它是我们在分析查询时必要的操作,理解了它输出结果的内容更有利于我们优化 SQL。为了方便大家的阅读,在下文中规定类似 key1 的表示二级索引,key_

    2024年02月11日
    浏览(66)
  • 性能优化实战使用CountDownLatch

    1.分析问题 原程序是分页查询EventAffinityScoreDO表的数据,每次获取2000条在一个个遍历去更新EventAffinityScoreDO表的数据。但是这样耗时比较慢,测试过30万的数据需要2小时 单个线程一个个遍历去更新表数据太慢了,我想把2000的数据分成多份,每份200条,可以分成10份。每份用一

    2024年02月07日
    浏览(32)
  • Angular 性能优化实战

    Angular 是一个非常强大的前端框架,但是如果不注意性能优化,应用程序可能会变得非常慢并增加加载时间。 以下是一些Angular性能优化经验的实战建议: 默认情况下,Angular检查应用程序中发生的所有数据更改,从而导致性能下降。为了解决这个问题,可以使用OnPush变更检测

    2024年02月13日
    浏览(39)
  • 高并发缓存实战RedisSon、性能优化

    对于经常访问的数据保留在redis缓存当中,不用带数据设置超时时间定期删除控制redis的大小 缓存击穿数据库没有被击穿 如果商家是批量导入的数据,呢么就会同时存到redis中,设置固定的时间就会导致缓存在一瞬间失效,用户访问不到就会将流量打到数据库上造成数据库段

    2024年02月13日
    浏览(61)
  • Android UI性能优化实战 识别绘制中的性能问题

    { super.onCreate(savedInstanceState); setContentView(R.layout.activity_overdraw_01); mInflater = LayoutInflater.from(this); mListView = (ListView) findViewById(R.id.id_listview_chats); mListView.setAdapter(new ArrayAdapter(this, -1, Droid.generateDatas()) { @Override public View getView(int position, View convertView, ViewGroup parent) { ViewHolder holder =

    2024年04月15日
    浏览(36)
  • 商智C店H5性能优化实战

    商智C店,是依托移动低码能力搭建的一个应用,产品面向B端商家。随着应用体量持续增大,考虑产品定位及用户体验,我们针对性能较差页面做了一次优化,并取得了不错的效果, 用户体验值(UEI)从一般提升到良好 。本文详细记录了优化思路及过程,期望给正在或打算做

    2024年02月03日
    浏览(30)
  • Elasticsearch性能优化:实战策略与最佳实践

    -在数据密集型的应用场景中,Elasticsearch作为一个强大的搜索和分析引擎,能够提供快速的搜索能力和处理大规模数据的能力。然而,随着数据量的增长和查询需求的复杂化,对Elasticsearch的性能优化成为了维护高效、稳定服务的重要任务。本文将深入探讨Elasticsearch的优化策略

    2024年04月23日
    浏览(39)
  • Android UI性能优化实战 识别绘制中的性能问题(1)

    { public String name; public int imageId; public String date; public String msg; public Droid(String msg, String date, int imageId, String name) { this.msg = msg; this.date = date; this.imageId = imageId; this.name = name; } public static List generateDatas() { List datas = new ArrayList(); datas.add(new Droid(“Lorem ipsum dolor sit amet, orci nullam cra”

    2024年04月13日
    浏览(44)

觉得文章有用就打赏一下文章作者

支付宝扫一扫打赏

博客赞助

微信扫一扫打赏

请作者喝杯咖啡吧~博客赞助

支付宝扫一扫领取红包,优惠每天领

二维码1

领取红包

二维码2

领红包