存档

‘Linux性能优化测试’ 分类的存档

mpstat pmap

2017年1月23日 评论已被关闭

mpstat pmap
http://xukaizijian.blog.163.com/blog/static/1704331192010113015251659?suggestedreading
mpstat: mpstat命令可以显示所有可用处理器的使用情况,处理器编号从0开始。
mpstat -P ALL显示每个处理器的平均使用率。

[root@10.10.90.97 ~]# mpstat -P ALL
Linux 2.6.18-164.el5xen (FOCUS9097) 12/30/2010 _x86_64_ (4 CPU)
01:48:08 PM CPU %usr %nice %sys %iowait %irq %soft %steal %guest %idle
01:48:08 PM all 0.33 0.00 0.19 0.37 0.00 0.00 0.00 0.00 99.11
01:48:08 PM 0 1.10 0.00 0.29 1.28 0.00 0.00 0.00 0.00 97.33
01:48:08 PM 1 0.08 0.00 0.18 0.07 0.00 0.00 0.00 0.00 99.66
01:48:08 PM 2 0.07 0.00 0.15 0.07 0.00 0.00 0.00 0.00 99.72
01:48:08 PM 3 0.09 0.00 0.15 0.04 0.00 0.00 0.00 0.00 99.72

pmap:pmap命令可以显示进程的内存映射,使用这个命令可以找出造成内存瓶颈的原因

语法:pmap -d PID :显示pid进程的内存信息

[root@10.10.90.97 ~]# pmap -d 2380
2380: sendmail: accepting connections
Address Kbytes Mode Offset Device Mapping
00002b42542f7000 736 r-x– 0000000000000000 068:00002 sendmail.sendmail
00002b42545af000 20 rw— 00000000000b8000 068:00002 sendmail.sendmail
…………………………
00002b42589a9000 2048 —– 000000000000b000 068:00002 libdigestmd5.so.2.0.22
00002b4258ba9000 4 rw— 000000000000b000 068:00002 libdigestmd5.so.2.0.22
00002b426a18f000 528 rw— 00002b426a18f000 000:00000 [ anon ]
00007fff785b6000 208 rw— 00007ffffffcb000 000:00000 [ stack ]
ffffffffff600000 8192 —– 0000000000000000 000:00000 [ anon ]
mapped: 79288K writeable/private: 2000K shared: 0K
最后一行说明:
mapped: 79288K: 内存映射所占空间大小
writeable/private: 2000K: 私有地址空间大小
shared: 0K :共享地址空间大小

关于FIN_WAIT2

2016年12月8日 评论已被关闭

关于FIN_WAIT2

http://huoding.com/2016/09/05/542

前些天,有朋友问我关于 FIN_WAIT2 的问题:如果主动关闭的一方在进入 FIN_WAIT2 状态后没有收到被动关闭的一方发送的 FIN 包,那么会怎样?

让我们热热身,通过一张旧图来回忆一下 TCP 关闭连接时的情况:

TCP Close

按照正常的状态迁移路径,当 FIN_WAIT2 收到 FIN 包后会迁移到 TIME_WAIT 状态。如果没有收到 FIN 包,那么连接状态会如何迁移,我们不妨测试一下:

#!/usr/bin/env python

import socket
import time

s = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
s.bind(('127.0.0.1', 1234))
s.listen(1)

c, _ = s.accept()

time.sleep(1000)

c.close()

如上是用 Python 实现的一个简单的 server 演示代码,需要注意的是我在 close 前设置了一个巨大的延迟时间,从而达到拖延服务端发出 FIN 包的目的。与之相对应的我们再实现一个简单的 client 演示代码,它没什么可说的,就是连上后直接关闭:

#!/usr/bin/env python

import socket
import time

s = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
s.connect(('127.0.0.1', 1234))
s.close()

测试的时候先启动服务端监听 1234 端口,再启动客户端连接 1234 端口,为了确认整个过程是否符合我们的预期,可以使用 tcpdump 监听通讯过程:

tcpdump -t -nn -i any port 1234

如图可见:在三次握手之后,客户端关闭了连接,服务端确认后没有发出 FIN 包,所以整个过程符合我们的预期,同时为了判断 FIN_WAIT2 存在了多久,写了如下代码:

shell> while sleep 1; do
    netstat -ant | grep FIN_WAIT2 | while read content; do
        echo -n $(date +"%T") ""
        echo $content
    done
done

监控发现,在本例中 FIN_WAIT2 存在的时间大约是一分钟左右:

FIN_WAIT2 存在的时间

实际上此时间是「net.ipv4.tcp_fin_timeout」控制的,不过在测试中发现,FIN_WAIT2 存在的时间并不是精确的等于 tcp_fin_timeout 的设置,存在一定的偏差。此外,需要说明的是在 tcp_fin_timeout 后,FIN_WAIT2 并没有迁移到 TIME_WAIT,而是直接关闭了。

关于 tcp_fin_timeout 的介绍,可以参考内核的说明:

The length of time an orphaned (no longer referenced by any application) connection will remain in the FIN_WAIT_2 state before it is aborted at the local end. While a perfectly valid “receive only” state for an un-orphaned connection, an orphaned connection in FIN_WAIT_2 state could otherwise wait forever for the remote to close its end of the connection.
Cf. tcp_max_orphans
Default: 60 seconds

介绍中提到了 orphan 的概念,指的是当一个 socket 不再被任何应用引用时,它便成为了一个孤儿,而 tcp_fin_timeout 限定了成为孤儿的 FIN_WAIT2 所能存活的时间。

注:orphan 太多的话会:The “Out of socket memory” error

或许有人会问:如果 FIN_WAIT2 没有成为孤儿,那么会如何:

#!/usr/bin/env python

import socket
import time

s = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
s.connect(('127.0.0.1', 1234))

s.shutdown(socket.SHUT_WR)

time.sleep(1000)

s.close()

在这一版的 client 代码中,我们没有直接 close 连接,而是通过 shutdown 来关闭,此时客户端同样会发送 FIN 包,但是并没有释放连接,所以本例中的 FIN_WAIT2 和上例中的 FIN_WAIT2 不同,其并不会成为孤儿。通过测试发现,此时 tcp_fin_timeout 将失效,而 本例中的 FIN_WAIT2 会一直存在,直到客户端 close 连接或者退出。

实际上,同其它 TCP 状态相比,通常 FIN_WAIT2 并不会给你添什么麻烦。如果你统计服务器上的 TCP 状态,你会发现它们多数时候都很少,如果不是,那么一定是应用层面上出了问题。至于 tcp_fin_timeout,我并不建议大家把它设置得太小,因为如上所说,正常情况下,TCP 连接并不会在 FIN_WAIT2 状态上停留太久,假设真的出现 FIN 包丢失之类的情况,那么给 FIN_WAIT2 状态一个合理的存在周期是必要的,毕竟丢失的 FIN 包可能会重传,在这一点上和 TIME_WAIT 为什么要存在 2MSL 是同样的原因。既然 TIME_WAIT 缺省存在 60 秒,那么 tcp_fin_timeout 缺省设置为 60 同样是一个合理的选择。

使用iostat分析IO性能

2016年12月8日 评论已被关闭

使用iostat分析IO性能
http://blog.csdn.net/yangzhenzhen/article/details/39078277
对于I/O-bond类型的进程,我们经常用iostat工具查看进程IO请求下发的数量、系统处理IO请求的耗时,进而分析进程与操作系统的交互过程中IO方面是否存在瓶颈。

下面通过iostat命令使用实例,说明使用iostat查看IO请求下发情况、系统IO处理能力的方法,以及命令执行结果中各字段的含义。

1.不加选项执行iostat

我们先来看直接执行iostat的输出结果:
linux # iostat
Linux 2.6.16.60-0.21-smp (linux) 06/12/12

avg-cpu: %user %nice %system %iowait %steal %idle
0.07 0.00 0.05 0.06 0.00 99.81

Device: tps Blk_read/s Blk_wrtn/s Blk_read Blk_wrtn
sda 0.58 9.95 37.47 6737006 25377400
sdb 0.00 0.00 0.00 824 0
复制代码
单独执行iostat,显示的结果为从系统开机到当前执行时刻的统计信息。以上输出中,除最上面指示系统版本、主机名和日期的一行外,另有两部分:

avg-cpu: 总体cpu使用情况统计信息,对于多核cpu,这里为所有cpu的平均值

Device: 各磁盘设备的IO统计信息

对于cpu统计信息一行,我们主要看iowait的值,它指示cpu用于等待io请求完成的时间。Device中各列含义如下:

Device: 以sdX形式显示的设备名称
tps: 每秒进程下发的IO读、写请求数量
Blk_read/s: 每秒读扇区数量(一扇区为512bytes)
Blk_wrtn/s: 每秒写扇区数量
Blk_read: 取样时间间隔内读扇区总数量
Blk_wrtn: 取样时间间隔内写扇区总数量
我们可以使用-c选项单独显示avg-cpu部分的结果,使用-d选项单独显示Device部分的信息。

2.指定采样时间间隔与采样次数

与sar命令一样,我们可以以”iostat interval [count] ”形式指定iostat命令的采样间隔和采样次数:

复制代码
linux # iostat -d 1 2
Linux 2.6.16.60-0.21-smp (linux) 06/13/12

Device: tps Blk_read/s Blk_wrtn/s Blk_read Blk_wrtn
sda 0.55 8.93 36.27 6737086 27367728
sdb 0.00 0.00 0.00 928 0

Device: tps Blk_read/s Blk_wrtn/s Blk_read Blk_wrtn
sda 2.00 0.00 72.00 0 72
sdb 0.00 0.00 0.00 0 0
复制代码
以上命令输出Device的信息,采样时间为1秒,采样2次,若不指定采样次数,则iostat会一直输出采样信息,直到按”ctrl+c”退出命令。注意,第1次采样信息与单独执行iostat的效果一样,为从系统开机到当前执行时刻的统计信息。

3.以kB为单位显示读写信息(-k选项)

我们可以使用-k选项,指定iostat的部分输出结果以kB为单位,而不是以扇区数为单位:

复制代码
linux # iostat -d -k
Linux 2.6.16.60-0.21-smp (linux) 06/13/12

Device: tps kB_read/s kB_wrtn/s kB_read kB_wrtn
sda 0.55 4.46 18.12 3368543 13686096
sdb 0.00 0.00 0.00 464 0
复制代码
以上输出中,kB_read/s、kB_wrtn/s、kB_read和kB_wrtn的值均以kB为单位,相比以扇区数为单位,这里的值为原值的一半(1kB=512bytes*2)

4.更详细的io统计信息(-x选项)

为显示更详细的io设备统计信息,我们可以使用-x选项,在分析io瓶颈时,一般都会开启-x选项:

复制代码
linux # iostat -x -k -d 1
Linux 2.6.16.60-0.21-smp (linux) 06/13/12

……
Device: rrqm/s wrqm/s r/s w/s rkB/s wkB/s avgrq-sz avgqu-sz await svctm %util
sda 0.00 9915.00 1.00 90.00 4.00 34360.00 755.25 11.79 120.57 6.33 57.60
复制代码
以上各列的含义如下:

rrqm/s: 每秒对该设备的读请求被合并次数,文件系统会对读取同块(block)的请求进行合并
wrqm/s: 每秒对该设备的写请求被合并次数
r/s: 每秒完成的读次数
w/s: 每秒完成的写次数
rkB/s: 每秒读数据量(kB为单位)
wkB/s: 每秒写数据量(kB为单位)
avgrq-sz:平均每次IO操作的数据量(扇区数为单位)
avgqu-sz: 平均等待处理的IO请求队列长度
await: 平均每次IO请求等待时间(包括等待时间和处理时间,毫秒为单位)
svctm: 平均每次IO请求的处理时间(毫秒为单位)
%util: 采用周期内用于IO操作的时间比率,即IO队列非空的时间比率

对于以上示例输出,我们可以获取到以下信息:

每秒向磁盘上写30M左右数据(wkB/s值)
每秒有91次IO操作(r/s+w/s),其中以写操作为主体
平均每次IO请求等待处理的时间为120.57毫秒,处理耗时为6.33毫秒
等待处理的IO请求队列中,平均有11.79个请求驻留

以上各值之间也存在联系,我们可以由一些值计算出其他数值,例如:

util = (r/s+w/s) * (svctm/1000)

对于上面的例子有:util = (1+90)*(6.33/1000) = 0.57603

如何解决TIME_WAIT过多的解决办法(附Socket中的TIME_WAIT状态详解)

2016年12月4日 评论已被关闭

如何解决TIME_WAIT过多的解决办法(附Socket中的TIME_WAIT状态详解)
http://blog.csdn.net/zjl410091917/article/details/7990787
Linux和windows下TIME_WAIT过多的解决办法

如果使用了nginx代理,那么系统TIME_WAIT的数量会变得比较多,这是由于nginx代理使用了短链接的方式和后端交互的原因,使得nginx和后端的ESTABLISHED变得很少而TIME_WAIT很多。这不但发生在安装nginx的代理服务器上,而且也会使后端的app服务器上有大量的TIME_WAIT。查阅TIME_WAIT资料,发现这个状态很多也没什么大问题,但可能因为它占用了系统过多的端口,导致后续的请求无法获取端口而造成障碍。

虽然TIME_WAIT会造成一些问题,但是要完全枪毙掉它也是不正当的,虽然看起来这么做没什么错。具体可看这篇文档:

http://hi.baidu.com/tim_bi/blog/item/35b005d784ca91d5a044df1d.html

所以目前看来最好的办法是让每个TIME_WAIT早点过期。

在linux上可以这么配置:

#让TIME_WAIT状态可以重用,这样即使TIME_WAIT占满了所有端口,也不会拒绝新的请求造成障碍
echo “1” > /proc/sys/net/ipv4/tcp_tw_reuse
#让TIME_WAIT尽快回收,我也不知是多久,观察大概是一秒钟
echo “1” > /proc/sys/net/ipv4/tcp_tw_recycle

很多文档都会建议两个参数都配置上,但是我发现只用修改tcp_tw_recycle就可以解决问题的了,TIME_WAIT重用TCP协议本身就是不建议打开的。

不能重用端口可能会造成系统的某些服务无法启动,比如要重启一个系统监控的软件,它用了40000端口,而这个端口在软件重启过程中刚好被使用了,就可能会重启失败的。linux默认考虑到了这个问题,有这么个设定:

#查看系统本地可用端口极限值
cat /proc/sys/net/ipv4/ip_local_port_range

用这条命令会返回两个数字,默认是:32768 61000,说明这台机器本地能向外连接61000-32768=28232个连接,注意是本地向外连接,不是这台机器的所有连接,不会影响这台机器的80端口的对外连接数。但这个数字会影响到代理服务器(nginx)对app服务器的最大连接数,因为nginx对app是用的异步传输,所以这个环节的连接速度很快,所以堆积的连接就很少。假如nginx对app服务器之间的带宽出了问题或是app服务器有问题,那么可能使连接堆积起来,这时可以通过设定nginx的代理超时时间,来使连接尽快释放掉,一般来说极少能用到28232个连接。

因为有软件使用了40000端口监听,常常出错的话,可以通过设定ip_local_port_range的最小值来解决:

echo “40001 61000” > /proc/sys/net/ipv4/ip_local_port_range

但是这么做很显然把系统可用端口数减少了,这时可以把ip_local_port_range的最大值往上调,但是好习惯是使用不超过32768的端口来侦听服务,另外也不必要去修改ip_local_port_range数值成1024 65535之类的,意义不大。

因为使用了nginx代理,在windows下也会造成大量TIME_WAIT,当然windows也可以调整:

在注册表(regedit)的HKEY_LOCAL_MACHINE/SYSTEM/CurrentControlSet/Services/Tcpip/Parameters上添加一个DWORD类型的值TcpTimedWaitDelay,值就是秒数,即可。

windows默认是重用TIME_WAIT,我现在还不知道怎么改成不重用的,本地端口也没查到是什么值,但这些都关系不大,都可以按系统默认运作。

————————————————————————————————————————

TIME_WAIT状态
根据TCP协议,主动发起关闭的一方,会进入TIME_WAIT状态,持续2*MSL(Max Segment Lifetime),缺省为240秒,在这个post中简洁的介绍了为什么需要这个状态。

值得一说的是,对于基于TCP的HTTP协议,关闭TCP连接的是Server端,这样,Server端会进入TIME_WAIT状态,可想而知,对于访问量大的Web Server,会存在大量的TIME_WAIT状态,假如server一秒钟接收1000个请求,那么就会积压240*1000=240,000个TIME_WAIT的记录,维护这些状态给Server带来负担。当然现代操作系统都会用快速的查找算法来管理这些TIME_WAIT,所以对于新的TCP连接请求,判断是否hit中一个TIME_WAIT不会太费时间,但是有这么多状态要维护总是不好。

HTTP协议1.1版规定default行为是Keep-Alive,也就是会重用TCP连接传输多个request/response,一个主要原因就是发现了这个问题。还有一个方法减缓TIME_WAIT压力就是把系统的2*MSL时间减少,因为240秒的时间实在是忒长了点,对于Windows,修改注册表,在HKEY_LOCAL_MACHINE/ SYSTEM/CurrentControlSet/Services/ Tcpip/Parameters上添加一个DWORD类型的值TcpTimedWaitDelay,一般认为不要少于60,不然可能会有麻烦。

对于大型的服务,一台server搞不定,需要一个LB(Load Balancer)把流量分配到若干后端服务器上,如果这个LB是以NAT方式工作的话,可能会带来问题。假如所有从LB到后端Server的IP包的source address都是一样的(LB的对内地址),那么LB到后端Server的TCP连接会受限制,因为频繁的TCP连接建立和关闭,会在server上留下TIME_WAIT状态,而且这些状态对应的remote address都是LB的,LB的source port撑死也就60000多个(2^16=65536,1~1023是保留端口,还有一些其他端口缺省也不会用),每个LB上的端口一旦进入Server的TIME_WAIT黑名单,就有240秒不能再用来建立和Server的连接,这样LB和Server最多也就能支持300个左右的连接。如果没有LB,不会有这个问题,因为这样server看到的remote address是internet上广阔无垠的集合,对每个address,60000多个port实在是够用了。

一开始我觉得用上LB会很大程度上限制TCP的连接数,但是实验表明没这回事,LB后面的一台Windows Server 2003每秒处理请求数照样达到了600个,难道TIME_WAIT状态没起作用?用Net Monitor和netstat观察后发现,Server和LB的XXXX端口之间的连接进入TIME_WAIT状态后,再来一个LB的XXXX端口的SYN包,Server照样接收处理了,而是想像的那样被drop掉了。翻书,从书堆里面找出覆满尘土的大学时代买的《UNIX Network Programming, Volume 1, Second Edition: Networking APIs: Sockets and XTI》,中间提到一句,对于BSD-derived实现,只要SYN的sequence number比上一次关闭时的最大sequence number还要大,那么TIME_WAIT状态一样接受这个SYN,难不成Windows也算BSD-derived?有了这点线索和关键字(BSD),找到这个post,在NT4.0的时候,还是和BSD-derived不一样的,不过Windows Server 2003已经是NT5.2了,也许有点差别了。

做个试验,用Socket API编一个Client端,每次都Bind到本地一个端口比如2345,重复的建立TCP连接往一个Server发送Keep-Alive=false的HTTP请求,Windows的实现让sequence number不断的增长,所以虽然Server对于Client的2345端口连接保持TIME_WAIT状态,但是总是能够接受新的请求,不会拒绝。那如果SYN的Sequence Number变小会怎么样呢?同样用Socket API,不过这次用Raw IP,发送一个小sequence number的SYN包过去,Net Monitor里面看到,这个SYN被Server接收后如泥牛如海,一点反应没有,被drop掉了。

按照书上的说法,BSD-derived和Windows Server 2003的做法有安全隐患,不过至少这样至少不会出现TIME_WAIT阻止TCP请求的问题,当然,客户端要配合,保证不同TCP连接的sequence number要上涨不要下降。

—————————————————————————————————————————-

Socket中的TIME_WAIT状态

在高并发短连接的server端,当server处理完client的请求后立刻closesocket此时会出现time_wait状态然后如果client再并发2000个连接,此时部分连接就连接不上了,用linger强制关闭可以解决此问题,但是linger会导致数据丢失,linger值为0时是强制关闭,无论并发多少多能正常连接上,如果非0会发生部分连接不上的情况!(可调用setsockopt设置套接字的linger延时标志,同时将延时时间设置为0。)
TCP/IP的RFC文档。TIME_WAIT是TCP连接断开时必定会出现的状态。
是无法避免掉的,这是TCP协议实现的一部分。
在WINDOWS下,可以修改注册表让这个时间变短一些

time_wait的时间为2msl,默认为4min.
你可以通过改变这个变量:
TcpTimedWaitDelay
把它缩短到30s
TCP要保证在所有可能的情况下使得所有的数据都能够被投递。当你关闭一个socket时,主动关闭一端的socket将进入TIME_WAIT状态,而被动关闭一方则转入CLOSED状态,这的确能够保证所有的数据都被传输。当一个socket关闭的时候,是通过两端互发信息的四次握手过程完成的,当一端调用close()时,就说明本端没有数据再要发送了。这好似看来在握手完成以后,socket就都应该处于关闭CLOSED状态了。但这有两个问题,首先,我们没有任何机制保证最后的一个ACK能够正常传输,第二,网络上仍然有可能有残余的数据包(wandering duplicates),我们也必须能够正常处理。
通过正确的状态机,我们知道双方的关闭过程如下

假设最后一个ACK丢失了,服务器会重发它发送的最后一个FIN,所以客户端必须维持一个状态信息,以便能够重发ACK;如果不维持这种状态,客户端在接收到FIN后将会响应一个RST,服务器端接收到RST后会认为这是一个错误。如果TCP协议能够正常完成必要的操作而终止双方的数据流传输,就必须完全正确的传输四次握手的四个节,不能有任何的丢失。这就是为什么socket在关闭后,仍然处于 TIME_WAIT状态,因为他要等待以便重发ACK。

如果目前连接的通信双方都已经调用了close(),假定双方都到达CLOSED状态,而没有TIME_WAIT状态时,就会出现如下的情况。现在有一个新的连接被建立起来,使用的IP地址与端口与先前的完全相同,后建立的连接又称作是原先连接的一个化身。还假定原先的连接中有数据报残存于网络之中,这样新的连接收到的数据报中有可能是先前连接的数据报。为了防止这一点,TCP不允许从处于TIME_WAIT状态的socket建立一个连接。处于TIME_WAIT状态的socket在等待两倍的MSL时间以后(之所以是两倍的MSL,是由于MSL是一个数据报在网络中单向发出到认定丢失的时间,一个数据报有可能在发送图中或是其响应过程中成为残余数据报,确认一个数据报及其响应的丢弃的需要两倍的MSL),将会转变为CLOSED状态。这就意味着,一个成功建立的连接,必然使得先前网络中残余的数据报都丢失了。

由于TIME_WAIT状态所带来的相关问题,我们可以通过设置SO_LINGER标志来避免socket进入TIME_WAIT状态,这可以通过发送RST而取代正常的TCP四次握手的终止方式。但这并不是一个很好的主意,TIME_WAIT对于我们来说往往是有利的。

客户端与服务器端建立TCP/IP连接后关闭SOCKET后,服务器端连接的端口
状态为TIME_WAIT
是不是所有执行主动关闭的socket都会进入TIME_WAIT状态呢?
有没有什么情况使主动关闭的socket直接进入CLOSED状态呢?
主动关闭的一方在发送最后一个 ack 后
就会进入 TIME_WAIT 状态 停留2MSL(max segment lifetime)时间
这个是TCP/IP必不可少的,也就是“解决”不了的。

也就是TCP/IP设计者本来是这么设计的
主要有两个原因
1。防止上一次连接中的包,迷路后重新出现,影响新连接
(经过2MSL,上一次连接中所有的重复包都会消失)
2。可靠的关闭TCP连接
在主动关闭方发送的最后一个 ack(fin) ,有可能丢失,这时被动方会重新发
fin, 如果这时主动方处于 CLOSED 状态 ,就会响应 rst 而不是 ack。所以
主动方要处于 TIME_WAIT 状态,而不能是 CLOSED 。

TIME_WAIT 并不会占用很大资源的,除非受到攻击。

还有,如果一方 send 或 recv 超时,就会直接进入 CLOSED 状态

socket-faq中的这一段讲的也很好,摘录如下:
2.7. Please explain the TIME_WAIT state.

Remember that TCP guarantees all data transmitted will be delivered,
if at all possible. When you close a socket, the server goes into a
TIME_WAIT state, just to be really really sure that all the data has
gone through. When a socket is closed, both sides agree by sending
messages to each other that they will send no more data. This, it
seemed to me was good enough, and after the handshaking is done, the
socket should be closed. The problem is two-fold. First, there is no
way to be sure that the last ack was communicated successfully.
Second, there may be “wandering duplicates” left on the net that must
be dealt with if they are delivered.

Andrew Gierth (andrew@erlenstar.demon.co.uk) helped to explain the
closing sequence in the following usenet posting:

Assume that a connection is in ESTABLISHED state, and the client is
about to do an orderly release. The client’s sequence no. is Sc, and
the server’s is Ss. Client Server
====== ======
ESTABLISHED ESTABLISHED
(client closes)
ESTABLISHED ESTABLISHED
——->>
FIN_WAIT_1
<<——–
FIN_WAIT_2 CLOSE_WAIT
<<——– (server closes)
LAST_ACK
, ——->>
TIME_WAIT CLOSED
(2*msl elapses…)
CLOSED

Note: the +1 on the sequence numbers is because the FIN counts as one
byte of data. (The above diagram is equivalent to fig. 13 from RFC
793).

Now consider what happens if the last of those packets is dropped in
the network. The client has done with the connection; it has no more
data or control info to send, and never will have. But the server does
not know whether the client received all the data correctly; that’s
what the last ACK segment is for. Now the server may or may not care
whether the client got the data, but that is not an issue for TCP; TCP
is a reliable rotocol, and must distinguish between an orderly
connection close where all data is transferred, and a connection abort
where data may or may not have been lost.

So, if that last packet is dropped, the server will retransmit it (it
is, after all, an unacknowledged segment) and will expect to see a
suitable ACK segment in reply. If the client went straight to CLOSED,
the only possible response to that retransmit would be a RST, which
would indicate to the server that data had been lost, when in fact it
had not been.

(Bear in mind that the server’s FIN segment may, additionally, contain
data.)

DISCLAIMER: This is my interpretation of the RFCs (I have read all the
TCP-related ones I could find), but I have not attempted to examine
implementation source code or trace actual connections in order to
verify it. I am satisfied that the logic is correct, though.

More commentarty from Vic:

The second issue was addressed by Richard Stevens (rstevens@noao.edu,
author of “Unix Network Programming”, see “1.5 Where can I get source
code for the book [book title]?”). I have put together quotes from
some of his postings and email which explain this. I have brought
together paragraphs from different postings, and have made as few
changes as possible.

From Richard Stevens (rstevens@noao.edu):

If the duration of the TIME_WAIT state were just to handle TCP’s full-
duplex close, then the time would be much smaller, and it would be
some function of the current RTO (retransmission timeout), not the MSL
(the packet lifetime).

