GNU Linux高并发性能优化方案

/***********************************************************

* Author : Samson

* Date : 07/14/2015

* Test platform:

* gcc (Ubuntu 4.8.2-19ubuntu1) 4.8.2

* GNU bash, 4.3.11(1)-release (x86_64-pc-linux-gnu)

* Nginx version:

* Nginx 1.6.2

* Nginx 1.8.0

* *********************************************************/

GNU Linux高并发性能优化方案

在GNU Linux系统中,影响连接个数的因素主是由于单个进程能够打开的最大文件数、端口数量决定的;而一个基于tcp的服务器的并发,除了上文说过的两个因素外,还有因为主要的tcp连接的很多属性,而问题最大的则是连接断开后的连接会在TIME_WAIT状态一直存在60秒,这就造成了在大量高并发的情况下当连接为此TIME_WAIT状态时没有可用连接。

1、修改端口号范围:

默认范围:

cat /proc/sys/net/ipv4/ip_local_port_range

32768 61000

众所周知,端口号的范围为0~65535,知名端口号介于1~255之间,256~1023之间的端口号通常都是由系统占用,所以我们需要更多可以使用的端口号的话,那么就需要修改系统中对端口使用范围变量;

修改方法:

1)、echo “1024 65535” > /proc/sys/net/ipv4/ip_local_port_range

2)、在/etc/sysctl.conf中进行如下的设置:

net.ipv4.ip_local_port_range=1024 65535

然后执行: sysctl -p 对这些设置进行生效;

3)、直接使用命令进行系统变量的优化

sysctl -w net.ipv4.ip_local_port_range=1024 65535

若端口不够用的时候报错信息

若没有空闲的端口可以使用时,将会报错,如:

connect() to ip:80 failed (99: Cannot assign requested address)

注意:

修改了端口的范围后,若是有多个服务在一台设备上时,若是先被其它服务先行启动将另外的服务的“众所周知”的端口给占用了,那么这个问题就比较不太好处理,在这种情况下,对于需要监听的服务进行先行启动,将服务要使用的“众所周知”的端口先行占用,就不会发生比较麻烦的情况了。

2、修改系统所有进程能够打开的文件数:

cat /proc/sys/fs/file-max

203466

若要修改的话:

echo 403466 > /proc/sys/fs/file-max

3、对于处理TIME_WAIT的问题,通过设置以下两项可以极大地提高并发

在进行了通信完毕后,完成通信的连接差不多在秒级间就进行了回收,经测试,再使用netstat -ntp,都不会再看到刚才使用的连接,但是在官方文档中说明了(Default value is 0. It should not be changed without advice/request of technical experts.)使用这两种方式需要非常谨慎;如下(修改方法请参看上面的修改方式):

net.ipv4.tcp_tw_reuse = 1

//表示开启重用。允许将TIME-WAIT sockets重新用于新的TCP连接,默认为0,表示关闭;

net.ipv4.tcp_tw_recycle = 1

//表示开启TCP连接中TIME-WAIT sockets的快速回收,默认为0,表示关闭。

由于以上两项在官方文档中有这样的描述”It should not be changed without advice/request of technical experts.“,也即是说,这两项在某些情况下会产生负作用或影响;

可能出现的影响:

net.ipv4.tcp_tw_recycle是与net.ipv4.tcp_timestamps是密切相关的,而net.ipv4.tcp_timestamps默认是开启的,当tcp_tw_recycle和tcp_timestamps同时打开时会激活TCP的一种隐藏属性:缓存连接的时间戳。60秒内,同一源IP的后续请求的时间戳小于缓存中的时间戳,内核就会丢弃该请求。

什么样的场景会使时间戳会小于缓存中的时间戳呢?

类似的故障场景:

多个客户端通过一个NAT访问一台服务器,因为NAT只改IP地址信息,但不会改变timestamp(TCP的时间戳不是系统时间,而是系统启动的时间uptime,所以两台机器的的TCP时间戳一致的可能性很小),那么就会出现请求被丢弃的情况,所以很容易造成连接失败的情况。

服务器上开启了tcp_tw_recycle用于TIME_WAIT的快速回收故障现象和分析步骤:

1) 通过NAT出口的多个客户端经常请求Web服务器无响应;

2) 在服务器抓包,发现服务端可以收到客户端的SYN请求,但是没有回应SYN,ACK,也就是说内核直接将包丢弃了。

解决方法:

