Linux内核参数优化

Linux服务器默认支持1024个TCP链接，在性能测试时，无论压力机还是项目服务器，都需要对tcp参数进行一些优化
ulimit -n：查看当前Linux系统最大的连接数

修改Linux系统允许创建最大的连接数
vi /etc/security/limits.conf
在最后一行添加
* soft nofile 1000000
* hard nofile 1000000

修改TCP参数，减少处于TIME_WAIT状态的连接数，避免连接不释放，Jmeter无可用连接
vi /etc/sysctl.conf
在文件末尾，添加以下参数
net.ipv4.tcp_syncookies = 1
net.ipv4.tcp_tw_reuse = 1
net.ipv4.tcp_tw_recycle = 1
net.ipv4.tcp_fin_timeout = 30
保存文件，执行以下命令让修改生效
/sbin/sysctl -p

TCP的三次握手和四次挥手
三次握手：客户端和服务端建立链接时，要进行三次握手
四次挥手：客户端和服务端断开链接时，要进行四次挥手
四次挥手结束之后，客户端和服务端不会理解释放tcp链接，tcp链接会处于中TIME_WAIT状态，默认会持续2分钟左右，如果再次期间，没有产生新的tcp请求，链接才会彻底断开。
每个tcp链接要占用服务器一个端口，服务端端口号固定是65535，如果老的tcp链接没有快速释放，会造成端口号不足，新的tcp链接没有办法申请端口。

多线程模式下的数据安全问题
1、多线程模式下
2、多线程执行的是多行代码
3、多行代码操作的是同一个资源（数据）

一、线程阻塞案例

（加并发，压力上不去，但是TPS就是上不去，CPU服务器还很空闲，需要分析程序太慢，程序不能充分利用资源）对程序或者数据库排查问题。JC也要排查

线程状态分析策略：
1、使用jstack进行线程dump（快照），并重定向到1个文件中，连续进行3次快照
2、在本地打开快照文件进行分析
3、搜索关键字“BLOCKED”，找到对应的线程信息
4、从上往下，找以"com,cn"开头的信息，这种一般都是业务代码，从这行代码再往上，都是业务代码调用的其他代码
5、根据阻塞发生的代码信息，找对应的代码进行分析（找开发协助）

Log4j的线程阻塞问题

级别越低，日志越多，日志量：ALL > DEBUG > INFO > WARN > ERROR > FATAL

线程阻塞问题排查流程
1、做线程dump
2、在dump文件中搜索关键字"BLOCKED"、"TIME_WAITTING"，查看每种状态的count数量
3、按照上述关键字搜索，查看跟本系统有关的业务代码堆栈信息

解决方案
1、减少代码中没有必要的日志输出
2、如果可以，提升日志级别，以减少日志
3、如果可以，更换其他的日志组件，如Log4j2、Logback等

二、线程死锁问题

定义
线程死锁就是有两个线程，一个线程锁住了资源A，又想去锁定资源B，另外一个线程锁定了资源B，
又想去锁定资源A，两个线程都想去得到对方的资源，而又不愿释放自己的资源
从而造成一种互相等待，无法执行的情况

现象
出现死锁后，tps降为0，压力测试工具无法得到服务器的响应，服务器硬件资源空闲，通过
jvisualvm去查看线程情况，至少两个线程一直处于红色的阻塞状态。
死锁经常表现为程序的停顿，或者不再响应用户的请求。从操作系统上观察，对应进程的CPU占用率为零。

死锁问题分析
如果出现死锁，必定有线程的阻塞。死锁是最严重的阻塞

解决

定位方法
通过jvisualvm或者jstack，进行线程dump，对线程状态进行分析,获取到哪行代码导致的死锁，如：
Found one Java-level deadlock:
http-bio-8080"-exec-162":
waiting to lock monitor 0x0818abac (object 0x84b40ad0, a com.lee.domain.Order),
which is held by ""http-bio-8080"-exec-158"
""http-bio-8080"-exec-158":
waiting to lock monitor 0x08188cd0 (object 0x84b3bc48, a com.lee.domain.Order),
which is held by ""http-bio-8080"-exec-162"

解决思路

1.避免嵌套加锁
2.减小锁的粒度，如果必须要嵌套加锁，锁内部的代码，越少越好（死锁的概率越低）

三、CPU消耗过高的问题

现象
压测过程中，发现应用服务器的CPU使用率比较高（>80%）
两种情况
1、接口的性能非常好，比如响应时间<10ms，tps很高，此时CPU使用率高是正常的，不需要优化
2、接口性能不好，比如响应时间>200ms，tps很低，此时需要考虑优化

CPU消耗高可能的原因
1、使用了复杂的算法，比如加密、解密
2、压缩、解压、序列化等操作
3、代码bug，比如死循环

定位方法
1、在windows上（本机）和服务器上（Linux），分别安装对应版本的jprofiler

2、执行jmx 脚本分析，在HOTSpots 分析代码中哪些函数占用CPU 时间长使用率高，一层一层分析入口

Windows：双击-下一步（略）
Linux：
1、上传安装包，执行命令rpm -ivh jprofiler_linux_11_0.rpm
2、tomcat/bin/catalina.sh文件配置jvm参数的地方添加
-agentpath:/opt/jprofiler11/bin/linux-x64/libjprofilerti.so=port=8849,nowait

解决方案：

比如
序列化：程序中对象和字符串之间的转换，对象->json字符串，json字符串->对象

to_json的方法占性能考虑别的方法比如fast_json