A couple of points about the TIME_WAIT state.

o The end that sends the first FIN goes into the TIME_WAIT state,
because that is the end that sends the final ACK. If the other
end’s FIN is lost, or if the final ACK is lost, having the end that
sends the first FIN maintain state about the connection guarantees
that it has enough information to retransmit the final ACK.

o Realize that TCP sequence numbers wrap around after 2**32 bytes
have been transferred. Assume a connection between A.1500 (host A,
port 1500) and B.2000. During the connection one segment is lost
and retransmitted. But the segment is not really lost, it is held
by some intermediate router and then re-injected into the network.
(This is called a “wandering duplicate”.) But in the time between
the packet being lost & retransmitted, and then reappearing, the
connection is closed (without any problems) and then another
connection is established between the same host, same port (that
is, A.1500 and B.2000; this is called another “incarnation” of the
connection). But the sequence numbers chosen for the new
incarnation just happen to overlap with the sequence number of the
wandering duplicate that is about to reappear. (This is indeed
possible, given the way sequence numbers are chosen for TCP
connections.) Bingo, you are about to deliver the data from the
wandering duplicate (the previous incarnation of the connection) to
the new incarnation of the connection. To avoid this, you do not
allow the same incarnation of the connection to be reestablished
until the TIME_WAIT state terminates.

Even the TIME_WAIT state doesn’t complete solve the second problem,
given what is called TIME_WAIT assassination. RFC 1337 has more
details.

o The reason that the duration of the TIME_WAIT state is 2*MSL is
that the maximum amount of time a packet can wander around a
network is assumed to be MSL seconds. The factor of 2 is for the
round-trip. The recommended value for MSL is 120 seconds, but
Berkeley-derived implementations normally use 30 seconds instead.
This means a TIME_WAIT delay between 1 and 4 minutes. Solaris 2.x
does indeed use the recommended MSL of 120 seconds.

A wandering duplicate is a packet that appeared to be lost and was
retransmitted. But it wasn’t really lost … some router had
problems, held on to the packet for a while (order of seconds, could
be a minute if the TTL is large enough) and then re-injects the packet
back into the network. But by the time it reappears, the application
that sent it originally has already retransmitted the data contained
in that packet.

Because of these potential problems with TIME_WAIT assassinations, one
should not avoid the TIME_WAIT state by setting the SO_LINGER option
to send an RST instead of the normal TCP connection termination
(FIN/ACK/FIN/ACK). The TIME_WAIT state is there for a reason; it’s
your friend and it’s there to help you :-)

I have a long discussion of just this topic in my just-released
“TCP/IP Illustrated, Volume 3”. The TIME_WAIT state is indeed, one of
the most misunderstood features of TCP.

I’m currently rewriting “Unix Network Programming” (see “1.5 Where
can I get source code for the book [book title]?”). and will include
lots more on this topic, as it is often confusing and misunderstood.

An additional note from Andrew:

Closing a socket: if SO_LINGER has not been called on a socket, then
close() is not supposed to discard data. This is true on SVR4.2 (and,
apparently, on all non-SVR4 systems) but apparently not on SVR4; the
use of either shutdown() or SO_LINGER seems to be required to
guarantee delivery of all data.

——————————————————————————————-

讨厌的 Socket TIME_WAIT 问题

netstat -n | awk ‘/^tcp/ {++state[$NF]} END {for(key in state) print key,”/t”,state[key]}’

会得到类似下面的结果,具体数字会有所不同:

LAST_ACK 1
SYN_RECV 14
ESTABLISHED 79
FIN_WAIT1 28
FIN_WAIT2 3
CLOSING 5
TIME_WAIT 1669

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

也就是说,这条命令可以把当前系统的网络连接状态分类汇总。

下面解释一下为啥要这样写:

一个简单的管道符连接了netstat和awk命令。

——————————————————————

每个TCP报文在网络内的最长时间,就称为MSL(Maximum Segment Lifetime),它的作用和IP数据包的TTL类似。

RFC793指出,MSL的值是2分钟,但是在实际的实现中,常用的值有以下三种:30秒,1分钟,2分钟。

注意一个问题,进入TIME_WAIT状态的一般情况下是客户端,大多数服务器端一般执行被动关闭,不会进入TIME_WAIT状态,当在服务

器端关闭某个服务再重新启动时,它是会进入TIME_WAIT状态的。

举例:
1.客户端连接服务器的80服务,这时客户端会启用一个本地的端口访问服务器的80,访问完成后关闭此连接,立刻再次访问服务器的

80,这时客户端会启用另一个本地的端口,而不是刚才使用的那个本地端口。原因就是刚才的那个连接还处于TIME_WAIT状态。
2.客户端连接服务器的80服务,这时服务器关闭80端口,立即再次重启80端口的服务,这时可能不会成功启动,原因也是服务器的连

接还处于TIME_WAIT状态。
检查net.ipv4.tcp_tw当前值,将当前的值更改为1分钟:
[root@aaa1 ~]# sysctl -a|grep net.ipv4.tcp_tw
net.ipv4.tcp_tw_reuse = 0
net.ipv4.tcp_tw_recycle = 0
[root@aaa1 ~]#

vi /etc/sysctl
增加或修改net.ipv4.tcp_tw值:
net.ipv4.tcp_tw_reuse = 1
net.ipv4.tcp_tw_recycle = 1

使内核参数生效:
[root@aaa1 ~]# sysctl -p

[root@aaa1 ~]# sysctl -a|grep net.ipv4.tcp_tw
net.ipv4.tcp_tw_reuse = 1
net.ipv4.tcp_tw_recycle = 1

用netstat再观察正常
这里解决问题的关键是如何能够重复利用time_wait的值,我们可以设置时检查一下time和wait的值
#sysctl -a | grep time | grep wait
net.ipv4.netfilter.ip_conntrack_tcp_timeout_time_wait = 120
net.ipv4.netfilter.ip_conntrack_tcp_timeout_close_wait = 60
net.ipv4.netfilter.ip_conntrack_tcp_timeout_fin_wait = 120

问一下TIME_WAIT有什么问题,是闲置而且内存不回收吗?

是的,这样的现象实际是正常的,有时和访问量大有关,设置这两个参数: reuse是表示是否允许重新应用处于TIME-WAIT状态的

socket用于新的TCP连接; recyse是加速TIME-WAIT sockets回收

Q: 我正在写一个unix server程序,不是daemon,经常需要在命令行上重启它,绝大
多数时候工作正常,但是某些时候会报告”bind: address in use”,于是重启失
败。

A: Andrew Gierth
server程序总是应该在调用bind()之前设置SO_REUSEADDR套接字选项。至于
TIME_WAIT状态,你无法避免,那是TCP协议的一部分。

Q: 如何避免等待60秒之后才能重启服务

A: Erik Max Francis

使用setsockopt,比如

————————————————————————–
int option = 1;

if ( setsockopt ( masterSocket, SOL_SOCKET, SO_REUSEADDR, &option,
sizeof( option ) ) < 0 )
{
die( “setsockopt” );
}
————————————————————————–

Q: 编写 TCP/SOCK_STREAM 服务程序时,SO_REUSEADDR到底什么意思?

A: 这个套接字选项通知内核,如果端口忙,但TCP状态位于 TIME_WAIT ,可以重用
端口。如果端口忙,而TCP状态位于其他状态,重用端口时依旧得到一个错误信息,
指明”地址已经使用中”。如果你的服务程序停止后想立即重启,而新套接字依旧
使用同一端口,此时 SO_REUSEADDR 选项非常有用。必须意识到,此时任何非期
望数据到达,都可能导致服务程序反应混乱,不过这只是一种可能,事实上很不
可能。

一个套接字由相关五元组构成,协议、本地地址、本地端口、远程地址、远程端
口。SO_REUSEADDR 仅仅表示可以重用本地本地地址、本地端口,整个相关五元组
还是唯一确定的。所以,重启后的服务程序有可能收到非期望数据。必须慎重使
用 SO_REUSEADDR 选项。

Q: 在客户机/服务器编程中(TCP/SOCK_STREAM),如何理解TCP自动机 TIME_WAIT 状
态?

A: W. Richard Stevens <1999年逝世,享年49岁>

下面我来解释一下 TIME_WAIT 状态,这些在<>
中2.6节解释很清楚了。

MSL(最大分段生存期)指明TCP报文在Internet上最长生存时间,每个具体的TCP实现
都必须选择一个确定的MSL值。RFC 1122建议是2分钟,但BSD传统实现采用了30秒。

TIME_WAIT 状态最大保持时间是2 * MSL,也就是1-4分钟。

IP头部有一个TTL,最大值255。尽管TTL的单位不是秒(根本和时间无关),我们仍需
假设,TTL为255的TCP报文在Internet上生存时间不能超过MSL。

TCP报文在传送过程中可能因为路由故障被迫缓冲延迟、选择非最优路径等等,结果
发送方TCP机制开始超时重传。前一个TCP报文可以称为”漫游TCP重复报文”,后一个
TCP报文可以称为”超时重传TCP重复报文”,作为面向连接的可靠协议,TCP实现必须
正确处理这种重复报文,因为二者可能最终都到达。

一个通常的TCP连接终止可以用图描述如下:

client server
FIN M
close —————–> (被动关闭)
ACK M+1
<—————–
FIN N
<—————– close
ACK N+1
—————–>

为什么需要 TIME_WAIT 状态?

假设最终的ACK丢失,server将重发FIN,client必须维护TCP状态信息以便可以重发
最终的ACK,否则会发送RST,结果server认为发生错误。TCP实现必须可靠地终止连
接的两个方向(全双工关闭),client必须进入 TIME_WAIT 状态,因为client可能面
临重发最终ACK的情形。

{
scz 2001-08-31 13:28

先调用close()的一方会进入TIME_WAIT状态
}

此外,考虑一种情况,TCP实现可能面临先后两个同样的相关五元组。如果前一个连
接处在 TIME_WAIT 状态,而允许另一个拥有相同相关五元组的连接出现,可能处理
TCP报文时,两个连接互相干扰。使用 SO_REUSEADDR 选项就需要考虑这种情况。

为什么 TIME_WAIT 状态需要保持 2MSL 这么长的时间?

如果 TIME_WAIT 状态保持时间不足够长(比如小于2MSL),第一个连接就正常终止了。
第二个拥有相同相关五元组的连接出现,而第一个连接的重复报文到达,干扰了第二
个连接。TCP实现必须防止某个连接的重复报文在连接终止后出现,所以让TIME_WAIT
状态保持时间足够长(2MSL),连接相应方向上的TCP报文要么完全响应完毕,要么被
丢弃。建立第二个连接的时候,不会混淆。

A: 小四

在Solaris 7下有内核参数对应 TIME_WAIT 状态保持时间

# ndd -get /dev/tcp tcp_time_wait_interval
240000
# ndd -set /dev/tcp tcp_time_wait_interval 1000

缺省设置是240000ms,也就是4分钟。如果用ndd修改这个值,最小只能设置到1000ms,
也就是1秒。显然内核做了限制,需要Kernel Hacking。

# echo “tcp_param_arr/W 0t0” | adb -kw /dev/ksyms /dev/mem
physmem 3b72
tcp_param_arr: 0x3e8 = 0x0
# ndd -set /dev/tcp tcp_time_wait_interval 0

我不知道这样做有什么灾难性后果,参看<>的声明。

Q: TIME_WAIT 状态保持时间为0会有什么灾难性后果?在普遍的现实应用中,好象也
就是服务器不稳定点,不见得有什么灾难性后果吧?

D: rain@bbs.whnet.edu.cn

Linux 内核源码 /usr/src/linux/include/net/tcp.h 中

#define TCP_TIMEWAIT_LEN (60*HZ) /* how long to wait to successfully
* close the socket, about 60 seconds */

最好不要改为0,改成1。端口分配是从上一次分配的端口号+1开始分配的,所以一般
不会有什么问题。端口分配算法在tcp_ipv4.c中tcp_v4_get_port中

php 性能分析工具xhprof使用简介

2016年11月12日 评论已被关闭

php 性能分析工具xhprof使用简介

http://www.ithao123.cn/content-11045393.html