1) 关闭服务其端的tcp_timestamps,故障可以解决,但是这么做存在安全和性能隐患,强烈建议不关闭此变量;

2) 关闭tcp_tw_recycle,故障也可以解决。推荐NAT环境下的机器不要开启该选项;

3)调整网络拓扑避免NAT的这种类似的情况;

4)客户端使用同一个NTP服务进行时间同步,使时间同步避免timestamp差异;

其它优化参数

net.ipv4.tcp_fin_timeout = 30

//表示如果套接字由本端要求关闭,这个参数决定了它保持在FIN-WAIT-2状态的时间。

net.ipv4.tcp_keepalive_time = 1200

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

net.ipv4.tcp_max_tw_buckets = 5000

//表示系统同时保持TIME_WAIT套接字的最大数量,如果超过这个数字,

//TIME_WAIT套接字将立刻被清除并打印警告信息。默认为180000,改为5000。

//对于Apache、Nginx等服务器,上几行的参数可以很好地减少TIME_WAIT套接字数量,

//此值和/proc/sys/net/ipv4/tcp_max_syn_backlog是一样的,也是对listen()函数中的backlog参数的限制,按照文档中的说明,应该最好是设置成和/proc/sys/net/ipv4/tcp_max_syn_backlog一样的值,此值的默认值是128:

cat /proc/sys/net/core/somaxconn

128

net.core.somaxconn = 40000

//指定未完成连接队列的最大长度,默认为1024个,是对socket的listen()函数中的backlog数量的限制,若服务器过载可以增大此值;

cat /proc/sys/net/ipv4/tcp_max_syn_backlog

1024

net.ipv4.tcp_max_syn_backlog = 40000

4、调整每个进程最大打开文件描述符限制

调整文件描述符限制:

$ ulimit -n

1024

修改此值,ulimit -n 4096

$vi /etc/security/limits.conf

//Setting Shell Limits for File Descriptors

*soft nofile 8192

*hard nofile 8192

这二者的区别,在/etc/security/limits.conf配置文件中配置好后,进行重启后再次使用ulimit -n将得到的值是8192.

5、通过重新编译内核代码减少TCP连接的TIME-WAIT时间

在内核代码中的include/net/tcp.h文件中,TIME-WAIT的定义如下:

//#define TCP_TIMEWAIT_LEN (60*HZ) /* how long to wait to destroy TIME-WAIT

* state, about 60 seconds */

可以通过修改TCP_TIMEWAIT_LEN的值,来加快连接的释放;修改后,内核进行编译后进行替换。

Nginx的配置与系统环境变量间的关系

系统默认的是1024,若在Nginx的配置文件中,配置了worker_connections 4096;后,再启动时,会出现这样的一个警告:

nginx: [warn] 4096 worker_connections exceed open file resource limit: 1024

Nginx中的这些和系统变量有关的,是根据系统中的配置而进行设置的,若大于了系统变量的范围的话,不会生效,会被默认成系统的值,如每个worker进行能够打开的文件数量就被默认成系统的值1024;

注意:

修改内核变量是有风险的,最好是在测试环境进行测试通过,再将配置平移到生产环境。

REF:

IPV4和IPV6的内核参数各项的意义及取值:

https://www.kernel.org/doc/Documentation/networking/ip-sysctl.txt

关于/proc目录下的主要项的介绍:

http://man7.org/linux/man-pages/man5/proc.5.html

版权声明:本文为博主原创文章,未经博主允许不得转载。

时间: 2024-08-06 07:28:36

GNU Linux高并发性能优化方案的相关文章

Linux高并发内核优化-TougheRadius

linux 内核优化 默认情况下,linux系统有一些限制,并不能直接支持高并发性能,需要做一些内核优化. 1.把以下内容加入 /etc/sysctl.conf 1 net.ipv4.ip_forward=1 2 net.ipv4.tcp_syncookies = 1 3 net.ipv4.tcp_tw_reuse = 1 4 net.ipv4.tcp_tw_recycle = 1 5 net.ipv4.tcp_fin_timeout = 30 6 net.ipv4.tcp_keepalive_

Tomcat 8/9 基于APR库的高并发性能优化

一.知识点扫盲 什么是APR?Apache Portable Runtime(APR)项目的任务是创建和维护软件库,为底层平台特定的实现提供可预测且一致的接口.主要目标是提供一个API,软件开发人员可以对其进行编码,并确保可预测的行为,如果不是相同的行为,无论其软件构建的平台如何,都可以减轻他们编写特殊情况的需要,以便解决或采取行动.平台特定缺陷或功能的优势. 二.tomcat的三种模式 Tomcat的运行模式有3种,即BIO.NIO和APR.1.BIO(blocking I/O)即阻塞式I/O

