java部署要考虑的centos场景优化

      做为一名码农，咱们在windows场景开发，可实际上线时大多数时候是在linux下部署运行的，经历的一些坑在此记录下来，是通识性的知识，新秀们遇到的几率大。

      先简单介绍下，我早年是在windows xp作java开发，用的jdk1.4，tomcat5，部署上线环境是在windows server 2003 和windows server 2008场景，随着linux的普及和大众化，慢慢的转移到了centos环境中来，固然也经历了jdk版本的过渡升迁（1.4，1.6，1.8），tomcat也是如此（5,6,7），中间也用到过weblogic（国企有钱）和oracle 11g（国企有钱，中间件和数据都是正版）。

安装完干净的操做系统后（不知道如今的云环境作了优化没有，好比买了ecs），默认参数状况下Linux对高并发支持并很差，主要受限于单进程最大打开文件数限制、内核TCP参数方面和IO事件分配机制等，面就从几方面来调整使Linux系统可以支持高并发的场境。

1.  先说说出现的问题：to many open files（花了我很久排查java代码倒是os层面的），起初经过log日志排查问题时觉得是java程序自己出现的bug，到后来查阅中英文资料才知道操做系统自己也要作配置的。

在Linux平台上，不管编写客户端程序仍是服务端程序，在进行高并发TCP链接处理时，最高的并发数量都要受到系统对用户单一进程同时可打开文件数量的限制(这是由于系统为每一个TCP链接都要建立一个socket句柄，每一个socket句柄同时也是一个文件句柄)。可以使用ulimit命令查看系统容许当前用户进程打开的文件数限制：

对于java级别的开发人员非系统管理员，务必要关注下参数：open files和 max user processes。

open files: 表示当前用户的每一个进程最多容许同时打开1024个文件，这1024个文件中还得除去每一个进程必然打开的标准输入，标准输出，标准错误，服务器监听 socket，进程间通信的unix域socket等文件，那么剩下的可用于客户端socket链接的文件数就只有大概1024-10=1014个左右。也就是说缺省状况下，基于Linux的通信程序最多容许同时1014个TCP并发链接。

对于想支持更高数量的TCP并发链接的通信处理程序，就必须修改Linux对当前用户的进程同时打开的文件数量的软限制(soft limit)和硬限制(hardlimit)。其中软限制是指Linux在当前系统可以承受的范围内进一步限制用户同时打开的文件数；硬限制则是根据系统硬件资源情况(主要是系统内存)计算出来的系统最多可同时打开的文件数量。一般软限制小于或等于硬限制。

Java进程file descriptor table中FD的总量能够经过命令 lsof -p $java_pid | wc -l 查到。

 可经过如下方式修改该值：

第一步：编辑 /etc/security/limits.conf ，增长内容

vi /etc/security/limits.conf
#键入
* soft nofile 4096  
* hard nofile 4096 
#而后保存

’注： *’号表示修改全部用户（也能够指定具体用户，好比有的中间件转完后会建立默认用户）的限制；soft或hard指定要修改软限制仍是硬限制；4096则指定了想要修改的新的限制值，即最大打开文件数(请注意软限制值要小于或等于硬限制)。修改完后保存文件。

第二步，编辑/etc/pam.d/login文件，在文件中添加以下行：

vi /etc/pam.d/login
#增长
session required /lib/security/pam_limits.so

这是告诉Linux在用户完成系统登陆后，应该调用pam_limits.so模块来设置系统对该用户可以使用的各类资源数量的最大限制(包括用户可打开的最大文件数限制)，而pam_limits.so模块就会从/etc/security/limits.conf文件中读取配置来设置这些限制值。修改完后保存此文件。

第三步，查看Linux系统级的最大打开文件数限制，使用以下命令：

cat /proc/sys/fs/file-max
#输出187932

该值代表这台Linux系统最多容许同时打开(即包含全部用户打开文件数总和)文件数，是Linux系统级硬限制，全部用户级的打开文件数限制都不该超过这个数值。一般这个系统级硬限制是Linux系统在启动时根据系统硬件资源情况计算出来的最佳的最大同时打开文件数限制。