[摘要:xphrof是甚么 是一款PHP机能剖析硬件,支撑LINUX。 民圆地点:http://xhprof.io/ 若何装置? 待增补 若何应用? 待增补 参数解释 首要目标: Inclusive Time ]

xphrof是什么

  • 是一款PHP性能分析软件,支持LINUX。
  • 官方地址:http://xhprof.io/

如何安装?

  • 待补充

如何使用?

  • 待补充

参数说明

  • 主要指标:
    • Inclusive Time (或子树时间):包括子函数所有执行时间。
    • Exclusive Time/Self Time:函数执行本身花费的时间,不包括子树执行时间。
    • Wall时间:花去了的时间或挂钟时间。
    • CPU时间:用户耗的时间+内核耗的时间
    • Function Name 函数名
    • Calls 调用次数
    • Calls% 调用百分比
  • 消耗时间
    • Incl. Wall Time (microsec) 调用的包括子函数所有花费时间 以微秒算(一百万分之一秒)
    • IWall% 调用的包括子函数所有花费时间的百分比
    • Excl. Wall Time (microsec) 函数执行本身花费的时间,不包括子树执行时间,以微秒算(一百万分之一秒)
    • EWall% 函数执行本身花费的时间的百分比,不包括子树执行时间
  • 消耗CPU
    • Incl. CPU(microsecs) 调用的包括子函数所有花费的cpu时间。减Incl. Wall Time即为等待cpu的时间
    • ICpu% Incl. CPU(microsecs)的百分比
    • Excl. CPU(microsec) 函数执行本身花费的cpu时间,不包括子树执行时间,以微秒算(一百万分之一秒)。
    • ECPU% Excl. CPU(microsec)的百分比
  • 消耗内存
    • Incl.MemUse(bytes) 包括子函数执行使用的内存。
    • IMemUse% Incl.MemUse(bytes)的百分比
    • Excl.MemUse(bytes) 函数执行本身内存,以字节算
    • EMemUse% Excl.MemUse(bytes)的百分比
  • 消耗内存峰值
    • Incl.PeakMemUse(bytes) Incl.MemUse的峰值
    • IPeakMemUse% Incl.PeakMemUse(bytes) 的峰值百分比
    • Excl.PeakMemUse(bytes) Excl.MemUse的峰值
    • EPeakMemUse% EMemUse% 峰值百分比

Yii、Yaf、CI、ThinkPHP高并发下性能测试

2016年11月12日 评论已被关闭

Yii、Yaf、CI、ThinkPHP高并发下性能测试

http://kokahkhk.blog.163.com/blog/static/2094280402014119101854373/

公司最近准备做个新项目,在考虑用个新框架来实施,所以测试了Yii、Yaf、CI、ThinkPHP在高并发100、200、300的性能表现

测试服务器:双核4G 64位Linux服务器
模拟情况:分别模拟300、200、100并发,对YII、CI、ThinkPHP、Yaf框架进行压测(4个框架都是最简单的demo,没有任何业务逻辑和数据库链接),并统计其方法调用、响应时间,系统指标等值进行对比。

首先来通过Xphrof来看下各个框架的 函数CPU使用率,内存开销,调用方法
Yii、Yaf、CI、ThinkPHP高并发下性能测试 - T-Mac - 小麦的博客

从框架启动调用方法来看,Yii由于扩展库比较多启动需要Call1055次函数,Yaf最少14个

再来看下内存占用,由于Yii调用函数比较多,消耗3M内存,而Yaf只有31k
函数CPU开销来看,YII框架CPU消耗共0.008%,而YAF的CPU消耗几乎为0
函数开销
Yii、Yaf、CI、ThinkPHP高并发下性能测试 - T-Mac - 小麦的博客
系统CPU占用
Yii、Yaf、CI、ThinkPHP高并发下性能测试 - T-Mac - 小麦的博客

响应时间

Yii、Yaf、CI、ThinkPHP高并发下性能测试 - T-Mac - 小麦的博客

总结:由于Yaf用C写的,性能表现相对出色,但是该框架是不是适合企业级应用还需要评估,并且由于该框架属于个人开发,未来更新维护也不是特别有保障;而thinkphp虽然单次调用方法和YII差不多,但是其CPU和内存占用,比YII低了很多,响应时间更是快了1s多,性能全面超过了YII;而CI,调用方法数比前2者少,但在响应时间和系统占用方面,比thinkphp更出色。另外在测试期间分别查看了各个框架对IO的读写,ThinkPHP和Yii对I/O读写相对其他2个框架要多些,如果使用TP/YII也要考虑I/O读写能力,综合来看Yaf比较适合大并发,业务逻辑不复杂的项目,CI相对比较折中。

用httping测试web页面响应时间

2016年11月10日 评论已被关闭

用httping测试web页面响应时间

http://www.linuxidc.com/Linux/2014-02/96165.htm

性能测试是软件测试中很重要的工程工程,有时候我们需要测试的一项内容便是web页面响应时间,httping就是这样一种专门用来测试web页面响应时间的开源软件。

在FreeBSD下安装

#cd /usr/ports/net/httping
#make install clean
#rehash

用法如下

#httping -h

httping: option requires an argument — h
HTTPing v1.2.6, (C) 2003-2008 folkert@vanheusden.com
SSL support included

-g url          url (e.g. -g http://localhost/)
-h hostname    hostname (e.g. localhost)
-p portnr      portnumber (e.g. 80)
-x host:port    hostname+portnumber of proxyserver
-c count        how many times to connect
-i interval    delay between each connect
-t timeout      timeout (default: 30s)
-s              show statuscodes
-S            split time in connect-time and processing time
-G              do a GET request instead of HEAD (read the
contents of the page as well)
-b              show transfer speed in KB/s (use with -G)
-B              like -b but use compression if available
-L x            limit the amount of data transferred (for -b)
to ‘x’ (in bytes)
-X              show the number of KB transferred (for -b)
-l              connect using SSL
-z              show fingerprint (SSL)
-f              flood connect (no delays)
-a              audible ping
-m              give machine parseable output (see
also -o and -e)
-o rc,rc,…    what http results codes indicate ‘ok’
coma seperated WITHOUT spaces inbetween
default is 200, use with -e
-e str          string to display when http result code
doesn’t match
-I str          use ‘str’ for the UserAgent header
-R str          use ‘str’ for the Referer header
-r              resolve hostname only once (usefull when
pinging roundrobin DNS: also takes the first
DNS lookup out of the loop so that the first
measurement is also correct)
-n warn,crit    Nagios-mode: return 1 when avg. response time
>= warn, 2 if >= crit, otherwhise return 0
-N x            Nagios mode 2: return 0 when all fine, ‘x’
when anything failes
-y ip[:port]  bind to ip-address (and thus interface) [/port]
-q              quiet, only returncode
-V              show the version
每一个选项都有注释 比较好懂

下面就用他来测试本地到sina的页面响应时间吧
由于网络延时 堵塞等原因 可能出现不稳定的结果
测试10次取平均值

#httping -c10 -g http://www.sina.com.cn

PING www.sina.com.cn:80 (http://www.sina.com.cn):
connected to www.sina.com.cn:80, seq=0 time=8.76 ms
connected to www.sina.com.cn:80, seq=1 time=4.81 ms
connected to www.sina.com.cn:80, seq=2 time=5005.72 ms
connected to www.sina.com.cn:80, seq=3 time=6204.22 ms
connected to www.sina.com.cn:80, seq=4 time=5.45 ms
connected to www.sina.com.cn:80, seq=5 time=5.63 ms
connected to www.sina.com.cn:80, seq=6 time=7.44 ms
connected to www.sina.com.cn:80, seq=7 time=5006.06 ms
connected to www.sina.com.cn:80, seq=8 time=5.16 ms
connected to www.sina.com.cn:80, seq=9 time=5.01 ms
— http://www.sina.com.cn ping statistics —
10 connects, 10 ok, 0.00% failed
round-trip min/avg/max = 4.8/1625.8/6204.2 ms

平均值为1625.8ms,也就是1.63s

如果是测试本网段的某个主机,则测试结果就比较可以信任了
#httping -c10 -g http://www.linuxidc.com

PING www.linuxidc.com:80 (http://www.linuxidc.com):
connected to www.linuxidc.com:80, seq=0 time=17.11 ms
connected to www.linuxidc.com:80, seq=1 time=23.52 ms
connected to www.linuxidc.com:80, seq=2 time=18.72 ms
connected to www.linuxidc.com:80, seq=3 time=19.37 ms
connected to www.linuxidc.com:80, seq=4 time=107.02 ms
connected to www.linuxidc.com:80, seq=5 time=19.70 ms
connected to www.linuxidc.com:80, seq=6 time=31.35 ms
connected to www.linuxidc.com:80, seq=7 time=21.85 ms
connected to www.linuxidc.com:80, seq=8 time=19.67 ms
connected to www.linuxidc.com:80, seq=9 time=19.52 ms
— http://www.linuxidc.com ping statistics —
10 connects, 10 ok, 0.00% failed
round-trip min/avg/max = 17.1/29.8/107.0 ms

测试结果出来了
最小web页面响应时间:17.1  ms
平均web页面响应时间:29.8  ms
最大web页面响应时间:107.0 ms

一般来说 对我们有意义的数据是是平均值

可以用shell直接取到这个值得

#httping -c5 -g http://www.linuxidc.com | tail -n1 | awk ‘{print $4}’ | cut -d/ -f2

还可以配合shell和rrdtool可以画出一张完美的web响应时间图来,还不错,^_^^_^

持续集成工具:Jenkins

2016年10月24日 评论已被关闭

持续集成工具:Jenkins

http://blog.csdn.net/liumiaocn/article/details/52159309

在DevOps的工具链中,有人曾说过唯一不可替换的就是持续集成的工具Jenkins。目前使用较多的可以与之抗衡的是hudson,但是jenkins和hudson,仅仅是被oracle收购之后产生的副作用,jenkins由hudson被迫更名,仅此而已。当然还有一些商业软件也用于持续集成,但是均难以撼动jenkins目前如日中天的地位。Jenkins2.0以后功能作了较大变化,让我们来一探究竟。

docker pull

[root@host32 ~]# docker pull jenkins
  • 1

确认下载

[root@host32 ~]# docker images |grep jenkins
jenkins             latest              5dc8da75a084        Less than a second ago   715.2 MB
[root@host32 ~]#
  • 1
  • 2
  • 3

docker run

由于宿主机的8080口已经被占用,所以port的mapping的时候使用9090作为对外服务的port,可根据情况自行设定

[root@host32 ~]# docker run -d -p 9090:8080 jenkins
  • 1

login画面

在URL中输入http://192.168.32.32:9090

这里写图片描述

说明:Jenkins目前用的最多的是1.6的稳定版本。2.0以后在安装的时候会自动生成一个这样的token(Administrator password),我们需要进入到使用jenkins的image启动起来的jenkins container中确认此token的内容,然后输入它就可以下一步了。

[root@host32 ~]# docker ps |grep jenkins
0fab3272c76b        jenkins             "/bin/tini -- /usr/lo"   7 minutes ago       Up 7 minutes        50000/tcp, 0.0.0.0:9090->8080/tcp   stupefied_nobel
[root@host32 ~]# docker exec -it 0fab3272c76b /bin/bash
jenkins@0fab3272c76b:/$ cat /var/jenkins_home/secrets/initialAdminPassword
c1f3c1b6acc0447a8e70c2379119013f
jenkins@0fab3272c76b:/$
  • 1
  • 2
  • 3
  • 4
  • 5
  • 6

输入查询出来的c1f3c1b6acc0447a8e70c2379119013f,然后continue,非docker的方式直接在linux上cat取得即可。

安装plugin

这里写图片描述

Jenkins在2.0后,加入了很多机能,更是在此处可以让用户在安装的时候便可以自由选择,但是在不能直接连接外网需要proxy设定的情形,还是不能特别方面的对应,因此而不能成功的情况目前可以先skip然后在jenkins中设定好代理再手动下载吧,期待后续的版本能不能更加人性一些,将jenkins的proxy设定的模块移到此处。
此处安装不需设定proxy,所以就默认选择直接继续了。

这里写图片描述

从这里可以清晰地看到在很多suggested plugins中,有个pipeline的plugin格外引人注目,其实这也是jenkins2.0后一个非常大的改进,DevOps的流水线,在jenkins中可以通过其提供的DSL进行编辑,这个时代已经是所有的人在作同一件事情了。

设定admin帐户

这里写图片描述

安装完成

这里写图片描述

在安装的过程中,我们可以看到版本是2.7.2,Jenkins基本上每周都会发布一个版本。但是dockerhub上的版本会有所滞后,如果想使用最新版本的话可以去下载最新的war,另外jenkins现在还提供了各种安装包,对于一个只需要java或者tomcat就可以运行的软件,提供rpm的安装包总是给人一种闲大发了的感觉,要不要给hpux或者aix或者IBM360上也做一些安装包呢。

画面确认

这里写图片描述

分类: Linux性能优化测试 标签:

tcp_keepalive的设置

2016年6月2日 评论已被关闭

tcp_keepalive的设置
http://blog.sina.com.cn/s/blog_a2d4803001013hrk.html
1.参数设置
查看相关的参数
sysctl -a|grep tcp_keepalive
net.ipv4.tcp_keepalive_intvl = 30
net.ipv4.tcp_keepalive_probes = 2
net.ipv4.tcp_keepalive_time = 160
设置相关的参数
sysctl -w net.ipv4.tcp_keepalive_time = 7500
也可以直接打开/etc/sysctl.conf
加入net.ipv4.tcp_keepalive_time = 7500,然后保存退出
让参数生效
sysctl -p
2.参数相关的说明
/proc/sys/net/ipv4/tcp_keepalive_time
当keepalive起用的时候,TCP发送keepalive消息的频度。缺省是2小时。
/proc/sys/net/ipv4/tcp_keepalive_intvl
当探测没有确认时,重新发送探测的频度。缺省是75秒。
/proc/sys/net/ipv4/tcp_keepalive_probes
在认定连接失效之前,发送多少个TCP的keepalive探测包。缺省值是9。这个值乘以tcp_keepalive_intvl之后决定了,一个连接发送了keepalive之后可以有多少时间没有回应
tcp_keepalive_time :INTEGER
默认值是7200(2小时)
当keepalive打开的情况下,TCP发送keepalive消息的频率。(由于目前网络攻击等因素,造成了利用这个进行的攻击很频繁,曾经也有cu的朋友提到过,说如果2边建立了连接,然后不发送任何数据或者rst/fin消息,那么持续的时间是不是就是2小时,空连接攻击? tcp_keepalive_time就是预防此情形的.我个人在做nat服务的时候的修改值为1800秒)
tcp_keepalive_probes:INTEGER
默认值是9
TCP发送keepalive探测以确定该连接已经断开的次数。(注意:保持连接仅在SO_KEEPALIVE套接字选项被打开是才发送.次数默认不需要修改,当然根据情形也可以适当地缩短此值.设置为5比较合适)
tcp_keepalive_intvl:INTEGER
默认值为75
探测消息发送的频率,乘以tcp_keepalive_probes就得到对于从开始探测以来没有响应的连接杀除的时间。默认值为75秒,也就是没有活动的连接将在大约11分钟以后将被丢弃。(对于普通应用来说,这个值有一些偏大,可以根据需要改小.特别是web类服务器需要改小该值,15是个比较合适的值)
$ /proc/sys/net/ipv4/tcp_keepalive_time
$ /proc/sys/net/ipv4/tcp_keepalive_intvl
$ /proc/sys/net/ipv4/tcp_keepalive_probes
这3个参数与TCP KeepAlive有关.默认值是:
tcp_keepalive_time = 7200 seconds (2 hours)
tcp_keepalive_probes = 9
tcp_keepalive_intvl = 75 seconds
意思是如果某个TCP连接在idle 2个小时后,内核才发起probe.如果probe 9次(每次75秒)不成功,内核才彻底放弃,认为该连接已失效.对服务器而言,显然上述值太大. 可调整到:
/proc/sys/net/ipv4/tcp_keepalive_time 1800
/proc/sys/net/ipv4/tcp_keepalive_intvl 30
/proc/sys/net/ipv4/tcp_keepalive_probes 3
tcp_keepalive_intvl:探测消息发送的频率

nginx负载均衡配置

2016年6月1日 评论已被关闭

nginx负载均衡配置
http://outofmemory.cn/code-snippet/3038/nginx-load-junheng-configuration
nginx负载均衡配置
使用负载均衡的话,可以修改配置http节点如下:

#设定http服务器,利用它的反向代理功能提供负载均衡支持
http {

#设定mime类型,类型由mime.type文件定义
include             /etc/nginx/mime.types;
default_type    application/octet-stream;

#设定日志格式
access_log        /var/log/nginx/access.log;

#省略上文有的一些配置节点
#。。。。。。。。。。

#设定负载均衡的服务器列表
upstream mysvr {
#weigth参数表示权值,权值越高被分配到的几率越大
server 192.168.8.1x:3128 weight=5;
#本机上的Squid开启3128端口,不是必须要squid
server 192.168.8.2x:80    weight=1;
server 192.168.8.3x:80    weight=6;
}

upstream mysvr2 {
#weigth参数表示权值,权值越高被分配到的几率越大
server 192.168.8.x:80    weight=1;
server 192.168.8.x:80    weight=6;
}

#第一个虚拟服务器
server {
#侦听192.168.8.x的80端口
listen             80;
server_name    192.168.8.x;

#对aspx后缀的进行负载均衡请求
location ~ .*\.aspx$ {
#定义服务器的默认网站根目录位置
root     /root;
#定义首页索引文件的名称
index index.php index.html index.htm;

#请求转向mysvr 定义的服务器列表
proxy_pass    http://mysvr ;

#以下是一些反向代理的配置可删除.

proxy_redirect off;

#后端的Web服务器可以通过X-Forwarded-For获取用户真实IP
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;

#允许客户端请求的最大单文件字节数
client_max_body_size 10m;

#缓冲区代理缓冲用户端请求的最大字节数,
client_body_buffer_size 128k;

#nginx跟后端服务器连接超时时间(代理连接超时)
proxy_connect_timeout 90;

#连接成功后,后端服务器响应时间(代理接收超时)
proxy_read_timeout 90;

#设置代理服务器(nginx)保存用户头信息的缓冲区大小
proxy_buffer_size 4k;

#proxy_buffers缓冲区,网页平均在32k以下的话,这样设置
proxy_buffers 4 32k;

#高负荷下缓冲大小(proxy_buffers*2)
proxy_busy_buffers_size 64k;

#设定缓存文件夹大小,大于这个值,将从upstream服务器传
proxy_temp_file_write_size 64k;

}
}
}

Nginx负载均衡配置实例详解

2016年6月1日 评论已被关闭

Nginx负载均衡配置实例详解

http://www.php100.com/html/program/nginx/2013/0905/5525.html
负载均衡是我们大流量网站要做的一个东西,下面我来给大家介绍在Nginx服务器上进行负载均衡配置方法,希望对有需要的同学有所帮助哦。负载均衡先来简单了解一下什么是负载均衡,单从字面上的意思来理解就可以解 负载均衡是我们大流量网站要做的一个东西,下面我来给大家介绍在Nginx服务器上进行负载均衡配置方法,希望对有需要的同学有所帮助哦。
负载均衡
先来简单了解一下什么是负载均衡,单从字面上的意思来理解就可以解释N台服务器平均分担负载,不会因为某台服务器负载高宕机而某台服务器闲置的情况。那么负载均衡的前提就是要有多台服务器才能实现,也就是两台以上即可。
测试环境
由于没有服务器,所以本次测试直接host指定域名,然后在VMware里安装了三台CentOS。
测试域名  :a.com
A服务器IP :192.168.5.149 (主)
B服务器IP :192.168.5.27
C服务器IP :192.168.5.126
部署思路
A服务器做为主服务器,域名直接解析到A服务器(192.168.5.149)上,由A服务器负载均衡到B服务器(192.168.5.27)与C服务器(192.168.5.126)上。

域名解析
由于不是真实环境,域名就随便使用一个a.com用作测试,所以a.com的解析只能在hosts文件设置。
打开:C:WindowsSystem32driversetchosts
在末尾添加
192.168.5.149    a.com
保存退出,然后启动命令模式ping下看看是否已设置成功

从截图上看已成功将a.com解析到192.168.5.149IP
A服务器nginx.conf设置
打开nginx.conf,文件位置在nginx安装目录的conf目录下。
在http段加入以下代码
upstream a.com {
server  192.168.5.126:80;
server  192.168.5.27:80;
}

server{
listen 80;
server_name a.com;
location / {
proxy_pass         http://a.com;
proxy_set_header   Host             $host;
proxy_set_header   X-Real-IP        $remote_addr;
proxy_set_header   X-Forwarded-For  $proxy_add_x_forwarded_for;
}
}
保存重启nginx
B、C服务器nginx.conf设置
打开nginx.confi,在http段加入以下代码
server{
listen 80;
server_name a.com;
index index.html;
root /data0/htdocs/www;
}
保存重启nginx
测试
当访问a.com的时候,为了区分是转向哪台服务器处理我分别在B、C服务器下写一个不同内容的index.html文件,以作区分。
打开浏览器访问a.com结果,刷新会发现所有的请求均分别被主服务器(192.168.5.149)分配到B服务器(192.168.5.27)与C服务器(192.168.5.126)上,实现了负载均衡效果。
B服务器处理页面

C服务器处理页面

假如其中一台服务器宕机会怎样?
当某台服务器宕机了,是否会影响访问呢?
我们先来看看实例,根据以上例子,假设C服务器192.168.5.126这台机子宕机了(由于无法模拟宕机,所以我就把C服务器关机)然后再来访问看看。
访问结果:

我们发现,虽然C服务器(192.168.5.126)宕机了,但不影响网站访问。这样,就不会担心在负载均衡模式下因为某台机子宕机而拖累整个站点了。
如果b.com也要设置负载均衡怎么办?
很简单,跟a.com设置一样。如下:
假设b.com的主服务器IP是192.168.5.149,负载均衡到192.168.5.150和192.168.5.151机器上
现将域名b.com解析到192.168.5.149IP上。
在主服务器(192.168.5.149)的nginx.conf加入以下代码:
upstream b.com {
server  192.168.5.150:80;
server  192.168.5.151:80;
}

server{
listen 80;
server_name b.com;
location / {
proxy_pass         http://b.com;
proxy_set_header   Host             $host;
proxy_set_header   X-Real-IP        $remote_addr;
proxy_set_header   X-Forwarded-For  $proxy_add_x_forwarded_for;
}
}
保存重启nginx
在192.168.5.150与192.168.5.151机器上设置nginx,打开nginx.conf在末尾添加以下代码:
server{
listen 80;
server_name b.com;
index index.html;
root /data0/htdocs/www;
}
保存重启nginx
完成以后步骤后即可实现b.com的负载均衡配置。
主服务器不能提供服务吗?
以上例子中,我们都是应用到了主服务器负载均衡到其它服务器上,那么主服务器本身能不能也加在服务器列表中,这样就不会白白浪费拿一台服务器纯当做转发功能,而是也参与到提供服务中来。
如以上案例三台服务器:
A服务器IP :192.168.5.149 (主)
B服务器IP :192.168.5.27
C服务器IP :192.168.5.126
我们把域名解析到A服务器,然后由A服务器转发到B服务器与C服务器,那么A服务器只做一个转发功能,现在我们让A服务器也提供站点服务。
我们先来分析一下,如果添加主服务器到upstream中,那么可能会有以下两种情况发生:
1、主服务器转发到了其它IP上,其它IP服务器正常处理;
2、主服务器转发到了自己IP上,然后又进到主服务器分配IP那里,假如一直分配到本机,则会造成一个死循环。
怎么解决这个问题呢?因为80端口已经用来监听负载均衡的处理,那么本服务器上就不能再使用80端口来处理a.com的访问请求,得用一个新的。于是我们把主服务器的nginx.conf加入以下一段代码:
server{
listen 8080;
server_name a.com;
index index.html;
root /data0/htdocs/www;
}

重启nginx,在浏览器输入a.com:8080试试看能不能访问。结果可以正常访问

既然能正常访问,那么我们就可以把主服务器添加到upstream中,但是端口要改一下,如下代码:
upstream a.com {
server  192.168.5.126:80;
server  192.168.5.27:80;
server  127.0.0.1:8080;
}
由于这里可以添加主服务器IP192.168.5.149或者127.0.0.1均可以,都表示访问自己。
重启Nginx,然后再来访问a.com看看会不会分配到主服务器上。

主服务器也能正常加入服务了。
最后
一、负载均衡不是nginx独有,著名鼎鼎的apache也有,但性能可能不如nginx。
二、多台服务器提供服务,但域名只解析到主服务器,而真正的服务器IP不会被ping下即可获得,增加一定安全性。

三、upstream里的IP不一定是内网,外网IP也可以。不过经典的案例是,局域网中某台IP暴露在外网下,域名直接解析到此IP。然后又这台主服务器转发到内网服务器IP中。
四、某台服务器宕机、不会影响网站正常运行,Nginx不会把请求转发到已宕机的IP上

使用apache benchmark(ab) 测试报错: apr_socket_recv: Connection timed out (110)

2016年5月23日 评论已被关闭

使用apache benchmark(ab) 测试报错: apr_socket_recv: Connection timed out (110)

http://blog.csdn.net/garn_hsia/article/details/12997477

网上流传方法一:

使用ab或者webbench做压力测试,如果并发数开到1000的时候,无法完成测试。到晚上查看资料发现是linux网络参数设置。

[longhao@longhao etc]# vi /etc/sysctl.conf
在kernel2.6之前的添加项:
net.ipv4.netfilter.ip_conntrack_max = 655360
net.ipv4.netfilter.ip_conntrack_tcp_timeout_established = 180

kernel2.6之后的添加项:
net.nf_conntrack_max = 655360  # net.nf_conntrack_max = 655360 也可以
net.netfilter.nf_conntrack_tcp_timeout_established = 1200

[longhao@longhao etc]# sysctl -p /etc/sysctl.conf

如果报错:error: “net.nf_conntrack_max” is an unknown key 则需要使用modprobe载入ip_conntrack模块,lsmod查看模块已载入。
[longhao@longhao etc]# modprobe  ip_conntrack

网上流传方法二:

按如下修改 Apache 源码目录下 support/ab.c 文件,重新编译安装。

         elseif(status != APR_SUCCESS) {
             err_recv++;
             if(recverrok) {
                 bad++;
                 close_connection(c);
                 if(verbosity >= 1) {
                     charbuf[120];
                     fprintf(stderr,”%s: %s (%d)\n”, “apr_socket_recv”, apr_strerror(status, buf, sizeofbuf), status);
                }
                 return;
            } else{
                 bad++;                                 //添加
                 close_connection(c);                   //添加
                 //apr_err(“apr_socket_recv”, status);  //注释
return;    //添加
             }
         }

 

linux下的web服务器压力测试工具之Siege

2016年5月23日 评论已被关闭

linux下的web服务器压力测试工具之Siege

http://blog.csdn.net/lenchio/article/details/28651911

介绍

Siege是一款开源的压力测试工具,可以根据配置对一个WEB站点进行多用户的并发访问,记录每个用户所有请求过程的相应时间,并在一定数量的并发访问下重复进行。

官方:http://www.joedog.org/
Siege下载:http://soft.vpser.net/test/siege/siege-2.67.tar.gz

安装

解压

# tar -zxf siege-2.67.tar.gz
进入解压目录:
# cd siege-2.67/
#./configure ; make
#make install

示例

siege -c 200 -r 10 -f example.url
-c是并发量,-r是重复次数。 url文件就是一个文本,每行都是一个url,它会从里面随机访问的。

example.url内容:

http://www.licess.cn
http://www.vpser.net
http://soft.vpser.net

结果说明

Lifting the server siege… done.
Transactions: 3419263 hits //完成419263次处理
Availability: 100.00 % //100.00 % 成功率
Elapsed time: 5999.69 secs //总共用时
Data transferred: 84273.91 MB //共数据传输84273.91 MB
Response time: 0.37 secs //相应用时1.65秒:显示网络连接的速度
Transaction rate: 569.91 trans/sec //均每秒完成 569.91 次处理:表示服务器后
Throughput: 14.05 MB/sec //平均每秒传送数据
Concurrency: 213.42 //实际最高并发数
Successful transactions: 2564081 //成功处理次数
Failed transactions: 11 //失败处理次数
Longest transaction: 29.04 //每次传输所花最长时间

Shortest transaction: 0.00 //每次传输所花最短时间

参考

http://www.cnblogs.com/shipengzhi/archive/2012/10/09/2716766.html

分类: Linux性能优化测试 标签:

linux下的web服务器压力测试工具之webbench

2016年5月23日 评论已被关闭

linux下的web服务器压力测试工具之webbench

http://blog.csdn.net/lenchio/article/details/28651717

介绍

webbench是Linux下的一个网站压力测试工具,最多可以模拟3万个并发连接去测试网站的负载能力。下载地址可以到google搜,我这里给出一个
下载地址:http://soft.vpser.net/test/webbench/webbench-1.5.tar.gz
解压后不到50K

安装

#tar zxvf webbench-1.5.tar.gz
#cd webbench-1.5
#make && make install
会在当前目录生成webbench可执行文件,直接可以使用了

示例

webbench -c 并发数 -t 运行测试时间 URL
如:
webbench -c 5000 -t 120 http://www.163.com

参考

http://www.cnblogs.com/shipengzhi/archive/2012/10/09/2716766.html

linux下的web服务器压力测试工具之http_load

2016年5月23日 评论已被关闭

linux下的web服务器压力测试工具之http_load

http://blog.csdn.net/lenchio/article/details/28651145

介绍

程序非常小,解压后也不到100K

http_load以并行复用的方式运行,用以测试web服务器的吞吐量与负载。但是它不同于大多数压力测试工具,它可以以一个单一的进程运行,一般不会把客户机搞死。还可以测试HTTPS类的网站请求。

安装

下载地址:http://soft.vpser.net/test/http_load/http_load-12mar2006.tar.gz

#tar zxvf http_load-12mar2006.tar.gz
#cd http_load-12mar2006
#make && make install

<!–more–>

命令格式:http_load  -p 并发访问进程数  -s 访问时间  需要访问的URL文件
参数其实可以自由组合,参数之间的选择并没有什么限制。比如你写成http_load -parallel 5 -seconds
300 urls.txt也是可以的。我们把参数给大家简单说明一下。
-parallel 简写-p :含义是并发的用户进程数。
-fetches 简写-f :含义是总计的访问次数
-rate    简写-p :含义是每秒的访问频率
-seconds简写-s :含义是总计的访问时间

示例

准备URL文件:urllist.txt,文件格式是每行一个URL,URL最好超过50-100个测试效果比较好.文件格式如下:

http://www.vpser.net/uncategorized/choose-vps.html
http://www.vpser.net/vps-cp/hypervm-tutorial.html
http://www.vpser.net/coupons/diavps-april-coupons.html
http://www.vpser.net/security/vps-backup-web-mysql.html

http_load -p 30 -s 60  urllist.txt
参数了解了,我们来看运行一条命令来看看它的返回结果
命令:% ./http_load -rate 5 -seconds 10 urls说明执行了一个持续时间10秒的测试,每秒的频率为5。
49 fetches, 2 max parallel, 289884 bytes, in 10.0148 seconds5916 mean bytes/connection4.89274
fetches/sec, 28945.5 bytes/secmsecs/connect: 28.8932 mean, 44.243 max, 24.488 minmsecs/first
-response: 63.5362 mean, 81.624 max, 57.803 minHTTP response codes: code 200 — 49

结果分析

1.49 fetches, 2 max parallel, 289884 bytes, in 10.0148 seconds
说明在上面的测试中运行了49个请求,最大的并发进程数是2,总计传输的数据是289884bytes,运行的时间是10.0148秒
2.5916 mean bytes/connection说明每一连接平均传输的数据量289884/49=5916
3.4.89274 fetches/sec, 28945.5 bytes/sec
说明每秒的响应请求为4.89274,每秒传递的数据为28945.5 bytes/sec
4.msecs/connect: 28.8932 mean, 44.243 max, 24.488 min说明每连接的平均响应时间是28.8932 msecs,最大的响应时间44.243 msecs,最小的响应时间24.488 msecs
5.msecs/first-response: 63.5362 mean, 81.624 max, 57.803 min
6、HTTP response codes: code 200 — 49     说明打开响应页面的类型,如果403的类型过多,那可能

备注

要注意是否系统遇到了瓶颈。
特殊说明:
测试结果中主要的指标是 fetches/sec、msecs/connect 这个选项,即服务器每秒能够响应的查询次数,用这个指标来衡量性能。似乎比 apache的ab准确率要高一些,也更有说服力一些。
Qpt-每秒响应用户数和response time,每连接响应用户时间。

测试的结果主要也是看这两个值。当然仅有这两个指标并不能完成对性能的分析,我们还需要对服务器的cpu、men进行分析,才能得出结论

参考

http://www.cnblogs.com/shipengzhi/archive/2012/10/09/2716766.html

前端后端工具汇总

2016年5月23日 评论已被关闭

前端后端工具汇总

http://blog.csdn.net/crazyhacking/article/details/18036723

一、http_load

程序非常小,解压后也不到100K

http_load以并行复用的方式运行,用以测试web服务器的吞吐量与负载。但是它不同于大多数压力测试工

具,它可以以一个单一的进程运行,一般不会把客户机搞死。还可以测试HTTPS类的网站请求。

下载地址:http://soft.vpser.net/test/http_load/http_load-12mar2006.tar.gz
安装很简单
#tar zxvf http_load-12mar2006.tar.gz
#cd http_load-12mar2006
#make && make install

命令格式:http_load  -p 并发访问进程数  -s 访问时间  需要访问的URL文件

参数其实可以自由组合,参数之间的选择并没有什么限制。比如你写成http_load -parallel 5 -seconds

300 urls.txt也是可以的。我们把参数给大家简单说明一下。
-parallel 简写-p :含义是并发的用户进程数。
-fetches 简写-f :含义是总计的访问次数
-rate    简写-p :含义是每秒的访问频率
-seconds简写-s :含义是总计的访问时间

准备URL文件:urllist.txt,文件格式是每行一个URL,URL最好超过50-100个测试效果比较好.文件格式

如下:
http://www.vpser.net/uncategorized/choose-vps.html
http://www.vpser.net/vps-cp/hypervm-tutorial.html
http://www.vpser.net/coupons/diavps-april-coupons.html
http://www.vpser.net/security/vps-backup-web-mysql.html
例如:

http_load -p 30 -s 60  urllist.txt
参数了解了,我们来看运行一条命令来看看它的返回结果
命令:% ./http_load -rate 5 -seconds 10 urls说明执行了一个持续时间10秒的测试,每秒的频率为5。

49 fetches, 2 max parallel, 289884 bytes, in 10.0148 seconds5916 mean bytes/connection4.89274

fetches/sec, 28945.5 bytes/secmsecs/connect: 28.8932 mean, 44.243 max, 24.488 minmsecs/first

-response: 63.5362 mean, 81.624 max, 57.803 minHTTP response codes: code 200 — 49

结果分析:
1.49 fetches, 2 max parallel, 289884 bytes, in 10.0148 seconds
说明在上面的测试中运行了49个请求,最大的并发进程数是2,总计传输的数据是289884bytes,运行的时间是10.0148秒
2.5916 mean bytes/connection说明每一连接平均传输的数据量289884/49=5916
3.4.89274 fetches/sec, 28945.5 bytes/sec
说明每秒的响应请求为4.89274,每秒传递的数据为28945.5 bytes/sec
4.msecs/connect: 28.8932 mean, 44.243 max, 24.488 min说明每连接的平均响应时间是28.8932 msecs

,最大的响应时间44.243 msecs,最小的响应时间24.488 msecs
5.msecs/first-response: 63.5362 mean, 81.624 max, 57.803 min
6、HTTP response codes: code 200 — 49     说明打开响应页面的类型,如果403的类型过多,那可能

要注意是否系统遇到了瓶颈。
特殊说明:
测试结果中主要的指标是 fetches/sec、msecs/connect 这个选项,即服务器每秒能够响应的查询次数,

用这个指标来衡量性能。似乎比 apache的ab准确率要高一些,也更有说服力一些。
Qpt-每秒响应用户数和response time,每连接响应用户时间。
测试的结果主要也是看这两个值。当然仅有这两个指标并不能完成对性能的分析,我们还需要对服务器的

cpu、men进行分析,才能得出结论

二、webbench

webbench是Linux下的一个网站压力测试工具,最多可以模拟3万个并发连接去测试网站的负载能力。下载

地址可以到google搜,我这里给出一个
下载地址:http://soft.vpser.net/test/webbench/webbench-1.5.tar.gz
这个程序更小,解压后不到50K,呵呵
安装非常简单
#tar zxvf webbench-1.5.tar.gz
#cd webbench-1.5
#make && make install
会在当前目录生成webbench可执行文件,直接可以使用了

用法:

webbench -c 并发数 -t 运行测试时间 URL
如:
webbench -c 5000 -t 120 http://www.vpser.net/

三、ab
ab是apache自带的一款功能强大的测试工具
安装了apache一般就自带了,
用法可以查看它的说明

$ ./ab
./ab: wrong number of arguments
Usage: ./ab [options] [http://]hostname[:port]/path
Options are:
-n requests Number of requests to perform
-c concurrency Number of multiple requests to make
-t timelimit Seconds to max. wait for responses
-p postfile File containing data to POST
-T content-type Content-type header for POSTing
-v verbosity How much troubleshooting info to print
-w Print out results in HTML tables
-i Use HEAD instead of GET
-x attributes String to insert as table attributes
-y attributes String to insert as tr attributes
-z attributes String to insert as td or th attributes
-C attribute Add cookie, eg. ‘Apache=1234. (repeatable)
-H attribute Add Arbitrary header line, eg. ‘Accept-Encoding: gzip’
Inserted after all normal header lines. (repeatable)
-A attribute Add Basic WWW Authentication, the attributes
are a colon separated username and password.
-P attribute Add Basic Proxy Authentication, the attributes
are a colon separated username and password.
-X proxy:port Proxyserver and port number to use
-V Print version number and exit
-k Use HTTP KeepAlive feature
-d Do not show percentiles served table.
-S Do not show confidence estimators and warnings.
-g filename Output collected data to gnuplot format file.
-e filename Output CSV file with percentages served
-h Display usage information (this message)
参数众多,一般我们用到的是-n 和-c
例如:
./ab -c 1000 -n 100 http://www.vpser.net/index.php

这个表示同时处理1000个请求并运行100次index.php文件.
四、Siege
一款开源的压力测试工具,可以根据配置对一个WEB站点进行多用户的并发访问,记录每个用户所有请求过程的相应时间,并在一定数量的并发访问下重复进行。
官方:http://www.joedog.org/
Siege下载:http://soft.vpser.net/test/siege/siege-2.67.tar.gz
解压:
# tar -zxf siege-2.67.tar.gz
进入解压目录:
# cd siege-2.67/
安装:
#./configure ; make
#make install

使用
siege -c 200 -r 10 -f example.url
-c是并发量,-r是重复次数。 url文件就是一个文本,每行都是一个url,它会从里面随机访问的。

example.url内容:

http://www.licess.cn
http://www.vpser.net
http://soft.vpser.net

结果说明
Lifting the server siege… done.
Transactions: 3419263 hits //完成419263次处理
Availability: 100.00 % //100.00 % 成功率
Elapsed time: 5999.69 secs //总共用时
Data transferred: 84273.91 MB //共数据传输84273.91 MB
Response time: 0.37 secs //相应用时1.65秒:显示网络连接的速度
Transaction rate: 569.91 trans/sec //均每秒完成 569.91 次处理:表示服务器后
Throughput: 14.05 MB/sec //平均每秒传送数据
Concurrency: 213.42 //实际最高并发数
Successful transactions: 2564081 //成功处理次数
Failed transactions: 11 //失败处理次数
Longest transaction: 29.04 //每次传输所花最长时间
Shortest transaction: 0.00 //每次传输所花最短时间

 

apache  ab工具

ab是Apache超文本传输协议(HTTP)的性能测试工具。 其设计意图是描绘当前所安装的Apache的执行性能, 主要是显示你安装的Apache每秒可以处理多少个请求 ab是Apache超文本传输协议(HTTP)的性能测试工具。 其设计意图是描绘当前所安装的Apache的执行性

ab -n1000 -c10 网址

-c concurrency
一次产生的请求个数。默认是一次一个

-n  总请求次数

参考: http://www.php100.com/html/webkaifa/apache/2010/0315/4133.html

转自:  http://www.vpser.net/opt/webserver-test.html

三种压力测试工具 http_load 和 apache ab 、 siege 压力测试

2016年5月23日 评论已被关闭

三种压力测试工具 http_load 和 apache ab 、 siege 压力测试

http://blog.csdn.net/lyflower/article/details/5873544

到http://www.acme.com/software/http_load/ 下载http_load ,安装也很简单直接make;make instlall 就行。

http_load 的标准的两个例子是:

  1. http_load -parallel 5 -fetches 1000 urls.txt
  2. http_load -rate 2 -seconds 300 urls.txt

 

例子只是个参考,参数其实可以自由组合,参数之间的选择并没有什么限制。比如你写成http_load -parallel 5 -seconds 300 urls.txt 也 是可以的。我们把参数给大家简单说明一下。 -parallel 简写 -p : 含义是并发的用 户进程数。

-fetches 简写 -f : 含义是总计的访 问次数

-rate    简写 -p : 含义是每秒的访 问频率

-seconds 简写 -s : 含义是总计的访问 时间

urls.txt 是一个url 列表,每个url 单独的一行。当然也可以直接跟一个url 而不是url 列表文件。
实例:

  1. http_load -rate 5 -seconds 10 urls
  2. 49 fetches, 2 max parallel, 289884 bytes, in 10.0148 seconds
  3. 5916 mean bytes/connection
  4. 4.89274 fetches/sec, 28945.5 bytes/sec
  5. msecs/connect: 28.8932 mean, 44.243 max, 24.488 min
  6. msecs/first-response: 63.5362 mean, 81.624 max, 57.803 min
  7. HTTP response codes:
  8.   code 200 — 49

分析:
1.49 fetches, 2 max parallel, 289884 bytes, in 10.0148 seconds
说明在上面的测试中运行了49个请求,最大的并发进程数是2,总计传输的数据是289884bytes,运行的时间是10.0148秒

2.5916 mean bytes/connection
说明每一连接平均传输的数据量289884/49=5916

3.4.89274 fetches/sec, 28945.5 bytes/sec
说明每秒的响应请求为4.89274,每秒传递的数据为28945.5 bytes/sec

4.msecs/connect: 28.8932 mean, 44.243 max, 24.488 min
说明每连接的平均响应时间是28.8932 msecs,最大的响应时间44.243 msecs,最小的响应时间24.488 msecs

5.msecs/first-response: 63.5362 mean, 81.624 max, 57.803 min

6、HTTP response codes: code 200 — 49
说明打开响应页面的类型,如果403的类型过多,那可能要注意是否系统遇到了瓶颈。
特殊说明:这里,我们一般会关注到的指标是fetches/sec、msecs/connect
他们分别对应的常用性能指标参数Qpt-每秒响应用户数和response time,每连接响应用户时间。测试的结果主要也是看这两个值。当然仅有这两个指标并不能完成对性能的分析,我们还需要对服务器的cpu、men进行分 析,才能得出结论

 

Sample run:









% ./http_load -rate 5 -seconds 10 urls







49 fetches, 2 max parallel, 289884 bytes, in 10.0148 seconds







5916 mean bytes/connection







4.89274 fetches/sec, 28945.5 bytes/sec







msecs/connect: 28.8932 mean, 44.243 max, 24.488 min







msecs/first-response: 63.5362 mean, 81.624 max, 57.803 min







HTTP response codes:







  code 200 -- 49











4.89274 fetches/sec 这个值得就是说服务器每秒能够响应的查询次数为4.8左右



这个值得是根据 49 fetches / 



10.0148 seconds 秒计算出来的







测试网站每秒所能承受的平均访问量

http_load -parallel 5 -fetches 1000 urls.txt

这段命令行是同时使用5个进程,随机访问urls.txt中的网址列表,总共访问1000次。运行之后的结果:

1000 fetches, 5 max parallel, 6e+06 bytes, in 58.1026 seconds
6000 mean bytes/connection
17.2109 fetches/sec , 103266 bytes/sec
msecs/connect: 0.403263 mean, 68.603 max, 0.194 min
msecs/first-response: 284.133 mean, 5410.13 max, 55.735 min
HTTP response codes:
code 200 — 1000

从上面的运行结果来看,目标网站仅仅能够承受每秒17次访问,不够强壮。

 

测试网站是否能承受住预期的访问压力

http_load -rate 2 -seconds 300 urls.txt

在300秒内保持一定的频率访问目标url。



如 果你需要测试https,你必须将 Makefile中
# CONFIGURE: If you want to compile in support for https, uncomment these
# definitions.  You will need to have already built OpenSSL, available at
# http://www.openssl.org/  Make sure the SSL_TREE definition points to the
# tree with your OpenSSL installation – depending on how you installed it,
# it may be in /usr/local instead of /usr/local/ssl.
SSL_TREE =    /usr
SSL_DEFS =    -DUSE_SSL
SSL_INC =    -I$(SSL_TREE)/include
SSL_LIBS =    -L$(SSL_TREE)/lib -lssl -lcrypto

由于使用到openssl,你必须安装openssl和相应的开发环境

apt-get install openssl
apt-get install libssl-dev

find -name ssl.h
/usr /include/openssl/ssl.h

所 以上面红色字体部分必须修改

http_load常见问题

 

平常使用http_load过程中的一些总结,分享出来,大家可以一起补充;

1.提示:bytes count wrong
如果httpd_load获取到的页面数据和上次不一致则会报错byte count wrong
如果是动态页面,此报错可以忽略;

2.报错:too many open files
系统限制的open files太小,ulimit -n 修改open files值即可;

3.无法发送大请求 (请求长度>600个字符)
默认接受请求的buf大小 http_load.c

912 static void
913 handle_connect( int cnum, struct timeval* nowP, int double_check )
914 {
915 int url_num;
916 char buf[600]; //根据需要修改,如:char buf[4096]
917 int bytes, r;

重新编译即可得到可发送大请求

4.Cannot assign requested address
客户端频繁的连服务器,由于每次连接都在很短的时间内结束,导致很多的TIME_WAIT,以至于用光了可用的端口号,所以新的连接没办法绑定端口,所以 要改客户端机器的配置,
在sysctl.conf里加:

net.ipv4.tcp_tw_reuse = 1 表示开启重用。允许将TIME-WAIT sockets重新用于新的TCP连接,默认为0,表示关闭;
net.ipv4.tcp_timestamps=1 开启对于TCP时间戳的支持,若该项设置为0,则下面一项设置
不起作用
net.ipv4.tcp_tw_recycle=1 表示开启TCP连接中TIME-WAIT sockets的快速回收

 

 

 

apache ab压力测试
以前安装好APACHE总是不知道该如何测试APACHE的性能,现在总算找到一个测试工具了。就是APACHE自带的测试工具AB(apache benchmark).在APACHE的bin目录下。

格式: ./ab [options] [http://]hostname[:port]/path
参数:
-n requests     Number of requests to perform
//在测试会话中所执行的请求个数。默认时,仅执 行一个请求
-c concurrency Number of multiple requests to make
//一次产生的请求个数。默认是一次一个。
-t timelimit    Seconds to max. wait for responses
//测试所进行的最大秒数。其内部隐含值是-n 50000。它可以使对服务器的测试限制在一个固定的总时间以内。默认时,没有时间限制。
-p postfile     File containing data to POST
//包含了需要POST的数 据的文件.
-T content-type Content-type header for POSTing
//POST数据所使用的Content-type头信息。
-v verbosity    How much troubleshooting info to print
//设置显示信息的详细程度 – 4或更大值会显示头信息, 3或更大值可以显示响应代码(404, 200等), 2或更大值可以显示警告和其他信息。 -V 显示版本号并退出。
-w              Print out results in HTML tables
//以HTML表的格式输出结果。默认时,它是白色背景的两列宽度的一张表。
-i              Use HEAD instead of GET
// 执行HEAD请求,而不是GET。
-x attributes   String to insert as table attributes
//
-y attributes   String to insert as tr attributes
//
-z attributes   String to insert as td or th attributes
//
-C attribute    Add cookie, eg. ‘Apache=1234. (repeatable)
//-C cookie-name=value 对请求附加一个Cookie:行。 其典型形式是name=value的一个参数对。此参数可以重复。
-H attribute    Add Arbitrary header line, eg. ‘Accept-Encoding: gzip’
Inserted after all normal header lines. (repeatable)
-A attribute    Add Basic WWW Authentication, the attributes
are a colon separated username and password.
-P attribute    Add Basic Proxy Authentication, the attributes
are a colon separated username and password.
//-P proxy-auth-username:password 对一个中转代理提供BASIC认证信任。用户名和密码由一个:隔开,并以base64编码形式发送。无论服务器是否需要(即, 是否发送了401认证需求代码),此字符串都会被发送。
-X proxy:port   Proxyserver and port number to use
-V              Print version number and exit
-k              Use HTTP KeepAlive feature
-d              Do not show percentiles served table.
-S              Do not show confidence estimators and warnings.
-g filename     Output collected data to gnuplot format file.
-e filename     Output CSV file with percentages served
-h              Display usage information (this message)
//-attributes 设置 属性的字符串. 缺陷程序中有各种静态声明的固定长度的缓冲区。另外,对命令行参数、服务器的响应头和其他外部输入的解析也很简单,这可能会有不良后果。它没有完整地实现 HTTP/1.x; 仅接受某些’预想’的响应格式。 strstr(3)的频繁使用可能会带来性能问题,即, 你可能是在测试ab而不是服务器的性能。

参数很多,一般我们用 -c 和 -n 参数就可以了. 例如:

./ab -c 1000 -n 1000 http://127.0.0.1/index.php

这个表示同时处理1000个请求并运行1000次index.php文件.
#/usr/local/xiaobai/apache2054/bin/ab -c 1000 -n 1000 http://127.0.0.1/index.html.zh-cn.gb2312
This is ApacheBench, Version 2.0.41-dev <$Revision: 1.121.2.12 $> apache-2.0
Copyright (c) 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/
Copyright (c) 1998-2002 The Apache Software Foundation, http://www.apache.org/

Benchmarking 127.0.0.1 (be patient)
Completed 100 requests
Completed 200 requests
Completed 300 requests
Completed 400 requests
Completed 500 requests
Completed 600 requests
Completed 700 requests
Completed 800 requests
Completed 900 requests
Finished 1000 requests
Server Software:        Apache/2.0.54
// 平台apache 版本2.0.54
Server Hostname:        127.0.0.1
//服务器主机名
Server Port:            80
//服务器端口

Document Path:          /index.html.zh-cn.gb2312
//测试的页面文档
Document Length:        1018 bytes
//文档大小

Concurrency Level:      1000
//并发数
Time taken for tests:   8.188731 seconds
//整个测试持续的时 间
Complete requests:      1000
//完成的请 求数量
Failed requests:        0
//失败的请求 数量
Write errors:           0

Total transferred:      1361581 bytes
//整个场景中的网络传输量
HTML transferred:       1055666 bytes
//整个场景中的HTML内容 传输量
Requests per second:    122.12 [#/sec] (mean)
//大家最关心的指标之一,相当于 LR 中的 每秒事务数 ,后面括号中的 mean 表示这是一个平均值
Time per request:       8188.731 [ms] (mean)
//大家最关心的指标之二,相当于 LR 中的 平均事务响应时间 ,后面括号中的 mean 表示这是一个平均值
Time per request:       8.189 [ms] (mean, across all concurrent requests)
//每个请求实际运行时间的平均值
Transfer rate:          162.30 [Kbytes/sec] received
//平均每秒网络上的流量,可以帮助排除是否存在网络流量过大导致响应时间延长的问题

Connection Times (ms)
min mean[+/-sd] median   max
Connect:        4 646 1078.7     89    3291
Processing:   165 992 493.1    938    4712
Waiting:      118 934 480.6    882    4554
Total:        813 1638 1338.9   1093    7785
//网络上消耗的时间的分解,各项数据的具体算法还不是很清楚

Percentage of the requests served within a certain time (ms)
50%   1093
66%   1247
75%   1373
80%   1493
90%   4061
95%   4398
98%   5608
99%   7368
100%   7785 (longest request)
//整个场景中所有请求的响应情况。在场景中每个请求都有一个响应时间,其中50%的用户响应时间小于1093 毫秒,60% 的用户响应时间小于1247 毫秒,最大的响应时间小于7785 毫秒

由于对于并发请求,cpu实际上并不是同时处理的,而是按照每个请求获得的时间片逐个轮转处理的,所以基本上第一个Time per request时间约等于第二个Time per request时间乘以并发请求数

 

 

 

3、siege

1)、简介
一款开源的压力测试工具,可以根据配置对一个WEB站点进行多用户的并发访问,记录每个用户所有请求过
程的相应时间,并在一定数量的并发访问下重复进行。2)、获取
http://www.joedog.org/

3)、安装
[root@localhost software]# tar -zxvf siege-2.69.tar.gz   #解压
[root@localhost software]# cd siege-2.69
[root@localhost siege-2.69]# ./configure –prefix=/usr/local/siege #配置安装目录
[root@localhost siege-2.69]# make && make install    #编译安装

注意:安装是会提示一下错误,
make[3]: Entering directory `/usr/local/software/siege-2.69/doc’
/usr/bin/install: cannot create regular file `/usr/local/siege/etc/siegerc’: No such file or
directory
make[3]: *** [install-exec-hook] Error 1
make[3]: Leaving directory `/usr/local/software/siege-2.69/doc’
make[2]: *** [install-exec-am] Error 2
make[2]: Leaving directory `/usr/local/software/siege-2.69/doc’
make[1]: *** [install-am] Error 2
make[1]: Leaving directory `/usr/local/software/siege-2.69/doc’
make: *** [install-recursive] Error 1
解决办法是:mkdir -p /usr/local/siege/etc/siegerc 建立这样一个目录就可以继续向下安装的。

4)、 使用

     命令格式:siege -c 并发量 -r 重复次数 -f urllist文件
urllist格式:
http://www.taoav.com
http://www.tuhaoduo.com
http://www.tiaonv.com
结果说明:
Lifting the server siege… done.
Transactions: 3419263 hits //完成419263次处理
Availability: 100.00 % //100.00 % 成功率
Elapsed time: 5999.69 secs //总共用时
Data transferred: 84273.91 MB //共数据传输84273.91 MB
Response time: 0.37 secs //相应用时1.65秒:显示网络连接的速度
Transaction rate: 569.91 trans/sec //均每秒完成 569.91 次处理:表示服务器后
Throughput: 14.05 MB/sec //平均每秒传送数据
Concurrency: 213.42 //实际最高并发数
Successful transactions: 2564081 //成功处理次数
Failed transactions: 11 //失败处理次数
Longest transaction: 29.04 //每次传输所花最长时间
Shortest transaction: 0.00 //每次传输所花最短时间

UnixBench:测试Linux VPS性能

2016年5月18日 评论已被关闭

UnixBench:测试Linux VPS性能

http://www.vpser.net/opt/unixbench.html

UnixBench是一款不错的Linux下的VPS性能测试软件,现在说一下具体用法。

UnixBench 4.10 下载地址:http://soft.vpser.net/test/unixbench/unixbench-4.1.0-wht.tar.gz

[root@noc ~]# wget http://soft.vpser.net/test/unixbench/unixbench-4.1.0-wht.tar.gz

[root@noc ~]# tar xzf unixbench-4.1.0-wht.tar.gz
[root@noc ~]# ls
unixbench-4.1.0-wht-2  unixbench-4.1.0-wht.tar.gz

[root@noc ~]# cd unixbench-4.1.0-wht-2/
[root@noc unixbench-4.1.0-wht-2]# make
如果遇到 Error: Please install /usr/bin/time. 错误提示
centos/fedora 下运行 yum install time
ubuntu/debian 下运行 apt-get install time

[root@noc unixbench-4.1.0-wht-2]# ./Run

以下是运行后显示的内容:

==============================================================
BYTE UNIX Benchmarks (Version 4.1-wht.2)
System — Linux noc.lnmp.org 2.6.18-92.1.13.el5.028stab059.6 #1 SMP Fri Nov 14 16:01:01 MSK 2008 i686 i686 i386 GNU/Linux
simfs                  5120000   1581972   3538028  31% /

Start Benchmark Run: Wed Feb  4 05:11:25 PST 2009
05:11:25 up 20 days, 21:26,  1 user,  load average: 0.00, 0.00, 0.00

End Benchmark Run: Wed Feb  4 05:21:40 PST 2009
05:21:40 up 20 days, 21:37,  1 user,  load average: 15.46, 6.32, 2.72
INDEX VALUES
TEST                                        BASELINE     RESULT      INDEX

Dhrystone 2 using register variables        376783.7 23797779.3      631.6
Double-Precision Whetstone                      83.1     1407.7      169.4
Execl Throughput                               188.3    10095.2      536.1
File Copy 1024 bufsize 2000 maxblocks         2672.0   204163.0      764.1
File Copy 256 bufsize 500 maxblocks           1077.0    74664.0      693.3
File Read 4096 bufsize 8000 maxblocks        15382.0  1629641.0     1059.4
Pipe Throughput                             111814.6  3058960.1      273.6
Pipe-based Context Switching                 15448.6   887966.3      574.8
Process Creation                               569.3    26803.0      470.8
Shell Scripts (8 concurrent)                    44.8     2503.6      558.8
System Call Overhead                        114433.5  2409758.4      210.6
=========
FINAL SCORE                                                     475.4
[root@noc unixbench-4.1.0-wht-2]#

Linux性能优化的两个重要参数(参考)

2016年5月18日 评论已被关闭

Linux性能优化的两个重要参数(参考)

http://www.cnblogs.com/dkblog/archive/2013/01/10/2854591.html

vfs_cache_pressure:
该文件表示内核回收用于directory和inode cache内存的倾向;缺省值100表示内核将根据pagecache和swapcache,把directory和inode cache保持在一个合理的百分比;降低该值低于100,将导致内核倾向于保留directory和inode cache;增加该值超过100,将导致内核倾向于回收directory和inode cache。
缺省设置:100

min_free_kbytes:
该文件表示强制Linux VM最低保留多少空闲内存(Kbytes)。
缺省设置:724(512M物理内存)

改变命令:
sysctl -w vm.vfs_cache_pressure=200
sysctl -w vm.min_free_kbytes=1024

参见:
http://bbs.chinaunix.net/viewthread.php?tid=849389
http://blog.sina.com.cn/s/blog_4b4de658010006m7.html

分类: Linux性能优化测试 标签:

性能之巅:Linux网络性能分析工具

2016年5月16日 评论已被关闭

性能之巅:Linux网络性能分析工具

http://www.infoq.com/cn/articles/linux-networking-performance-analytics?utm_source=infoq&utm_medium=related_content_link&utm_campaign=relatedContent_news_clk

编者按:InfoQ开设新栏目“品味书香”,精选技术书籍的精彩章节,以及分享看完书留下的思考和收获,欢迎大家关注。本文节选自格雷格著《性能之巅:洞悉系统、企业与云计算》中第10.6节,介绍了其中Linux部分网络性能分析工具的使用方法。

本文介绍基于Linux操作系统的网络性能分析工具。它们的使用策略参见前面的部分。

本节介绍的工具列于下表中。

Linux Solaris 描述
netstat netstat 多种网络栈和接口统计信息
sar 统计信息历史
ifconfig ifconfig 接口配置
ip dladm 网络接口统计信息
nicstat nicstat 网络接口吞吐量和使用率
ping ping 测试网络连通性
traceroute traceroute 测试网络路由
pathchar pathchar 确定网络路径特征
tcpdump snoop/tcpdump 网络数据包嗅探器
Wireshark Wireshark 图形化网络数据包检查器
DTrace, perf DTrace TCP/IP栈跟踪:连接、数据包、丢包、延时

本文将仅介绍Linux系统中的前7个网络性能分析工具。一开始是系统层面的统计数据,进而向下挖掘到包嗅探和事件跟踪。完整的功能请参考这些工具的文档,包括Man手册。

netstat

基于使用的选项,netstat(8)命令能报告多种类型的网络统计数据,就像具有多种功能的组合工具。选项介绍如下:

  • (默):列出连接的套接字。
  • -a列出所有套接字的信息。
  • -s网络栈统计信息。
  • -i网络接口信息。
  • -r列出路由表。

其他选项能修改输出,例如-n不解析IP地址为主机名,以及-v(可用时)显示冗长的详细信息。

一个netstat(8)接口统计信息的示例如下:

数据列包括网络接口(Iface)、MTU以及一系列接收(RX-)和传输(TX-)的指标。

  • OK成功传输的数据包。
  • ERR错误数据包。
  • DRP丢包。
  • OVR超限。

丢包和超限是网络接口的指针,并且能和错误一起用USE方法检查。

-c连续模式能与-i一并使用,每秒输出这些累积的计数器。它提供计算数据包速率的数据。

下面是一个netstat(8)网络栈统计数据(片段)的示例:

输出列出了多项按协议分组的网络数据,主要是来自TCP的。所幸的是,其中多数有较长的描述性名称,因此它们的意思显而易见。不幸的是这些输出缺乏一致性而且有拼写错误,用程序处理这段文字比较麻烦。

许多与性能相关的指标以加粗强调,用以指出可用的信息。其中许多指标要求对TCP行为的深刻理解,包括近些年引入的的最新功能和算法。下面是一些值得查找的示例指标。

  • 相比接收的总数据包更高速的包转发率:检查服务器是否应该转发(路由)数据包。
  • 开放的被动连接:监视它们能显示客户机连接负载。
  • 相比发送的数据段更高的数据段重传输率:能支持网络的不稳定。这可能是意料之中的(互联网客户)。
  • 套接字缓冲超限导致的数据包从接收队列中删除:这是网络饱和的标志,能够通过增加套接字缓冲来修复——前提是有足够的系统资源支持应用程序。

一些统计信息名称包括拼写错误。如果其他的监视工具建立在同样的输出上,简单地修复它们可能有问题。这类工具最好能从/proc资源读取这些统计信息,它们是/proc/net/snmp和/proc/net/netstat。例如:

/proc/net/snmp统计信息也用于SNMP管理信息库(MIB),它提供关于每个统计信息的用途的更进一步的文档。扩展的统计信息在/proc/net/netstat中。

netstat(8)可以接受以秒为单位的时间间隔,它按每个时间间隔连续地输出累加的计数器。后期处理这些输出可以计算每个计数器的速率。

sar

系统活动报告工具sar(1)可以观测当前活动并且能配置为保存和报告历史统计数据。第4章中介绍过它,并且本书的多个章节在需要时也会提及它。

Linux版本用以下选项提供网络统计信息。

  • -n DEV网络接口统计信息。
  • -n EDEV网络接口错误。
  • -n IPIP数据报统计信息。
  • -n EIPIP错误统计信息。
  • -n TCPTCP统计信息。
  • -n ETCPTCP错误统计信息。
  • -n SOCK套接字使用。

提供的统计信息见下表。

选项 统计信息 描述 单位
-n DEV rxpkg/s 接收的数据包 数据包/s
-n DEV txpkt/s 传输的数据包 数据包/s
-n DEV rxkB/s 接收的千字节 千字节/s
-n DEV txkB/s 传输的千字节 千字节/s
-n EDEV rxerr/s 接收数据包错误 数据包/s
-n EDEV txerr/s 传输数据包错误 数据包/s
-n EDEV coll/s 碰撞 数据包/s
-n EDEV rxdrop/s 接收数据包丢包(缓冲满) 数据包/s
-n EDEV txdrop/s 传输数据包丢包(缓冲满) 数据包/s
-n EDEV rxfifo/s 接收的数据包FIFO超限错误 数据包/s
-n EDEV txfifo/s 传输的数据包FIFO超限错误 数据包/s
-n IP irec/s 输入的数据报文(接收) 数据报文/s
-n IP fwddgm/s 转发的数据报文 数据报文/s
-n IP orq/s 输出的数据报文请求(传输) 数据报文/s
-n EIP idisc/s 输入的丢弃(例如,缓冲满) 数据报文/s
-n EIP odisc/s 输出的丢弃(例如,缓冲满) 数据报文/s
-n TCP active/s 新的主动TCP连接(connect()) 连接数/s
-n TCP active/s 新的被动TCP连接(listen()) 连接数/s
-n TCP active/s 输入的段(接收) 段/s
-n TCP active/s 输出的段(接收) 段/s
-n ETCP active/s 主动TCP失败连接 连接数/s
-n ETCP active/s TCP段重传 段/s
-n SOCK totsck 使用中的总数据包 sockets
-n SOCK ip-frag 当前队列中的IP数据片 fragments
-n SOCK tcp-tw TIME-WAIT中的TCP套接字 sockets

这里,许多统计信息名称包括方向和计量单位:rx是“接收”,i是“输入”,seg是“段”,依此类推。完整的列表参考Man手册,它包括ICMP、UDP、NFS和IPv6在内的统计信息以及对应的SNMP名称的说明(例如,ipInReceives对应irec/s)。

以下示例是每秒打印的TCP统计信息:

输出显示被动连接率(入站)接近30/s。

网络接口统计信息列(NET)列出所有接口,然而通常只对一个接口感兴趣。以下示例利用awk(1)过滤输出:

这显示出传输和发送的网络吞吐量。这里双向的速率都超过了2MB/s。

ifconfig

ifconfig(8)命令能手动设置网络接口。它也可以列出所有接口的当前配置。用它来检查系统、网络以及路由设置有助于静态性能调优。

Linux版本的输出包括以下这些统计信息:

这些计数器与之前介绍的netstat -i命令一致。txqueuelen是这个接口发送队列的长度。Man手册介绍了这个数值的调优:

对于速度较低的高延时设备(调制解调器连接,ISDN),设置较小的值有助于预防高速的大量传输影响如telnet在内的交互通信。

Linux中,ifconfig(8)已经被ip(8)命令淘汰。

ip

Linux的ip(8)命令能配置网络接口和路由,并且观测它们的状态和统计信息。例如,显示连接统计信息:

除了添加了接收(RX)和传输(TX)字节,这些计数器与之前介绍的netstat -i命令一致。这利于方便地观测吞吐量,不过ip(8)不提供按时间间隔输出报告的方式(利用sar(1))。

nicstat

最初为基于Solaris的系统编写,nicstat(1)这个开源工具输出包括吞吐量和使用率在内的网络接口统计信息。nicstat(1)延续传统的资源统计工具iostat(1M)mpstat(1M)的风格。用C和Perl编写的版本可用于基于Solaris和Linux的系统[3]。

例如以下的1.92 Linux版本的输出:

最前面的输出是自系统启动以来的总结,紧接着是按时间间隔的总结。这里的时间间隔总结显示了eth4接口的使用率为35%(这里报告的是当前RX或者TX方向的最大值),并且读速度为42MB/s。

字段包括接口名称(Int)、最大使用率(%Util)、反映接口饱和度的统计信息(Sat),以及一系列带前缀的统计信息:r是“读”(接收)而w是“写”(传输)。

  • KB/s千字节每秒。
  • Pk/s数据包每秒。
  • Avs/s平均数据包大小,以字节为单位。

该版本支持多种选项,包括-z用来忽略数值为0的行(闲置的接口)以及-t显示TCP统计信息。

由于能提供使用率和饱和度数值,nicstat(1)特别适用于USE方法。

ping

ping(8)命令发送ICMP echo请求数据包测试网络连通性。例如:

输出显示每个包的往返时间(rtt)并总结各种统计信息。由于时间戳是由ping(8)命令自己计量的,其中包括获取时间戳到处理网络I/O的整个CPU代码路径执行时间。

与应用程序协议相比,路由器可能以较低的优先级处理ICMP数据包,因而延时可能比通常情况下有更高的波动。

traceroute

traceroute(8)命令发出一系列数据包实验性地探测到一个主机当前的路由。它的实现利用了递增每个数据包IP协议的生存时间(TTL),从而导致网关顺序地发送ICMP超时响应报文,向主机揭示自己的存在(如果防火墙没有拦截它们)。

例如测试一个加利福尼亚的主机与一个弗吉尼亚的目标间当前的路由:

每一跳显示连续的三个RTT,它们可用作网络延时统计信息的粗略数据源。类似ping(8),由于发送低优先级的数据包,它可能会显示出比其他应用程序协议更高的延时。

也可以把显示的路径作为静态性能调优的研究对象。网络被设计为动态的并且能响应故障。路径的变化可能会降低性能。

书籍介绍

《性能之巅:洞悉系统、企业与云计算》基于Linux 和Solaris系统阐述了适用于所有系统的性能理论和方法,Brendan Gregg 将业界普遍承认的性能方法、工具和指标收集于本书之中。阅读本书,你能洞悉系统运作的方式,学习到分析和提高系统与应用程序性能的方法,这些性能方法同样适用于大型企业与云计算这类最为复杂的环境的性能分析与调优。

分类: Linux性能优化测试 标签: