2012年2月

time_wait过多的优化

对于处理并发量较高的Server,统计会发现本机tcp的time_wait状态的连接非常多

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

TIME_WAIT 24413

established) 1

SYN_SENT 1

FIN_WAIT1 1

State 1

ESTABLISHED 15

LAST_ACK 1

LISTEN 7

该time_wait的默认值为2*MSL,MSL即max segment lifetime,是一个tcp包的最大生存时间

MSL值在Linux上好像默认是30秒,所以从time_wait状态变化到CLOSED大约需要60s时间

另外一方面,本机可用的发起连接的socket端口是有限的,可通过以下命令查看

cat /proc/sys/net/ipv4/ip_local_port_range

32768   61000

也即大约只有2万多个端口可用,如果处于 time_wait状态的连接很多

很有可能会影响本机向外发起的连接(比如说nginx的proxy服务器),出现端口不够用的情况

可以通过以下参数去减少time_wait的连接

vi /etc/sysctl.conf

#开启time_wait状态的socket重用

net.ipv4.tcp_tw_reuse = 1

#开启time_wait状态的socket快速回收

net.ipv4.tcp_tw_recycle = 1

/sbin/sysctl -p

或者直接修改time_wait的等待时间

echo 30 > /proc/sys/net/ipv4/tcp_fin_timeout

更多的Linux内核优化可参见

http://performancewiki.com/linux-tuning.html

GlusterFS性能优化

运维的同学前端时间搭建了一个4台Server的GlusterFS集群

按照其默认的配置,没有使用replicate,读性能还是不错的,每秒大概100M

但写性能相当比较糟糕,每秒大概只有5M左右,几乎比NFS慢了一个数量级

GlusterFS的官方文档比较恶心,在其首页没有具体配置文档的链接,费了好大劲才找到

其Translators的说明文档,见这里,可以参考下

使用一些Translators进行优化后,写性能有了不少的提升,基本能达到25M-30M每秒,这个速度还是基本可以接受的

优化后,读的性能有了一定的下降,不过下降不太明显,每秒在70M-100M之间,也还是可以的

在Client端和Server端都是需要做一些优化的,主要是增加io-cache,write-behind,quick-read,io-threads这些选项

其中对性能提高最大的应该是write-behind,它相当于是个异步写

 

我们利用cluster/replicate和cluster/distribute就可以搭建一个分布式,高可用,可扩展的存储系统

server端的部分配置如下:

volume posix

type storage/posix 

option directory /data-b

end-volume

 

volume locks

type features/locks

subvolumes posix

end-volume

 

volume brick

type performance/io-threads

option thread-count 8 # default is 16

subvolumes locks

end-volume

 

volume server

type protocol/server

option transport-type tcp

subvolumes brick

option auth.addr.brick.allow *

end-volume

client的部分配置如下

volume client1

type protocol/client

option transport-type tcp

option remote-host 10.0.0.1

option remote-subvolume brick # name of the remote volume

end-volume

 

......

 

volume replicate1

    type cluster/replicate

    subvolumes client1 client2

end-volume

 

volume distribute

type cluster/distribute

subvolumes replicate1 replicate2

end-volume

 

volume iocache

  type performance/io-cache

  option cache-size 1024MB        # default is 32MB

  option cache-timeout 1                 # default is 1 second

  subvolumes distribute 

end-volume

 

volume readahead

  type performance/read-ahead

  option page-count 16 # cache per file = (page-count x page-size)

  subvolumes iocache

end-volume

 

volume writebehind

  type performance/write-behind

  option cache-size 512MB     # default is equal to aggregate-size

  option flush-behind on      # default is 'off'

  subvolumes readahead

end-volume

 

volume quickread

  type performance/quick-read

  option cache-timeout 1         # default 1 second

  option max-file-size 256KB        # default 64Kb

  subvolumes writebehind

end-volume

 

volume iothreads

  type performance/io-threads

  option thread-count 8 # default is 16

  subvolumes quickread

end-volume

http协议中的keep-alive

通常,我们说的http长连接,实际上是包含2种不同的含义:

  1. comet,是服务器和浏览器之间维持一个长时间的http连接,用于服务器消息的实时推送,见Web应用中的Comet技术,这种模式下,浏览器只会发送一次request请求,而server端会不断吐出消息给浏览器端,直到超时或者手工终止连接
  2. keep-alive,是http协议中定义的一个规范,它是利用同一个tcp连接处理多个http请求和响应,节省了tcp连接3次握手的开销,同时也就减少了后续请求的延时

HTTP/1.0
在HTTP/1.0版本中,并没有官方的标准来规定Keep-Alive如何工作,因此实际上它是被附加到HTTP/1.0协议上,如果客户端浏览器支持Keep-Alive,那么就在HTTP请求头中添加一个字段 Connection: Keep-Alive,当服务器收到附带有Connection: Keep-Alive的请求时,它也会在响应头中添加一个同样的字段来使用Keep-Alive。这样一来,客户端和服务器之间的HTTP连接就会被保持,不会断开(超过Keep-Alive规定的时间,意外断电等情况除外),当客户端发送另外一个请求时,就使用这条已经建立的连接
 
HTTP/1.1
在HTTP/1.1版本中,默认情况下所在HTTP1.1中所有连接都被保持,除非在请求头或响应头中指明要关闭:Connection: Close,所以在1.1版本中,Connection: Keep-Alive字段实际上已经意义不大了


现有的Apache/Nginx等都支持KeepAlive模式,在nginx中配置:

keepalive_timeout  65;

如果想关闭keepalive,只需将keepalive_timeout设为0即可

resin/tomcat等容器也都是支持Keepalive的,JDK中的URL类同样默认支持keepalive

 

要想真正理解keep-alive长连接模式,我们可以使用wireshark或tcpdump去抓包

对于一个没有开启keep-alive的server,response会返回Connection: Close,然后tcp连接马上就关闭了,见下图

如果开启了keep-alive,那么会在一个tcp连接上发送多个http请求

而且是在keepalive超时后,tcp连接才关闭,下图可以看出过了16秒后tcp连接才关闭

 

另:推荐一篇文章:HTTP长连接

最新文章

最近回复

  • feifei435:这两个URI实际是不一样的
  • zsy: git push origin 分支 -f 给力!
  • 冼敏兵:简单易懂,good fit
  • Jack:无需改配置文件,看着累! # gluster volume se...
  • Mr.j:按照你的方法凑效了,折腾死了。。。。
  • zheyemaster:补充一句:我的网站路径:D:\wamp\www ~~菜鸟站长, ...
  • zheyemaster:wamp2.5(apache2.4.9)下局域网访问403错误的...
  • Git中pull对比fetch和merge | 炼似春秋:[…] 首先,我搜索了git pull和git fe...
  • higkoo:总结一下吧, 性能调优示例: gluster volume s...
  • knowaeap:请问一下博主,你维护的openyoudao支持opensuse吗

分类

归档

其它