相关问题排查参数或方法

jmc 远程连接 java启动增加如下参数
-Dcom.sun.management.jmxremote.port=7091 
-Dcom.sun.management.jmxremote.authenticate=false 
-Dcom.sun.management.jmxremote.ssl=false
可以分析堆内存  cpu等

TCP

netstat -ant  
CLOSED：无连接是活动的或正在进行
LISTEN：服务器在等待进入呼叫
SYN_RECV：一个连接请求已经到达，等待确认
SYN_SENT：应用已经开始，打开一个连接
ESTABLISHED：正常数据传输状态
FIN_WAIT1：应用说它已经完成
FIN_WAIT2：另一边已同意释放
ITMED_WAIT：等待所有分组死掉
CLOSING：两边同时尝试关闭
TIME_WAIT：另一边已初始化一个释放
LAST_ACK：等待所有分组死掉

net.ipv4.tcp_syncookies = 1 表示开启SYN Cookies。当出现SYN等待队列溢出时，启用cookies来处理，可防范少量SYN攻击，默认为0，表示关闭；
net.ipv4.tcp_tw_reuse = 1 表示开启重用。允许将TIME-WAIT sockets重新用于新的TCP连接，默认为0，表示关闭；
net.ipv4.tcp_tw_recycle = 1 表示开启TCP连接中TIME-WAIT sockets的快速回收，默认为0，表示关闭。
net.ipv4.tcp_fin_timeout 修改系默认的 TIMEOUT 时间

net.ipv4.tcp_keepalive_time = 1200 
#表示当keepalive起用的时候，TCP发送keepalive消息的频度。缺省是2小时，改为20分钟。
net.ipv4.ip_local_port_range = 1024 65000 
#表示用于向外连接的端口范围。缺省情况下很小：32768到61000，改为1024到65000。
net.ipv4.tcp_max_syn_backlog = 8192 
#表示SYN队列的长度，默认为1024，加大队列长度为8192，可以容纳更多等待连接的网络连接数。
net.ipv4.tcp_max_tw_buckets = 5000 
#表示系统同时保持TIME_WAIT套接字的最大数量，如果超过这个数字，TIME_WAIT套接字将立刻被清除并打印警告信息。
默认为180000，改为5000。对于Apache、Nginx等服务器，上几行的参数可以很好地减少TIME_WAIT套接字数量，但是对于 Squid，效果却不大。此项参数可以控制TIME_WAIT套接字的最大数量，避免Squid服务器被大量的TIME_WAIT套接字拖死

vi /etc/sysctl.conf
增加net.ipv4.tcp_tw_recycle = 1
表示开启TCP连接中TIME-WAIT sockets的快速回收，默认为0，表示关闭。实在吃不消不得已才开启。

net.ipv4.tcp_tw_reuse = 1
Tcp TIME_WAIT 端口重用，推荐打开，默认为0，表示关闭，打开后允许将TIME-WAIT sockets重新用于新的TCP连接。

net.ipv4.tcp_fin_timeout = 10
修改系統默认的 TIMEOUT 时间，默认为60，这个参数决定了它保持在FIN-WAIT-2状态的时间。

net.ipv4.tcp_keepalive_time = 30
表示当keepalive启用的时候，TCP发送keepalive消息的频度。缺省是2小时，改为30秒。

net.ipv4.ip_local_port_range = 1025 64511
表示用于向外连接的端口范围。缺省情况下很小：32768到61000，改为1025到64511。

net.ipv4.tcp_max_syn_backlog = 8192
表示SYN队列的长度，默认为1024，加大队列长度为8192，可以容纳更多等待连接(SYN_RECV)的网络连接数。
通过dmesg可以确认是否有该情况发生 dmesg | grep "TCP: drop open request from"，可以用命令 netstat -ant|grep SYN_RECV|wc -l 查看具体大小，大多数情况下这个值应该是0或很小，因为半连接状态从第一次握手完成时进入，第三次握手完成后退出，正常的网络环境中这个过程发生很快，如果这个值较大，服务器极有可能受到了SYN Flood攻击。
另外，上述行为受到内核参数tcp_syncookies的影响，若启用syncookie机制，当半连接队列溢出时，并不会直接丢弃SYN包，而是回复带有syncookie的SYC+ACK包，设计的目的是防范SYN Flood造成正常请求服务不可用。

