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

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

原文链接:https://www.cnblogs.com/dongguangming/p/12631517.html
如有疑问请与原作者联系

标签：

版权申明：本站文章部分自网络，如有侵权，请联系：west999com@outlook.com
特别注意：本站所有转载文章言论不代表本站观点，本站所提供的摄影照片，插画，设计作品，如需使用，请与原作者联系，版权归原作者所有