若是没有特殊须要，不该该修改此限制，除非想为用户级打开文件数限制设置超过此限制的值。修改此硬限制的方法是修改/etc/sysctl.conf文件内fs.file-max= 187932

这是让Linux在启动完成后强行将系统级打开文件数硬限制设置为187932。修改完后保存此文件。

完成上述步骤后重启系统，通常状况下就能够将Linux系统对指定用户的单一进程容许同时打开的最大文件数限制设为指定的数值。若是重启后用ulimit-n命令查看用户可打开文件数限制仍然低于上述步骤中设置的最大值，这多是由于在用户登陆脚本/etc/profile中使用ulimit-n命令已经将用户可同时打开的文件数作了限制。因为经过ulimit-n修改系统对用户可同时打开文件的最大数限制时，新修改的值只能小于或等于上次ulimit-n设置的值，所以想用此命令增大这个限制值是不可能的。因此，若是有上述问题存在，就只能去打开/etc/profile脚本文件，在文件中查找是否使用了ulimit-n限制了用户可同时打开的最大文件数量，若是找到，则删除这行命令，或者将其设置的值改成合适的值，而后保存文件，用户退出并从新登陆系统便可。

至此，就为支持高并发TCP链接处理的通信处理程序解除关于打开文件数量方面的系统限制。

2.  网络方面，出现大量的tcp链接不上

在Linux上编写支持高并发TCP链接的客户端通信处理程序时，有时会发现尽管已经解除了系统对用户同时打开文件数的限制，但仍会出现并发TCP链接数增长到必定数量时，再也没法成功创建新的TCP链接的现象。出现这种如今的缘由有多种。

第一种状况：多是由于Linux网络内核对本地端口号范围有限制。此时，进一步分析为何没法创建TCP链接，会发现问题出在connect()调用返回失败，查看系统错误提示消息是“Can’t assign requested address”。同时，若是在此时用tcpdump工具监视网络，会发现根本没有TCP链接时客户端发SYN包的网络流量。这些状况说明问题在于本地Linux系统内核中有限制。其实，问题的根本缘由在于Linux内核的TCP/ip协议实现模块对系统中全部的客户端TCP链接对应的本地端口号的范围进行了限制(例如，内核限制本地端口号的范围为1024~32768之间)。

当系统中某一时刻同时存在太多的TCP客户端链接时，因为每一个TCP客户端链接都要占用一个惟一的本地端口号(此端口号在系统的本地端口号范围限制中)，若是现有的TCP客户端链接已将全部的本地端口号占满，则此时就没法为新的TCP客户端链接分配一个本地端口号了，所以系统会在这种状况下在connect()调用中返回失败，并将错误提示消息设为“Can’t assign requested address”。有关这些控制逻辑能够查看Linux内核源代码，以linux2.6内核为例，能够查看tcp_ipv4.c文件中以下函数：

static int tcp_v4_hash_connect(struct sock *sk)

请注意上述函数中对变量sysctl_local_port_range的访问控制。变量sysctl_local_port_range的初始化则是在tcp.c文件中的以下函数中设置：

void __init tcp_init(void)

内核编译时默认设置的本地端口号范围可能过小，所以须要修改此本地端口范围限制。

第一步，修改/etc/sysctl.conf文件，在文件中添加以下行：

vi /etc/sysctl.conf
#添加
net.ipv4.ip_local_port_range = 1024 65000

这代表将系统对本地端口范围限制设置为1024~65000之间。请注意，本地端口范围的最小值必须大于或等于1024；而端口范围的最大值则应小于或等于65535。修改完后保存此文件。

第二步，执行sysctl命令：

sysctl -p

若是系统没有错误提示，就代表新的本地端口范围设置成功。若是按上述端口范围进行设置，则理论上单独一个进程最多能够同时创建60000多个TCP客户端链接。