net.ipv4.tcp_max_tw_buckets = 5000
表示系统同时保持TIME_WAIT套接字的最大数量，如果超过这个数字，TIME_WAIT套接字将立刻被清除并打印警告信息/var/log/messages。默认为180000，改为5000。

net.ipv4.tcp_syn_retries = 1
对于一个新建连接，内核要发送多少个 SYN 连接请求才决定放弃。不应该大于255，默认值是5

net.ipv4.tcp_window_scaling = 0
TCP窗口自动调节，如果TCP窗口最大超过65535(64K)，必须设置该数值为1，否则访问速度会严重下降，默认值1，设置0关闭。

net.ipv4.tcp_sack = 0
有选择的应答，默认1，设置0关闭。

net.ipv4.tcp_syncookies = 1 表示开启SYN Cookies。当出现SYN等待队列溢出时，启用cookies来处理，可防范少量SYN攻击，默认为0，表示关闭；
net.ipv4.tcp_tw_reuse = 1 表示开启重用 允许将TIME-WAIT sockets重新用于新的TCP 连接默认为0 表示关闭
net.ipv4.tcp_tw_recycle = 1 表示开启TCP连接中TIME-WAIT sockets的快速回收，默认为0，表示关闭。
net.ipv4.tcp_fin_timeout 修改系統默认的 TIMEOUT 时间

然后执行 /sbin/sysctl -p 让参数生效

查看tcp连接数 netstat -nalpt | grep 3306 |wc -l

一、查看服务器的内存和服务器核数大小
①查看服务器内存大小

cat /proc/meminfo | grep MemTotal

②查看服务器核数

总核数 = 物理CPU个数 * 每个物理CPU的核数

查看CPU的个数：

cat /proc/cpuinfo| grep "physical id"| sort| uniq| wc -l

查看每个CPU中core的个数

cat /proc/cpuinfo| grep "cpu cores"| uniq

二、查看服务器的负载
在确定CPU的内存和CPU核数后，就可以进一步观察服务器的负载

Linux的负载高，主要是由于CPU使用、内存使用、IO消耗三部分引起的。其中任何一项的急剧增加，都会使得服务器的负载急剧升高

top:查看服务器的负载

第一行：

top - 14:50:58 up 16:46,  2 users,  load average: 1.15, 0.63, 0.44
14:50:58 ：系统当前时间 
up 16:46 ：系统开机到现在经过了2天 
2 users：当前1用户在线 
load average: 1.15, 0.63, 0.44：系统1分钟、5分钟、15分钟的CPU负载信息. 
备注：load average后面三个数值的含义是最近1分钟、最近5分钟、最近15分钟系统的负载值。这个值的意义是，单位时间段内CPU活动进程数。如果你的机器为单核，那么只要这几个值均<1，代表系统就没有负载压力，如果你的机器为N核，那么必须是这几个值均＜N才可认为系统没有负载压力。

第二行解释： 
Tasks: 147 total,   1 running, 146 sleeping,   0 stopped,   0 zombie
147 total,：当前有108个任务 
1 running：1个任务正在运行 
46 sleeping,：107个进程处于睡眠状态 
  0 stopped：停止的进程数 
0 zombie：僵死的进程数

第三行解释： 
Cpu(s):  1.7%us,  0.2%sy,  0.0%ni, 95.6%id,  2.3%wa,  0.1%hi,  0.1%si,  0.0%st
1.7%us：用户态进程占用CPU时间百分比 
0.2%sy,：内核占用CPU时间百分比 
 0.0%ni：renice值为负的任务的用户态进程的CPU时间百分比。nice是优先级的意思 
95.6%id：空闲CPU时间百分比 
2.3%wa：等待I/O的CPU时间百分比 
0.1%hi：CPU硬中断时间百分比 
0.1%si：CPU软中断时间百分比

