您的位置: 首页  >  文章  >  性能分析

性能分析

分类: 文章 • 2024-10-03 15:19:10
  1. Swap交换分区

Swap的相关参数swappiness，默认为60，意思是当剩余物理内存低于40%时，开始使用交换内存。 查看swappiness的配置
sysctl -a | grep vm.swappiness

  1. linux内核参数

查看内核参数：
sysctl命令用于运行时配置内核参数
-a 查看所有系统参数
-w 临时修改系统参数
例如: sysctl -a|grep swappiness 查看swappiness的内核参数
–
修改内核参数
临时修改:
例如： sysctl -w vm.swappiness=40 临时修改swappiness的值为40
永久修改:
修改/proc/sys/目录中的文件。例如： echo 1 > /proc/sys/net/ipv4/tcp_tw_reuse
修改tcp_tw_reuse的值为1 echo 1 > /proc/sys/net/ipv4/tcp_tw_recycle
修改tcp_tw_recycle的值为1 echo 30 > /proc/sys/net/ipv4/tcp_fin_timeout
修改tcp_fin_timeout的值为30 或者
修改/etc/sysctl.conf文件里对应参数的值修改后执行sysctl
-p立即生效

  1. Keeplive和keep-Alive的区别（长连接）

Keeplive是TCP层的概念，侧重在保持客户端和服务端的连接，一方会不定期发送心跳包给另一方，当一方端掉的时候，没有断掉的定时发送几次心跳包，如果间隔发送几次，对方都返回的是RST，而不是ACK，那么就释放当前链接。设想一下，如果tcp层没有keepalive的机制，一旦一方断开连接却没有发送FIN给另外一方的话，那么另外一方会一直以为这个连接还是存活的，几天，几月。那么这对服务器资源的影响是很大的
–
keep-Alive是http层的概念，http连接是客户端连接上服务端，然后结束请求后，由客户端或者服务端进行http连接的关闭。下次再发送请求的时候，客户端再发起一个连接，传送数据，关闭连接。这么个流程反复。但是一旦客户端发送connection:keep-alive头给服务端，且服务端也接受这个keep-alive的话，两边对上暗号，这个连接就可以复用了，一个http处理完之后，另外一个http数据直接从这个连接走了。减少新建和断开TCP连接的消耗
–
HTTP协议的Keep-Alive意图在于短时间内连接复用，希望可以短时间内在同一个连接上进行多次请求/响应
–
TCP的KeepAlive机制意图在于保活、心跳，检测连接错误。当一个TCP连接两端长时间没有数据传输时(通常默认配置是2小时)，发送keepalive探针，探测链接是否存活
–
在TCP层是没有“请求”一说的，请求是http的概念，http是建立在TCP之上（之后）的

  1. cookie、session、token的区别

cookie是由服务端生成，已key-value形式保存在客户端的一个字符串。
session保存在服务端的一个标识，用于标识是哪个客户端来访问了。
token是用户第一次登录成功后，服务器给客户端放回一个token信息，以后用户每次访问都带着这个token信息去请求服务器，是一种基于token的身份验证

  1. CPU软中断理解

cat /proc/interrupts软中断
cat /proc/softirqs硬中断
–
软中断分为上半部分和下半部分 上半部直接处理硬件请求，也就是我们常说的硬中断，特点是快速执行
而下半部则是由内核触发，也就是我们常说的软中断，特点是延迟执行

内核自定义的事件也属于软中断，比如内核调度和RCU 锁

每个CPU都对应一个软中断内核线程，名字为 “ksoftirqd/CPU 编号”

观察软中断的变化速率 watch -d cat /proc/softirqs

软中断的类型 TIMER（定时中断）、NET_RX（网络接收）、SCHED（内核调度）、RCU（RCU 锁）

分析方法

  1. 通过top查看si
  2. 通过watch -d cat /proc/softirqs 查看软中断的变化速度，变化最快的为有问题的
  1. 三次握手里的全连接队列和半连接队列