第二种状况：没法创建TCP链接的缘由多是由于Linux网络内核的IP_TABLE防火墙对最大跟踪的TCP链接数有限制。此时程序会表现为在 connect()调用中阻塞，如同死机，若是用tcpdump工具监视网络，也会发现根本没有TCP链接时客户端发SYN包的网络流量。因为 IP_TABLE防火墙在内核中会对每一个TCP链接的状态进行跟踪，跟踪信息将会放在位于内核内存中的conntrack database中，这个数据库的大小有限，当系统中存在过多的TCP链接时，数据库容量不足，IP_TABLE没法为新的TCP链接创建跟踪信息，因而表现为在connect()调用中阻塞。此时就必须修改内核对最大跟踪的TCP链接数的限制，方法同修改内核对本地端口号范围的限制是相似的：

第一步，修改/etc/sysctl.conf文件，在文件中添加以下行：

vi /etc/sysctl.conf
#追加
net.ipv4.ip_conntrack_max = 10240

这代表将系统对最大跟踪的TCP链接数限制设置为10240。请注意，此限制值要尽可能小，以节省对内核内存的占用。

第二步，执行sysctl命令：

sysctl -p

若是系统没有错误提示，就代表系统对新的最大跟踪的TCP链接数限制修改为功。若是按上述参数进行设置，则理论上单独一个进程最多能够同时创建10000多个TCP客户端链接。

第三种状况： TCP链接断开后，会以TIME_WAIT状态保留必定的时间，而后才会释放端口。当并发请求过多的时候，就会产生大量的TIME_WAIT状态的链接，没法及时断开的话，会占用大量的端口资源和服务器资源。这个时候咱们能够优化TCP的内核参数，来及时将TIME_WAIT状态的端口清理掉。

下面介绍的方法只对拥有大量TIME_WAIT状态的链接致使系统资源消耗有效，若是不是这种状况下，效果可能不明显。可使用netstat命令去查TIME_WAIT状态的链接状态，输入下面的组合命令，查看当前TCP链接的状态和对应的链接数量：

netstat -n | awk '/^tcp/ {++S[$NF]} END {for(a in S) print a, S[a]}'

这个命令会输出相似下面的结果：

LAST_ACK16

SYN_RECV348

ESTABLISHED70

FIN_WAIT1229

FIN_WAIT230

CLOSING33

TIME_WAIT18098

咱们只用关心TIME_WAIT的个数，在这里能够看到，有18000多个TIME_WAIT，这样就占用了18000多个端口。要知道端口的数量只有65535个，占用一个少一个，会严重的影响到后继的新链接。这种状况下，咱们就有必要调整下Linux的TCP内核参数，让系统更快的释放TIME_WAIT链接。

编辑配置文件:/etc/sysctl.conf，在这个文件中，加入下面的几行内容：

# 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

输入下面的命令，让内核参数生效：

# sysctl-p

简单的说明上面的参数的含义：

net.ipv4.tcp_syncookies= 1

表示开启SYNCookies。当出现SYN等待队列溢出时，启用cookies来处理，可防范少许SYN攻击，默认为0，表示关闭；

net.ipv4.tcp_tw_reuse= 1

表示开启重用。容许将TIME-WAIT sockets从新用于新的TCP链接，默认为0，表示关闭；

net.ipv4.tcp_tw_recycle= 1

表示开启TCP链接中TIME-WAITsockets的快速回收，默认为0，表示关闭；

net.ipv4.tcp_fin_timeout

修改系統默认的TIMEOUT 时间。

在通过这样的调整以后，除了会进一步提高服务器的负载能力以外，还可以防护小流量程度的DoS、CC和SYN攻击。

此外，若是你的链接数自己就不少，咱们能够再优化一下TCP的可以使用端口范围，进一步提高服务器的并发能力。依然是往上面的参数文件中，加入下面这些配置：

net.ipv4.tcp_keepalive_time= 1200

net.ipv4.ip_local_port_range= 1024 65535

net.ipv4.tcp_max_syn_backlog= 8192

net.ipv4.tcp_max_tw_buckets= 5000

这几个参数，建议只在流量很是大的服务器上开启，会有显著的效果。通常的流量小的服务器上，没有必要去设置这几个参数。

net.ipv4.tcp_keepalive_time= 1200