st 虚拟机偷取时间

 

第四行解释： 
Mem:  32959108k total, 32783520k used,   175588k free,   291084k buffers
32959108k total：物理内存总数 
32783520k used： 使用的物理内存 
175588k free：空闲的物理内存 
291084k buffers：用作缓存的内存

第五行解释： 
Swap:  4194296k total,      148k used,  4194148k free, 10365856k cached
4194296k total：交换空间的总量 
148k used： 使用的交换空间 
4194148k free：空闲的交换空间 
10365856k cached：缓存的交换空间

当服务器的一些性能指标都良好的情况下，就要排查数据库方面

如下配置是写在sysctl.conf中，可使用sysctl -p生效，
相关参数仅供参考，具体数值还需要根据机器性能，应用场景等实际情况来做更细微调整。

 
net.core.netdev_max_backlog = 400000
#该参数决定了，网络设备接收数据包的速率比内核处理这些包的速率快时，允许送到队列的数据包的最大数目。

net.core.optmem_max = 10000000
#该参数指定了每个套接字所允许的最大缓冲区的大小

net.core.rmem_default = 10000000
#指定了接收套接字缓冲区大小的缺省值（以字节为单位）。

net.core.rmem_max = 10000000
#指定了接收套接字缓冲区大小的最大值（以字节为单位）。

net.core.somaxconn = 100000
#Linux kernel参数，表示socket监听的backlog(监听队列)上限

net.core.wmem_default = 11059200
#定义默认的发送窗口大小；对于更大的 BDP 来说，这个大小也应该更大。

net.core.wmem_max = 11059200
#定义发送窗口的最大大小；对于更大的 BDP 来说，这个大小也应该更大。

net.ipv4.conf.all.rp_filter = 1
net.ipv4.conf.default.rp_filter = 1
#严谨模式 1 (推荐)
#松散模式 0

net.ipv4.tcp_congestion_control = bic
#默认推荐设置是 htcp

net.ipv4.tcp_window_scaling = 0
#关闭tcp_window_scaling
#启用 RFC 1323 定义的 window scaling；要支持超过 64KB 的窗口，必须启用该值。

net.ipv4.tcp_ecn = 0
#把TCP的直接拥塞通告(tcp_ecn)关掉

net.ipv4.tcp_sack = 1
#关闭tcp_sack
#启用有选择的应答（Selective Acknowledgment），
#这可以通过有选择地应答乱序接收到的报文来提高性能（这样可以让发送者只发送丢失的报文段）；
#（对于广域网通信来说）这个选项应该启用，但是这会增加对 CPU 的占用。

net.ipv4.tcp_max_tw_buckets = 10000
#表示系统同时保持TIME_WAIT套接字的最大数量

net.ipv4.tcp_max_syn_backlog = 8192
#表示SYN队列长度，默认1024，改成8192，可以容纳更多等待连接的网络连接数。

net.ipv4.tcp_syncookies = 1
#表示开启SYN Cookies。当出现SYN等待队列溢出时，启用cookies来处理，可防范少量SYN攻击，默认为0，表示关闭；

net.ipv4.tcp_timestamps = 1
#开启TCP时间戳
#以一种比重发超时更精确的方法（请参阅 RFC 1323）来启用对 RTT 的计算；为了实现更好的性能应该启用这个选项。

net.ipv4.tcp_tw_reuse = 1
#表示开启重用。允许将TIME-WAIT sockets重新用于新的TCP连接，默认为0，表示关闭；

net.ipv4.tcp_tw_recycle = 1
#表示开启TCP连接中TIME-WAIT sockets的快速回收，默认为0，表示关闭。

net.ipv4.tcp_fin_timeout = 10
#表示如果套接字由本端要求关闭，这个参数决定了它保持在FIN-WAIT-2状态的时间。

net.ipv4.tcp_keepalive_time = 1800
#表示当keepalive起用的时候，TCP发送keepalive消息的频度。缺省是2小时，改为30分钟。

net.ipv4.tcp_keepalive_probes = 3
#如果对方不予应答，探测包的发送次数

