调优类：linux、nginx、tomcat

linux内核调优

打开文件 /etc/sysctl.conf，增加以下设置

#该参数设置系统的TIME_WAIT的数量，如果超过默认值则会被立即清除
net.ipv4.tcp_max_tw_buckets = 20000
#定义了系统中每一个端口最大的监听队列的长度，这是个全局的参数
net.core.somaxconn = 65535
#对于还未获得对方确认的连接请求，可保存在队列中的最大数目
net.ipv4.tcp_max_syn_backlog = 262144
#在每个网络接口接收数据包的速率比内核处理这些包的速率快时，允许送到队列的数据包的最大数目
net.core.netdev_max_backlog = 30000
#能够更快地回收TIME-WAIT套接字。此选项会导致处于NAT网络的客户端超时，建议为0
net.ipv4.tcp_tw_recycle = 0
#系统所有进程一共可以打开的文件数量
fs.file-max = 6815744
#防火墙跟踪表的大小。注意：如果防火墙没开则会提示error: "net.netfilter.nf_conntrack_max" is an unknown key，忽略即可

增加socket缓存区的内存大小

net.ipv4.tcp_mem  =   379008       505344  758016
net.ipv4.tcp_wmem = 4096        16384   4194304
net.ipv4.tcp_rmem = 4096          87380   4194304
net.core.wmem_default = 8388608
net.core.rmem_default = 8388608
net.core.rmem_max = 16777216
net.core.wmem_max = 16777216
net.ipv4.tcp_tw_reuse

nginx调优

当我需要进行性能优化时，说明我们服务器无法满足日益增长的业务。性能优化是一个比较大的课题，需要从以下几个方面进行探讨

• 当前系统结构瓶颈
• 了解业务模式
• 性能与安全
  1、当前系统结构瓶颈
  首先需要了解的是当前系统瓶颈，用的是什么，跑的是什么业务。里面的服务是什么样子，每个服务最大支持多少并发。比如针对nginx而言，我们处理静态资源效率最高的瓶颈是多大？能支持多少qps访问请求？怎么得出系统当前的结构瓶颈？
  可以通过查看当前cpu负荷，内存使用率，进程使用率来做简单判断。还可以通过操作系统的一些工具来判断当前系统性能瓶颈，如分析对应的日志，查看请求数量。也可以通过nginx http_stub_status_module模块来查看对应的连接数，总握手次数，总请求数。也可以对线上进行压力测试，来了解当前的系统能性能，并发数，做好性能评估。
  2、了解业务模式
  虽然我们是在做性能优化，但还是要熟悉业务，最终目的都是为业务服务的。我们要了解每一个接口业务类型是什么样的业务，比如电子商务抢购模式，这种情况平时流量会很小，但是到了抢购时间，流量一下子就会猛涨。也要了解系统层级结构，每一层在中间层做的是代理还是动静分离，还是后台进行直接服务。需要我们对业务接入层和系统层次要有一个梳理
  3、性能与安全
  性能与安全也是一个需要考虑的因素，往往大家注重性能忽略安全或注重安全又忽略性能。比如说我们在设计防火
  墙时，如果规则过于全面肯定会对性能方面有影响。如果对性能过于注重在安全方面肯定会留下很大隐患。所以大
  家要评估好两者的关系，把握好两者的孰重孰轻，以及整体的相关性。权衡好对应的点。
  4、系统与nginx性能优化
  大家对相关的系统瓶颈及现状有了一定的了解之后，就可以根据影响性能方面做一个全体的评估和优化。
  网络（网络流量、是否有丢包，网络的稳定性都会影响用户请求）
  系统（系统负载、饱和、内存使用率、系统的稳定性、硬件磁盘是否有损坏）
  服务（连接优化、内核性能优化、http服务请求优化都可以在nginx中根据业务来进行设置）
  程序（接口性能、处理请求速度、每个程序的执行效率）
  数据库、底层服务

文件句柄-用户局部性修改
如root设置为65535，其他用户按个人业务设置

一般的配置文件设置都有自己的模板，再根据业务类型进行调整
大体内容为：
将进程用户设为普通用户
work线程数=cpu核数，或者设置为auto
日志配置为warn级别等等