性能分析
–
握手过程：
第一次：client发送syn到server进行握手
第二次：server收到syn后回复syn+ack给client同时服务端将相关信息放在半连接队列中。
第三次：client收到syn+ack后回复server一个ack，表示收到了server的syn+ack，server收到client的ack后将根据不同的情况进行不同的处理(这与tcp_abort_on_overflow参数和accept
queue全连接队列是否已满有关)
–
在握手阶段存在两个队列：
全连接队列(accept queue)
半连接队列(syns queue）
–
解析：当第一次握手(client客户端的SYN到达server服务端时)TCP会在未完成连接队列中创建一个新项，这一项会一直保留在未完成连接队列中直到第三次握手(客户对服务器SYN的ACK)结束为止。如果三次握手全部正常完成，该项则会从未完成连接队列移到已完成连接队列的队尾。当进程调用accept()时，已完成连接队列中的队头项将返回给进程。
–
第三次握手时sever的具体处理方式
性能分析
–
场景1：当全连接未满 当server收到client的ack后会先判断全连接队列accept
queue是否已满，如果队列未满则从半连接队列拿出相关信息存放入全连接队列中，之后服务端accept()处理此请求。
–
场景2：当全连接已满且tcp_abort_on_overflow = 0 server会扔掉client
发过来的ack。之后隔一段时间server会重发握手第二步的syn+ack包给client，如果客户端连接一直排队不上等待超时则会报超时异常，即Connection timieout。
–
场景3：全连接已满且tcp_abort_on_overflow = 1时
server会发送一个reset包给client，表示废除这个握手过程和这个连接(客户端会报connection reset by peer异常)
–
如何查看半连接队列是否溢出
我们通过 SYNs to LISTEN sockets dropped 来判断半连接队列是否溢出
[[email protected] ~]# netstat -s |grep -I listen 8866 SYNs to LISTEN sockets dropped 如上所知，半连接队列满了，SYN包被扔掉了。

半连接队列相关参数
1） backlog
2） 内核参数tcp_max_syn_backlog
–
如何查看全连接队列是否溢出
通过 times the listen queue of a socket overflowed 来判断全连接队列是否溢出 [[email protected] ~]# netstat -s |grep overflow 154864
times the listen queue of a socket overflowed 如图所知，全连接队列溢出了。
–
全连接队列的相关参数
1） net.core.somaxconn：系统中每一个端口最大的监听队列的长度。
2）net.core.netdev_max_backlog：每个网络接口接收数据包的速率比内核处理这些包的速率快时，允许送到队列的数据包的最大数目。
3） open_file：文件句柄数

  1. 三次握手基础知识普及

[1] 搞清楚流程
–
[2] 为什么连接的时候是三次握手，断开连接的时候是四次握手呢
–
[3] Connection timeout和Connection reset出现的原因
–
[4] TIME_WAIT出现的原因及解决办法
性能分析
–
[5] Linux服务器上端口数、TCP连接数的关系
一台linux服务器最多能开65535个端口（1024以下为保留端口），但可以有成千上万的TCP连接数，具体要看最大文件句柄（文件描述符）限制和TCP参数的优化程度。
具体可参考：https://www.jb51.net/article/169556.htm
我们在压测一台目标服务器，想看下负载的连接数，当我们压到一定数量的时候，控制台突然报"too many openfiles"，这是因为linux系统创建一个TCP连接的时候，都会创建一个socket句柄，每个socket句柄就是一个文件句柄。操作系统对打开的文件句柄数量是有限制的。
–
[6] Backlog是什么
–
[7] TCP协议中常用标识
SYN 请求建立连接
ACK 确认是否收到（一般为1）
FIN 希望断开连接
RST 对方要求重新建立连接、复位
–
[8] 以下主动关闭端为客户端，被动关闭端为服务器。
LISTEN 侦听来自远方的TCP端口的连接请求（服务端）
SYN_SENT 请求已发送（客户端）
SYN_RECV 服务器已确认ACK，同时向客户端发送SYN后
ESTABLISHED 连接已建立
FIN_WAIT-1 客户端请求主动关闭
FIN_WAIT-2 主动关闭端收到ACK后，进入FIN_WAIT-2状态
CLOSE_WAIT 被动关闭端收到FIN后，并回复ACK后
LAST_ACK 被动关闭端给主动关闭端发送FIN（）后
TIME_WAIT 主动关闭端收到FIN（连接释放报文）后，并发送ACK后
CLOSED 被动关闭端接收到ACK后，进入CLOSED，连接结束

  1. JVM

[1] JVM内存模型
年轻代
老年代
持久代（java8叫元空间）
–
[2] GC作用: 回收不可用的对象，移动可用对象
–
[3] JVM优化
-Xms=-Xmx
-server
–
[4] JVM性能问题定位
jmap
jstatck
jstat

  1. mysql

[1] 事务
事务必须满足的4个特性：原子性、一致性、隔离性、持久性
BEGIN 开始一个事务
ROLLBACK 事务回滚
COMMIT 事务确认
–
[2] DDL和DML操作
–
[3] 索引
普通索引（加速查找）
唯一索引（加速查找+索引列值唯一）
主键索引（加速查找+索引列不能重复）

创建索引
删除索引
索引失效的N多种情况
–
[4] 存储引擎
innodb 支持事务
myisam 不支持事务
–
[5] explain优化sql
–
[6] mysql、redis、es比较
mysql：关系型数据库，数据存在硬盘，支持事务
redis：非关系型数据库，数据存储在内存、支持持久化
es：不是数据库，是全文检索中间件，适合存储更新频率比较低的数据，比如：商品编号

  1. redis

[1] redis特性
数据存储在内存中，所以速度快
单线程运行
支持持久化
key/value存储
支持主从复制和集群
–
[2] redis原理
–
[3] 基本数据类型
string
list
set
hash
[4] 持久化
redis持久化分为两种，RDB和AOF RDB
–
RDB是将redis某一时刻的数据持久化到磁盘中，是一种快照式的持久化方法
RDB缺点：redis故障时数据可能会丢失
–
AOF：将redis执行过的所有写指令记录下来，在下次redis重新启动时，只要把这些写指令从前到后再重复执行一遍，就可以实现数据恢复了
AOF优点：可以恢复不小心删除的数据；万一出现故障，最多丢失1秒的数据 AOF缺点：AOF文件比RDB大，恢复速度慢

相关推荐