net.ipv4.tcp_keepalive_intvl = 15
#keepalive探测包的发送间隔

net.ipv4.tcp_mem
#确定 TCP 栈应该如何反映内存使用；每个值的单位都是内存页（通常是 4KB）。
#第一个值是内存使用的下限。
#第二个值是内存压力模式开始对缓冲区使用应用压力的上限。
#第三个值是内存上限。在这个层次上可以将报文丢弃，从而减少对内存的使用。对于较大的 BDP 可以增大这些值（但是要记住，其单位是内存页，而不是字节）。

net.ipv4.tcp_rmem
#与 tcp_wmem 类似，不过它表示的是为自动调优所使用的接收缓冲区的值。

net.ipv4.tcp_wmem = 30000000 30000000 30000000
#为自动调优定义每个 socket 使用的内存。
#第一个值是为 socket 的发送缓冲区分配的最少字节数。
#第二个值是默认值（该值会被 wmem_default 覆盖），缓冲区在系统负载不重的情况下可以增长到这个值。
#第三个值是发送缓冲区空间的最大字节数（该值会被 wmem_max 覆盖）。

net.ipv4.ip_local_port_range = 1024 65000
#表示用于向外连接的端口范围。缺省情况下很小：32768到61000，改为1024到65000。

net.ipv4.netfilter.ip_conntrack_max=204800
#设置系统对最大跟踪的TCP连接数的限制

net.ipv4.tcp_slow_start_after_idle = 0
#关闭tcp的连接传输的慢启动，即先休止一段时间，再初始化拥塞窗口。

net.ipv4.route.gc_timeout = 100
#路由缓存刷新频率，当一个路由失败后多长时间跳到另一个路由，默认是300。

net.ipv4.tcp_syn_retries = 1
#在内核放弃建立连接之前发送SYN包的数量。

net.ipv4.icmp_echo_ignore_broadcasts = 1
# 避免放大攻击

net.ipv4.icmp_ignore_bogus_error_responses = 1
# 开启恶意icmp错误消息保护

net.inet.udp.checksum=1
#防止不正确的udp包的攻击

net.ipv4.conf.default.accept_source_route = 0
#是否接受含有源路由信息的ip包。参数值为布尔值，1表示接受，0表示不接受。
#在充当网关的linux主机上缺省值为1，在一般的linux主机上缺省值为0。
#从安全性角度出发，建议你关闭该功能。

带宽跑满或跑高的分析处理
对于正常进程导致的带宽跑满或跑高的问题，需要对服务器的带宽进行升级。对于异常进程，有可能是由于恶意程序问题，或者是部分 IP 恶意访问导致，也可能是服务遭到了 CC 攻击。

通常情况下，您可以使用 iftop 工具或 nethogs 查看流量的占用情况，进而定位到具体的进程。

使用 iftop 工具排查
在服务器内部安装 iftop 流量监控工具。

yum install iftop -y

服务器外网带宽被占满时，如果通过远程无法登陆，可通过阿里云终端管理进入到服务器内部，运行下面命令查看流量占用情况：

 
注意：-P 参数将会显示请求端口。执行 iftop -i eth0 -P 命令，可以查看通过服务器哪个端口建立的连接，以及内网流量。举例如下：

iftop -i eth1 -P

执行 netstat 命令反查 53139 端口对应的进程。

 
4

netstat -tunlp |grep 53139

经反查，服务器上 vsftpd 服务产生大量流量，您可以通过停止服务或使用 iptables 服务来对指定地址进行处理，如屏蔽 IP 地址或限速，以保证服务器带宽能够正常使用。

使用 nethogs 进行排查
在服务器内部安装 nethogs 流量监控工具。

 
yum install nethogs -y

通过 nethogs 工具来查看网卡上进程级的流量信息，若未安装可以通过 yum、apt-get 等方式安装。举例如下：

若 eth1 网卡跑满，执行命令 nethogs eth1。

查看每个进程的网络带宽情况以及进程对应的 PID。

确定导致带宽跑满或跑高的具体进程。

5