高性能高并发网站优化方案1

1. 监控网站数据库负载. 2. "explain"所有的SQL语句. 3. 缓存所有能缓存的东西. 4. 归档好代码. 硬件方面: 先要找出瓶颈在哪个部分:是CPU负荷太高(经常100%),还是内存不够用(大量使用虚拟内存),还是磁盘I/O性能跟不上(硬盘指示灯狂闪)?这几个都是可以通过升级硬件来解决或者改善的(使用更高等级的CPU,更快速和更大容量的内存,配置硬件磁盘阵列并使用更多数量的高速SCSI硬盘),但这需要较大的投入. 软件方面: 如果使用了更大容量的内存和改善的I/O性能

大型php网站性能和并发访问优化方案

网站性能优化对于大型网站来说非常重要,一个网站的访问打开速度影响着用户体验度,网站访问速度慢会造成高跳出率,小网站很好解决,那对于大型网站由于栏目多,图片和图像都比较庞大,那该怎么进行整体性能优化呢?本文为你提供一份大型php网站性能和并发访问优化方案. 一.大型网站性能提高策略: 大型网站,比如门户网站,在面对大量用户访问.高并发请求方面,基本的解决方案集中在这样几个环节:使用高性能的服务器.高性能的数据库.高效率的编程语言.还有高性能的Web容器.这几个解决思路在一定程度上意味着更大的投入.

mysql 性能优化方案 (转)

网 上有不少MySQL 性能优化方案,不过,mysql的优化同sql server相比,更为麻烦与复杂,同样的设置,在不同的环境下 ,由于内存,访问量,读写频率,数据差异等等情况,可能会出现不同的结果,因此简单地根据某个给出方案来配置mysql是行不通的,最好能使用 status信息对mysql进行具体的优化. mysql> show global status; 可以列出mysql服务器运行各种状态值,另外,查询mysql服务器配置信息语句: mysql> show variables; 一

kvm性能优化方案

kvm性能优化方案 kvm性能优化,主要集中在cpu.内存.磁盘.网络,4个方面,当然对于这里面的优化,也是要分场景的,不同的场景其优化方向也是不同的,下面具体聊聊这4个方面的优化细节. cpu 在介绍cpu之前,必须要讲清楚numa的概念,建议先参考如下两篇文章 CPU Topology 玩转cpu-topology 查看cpu信息脚本: #!/bin/bash # Simple print cpu topology # Author: kodango function get_nr_proc

Oracle在Linux下的性能优化

Oracle数据库内存参数的优化 Ø       与oracle相关的系统内核参数 Ø       SGA.PGA参数设置   Oracle下磁盘存储性能优化 Ø       文件系统的选择(ext2/ext3.xfs.ocfs2) Ø       Oracle ASM存储  1.优化oracle性能参数之前要了解的情况 1)物理内存有多大 2)操作系统估计要使用多大内存 3)数据库是使用文件系统还是裸设备 4)有多少并发连接 5)应用是OLTP类型还是OLAP类型 2.oracle数据库内存参

(转)Web性能优化方案

第一章 打开网站慢现状分析 在公司访问部署在IDC机房的VIP网站时会感觉很慢.是什么原因造成的?为了缩短页面的响应时间,改进我们的用户体验,我们需要知道用户的时间花在等待什么东西上. 可以跟踪一下我们的登录页面,如下图所示 从上图我们可以分析知道,HTML文档只占了总响应时间的20%,其它80%响应时间用来下载JS.CSS.图片等组件.所以WEB前端有很大的优化空间,我们将从WEB的前端优化.后端优化两方面综合考虑给出WEB的性能优化方案. 第二章 WEB前台的优化规则 一.尽量减少 HTTP

Redmine性能优化方案

近来公司redmine服务器表现很糟糕,在16核,64GRAM的机器上,压测结果竟然只有每秒5~7个请求,部分页面一个都出不来. 以下是我对Redmine性能优化方案: redmine服务器性能问题排查与优化建议: 以下建议的方案是基于redmine运行期的log文件中的render耗时.activerecord耗时,linux系统性能指标采样与 mysql 性能指标采样分析,以及redmine在不同web server下的benchmark而得:   一. 问题排查与定量分析 通过分析redm