表示当keepalive起用的时候，TCP发送keepalive消息的频度。缺省是2小时，改成20分钟。

ip_local_port_range= 1024 65535

表示用于向外链接的端口范围。缺省状况下很小，改成1024到65535。

net.ipv4.tcp_max_syn_backlog= 8192

表示SYN队列的长度，默认为1024，加大队列长度为8192，能够容纳更多等待链接的网络链接数。

net.ipv4.tcp_max_tw_buckets= 5000

表示系统同时保持TIME_WAIT的最大数量，若是超过这个数字，TIME_WAIT将马上被清除并打印警告信息。默认为180000，改成5000。此项参数能够控制TIME_WAIT的最大数量，只要超出了。

net.ipv4.tcp_max_syn_backlog= 65536

记录的那些还没有收到客户端确认信息的链接请求的最大值。对于有128M内存的系统而言，缺省值是1024，小内存的系统则是128。

net.core.netdev_max_backlog= 32768

每一个网络接口接收数据包的速率比内核处理这些包的速率快时，容许送到队列的数据包的最大数目。

net.core.somaxconn= 32768

例如web应用中listen函数的backlog默认会给咱们内核参数的net.core.somaxconn限制到128，而nginx定义的NGX_LISTEN_BACKLOG默认为511，因此有必要调整这个值。

net.core.wmem_default= 8388608

net.core.rmem_default= 8388608

net.core.rmem_max= 16777216 #最大socket读buffer,可参考的优化值:873200

net.core.wmem_max= 16777216 #最大socket写buffer,可参考的优化值:873200

net.ipv4.tcp_timestsmps= 0

时间戳能够避免序列号的卷绕。一个1Gbps的链路确定会遇到之前用过的序列号。时间戳可以让内核接受这种“异常”的数据包。这里须要将其关掉。

net.ipv4.tcp_synack_retries= 2

为了打开对端的链接，内核须要发送一个SYN并附带一个回应前面一个SYN的ACK。也就是所谓三次握手中的第二次握手。这个设置决定了内核放弃链接以前发送SYN+ACK包的数量。

net.ipv4.tcp_syn_retries= 2

在内核放弃创建链接以前发送SYN包的数量。

#net.ipv4.tcp_tw_len= 1

net.ipv4.tcp_tw_reuse= 1

开启重用。容许将TIME-WAITsockets从新用于新的TCP链接。

net.ipv4.tcp_wmem= 8192 436600 873200

TCP写buffer,可参考的优化值:8192 436600 873200

net.ipv4.tcp_rmem = 32768 436600 873200

TCP读buffer,可参考的优化值:32768 436600 873200

net.ipv4.tcp_mem= 94500000 91500000 92700000

一样有3个值,意思是:

net.ipv4.tcp_mem[0]:低于此值，TCP没有内存压力。

net.ipv4.tcp_mem[1]:在此值下，进入内存压力阶段。

net.ipv4.tcp_mem[2]:高于此值，TCP拒绝分配socket。

上述内存单位是页，而不是字节。可参考的优化值是:7864321048576 1572864

net.ipv4.tcp_max_orphans= 3276800

系统中最多有多少个TCP套接字不被关联到任何一个用户文件句柄上。

若是超过这个数字，链接将即刻被复位并打印出警告信息。

这个限制仅仅是为了防止简单的DoS攻击，不能过度依靠它或者人为地减少这个值，

更应该增长这个值(若是增长了内存以后)。

net.ipv4.tcp_fin_timeout= 30

若是套接字由本端要求关闭，这个参数决定了它保持在FIN-WAIT-2状态的时间。对端能够出错并永远不关闭链接，甚至意外当机。缺省值是60秒。2.2 内核的一般值是180秒，你能够按这个设置，但要记住的是，即便你的机器是一个轻载的WEB服务器，也有由于大量的死套接字而内存溢出的风险，FIN-WAIT-2的危险性比FIN-WAIT-1要小，由于它最多只能吃掉1.5K内存，可是它们的生存期长些。