若进程确定是恶意程序，可以通过执行 kill -TERM <PID> 来终止程序。

说明： 如果是 Web 服务程序，您可以使用 iftop 等工具来查询具体 IP 来源，然后分析 Web 访问日志是否为正常流量。日志分析可以使用 logwatch 或 awstats 等工具进行。

安装iftop 
安装方法1、编译安装

如果采用编译安装可以到iftop官网下载最新的源码包。

安装前需要已经安装好基本的编译所需的环境，比如make、gcc、autoconf等。安装iftop还需要安装libpcap和libcurses。

CentOS上安装所需依赖包：

yum install flex byacc  libpcap ncurses ncurses-devel libpcap-devel

Debian上安装所需依赖包：

apt-get install flex byacc  libpcap0.8 libncurses5

下载iftop

wget  http://www.ex-parrot.com/pdw/iftop/download/iftop-0.17.tar.gz

tar zxvf iftop-0.17.tar.gz

cd iftop-0.17

./configure

make && make install

configure: error: can't find pcap.h
You're not going to get very far without libpcap.
那你需要先安装libpcap，找到相应的rpm文件，比如：

-rw-r--r-- 1 root root  108987 Apr  3 08:21 libpcap-0.9.4-8.1.i386.rpm
-rw-r--r-- 1 root root  119062 Apr  3 08:21 libpcap-devel-0.9.4-8.1.i386.rpm

安装方法2：(懒人办法，最简单) 

CentOS系统：

yum -y install iftop

Debian系统运行：apt-get install iftop

运行iftop 
直接运行： iftop

vmstat -n 1
r： 表示系统中 CPU 等待处理的线程。由于 CPU 每次只能处理一个线程，所以，该数值越大，通常表示系统运行越慢。

us：用户模式消耗的 CPU 时间百分比。该值较高时，说明用户进程消耗的 CPU 时间比较多，比如，如果该值长期超过 50%，则需要对程序算法或代码等进行优化。

sy：内核模式消耗的 CPU 时间百分比。

wa：IO 等待消耗的 CPU 时间百分比。该值较高时，说明 IO 等待比较严重，这可能磁盘大量作随机访问造成的，也可能是磁盘性能出现了瓶颈。

id：处于空闲状态的 CPU 时间百分比。如果该值持续为 0，同时 sy 是 us 的两倍，则通常说明系统则面临着 CPU 资源的短缺。

load average 是对 CPU 负载的评估，其值越高，说明其任务队列越长，处于等待执行的任务越多。
出现此种情况时，可能是由于僵死进程导致的。可以通过指令 ps -axjf  查看是否存在 D 状态进程。
D 状态是指不可中断的睡眠状态。该状态的进程无法被 kill，也无法自行退出。只能通过恢复其依赖的资源或者重启系统来解决。

kswapd0 进程占用 CPU 较高
操作系统都用分页机制来管理物理内存，操作系统将磁盘的一部分划出来作为虚拟内存，由于内存的速度要比磁盘快得多，所以操作系统要按照某种换页机制将不需要的页面换到磁盘中，将需要的页面调到内存中，由于内存持续不足，这个换页动作持续进行，kswapd0是虚拟内存管理中负责换页的，当服务器内存不足的时候kswapd0会执行换页操作，这个换页操作是十分消耗主机CPU资源的。如果通过top发现该进程持续处于非睡眠状态，且运行时间较长，可以初步判定系统在持续的进行换页操作，可以将问题转向内存不足的原因来排查。

问题描述：
kswapd0 进程占用了系统大量 CPU 资源。

处理办法：
Linux 系统通过分页机制管理内存的同时，将磁盘的一部分划出来作为虚拟内存。而 kswapd0 是 Linux 系统虚拟内存管理中负责换页的进程。当系统内存不足时，kswapd0 会频繁的进行换页操作。而由于换页操作非常消耗 CPU 资源，所以会导致该进程持续占用较高 CPU 资源。
如果通过 top 等监控发现 kswapd0 进程持续处于非睡眠状态，且运行时间较长并持续占用较高 CPU 资源，则通常是由于系统在持续的进行换页操作所致。则可以通过 free 、ps 等指令进一步查询系统及系统内进程的内存占用情况，做进一步排查分析。

