??xml version="1.0" encoding="utf-8" standalone="yes"?>
问题描述:crontab中启动的shell脚本不能正常q行Q但是用手动执行没有问题,?home/.profile中设定了脚本所需要的环境变量?/p>
解答:cron命o的默认shell?usr/bin/bshQ如果要在cron启动的脚本中使用kshQ就必须在脚本中的第一行添?#8220;#!/usr/bin/ksh”的声明?/p>
如果cronq程启动的shell脚本要用d时的环境变量Q就必须在cron启动的shell脚本中添加下面的内容Q才能够在启动的脚本中?br /> $home/.profile文g中的环境变量?/p>
. $home/.profile
q是因ؓcronq程执行的shell脚本是不会自动加载用L录下?profile文gQ所以需要脚本自己加载所需要的环境变量?br />
================
环境变量文g加蝲序
/etc/profile: 此文件ؓpȝ的每个用戯|环境信?当用L一ơ登录时,该文件被执行.
q从/etc/profile.d目录的配|文件中搜集shell的设|?
/etc/bashrc: 为每一个运行bash shell的用h行此文g.当bash shell被打开?该文件被d.
~/.bash_profile: 每个用户都可使用该文件输入专用于自己使用的shell信息,当用L录时,?/span>
文g仅仅执行一?默认情况?他设|一些环境变?执行用户?bashrc文g.
~/.bashrc: 该文件包含专用于你的bash shell的bash信息,当登录时以及每次打开新的shell??/span>
该文件被d.
~/.bash_logout: 当每ơ退出系l?退出bash shell)?执行该文?
另外,/etc/profile中设定的变量(全局)的可以作用于M用户,而~/.bashrc{中讑֮的变?局?只能l承/etc/profile中的变量,他们?父子"关系.
~/.bash_profile 是交互式、login 方式q入 bash q行?/span>
~/.bashrc 是交互式 non-login 方式q入 bash q行?/span>
通常二者设|大致相同,所以通常前者会调用后者?/span>
׃TCP协议能够提供端到端的可靠传输Q因此被大量的网l应用程序用。但是,可靠性的建立是要付出代h的。TCP协议保证可靠性的措施Q如建立q维护连接、控制数据有序的传递等都会消耗一定的|络带宽?/p>
Netperf可以模拟三种不同的TCP量模式Q?/p>
1Q?单个TCPq接Q批量(bulkQ传输大量数?/p>
2Q?单个TCPq接Qclienth/server应答的交易(transactionQ方?/p>
3Q?多个TCPq接Q每个连接中一对请?应答的交易方?/p>
UDP没有建立q接的负担,但是UDP不能保证传输的可靠性,所以用UDP的应用程序需要自行跟t每个发出的分组Qƈ重发丢失的分l?/p>
Netperf可以模拟两种UDP的流量模式:
1Q?从client到server的单向批量传?/p>
2Q?h/应答的交易方?/p>
׃UDP传输的不可靠性,在用netperf时要保发送的~冲区大不大于接收~冲区大,否则数据会丢失,netperf给出错误的l果。因此,对于接收到分l的l计不一定准,需要结合发送分l的l计l合得出l论?/p>
在unixpȝ中,可以直接q行可执行程序来启动netserverQ也可以让inetd或xinetd来自动启动netserver?/p>
当netserver在server端启动以后,可以在client端运行netperf来测试网l的性能。netperf通过命o行参数来控制试的类型和具体的测试选项。根据作用范围的不同Qnetperf的命令行参数可以分ؓ两大c:全局命o行参数、测试相关的局部参敎ͼ两者之间?-分隔Q?/p>
netperf [global options]-- [test-specific options] |
q里我们只解释那些常用的命o行参敎ͼ其它的参数读者可以查询netperf的man手册?/p>
-H host Q指定远端运行netserver的server IP地址?/p>
-l testlenQ指定测试的旉长度Q秒Q?/p>
-t testnameQ指定进行的试cdQ包括TCP_STREAMQUDP_STREAMQTCP_RRQTCP_CRRQUDP_RRQ在下文中分别对它们说明?/p>
在后面的试中,netserverq行?92.168.0.28Qserver与client通过局域网q接Q?00M HubQ?/p>
试扚wQbulkQ网l流量的性能
扚w数据传输典型的例子有ftp和其它类似的|络应用Q即一ơ传输整个文Ӟ。根据用传输协议的不同Q批量数据传输又分ؓTCP扚w传输和UDP扚w传输?/p>
1Q?TCP_STREAM
Netperf~省情况下进行TCP扚w传输Q即-t TCP_STREAM。测试过E中Qnetperf向netserver发送批量的TCP数据分组Q以定数据传输q程中的吞吐量:
./netperf -H 192.168.0.28 -l 60 TCP STREAM TEST to 192.168.0.28 Recv Send Send Socket Socket Message Elapsed Size Size Size Time Throughput bytes bytes bytes secs. 10^6bits/sec 87380 16384 16384 60.00 88.00 |
从netperf的结果输ZQ我们可以知道以下的一些信息:
1Q?q端pȝQ即serverQ用大ؓ87380字节的socket接收~冲
2Q?本地pȝQ即clientQ用大ؓ16384字节的socket发送缓?/p>
3Q?向远端系l发送的试分组大小?6384字节
4Q?试l历的时间ؓ60U?/p>
5Q?吞吐量的试l果?8Mbits/U?/p>
在缺省情况下Qnetperf向发送的试分组大小讄为本地系l所使用的socket发送缓冲大?/p>
TCP_STREAM方式下与试相关的局部参数如下表所C:
参数 | 说明 |
-s size | 讄本地pȝ的socket发送与接收~冲大小 |
-S size | 讄q端pȝ的socket发送与接收~冲大小 |
-m size | 讄本地pȝ发送测试分l的大小 |
-M size | 讄q端pȝ接收试分组的大?/td> |
-D | ҎCq端pȝ的socket讄TCP_NODELAY选项 |
通过修改以上的参敎ͼq观察结果的变化Q我们可以确定是什么因素媄响了q接的吞吐量。例如,如果怀疑\由器׃~Z_的缓冲区I间Q得{发大的分l时存在问题Q就可以增加试分组Q?mQ的大小Q以观察吞吐量的变化Q?/p>
./netperf -H 192.168.0.28 -l 60 -- -m 2048 TCP STREAM TEST to 192.168.0.28 Recv Send Send Socket Socket Message Elapsed Size Size Size Time Throughput bytes bytes bytes secs. 10^6bits/sec 87380 16384 2048 60.00 87.62 |
在这里,试分组的大减到2048字节Q而吞吐量却没有很大的变化Q与前面例子中测试分l大ؓ16K字节相比Q。相反,如果吞吐量有了较大的提升Q则说明在网l中间的路由器确实存在缓冲区的问题?/p>
2Q?UDP_STREAM
UDP_STREAM用来试q行UDP扚w传输时的|络性能。需要特别注意的是,此时试分组的大不得大于socket的发送与接收~冲大小Q否则netperf会报出错提示Q?/p>
./netperf -t UDP_STREAM -H 192.168.0.28 -l 60 UDP UNIDIRECTIONAL SEND TEST to 192.168.0.28 udp_send: data send error: Message too long |
Z避免q样的情况,可以通过命o行参数限定测试分l的大小Q或者增加socket的发?接收~冲大小。UDP_STREAM方式使用与TCP_STREAM方式相同的局部命令行参数Q因此,q里可以使用-m来修Ҏ试中使用分组的大:
./netperf -t UDP_STREAM -H 192.168.0.28 -- -m 1024 UDP UNIDIRECTIONAL SEND TEST to 192.168.0.28 Socket Message Elapsed Messages Size Size Time Okay Errors Throughput bytes bytes secs # # 10^6bits/sec 65535 1024 9.99 114127 0 93.55 65535 9.99 114122 93.54 |
UDP_STREAM方式的结果中有两行测试数据,W一行显C的是本地系l的发送统计,q里的吞吐量表示netperf向本地socket发送分l的能力。但是,我们知道QUDP是不可靠的传输协议,发送出ȝ分组数量不一定等于接收到的分l数量?/p>
W二行显C的是q端pȝ接收的情况,׃client与server直接q接在一P而且|络中没有其它的量Q所以本地系l发送过ȝ分组几乎都被q端pȝ正确的接收了Q远端系l的吞吐量也几乎{于本地pȝ的发送吞吐量。但是,在实际环境中Q一般远端系l的socket~冲大小不同于本地系l的socket~冲区大,而且׃UDP协议的不可靠性,q端pȝ的接收吞吐量要远q小于发送出ȝ吞吐量?/p>
试h/应答Qrequest/responseQ网l流量的性能
另一cd见的|络量cd是应用在client/serverl构中的request/response模式。在每次交易QtransactionQ中Qclient向server发出的查询分组Qserver接收到请求,l处理后q回大的l果数据。如下图所C:
1Q?TCP_RR
TCP_RR方式的测试对象是多次TCP request和response的交易过E,但是它们发生在同一个TCPq接中,q种模式常常出现在数据库应用中。数据库的clientE序与serverE序建立一个TCPq接以后Q就在这个连接中传送数据库的多ơ交易过E?/p>
./netperf -t TCP_RR -H 192.168.0.28 TCP REQUEST/RESPONSE TEST to 192.168.0.28 Local /Remote Socket Size Request Resp. Elapsed Trans. Send Recv Size Size Time Rate bytes Bytes bytes bytes secs. per sec 16384 87380 1 1 10.00 9502.73 16384 87380 |
Netperf输出的结果也是由两行l成。第一行显C本地系l的情况Q第二行昄的是q端pȝ的信息。^均的交易率(transaction rateQؓ9502.73?U。注意到q里每次交易中的request和response分组的大都?个字节,不具有很大的实际意义。用户可以通过试相关的参数来改变request和response分组的大,TCP_RR方式下的参数如下表所C:
参数 | 说明 |
-r req,resp | 讄request和reponse分组的大?/td> |
-s size | 讄本地pȝ的socket发送与接收~冲大小 |
-S size | 讄q端pȝ的socket发送与接收~冲大小 |
-D | ҎCq端pȝ的socket讄TCP_NODELAY选项 |
通过使用-r参数Q我们可以进行更有实际意义的试Q?/p>
./netperf -t TCP_RR -H 192.168.0.28 -- -r 32,1024 TCP REQUEST/RESPONSE TEST to 192.168.0.28 Local /Remote Socket Size Request Resp. Elapsed Trans. Send Recv Size Size Time Rate bytes Bytes bytes bytes secs. per sec 16384 87380 32 1024 10.00 4945.97 16384 87380 |
从结果中可以看出Q由于request/reponse分组的大增加了Q导致了交易率明昄下降?注:相对于实际的pȝQ这里交易率的计没有充分考虑C易过E中的应用程序处理时Ӟ因此l果往往会高于实际情c?/p>
2Q?TCP_CRR
与TCP_RR不同QTCP_CRR为每ơ交易徏立一个新的TCPq接。最典型的应用就是HTTPQ每ơHTTP交易是在一条单独的TCPq接中进行的。因此,׃需要不停地建立新的TCPq接Qƈ且在交易l束后拆除TCPq接Q交易率一定会受到很大的媄响?/p>
./netperf -t TCP_CRR -H 192.168.0.28 TCP Connect/Request/Response TEST to 192.168.0.28 Local /Remote Socket Size Request Resp. Elapsed Trans. Send Recv Size Size Time Rate bytes Bytes bytes bytes secs. per sec 131070 131070 1 1 9.99 2662.20 16384 87380 |
即是用一个字节的request/response分组Q交易率也明昄降低了,只有2662.20?U。TCP_CRR使用与TCP_RR相同的局部参数?/p>
3Q?UDP_RR
UDP_RR方式使用UDP分组q行request/response的交易过E。由于没有TCPq接所带来的负担,所以我们推交易率一定会有相应的提升?/p>
./netperf -t UDP_RR -H 192.168.0.28 UDP REQUEST/RESPONSE TEST to 192.168.0.28 Local /Remote Socket Size Request Resp. Elapsed Trans. Send Recv Size Size Time Rate bytes Bytes bytes bytes secs. per sec 65535 65535 1 1 9.99 10141.16 65535 65535 |
l果证实了我们的推测Q交易率?0141.16?U,高过TCP_RR的数倹{不q,如果出现了相反的l果Q即交易率反而降低了Q也不需要担心,因ؓq说明了在网l中Q\由器或其它的|络讑֤对UDP采用了与TCP不同的缓冲区I间和处理技术?/p>
http://www.ibm.com/developerworks/cn/linux/l-netperf/Java version 1.6.0_13
Java HotSpot(TM) Client VM
11.3-b02
Sun Microsystems Inc.
Direct access using member field:
47 125 47 46 46
average time = 66 ms.
Reference access to member field:
109 109 110 94 109
average time = 106 ms.
Reflection access to member field:
13094 12984 13063 13062 13094
average time = 13051 ms.
Java version 1.6.0_13
Java HotSpot(TM) Client VM
11.3-b02
Sun Microsystems Inc.
Direct call using member field:
47 31 109 109 31
average time = 70 ms.
Direct call using passed value:
16 16 16 31 15
average time = 20 ms.
Call to object using member field:
46 47 47 47 32
average time = 43 ms.
Call to object using passed value:
15 16 31 16 16
average time = 20 ms.
Reflection call using member field:
812 782 844 844 844
average time = 829 ms.
Reflection call using passed value:
938 953 954 1031 953
average time = 973 ms.
Java version 1.6.0_13
Java HotSpot(TM) Client VM
11.3-b02
Sun Microsystems Inc.
Direct Object creation:
62 47 78 32 93
average time = 63 ms.
Reflection Object creation:
125 94 94 109 187
average time = 121 ms.
Direct byte[8] creation:
125 187 94 172 94
average time = 137 ms.
Reflection byte[8] creation:
266 171 187 188 219
average time = 191 ms.
Direct byte[64] creation:
250 172 156 125 203
average time = 164 ms.
Reflection byte[64] creation:
281 219 203 203 219
average time = 211 ms.
Java version 1.6.0_13
Java HotSpot(TM) Client VM
11.3-b02
Sun Microsystems Inc.
Direct access using member field:
47 125 47 46 46
average time = 66 ms.
Reference access to member field:
109 109 110 94 109
average time = 106 ms.
Reflection access to member field:
13094 12984 13063 13062 13094
average time = 13051 ms.
Java version 1.6.0_13
Java HotSpot(TM) Client VM
11.3-b02
Sun Microsystems Inc.
Direct call using member field:
47 31 109 109 31
average time = 70 ms.
Direct call using passed value:
16 16 16 31 15
average time = 20 ms.
Call to object using member field:
46 47 47 47 32
average time = 43 ms.
Call to object using passed value:
15 16 31 16 16
average time = 20 ms.
Reflection call using member field:
812 782 844 844 844
average time = 829 ms.
Reflection call using passed value:
938 953 954 1031 953
average time = 973 ms.
Java version 1.6.0_13
Java HotSpot(TM) Client VM
11.3-b02
Sun Microsystems Inc.
Direct Object creation:
62 47 78 32 93
average time = 63 ms.
Reflection Object creation:
125 94 94 109 187
average time = 121 ms.
Direct byte[8] creation:
125 187 94 172 94
average time = 137 ms.
Reflection byte[8] creation:
266 171 187 188 219
average time = 191 ms.
Direct byte[64] creation:
250 172 156 125 203
average time = 164 ms.
Reflection byte[64] creation:
281 219 203 203 219
average time = 211 ms.