同时还涉及到一个TCP 拥塞算法的问题，你能够用下面的命令查看本机提供的拥塞算法控制模块：

sysctlnet.ipv4.tcp_available_congestion_control

对于几种算法的分析，详情能够参考下：TCP拥塞控制算法的优缺点、适用环境、性能分析，好比高延时能够试用hybla，中等延时能够试用htcp算法等。

若是想设置TCP 拥塞算法为hybla

net.ipv4.tcp_congestion_control=hybla

额外的，对于内核版高于于3.7.1的，咱们能够开启tcp_fastopen：

net.ipv4.tcp_fastopen= 3

三、使用支持高并发网络I/O的编程技术（可参考Unix网络编程一书）

在Linux上编写高并发TCP链接应用程序时，必须使用合适的网络I/O技术和I/O事件分派机制。

可用的I/O技术有同步I/O，非阻塞式同步I/O(也称反应式I/O)，以及异步I/O。在高TCP并发的情形下，若是使用同步I/O，这会严重阻塞程序的运转，除非为每一个TCP链接的I/O建立一个线程。可是，过多的线程又会因系统对线程的调度形成巨大开销。所以，在高TCP并发的情形下使用同步 I/O是不可取的，这时能够考虑使用非阻塞式同步I/O或异步I/O。非阻塞式同步I/O的技术包括使用select()，poll()，epoll等机制。异步I/O的技术就是使用AIO。

从I/O事件分派机制来看，使用select()是不合适的，由于它所支持的并发链接数有限(一般在1024个之内)。若是考虑性能，poll()也是不合适的，尽管它能够支持的较高的TCP并发数，可是因为其采用“轮询”机制，当并发数较高时，其运行效率至关低，并可能存在I/O事件分派不均，致使部分TCP链接上的I/O出现“饥饿”现象。而若是使用epoll或AIO，则没有上述问题(早期Linux内核的AIO技术实现是经过在内核中为每一个 I/O请求建立一个线程来实现的，这种实现机制在高并发TCP链接的情形下使用其实也有严重的性能问题。但在最新的Linux内核中，AIO的实现已经获得改进)。

综上所述，在开发支持高并发TCP链接的Linux应用程序时，应尽可能使用epoll或AIO技术来实现并发的TCP链接上的I/O控制，这将为提高程序对高并发TCP链接的支持提供有效的I/O保证。

4. 日志里出现了“ java.lang.OutOfMemoryError: ”

从两方面论述，操做系统和java方面

4.1  操做系统配置

一开始的印象是java应用程序代码的问题，也颇有概率是系统没有作参数优化，继续编辑 /etc/security/limits.conf 文件

vi /etc/security/limits.conf
#追加
• soft nproc 81920

• hard nproc 81920

注： * 表示全部用户，soft、hard表示软限制、硬限制。（软限制<=硬限制）

4.2  jvm方面的参数配置

jvm结构图：

1,JVM内存划分分为年轻代（Young Generation）、老年代（Old Generation）、永久代（Permanent Generation）。
2,年轻代又分为Eden和Survivor区。Survivor区由FromSpace和ToSpace组成。Eden区占大容量，Survivor两个区占小容量，默认比例大概是8:2。
3,堆内存（Heap）=年轻代+老年代。非堆内存=永久代。
4,堆内存用途：存放的是对象，垃圾收集器就是收集这些对象，而后根据GC算法回收。
5,非堆内存用途：JVM自己使用，存放一些类、方法、常量、属性等。
6,年轻代：新生成的对象首先放到年轻代的Eden区中，当Eden满时，通过GC后，还存活的对象被复制到Survivor区的FromSpace中，若是Survivor区满时，会再被复制到Survivor区的ToSpace区。若是还有存活对象，会再被复制到老年代。
7,老年代：在年轻代中通过GC后还存活的对象会被复制到老年代中。当老年代空间不足时，JVM会对老年代进行彻底的垃圾回收（Full GC）。若是GC后，仍是没法存放从Survivor区复制过来的对象，就会出现OOM（Out of Memory）。
8,永久代：也称为方法区，存放静态类型数据，好比类、方法、属性等。