相关问题

问题一：Linux实例NAT哈希表满导致ECS实例丢包
提示：此处涉及的内核参数如下。

net.netfilter.nf_conntrack_buckets
net.nf_conntrack_max
 

问题现象
Linux实例出现间歇性丢包，无法连接实例。请参考ping 丢包或不通时链路测试说明，通过tracert、mtr等工具排查，外部网络未见异常。同时，在系统日志中重复出现大量类似如下错误信息。

Feb  6 16:05:07 i-*** kernel: nf_conntrack: table full, dropping packet.
Feb  6 16:05:07 i-*** kernel: nf_conntrack: table full, dropping packet.
Feb  6 16:05:07 i-*** kernel: nf_conntrack: table full, dropping packet.
Feb  6 16:05:07 i-*** kernel: nf_conntrack: table full, dropping packet.
 

原因分析
ip_conntrack是Linux系统内NAT的一个跟踪连接条目的模块。ip_conntrack模块会使用一个哈希表记录TCP协议“established connection”记录，当这个哈希表满之后，便会导致“nf_conntrack: table full, dropping packet”错误。Linux系统会开辟一个空间，用于维护每一个TCP链接，这个空间的大小与nf_conntrack_buckets、nf_conntrack_max参数相关，后者的默认值是前者的4倍，所以一般建议调大nf_conntrack_max参数值。

注：系统维护连接比较消耗内存，请在系统空闲和内存充足的情况下调大nf_conntrack_max参数，且根据系统的情况而定。

 

解决方法
登录Linux实例，如何登录Linux实例请参见使用管理终端连接Linux实例。
执行如下命令，编辑系统内核配置。
vi /etc/sysctl.conf
修改哈希表项最大值参数net.netfilter.nf_conntrack_max为655350。
修改超时参数net.netfilter.nf_conntrack_tcp_timeout_established为1200，默认情况下超时时间是432000秒。
执行sysctl -p命令，使配置生效。
 

问题二：报“Time wait bucket table overflow”错误
提示：此处涉及的内核参数为net.ipv4.tcp_max_tw_buckets。

 

问题现象
Linux实例的/var/log/message日志信息全是类似“kernel: TCP: time wait bucket table overflow”的报错信息，提示“time wait bucket table”溢出，系统显示类似如下。
Feb 18 12:28:38 i-*** kernel: TCP: time wait bucket table overflow
Feb 18 12:28:44 i-*** kernel: printk: 227 messages suppressed.
Feb 18 12:28:44 i-*** kernel: TCP: time wait bucket table overflow
Feb 18 12:28:52 i-*** kernel: printk: 121 messages suppressed.
Feb 18 12:28:52 i-*** kernel: TCP: time wait bucket table overflow
Feb 18 12:28:53 i-*** kernel: printk: 351 messages suppressed.
Feb 18 12:28:53 i-*** kernel: TCP: time wait bucket table overflow
Feb 18 12:28:59 i-*** kernel: printk: 319 messages suppressed.
执行如下命令，统计处于TIME_WAIT状态的TCP连接数，发现处于TIME_WAIT状态的TCP连接非常多。
netstat -ant|grep TIME_WAIT|wc -l
 

原因分析
参数net.ipv4.tcp_max_tw_buckets可以调整内核中管理TIME_WAIT状态的数量。当实例中处于TIME_WAIT状态，及需要转换为TIME_WAIT状态的连接数之和超过net.ipv4.tcp_max_tw_buckets参数值时，message日志中将报“time wait bucket table” 错误，同时内核关闭超出参数值的部分TCP连接。您需要根据实际情况适当调高net.ipv4.tcp_max_tw_buckets参数，同时从业务层面去改进TCP连接。

 

解决方法
执行如下命令，统计TCP连接数。
netstat -anp |grep tcp |wc -l
执行如下命令，查询net.ipv4.tcp_max_tw_buckets参数。如果确认连接使用很高，则容易超出限制。
vi /etc/sysctl.conf
根据现场情况，增加net.ipv4.tcp_max_tw_buckets参数值的大小。
执行sysctl -p命令，使配置生效。
 