• 日志级别共6种（OFF、FATAL、ERROR、WARN、INFO、DEBUG、TRACE、 ALL）

   ALL 最低等级的，用于打开所有日志记录。
   
   TRACE designates finer-grained informational events than the DEBUG.Since:1.2.12，很低的日志级别，一般不会使用。
   
   DEBUG 指出细粒度信息事件对调试应用程序是非常有帮助的，主要用于开发过程中打印一些运行信息。
   
   INFO 消息在粗粒度级别上突出强调应用程序的运行过程。打印一些你感兴趣的或者重要的信息，这个可以用于生产环境中输出程序运行的一些重要信息，但是不能滥用，避免打印过多的日志。
   
   WARN 表明会出现潜在错误的情形，有些信息不是错误信息，但是也要给程序员的一些提示。
   
   ERROR 指出虽然发生错误事件，但仍然不影响系统的继续运行。打印错误和异常信息，如果不想输出太多的日志，可以使用这个级别。
   
   FATAL 指出每个严重的错误事件将会导致应用程序的退出。这个级别比较高了。重大错误，这种级别你可以直接停止程序了。
   
   OFF 最高等级的，用于关闭所有日志记录。
  

tomcat调优

一、内存调优
设置 java_OPTS 参数
　 　-server 启用jdk 的 server 版；
　　-Xms java虚拟机初始化时的最小内存；
　　 -Xmx java虚拟机可使用的最大内存；
　　 -XX: PermSize 内存永久保留区域
　　 -XX:MaxPermSize 内存最大永久保留区域
一般设置-Xms，-Xmx相等以避免在每次GC后调整堆的大小，因为默认空余堆内存小于40%时，JVM就会增大堆直到-Xmx的最大限制；空余堆内存大于70%时，JVM会减少堆直到-Xms的最小限制

优化jvm–优化垃圾回收策略
优化catalina.sh配置文件。在catalina.sh配置文件中添加以下代码

tomcat分配1G内存模板
JAVA_OPTS="
-Djava.awt.headless=true
-Dfile.encoding=UTF-8
-server
-Xms1024m
-Xmx1024m
-XX:NewSize=512m
-XX:MaxNewSize=512m
-XX:PermSize=512m
-XX:MaxPermSize=512m

每天0点定时重启tomcat

二、安全优化
1.telnet端口保护 8005—>8000-8999之间其他的端口
2.ajp连接端口保护 8009—>8000-8999之间其他的端口
通过iptables规则限制ajp端口访问的权限仅为线上机器，目的防止线下的测试流量被mod_jk转发至线上tomcat服务器
3.禁用管理端

• 删除默认的{tomcat安装目录}/conf/tomcat-user.xml文件，重启tomcat后将会自动生成新的文件

• 删除{tomcat安装}/webapps下默认的所有目录和文件

• 将tomcat应用根目录配置为tomcat安装目录以外的目录
  目的：对于前端web模块，tomcat管理端属于tomcat的高危安全隐患，一旦被攻破，黑客通过上传web shell的方式将会直接取得服务器的控制权，后果极其严重
  4.降权启动

• tomcat启动用户权限必须为非root权限，尽量降低tomcat启动用户的目录访问权限

• 如需直接对外使用80端口，可通过普通账号启动后，配置iptables规则进行转发
  5.文件列表访问控制：listingfalse
  6.版本信息隐藏
  7.访问日志格式规范

• 开启tomcat默认访问日志中的referer和user-agent记录，出现安全问题能够根据日志进行问题排查

• 异步非阻塞：
  每进来一个request，会有一个worker进程去处理。但不是全程的处理，处理到什么程度呢？处理
  到可能发生阻塞的地方，比如向上游（后端）服务器转发request，并等待请求返回。那么，这个处理
  的worker不会这么一直等着，他会在发送完请求后，注册一个事件：“如果upstream返回了，告诉我一声，
  我再接着干”。于是他就休息去了。这就是异步。此时，如果再有request 进来，他就可以很快再按这种
  方式处理。这就是非阻塞和IO多路复用。而一旦上游服务器返回了，就会触发这个事件，worker才会来
  接手，这个request才会接着往下走。这就是异步回调。