JVM内存设置不是越大越好，具体仍是根据项目对象实际占用内存大小而定，能够经过Java自带的分析工具来查看。若是设置过大，会增长回收时间，从而增长暂停应用时间，并且从未遇到过专门弄台服务器跑java程序，都是混合式场景跑着数据库，tomcat，nginx等 

#按需配置优化，这只是参考
JAVA_OPTS="-server-Xms1024m -Xmx1536m -XX:PermSize=256m -XX:MaxPermSize=512m-XX:+UseConcMarkSweepGC -XX:+UseParallelGCThreads=8XX:CMSInitiatingOccupancyFraction=80 -XX:+UseCMSCompactAtFullCollection-XX:CMSFullGCsBeforeCompaction=0 -XX:-PrintGC -XX:-PrintGCDetails-XX:-PrintGCTimeStamps -Xloggc:/log/java.log"

5.  经过tomcat（开源免费）优化配置，略

#只是参考，实际场景看须要
<Connectorport="8080"protocol="org.apache.coyote.http11.Http11NioProtocol"
               maxThreads="1000"
               minSpareThreads="100"
               maxSpareThreads="200"
               acceptCount="900"
               disableUploadTimeout="true"
              connectionTimeout="20000"
               URIEncoding="UTF-8"
               enableLookups="false"
               redirectPort="8443"
               compression="on"
              compressionMinSize="1024"
              compressableMimeType="text/html,text/xml,text/css,text/javascript"/>

参数说明：
org.apache.coyote.http11.Http11NioProtocol：调整工做模式为Nio
maxThreads：最大线程数，默认150。增大值避免队列请求过多，致使响应缓慢。
minSpareThreads：最小空闲线程数。
maxSpareThreads：最大空闲线程数，若是超过这个值，会关闭无用的线程。
acceptCount：当处理请求超过此值时，将后来请求放到队列中等待。
disableUploadTimeout：禁用上传超时时间
connectionTimeout：链接超时，单位毫秒，0表明不限制
URIEncoding：URI地址编码使用UTF-8
enableLookups：关闭dns解析，提升响应时间
compression：启用压缩功能
compressionMinSize：最小压缩大小，单位Byte
compressableMimeType：压缩的文件类型

Tomcat有三种工做模式：Bio、Nio和Apr

下面简单了解下他们工做原理：

Bio(BlockingI/O)：默认工做模式，阻塞式I/O操做，没有任何优化技术处理，性能比较低。
Nio(New I/O orNon-Blocking)：非阻塞式I/O操做，有Bio有更好的并发处理性能。
Apr(ApachePortable Runtime，Apache可移植运行库)：首选工做模式，主要为上层的应用程序提供一个能够跨越多操做系统平台使用的底层支持接口库。
tomcat利用基于Apr库tomcat-native来实现操做系统级别控制，提供一种优化技术和非阻塞式I/O操做，大大提升并发处理能力。可是须要安装apr和tomcat-native库。

附一份参考 内核参数sysctl.conf （实际场景中作调整）：

net.ipv4.ip_local_port_range = 1024 65536
net.core.rmem_max=16777216
net.core.wmem_max=16777216
net.ipv4.tcp_rmem=4096 87380 16777216
net.ipv4.tcp_wmem=4096 65536 16777216
net.ipv4.tcp_fin_timeout = 10
net.ipv4.tcp_tw_recycle = 1
net.ipv4.tcp_timestamps = 0
net.ipv4.tcp_window_scaling = 0
net.ipv4.tcp_sack = 0
net.core.netdev_max_backlog = 30000
net.ipv4.tcp_no_metrics_save=1
net.core.somaxconn = 262144
net.ipv4.tcp_syncookies = 0
net.ipv4.tcp_max_orphans = 262144
net.ipv4.tcp_max_syn_backlog = 262144
net.ipv4.tcp_synack_retries = 2
net.ipv4.tcp_syn_retries = 2

总结基本上完毕，若有新状况接着写。。。学好linux，对java从业人员有益无害，推荐两本书《深刻理解计算机系统》和Unix网络编程卷1