问题三：Linux实例中FIN_WAIT2状态的TCP链接过多
提示：此处涉及的内核参数为net.ipv4.tcp_fin_timeout。

 

问题现象
FIN_WAIT2状态的TCP链接过多。

 

原因分析
在HTTP服务中，Server由于某种原因会主动关闭连接，例如KEEPALIVE超时的情况下。作为主动关闭连接的Server就会进入FIN_WAIT2状态。
在TCP/IP协议栈中，存在半连接的概念，FIN_WAIT2状态不算超时，如果Client不关闭，FIN_WAIT2状态将保持到系统重启，越来越多的FIN_WAIT2状态会致使内核Crash。
建议调小net.ipv4.tcp_fin_timeout参数的值，以便加快系统关闭处于FIN_WAIT2状态的TCP连接。
 

解决方法
执行vi /etc/sysctl.conf命令，修改或增加以下内容。
net.ipv4.tcp_syncookies = 1
net.ipv4.tcp_fin_timeout = 30
net.ipv4.tcp_max_syn_backlog = 8192
net.ipv4.tcp_max_tw_buckets = 5000
执行sysctl -p命令，使配置生效。
注：由于FIN_WAIT2状态的TCP连接会进入TIME_WAIT状态，请同时参考问题二：报“Time wait bucket table overflow”错误。

 

问题四：Linux实例中出现大量CLOSE_WAIT状态的TCP连接
问题现象
执行如下命令，发现当前系统中处于CLOSE_WAIT状态的TCP连接非常多。

netstat -atn|grep CLOSE_WAIT|wc -l
 

原因分析
根据实例上的业务量判断CLOSE_WAIT数量是否超出了正常的范围。TCP连接断开时需要进行四次挥手，TCP连接的两端都可以发起关闭连接的请求，若对端发起了关闭连接，但本地没有关闭连接，那么该连接就会处于CLOSE_WAIT状态。虽然该连接已经处于半开状态，但是已经无法和对端通信，需要及时的释放该连接。建议从业务层面及时判断某个连接是否已经被对端关闭，即在程序逻辑中对连接及时关闭，并进行检查。

 

解决方法
编程语言中对应的读、写函数一般包含了检测CLOSE_WAIT状态的TCP连接功能，可通过执行如下命令，查看当前实例上处于CLOSE_WAIT状态的连接数。Java语言和C语言中关闭连接的方法如下。

netstat -an|grep CLOSE_WAIT|wc -l
 

Java语言

通过read方法来判断I/O 。当read方法返回-1时，则表示已经到达末尾。
通过close方法关闭该链接。
 

C语言

检查read的返回值。

若等于0，则可以关闭该连接。
若小于0，则查看error，若不是AGAIN，则同样可以关闭连接。
 

问题五：客户端配置NAT后仍无法访问ECS或RDS远端服务器
提示：此处涉及的内核参数如下。

net.ipv4.tcp_tw_recycle
net.ipv4.tcp_timestamps
 

问题现象
客户端配置NAT后无法访问远端ECS、RDS，包括配置了SNAT的VPC中的ECS实例。同时无法访问其他ECS或RDS等云产品，抓包检测发现远端ECS和RDS对客户端发送的SYN包没有响应。

 

原因分析
若远端服务器的内核参数net.ipv4.tcp_tw_recycle和net.ipv4.tcp_timestamps的值都为1，则远端服务器会检查每一个报文中的时间戳（Timestamp），若Timestamp不是递增的关系，不会响应这个报文。配置NAT后，远端服务器看到来自不同客户端的源IP相同，但NAT前每一台客户端的时间可能会有偏差，报文中的Timestamp就不是递增的情况。

 

解决方法
远端服务器为ECS时，修改net.ipv4.tcp_tw_recycle参数为0。
远端服务器为RDS等PaaS服务时。RDS无法直接修改内核参数，需要在客户端上修改net.ipv4.tcp_tw_recycle参数和net.ipv4.tcp_timestamps参数为0。
 

问题六：存在大量处于TIME_WAIT状态的连接
提示：此处涉及的内核参数如下。

net.ipv4.tcp_syncookies
net.ipv4.tcp_tw_reuse
net.ipv4.tcp_tw_recycle
net.ipv4.tcp_fin_timeout
 

问题现象
云服务器中存在大量处于TIME_WAIT状态的连接。

 

原因分析
首先通过调用close()发起主动关闭，在发送最后一个ACK之后会进入time_wait的状态，该发送方会保持2MSL时间之后才会回到初始状态。MSL值是数据包在网络中的最大生存时间。产生这种结果使得这个TCP连接在2MSL连接等待期间，定义这个连接的四元组（客户端IP地址和端口，服务端IP地址和端口号）不能被使用。

 

解决方法
通过netstat或ss命令，可以看到大量处于TIME_WAIT状态的连接。

执行如下命令，查看TIME_WAIT状态的连接数量。
netstat -n | awk ‘/^tcp/ {++y[$NF]} END {for(w in y) print w, y[w]}’
执行如下命令，编辑系统内核配置。
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 
 

问题七：服务端断开连接后客户端仍然可以看到是建立连接的
提示：此处涉及的内核参数为net.ipv4.tcp_fin_timeout。

 

问题现象
服务端A与客户端B建立了TCP连接，之后服务端A主动断开了连接，但是在客户端B上仍然看到连接是建立的。

clienta

 

原因分析
通常是由于修改了服务端默认的net.ipv4.tcp_fin_timeout内核参数所致。

 

解决方法
执行如下命令，修改配置，设置net.ipv4.tcp_fin_timeout=30。
 vi /etc/sysctl.conf
执行如下命令，使配置生效。
sysctl -p
 

问题八：无法在本地网络环境通过SSH连接Linux实例
提示：此处涉及的内核参数如下。

net.ipv4.tcp_tw_recycle
net.ipv4.tcp_timestamps
 

问题现象
无法在本地网络环境通过SSH连接Linux实例，或者访问该Linux实例上的HTTP业务出现异常。Telnet测试会被reset。

 

原因分析
如果您的本地网络是NAT共享方式上网，该问题可能是由于本地NAT环境和目标Linux相关内核参数配置不匹配导致。尝试通过修改目标Linux实例内核参数来解决问题。

远程连接目标Linux实例。
执行如下命令，查看当前配置。
cat /proc/sys/net/ipv4/tcp_tw_recycle
cat /proc/sys/net/ipv4/tcp_timestamps
查看上述两个配置的值是否为 0，如果为 1，NAT环境下的请求可能会导致上述问题。
 

解决方法
通过如下方式将上述参数值修改为0。

执行如下命令，修改配置文件。
vi /etc/sysctl.conf
添加如下内容。
net.ipv4.tcp_tw_recycle=0
net.ipv4.tcp_timestamps=0
执行如下命令，使配置生效。
sysctl -p 
重新SSH登录实例，或者进行业务访问测试。

线程数控制：高并发下如果线程较多时，Context Switch会非常明显，超过CPU核心数的线程不会带来任何好处。不是特别耗时的操作的话，业务线程池也是有害无益的

非阻塞I/O操作：要想线程少还多做事，避免阻塞是一定要做的。

减少系统调用：虽然Mode Switch比Context Switch的开销要小得多，但我们还是要尽量减少频繁的syscall

数据零拷贝：从内核空间的Direct Buffer拷贝到用户空间，每次透传都拷贝的话累积起来是个不小的开销。

共享状态保护：中间件内部的并发处理也是决定性能的关键。

问题还没完 因为某些国家的进口管制限制 Java发布的运行环境包中的加解密有一定的限制 比如默认不允许256位密钥的AES加解密 解决方法就是修改策略文件 
从官方网站下载JCE无限制权限策略文件 注意自己JDK的版本别下错了 将local_policy.jar和US_export_policy.jar这两个文件替换

 

http://alvinalexander.com/java/java-command-design-pattern-in-java-examples