The NoteBook of EricKong

1、首先，bash中0，1，2三个数字分别代表STDIN_FILENO、STDOUT_FILENO、STDERR_FILENO，即标准输入（一般是键盘），标准输出（一般是显示屏，准确的说是用户终端控制台），标准错误（出错信息输出）。

2、输入输出可以重定向，所谓重定向输入就是在命令中指定具体的输入来源，譬如 cat < test.c 将test.c重定向为cat命令的输入源。输出重定向是指定具体的输出目标以替换默认的标准输出，譬如ls > 1.txt将ls的结果从标准输出重定向为1.txt文本。有时候会看到如 ls >> 1.txt这类的写法，> 和 >> 的区别在于：> 用于新建而>>用于追加。即ls > 1.txt会新建一个1.txt文件并且将ls的内容输出到新建的1.txt中，而ls >> 1.txt则用在1.txt已经存在，而我们只是想将ls的内容追加到1.txt文本中的时候。

3、默认输入只有一个（0，STDIN_FILENO），而默认输出有两个（标准输出1 STDOUT_FILENO，标准错误2 STDERR_FILENO）。因此默认情况下，shell输出的错误信息会被输出到2，而普通输出信息会输出到1。但是某些情况下，我们希望在一个终端下看到所有的信息（包括标准输出信息和错误信息），要怎么办呢？

       对了，你可以使用我们上面讲到的输出重定向。思路有了，怎么写呢？ 非常直观的想法就是2>1（将2重定向到1嘛），行不行呢？试一试就知道了。我们进行以下测试步骤：

1）mkdir test && cd test                ; 创建test文件夹并进入test目录

2）touch a.txt b.c c                          ; 创建a.txt b.c c 三个文件

3）ls > 1                                           ; 按我们的猜测，这句应该是将ls的结果重定向到标准输出，因此效果和直接ls应该一样。但是实际这句执行后，标准输出中并没有任何信息。

4）ls                                                  ; 执行3之后再次ls，则会看到test文件夹中多了一个文件1

5）cat 1                                            ; 查看文件1的内容，实际结果为：1 a.txt b.c c     可见步骤3中 ls > 1并不是将ls的结果重定向为标准输出，而是将结果重定向到了一个文件1中。即1在此处不被解释为STDOUT_FILENO，而是文件1。

4、到了此时，你应该也能猜到2>&1的用意了。不错，2>&1就是用来将标准错误2重定向到标准输出1中的。此处1前面的&就是为了让bash将1解释成标准输出而不是文件1。至于最后一个&，则是让bash在后台执行。

1．什么是会话保持？
在大多数电子商务的应用系统或者需要进行用户身份认证的在线系统中，一个客户与服务器经常经过好几次的交互过程才能完成一笔交易或者是一个请求的完成。由于这几次交互过程是密切相关的，服务器在进行这些交互过程的某一个交互步骤时，往往需要了解上一次交互过程的处理结果，或者上几步的交互过程结果，服务器进行下一步操作时就要求所有这些相关的交互过程都由一台服务器完成，而不能被负载均衡器分散到不同的服务器上。

    而这一系列的相关的交互过程可能是由客户到服务器的一个连接的多次会话完成，也可能是在客户与服务器之间的多个不同连接里的多次会话完成。不同连接的多次会话，最典型的例子就是基于http的访问，一个客户完成一笔交易可能需多次点击，而一个新的点击产生的请求，可能会重用上一次点击建立起来的连接，也可能是一个新建的连接。

    会话保持就是指在负载均衡器上有这么一种机制，可以识别做客户与服务器之间交互过程的关连性，在作负载均衡的同时，还保证一系列相关连的访问请求会保持分配到一台服务器上。

2．F5支持什么样的会话保持方法？
    F5 Big-IP支持多种的会话保持方法，其中包括：简单会话保持（源地址会话保持）、HTTP Header的会话保持，基于SSL Session ID的会话保持，i-Rules会话保持以及基于HTTP Cookie的会话保持，此外还有基于SIP ID以及Cache设备的会话保持等，但常用的是简单会话保持，HTTP Header的会话保持以及 HTTP Cookie会话保持以及基于i-Rules的会话保持。

2.1 简单会话保持
    简单会话保持也被称为基于源地址的会话保持，是指负载均衡器在作负载均衡时是根据访问请求的源地址作为判断关连会话的依据。对来自同一IP地址的所有访问 请求在作负载均时都会被保持到一台服务器上去。在BIG-IP设备上可以为“同一IP地址”通过网络掩码进行区分，比如可以通过对IP地址 192.168.1.1进行255.255.255.0的网络掩码，这样只要是来自于192.168.1.0/24这个网段的流量BIGIP都可以认为他们是来自于同一个用户，这样就将把来自于192.168.1.0/24网段的流量会话保持到特定的一台服务器上。

    简单会话保持里另外一个很重要的参数就是连接超时值，BIGIP会为每一个进行会话保持的会话设定一个时间值，当一个会话上一次完成到这个会话下次再来之前的间隔如果小于这个超时值，BIGIP将会将新的连接进行会话保持，但如果这个间隔大于该超时值，BIGIP将会将新来的连接认为是新的会话然后进行负载平衡。

    基于原地址的会话保持实现起来简单，只需要根据数据包三、四层的信息就可以实现，效率也比较高。存在的问题就在于当多个客户是通过代理或地址转换的方式来访问服务器时，由于都分配到同一台服务器上，会导致服务器之间的负载严重失衡。另外一种情况上客户机数量很少，但每个客户机都会产生多个并发访问，对这些并发访问也要求通过负载均衡器分配到多个服器上，这时基于客户端源地址的会话保持方法也会导致负载均衡失效。

2.2 基于Cookie的会话保持
2.2.1 Cookie插入模式：
    在Cookie插入模式下，Big-IP将负责插入cookie，后端服务器无需作出任何修改

    当客户进行第一次请求时，客户HTTP请求（不带cookie）进入BIG-IP， BIG-IP根据负载平衡算法策略选择后端一台服务器，并将请求发送至该服务器，后端服务器进行HTTP回复（不带cookie）被发回BIGIP，然后 BIG-IP插入cookie，将HTTP回复返回到客户端。当客户请求再次发生时，客户HTTP请求（带有上次BIGIP插入的cookie）进入 BIGIP，然后BIGIP读出cookie里的会话保持数值，将HTTP请求（带有与上面同样的cookie）发到指定的服务器，然后后端服务器进行请求回复，由于服务器并不写入cookie，HTTP回复将不带有cookie，恢复流量再次经过进入BIG-IP时，BIG-IP再次写入更新后的会话保持 cookie。

2.2.2 Cookie 重写模式
    当客户进行第一次请求时，客户HTTP请求（不带cookie）进入BIGIP， BIGIP根据负载均衡算法策略选择后端一台服务器，并将请求发送至该服务器，后端服务器进行HTTP回复一个空白的cookie并发回BIGIP，然后BIGIP重新在cookie里写入会话保持数值，将HTTP回复返回到客户端。当客户请求再次发生时，客户HTTP请求（带有上次BIGIP重写的 cookie）进入BIGIP，然后BIGIP读出cookie里的会话保持数值，将HTTP请求（带有与上面同样的cookie）发到指定的服务器，然后后端服务器进行请求回复，HTTP回复里又将带有空的cookie，恢复流量再次经过进入BIGIP时，BIGIP再次写入更新后会话保持数值到该 cookie。

2.2.3 Passive Cookie 模式，服务器使用特定信息来设置cookie。
    当客户进行第一次请求时，客户HTTP请求（不带cookie）进入BIGIP， BIGIP根据负载平衡算法策略选择后端一台服务器，并将请求发送至该服务器，后端服务器进行HTTP回复一个cookie并发回BIGIP，然后 BIGIP将带有服务器写的cookie值的HTTP回复返回到客户端。当客户请求再次发生时，客户HTTP请求（带有上次服务器写的cookie）进入 BIGIP，然后BIGIP根据cookie里的会话保持数值，将HTTP请求（带有与上面同样的cookie）发到指定的服务器，然后后端服务器进行请 求回复，HTTP回复里又将带有更新的会话保持cookie，恢复流量再次经过进入BIGIP时，BIGIP将带有该cookie的请求回复给客户端。

2.2.4 Cookie Hash模式：
    当客户进行第一次请求时，客户HTTP请求（不带cookie）进入BIGIP， BIGIP根据负载均衡算法策略选择后端一台服务器，并将请求发送至该服务器，后端服务器进行HTTP回复一个cookie并发回BIGIP，然后 BIGIP将带有服务器写的cookie值的HTTP回复返回到客户端。当客户请求再次发生时，客户HTTP请求（带有上次服务器写的cookie）进入 BIGIP，然后BIGIP根据cookie里的一定的某个字节的字节数来决定后台服务器接受请求，将HTTP请求（带有与上面同样的cookie）发到指定的服务器，然后后端服务器进行请求回复，HTTP回复里又将带有更新后的cookie，恢复流量再次经过进入BIGIP时，BIGIP将带有该 cookie的请求回复给客户端。

2.3 SSL Session ID会话保持
    在用户的SSL访问系统的环境里，当SSL对话首次建立时，用户与服务器进行首次信息交换以：1}交换安全证书，2）商议加密和压缩方法，3）为每条对话 建立Session ID。由于该Session ID在系统中是一个唯一数值，由此，BIGIP可以应用该数值来进行会话保持。当用户想与该服务器再次建立连接时，BIGIP可以通过会话中的 SSL Session ID识别该用户并进行会话保持。

    基于SSL Session ID的会话保持就需要客户浏览器在进行会话的过程中始终保持其SSL Session ID不变，但实际上，微软Internet Explorer被发现在经过特定一段时间后将主动改变SSL Session ID，这就使基于SSL Session ID的会话保持实际应用范围大大缩小。

Linux系统中，有时候普通用户有些事情是不能做的，除非是root用户才能做到。这时就需要用su命令临时切换到root身份来做事了。

su：substitute['sʌbstɪtjuːt]代替 user
su 的语法为：
su [OPTION选项参数] [用户]
-, -l, --login 登录并改变到所切换的用户环境；
-c, --commmand=COMMAND 执行一个命令，然后退出所切换到的用户环境；

用su命令切换用户后，可以用 exit 命令或快捷键[Ctrl+D]可返回原登录用户。

例子：
su 在不加任何参数，默认为切换到root用户，但没有转到root用户家目录下，也就是说这时虽然是切换为root用户了，但并没有改变root登录环境；用户默认的登录环境，可以在/etc/passwd 中查得到，包括家目录，SHELL定义等；
su 加参数 - ，表示默认切换到root用户，并且改变到root用户的环境；

用su是可以切换用户身份，如果每个普通用户都能切换到root身份，如果某个用户不小心泄漏了root的密码，那岂不是系统非常的不安全？没有错，为了改进这个问题，产生了sudo这个命令。使用sudo执行一个root才能执行的命令是可以办到的，但是需要输入密码，这个密码并不是root的密码而是用户自己的密码。默认只有root用户能使用sudo命令，普通用户想要使用sudo，是需要root预先设定的，即，使用visudo命令去编辑相关的配置文件/etc/sudoers。如果没有visudo这个命令，请使用 "yum install -y sudo" 安装。

默认root能够sudo是因为这个文件中有一行” root ALL=(ALL) ALL”

sudo 的适用条件：
由于su对切换到超级权限用户root后，权限的无限制性，所以su并不能担任多个管理员所管理的系统。如果用su来切换到超级用户来管理系统，也不能明 确哪些工作是由哪个管理员进行的操作。特别是对于服务器的管理有多人参与管理时，最好是针对每个管理员的技术特长和管理范围，并且有针对性的下放给权限， 并且约定其使用哪些工具来完成与其相关的工作，这时我们就有必要用到 sudo。
通过sudo，我们能把某些超级权限有针对性的下放，并且不需要普通用户知道root密码，所以sudo 相对于权限无限制性的su来说，还是比较安全的，所以sudo 也能被称为受限制的su ；另外sudo 是需要授权许可的，所以也被称为授权许可的su；
sudo 执行命令的流程：是当前用户切换到root（或其它指定切换到的用户），然后以root（或其它指定的切换到的用户）身份执行命令，执行完成后，直接退回到当前用户；而这些的前提是要通过sudo的配置文件/etc/sudoers来进行授权；

从编写 sudo 配置文件/etc/sudoers开始
sudo的配置文件是/etc/sudoers ，我们可以用他的专用编辑工具visodu ，此工具的好处是在添加规则不太准确时，保存退出时会提示给我们错误信息；配置好后，可以用切换到您授权的用户下，通过sudo -l 来查看哪些命令是可以执行或禁止的；
/etc/sudoers 文件中每行算一个规则，前面带有#号可以当作是说明的内容，并不执行；如果规则很长，一行列不下时，可以用\号来续行，这样看来一个规则也可以拥有多个行；
/etc/sudoers 的规则可分为两类；一类是别名定义，另一类是授权规则；别名定义并不是必须的，但授权规则是必须的；

sudo授权规则(sudoers配置)：
授权用户 主机=命令动作
这三个要素缺一不可，但在动作之前也可以指定切换到特定用户下，在这里指定切换的用户要用( )号括起来，如果不需要密码直接运行命令的，应该加NOPASSWD:参数，但这些可以省略；举例说明；

sudoers的缺省配置：
Html代码  收藏代码
#############################################################  
# sudoers file.  
#  
# This file MUST be edited with the 'visudo' command as root.  
#  
# See the sudoers man page for the details on how to write a sudoers file.  
#  
# Host alias specification  
# User alias specification  
# Cmnd alias specification  
# Defaults specification  
# User privilege specification  
root    ALL=(ALL) ALL  
# Uncomment to allow people in group wheel to run all commands  
# %wheel        ALL=(ALL)       ALL  
# Same thing without a password  
# %wheel        ALL=(ALL)       NOPASSWD: ALL  
# Samples  
# %users  ALL=/sbin/mount /cdrom,/sbin/umount /cdrom  
# %users  localhost=/sbin/shutdown -h now  
##################################################################  

1. 最简单的配置，让普通用户support具有root的所有权限
执行visudo之后，可以看见缺省只有一条配置：
root    ALL=(ALL) ALL
那么你就在下边再加一条配置：
support ALL=(ALL) ALL
这样，普通用户support就能够执行root权限的所有命令
以support用户登录之后，执行：
sudo su -
然后输入support用户自己的密码，就可以切换成root用户了
2. 让普通用户support只能在某几台服务器上，执行root能执行的某些命令
首先需要配置一些Alias，这样在下面配置权限时，会方便一些，不用写大段大段的配置。Alias主要分成4种
Host_Alias
Cmnd_Alias
User_Alias
Runas_Alias
1) 配置Host_Alias：就是主机的列表
Host_Alias      HOST_FLAG = hostname1, hostname2, hostname3
2) 配置Cmnd_Alias：就是允许执行的命令的列表，命令前加上!表示不能执行此命令.
命令一定要使用绝对路径，避免其他目录的同名命令被执行，造成安全隐患 ,因此使用的时候也是使用绝对路径!
Cmnd_Alias      COMMAND_FLAG = command1, command2, command3 ，!command4
3) 配置User_Alias：就是具有sudo权限的用户的列表
User_Alias USER_FLAG = user1, user2, user3
4) 配置Runas_Alias：就是用户以什么身份执行（例如root，或者oracle）的列表
Runas_Alias RUNAS_FLAG = operator1, operator2, operator3
5) 配置权限
配置权限的格式如下：
USER_FLAG HOST_FLAG=(RUNAS_FLAG) COMMAND_FLAG
如果不需要密码验证的话，则按照这样的格式来配置
USER_FLAG HOST_FLAG=(RUNAS_FLAG) NOPASSWD: COMMAND_FLAG
配置示例：
Html代码  收藏代码
############################################################################  
# sudoers file.  
#  
# This file MUST be edited with the 'visudo' command as root.  
#  
# See the sudoers man page for the details on how to write a sudoers file.  
#  
# Host alias specification  
Host_Alias      EPG = 192.168.1.1, 192.168.1.2  
# User alias specification  
# Cmnd alias specification  
Cmnd_Alias      SQUID = /opt/vtbin/squid_refresh, !/sbin/service, /bin/rm 
 
Cmnd_Alias      ADMPW = /usr/bin/passwd [A-Za-z]*, !/usr/bin/passwd, !/usr/bin/passwd root  
# Defaults specification  
# User privilege specification  
root    ALL=(ALL) ALL  
support EPG=(ALL) NOPASSWD: SQUID  
support EPG=(ALL) NOPASSWD: ADMPW 
# Uncomment to allow people in group wheel to run all commands  
# %wheel        ALL=(ALL)       ALL  
# Same thing without a password  
# %wheel        ALL=(ALL)       NOPASSWD: ALL  
# Samples  
# %users  ALL=/sbin/mount /cdrom,/sbin/umount /cdrom  
# %users  localhost=/sbin/shutdown -h now  
############################################################### 

LVS和Nginx都可以用作多机负载的方案，它们各有优缺，在生产环境中需要好好分析实际情况并加以利用。

　　首先提醒，做技术切不可人云亦云，我云即你云；同时也不可太趋向保守，过于相信旧有方式而等别人来帮你做垫被测试。把所有即时听说到的好东西加以钻研，从而提高自己对技术的认知和水平，乃是一个好习惯。

下面来分析一下两者：

一、lvs的优势：

　　1、抗负载能力强，因为lvs工作方式的逻辑是非常之简单，而且工作在网络4层仅做请求分发之用，没有流量，所以在效率上基本不需要太过考虑。在我手里的 lvs，仅仅出过一次问题：在并发最高的一小段时间内均衡器出现丢包现象，据分析为网络问题，即网卡或linux2.4内核的承载能力已到上限，内存和 cpu方面基本无消耗。

　　2、配置性低，这通常是一大劣势，但同时也是一大优势，因为没有太多可配置的选项，所以除了增减服务器，并不需要经常去触碰它，大大减少了人为出错的几率。

　　3、工作稳定，因为其本身抗负载能力很强，所以稳定性高也是顺理成章，另外各种lvs都有完整的双机热备方案，所以一点不用担心均衡器本身会出什么问题，节点出现故障的话，lvs会自动判别，所以系统整体是非常稳定的。

　　4、无流量，上面已经有所提及了。lvs仅仅分发请求，而流量并不从它本身出去，所以可以利用它这点来做一些线路分流之用。没有流量同时也保住了均衡器的IO性能不会受到大流量的影响。

　　5、基本上能支持所有应用，因为lvs工作在4层，所以它可以对几乎所有应用做负载均衡，包括http、数据库、聊天室等等。

　　另：lvs也不是完全能判别节点故障的，譬如在wlc分配方式下，集群里有一个节点没有配置VIP，会使整个集群不能使用，这时使用wrr分配方式则会丢掉一台机。目前这个问题还在进一步测试中。所以，用lvs也得多多当心为妙。

二、nginx和lvs作对比的结果

　　1、nginx工作在网络的7层，所以它可以针对http应用本身来做分流策略，比如针对域名、目录结构等，相比之下lvs并不具备这样的功能，所以 nginx单凭这点可利用的场合就远多于lvs了；但nginx有用的这些功能使其可调整度要高于lvs，所以经常要去触碰触碰，由lvs的第2条优点 看，触碰多了，人为出问题的几率也就会大。

　　2、nginx对网络的依赖较小，理论上只要ping得通，网页访问正常，nginx就能连得通，nginx同时还能区分内外网，如果是同时拥有内外网的 节点，就相当于单机拥有了备份线路；lvs就比较依赖于网络环境，目前来看服务器在同一网段内并且lvs使用direct方式分流，效果较能得到保证。另 外注意，lvs需要向托管商至少申请多一个ip来做Visual IP，貌似是不能用本身的IP来做VIP的。要做好LVS管理员，确实得跟进学习很多有关网络通信方面的知识，就不再是一个HTTP那么简单了。

　　3、nginx安装和配置比较简单，测试起来也很方便，因为它基本能把错误用日志打印出来。lvs的安装和配置、测试就要花比较长的时间了，因为同上所述，lvs对网络依赖比较大，很多时候不能配置成功都是因为网络问题而不是配置问题，出了问题要解决也相应的会麻烦得多。

　　4、nginx也同样能承受很高负载且稳定，但负载度和稳定度差lvs还有几个等级：nginx处理所有流量所以受限于机器IO和配置；本身的bug也还是难以避免的；nginx没有现成的双机热备方案，所以跑在单机上还是风险较大，单机上的事情全都很难说。

　　5、nginx可以检测到服务器内部的故障，比如根据服务器处理网页返回的状态码、超时等等，并且会把返回错误的请求重新提交到另一个节点。目前lvs中 ldirectd也能支持针对服务器内部的情况来监控，但lvs的原理使其不能重发请求。重发请求这点，譬如用户正在上传一个文件，而处理该上传的节点刚 好在上传过程中出现故障，nginx会把上传切到另一台服务器重新处理，而lvs就直接断掉了，如果是上传一个很大的文件或者很重要的文件的话，用户可能 会因此而恼火。

　　6、nginx对请求的异步处理可以帮助节点服务器减轻负载，假如使用Apache直接对外服务，那么出现很多的窄带链接时apache服务器将会占用大 量内存而不能释放，使用多一个nginx做apache代理的话，这些窄带链接会被nginx挡住，apache上就不会堆积过多的请求，这样就减少了相 当多的内存占用。这点使用squid也有相同的作用，即使squid本身配置为不缓存，对apache还是有很大帮助的。lvs没有这些功能，也就无法能 比较。

　　7、nginx能支持http和email（email的功能估计比较少人用），lvs所支持的应用在这点上会比nginx更多。

　　在使用上，一般最前端所采取的策略应是lvs，也就是DNS的指向应为lvs均衡器，lvs的优点令它非常适合做这个任务。

　　重要的ip地址，最好交由lvs托管，比如数据库的ip、webservice服务器的ip等等，这些ip地址随着时间推移，使用面会越来越大，如果更换ip则故障会接踵而至。所以将这些重要ip交给lvs托管是最为稳妥的，这样做的唯一缺点是需要的VIP数量会比较多。

　　nginx可作为lvs节点机器使用，一是可以利用nginx的功能，二是可以利用nginx的性能。当然这一层面也可以直接使用squid，squid的功能方面就比nginx弱不少了，性能上也有所逊色于nginx。

　　nginx也可作为中层代理使用，这一层面nginx基本上无对手，唯一可以撼动nginx的就只有lighttpd了，不过lighttpd目前还没有 能做到nginx完全的功能，配置也不那么清晰易读。另外，中层代理的IP也是重要的，所以中层代理也拥有一个VIP和lvs是最完美的方案了。

　　nginx也可作为网页静态服务器，不过超出了本文讨论的范畴，简单提一下。

　　具体的应用还得具体分析，如果是比较小的网站（日PV<1000万），用nginx就完全可以了，如果机器也不少，可以用DNS轮询，lvs所耗费的机器还是比较多的；大型网站或者重要的服务，机器不发愁的时候，要多多考虑利用lvs。

在Linux中常用于判断问题所在的初步定位或性能瓶颈，iostat则给我们提供了丰富的IO状态信息，其他工具还有iotop。

letong@me:~$ sudo iostat
Linux 3.13.0-41-generic (me) 2014年12月18日 _x86_64_ (4 CPU)

avg-cpu: %user %nice %system %iowait %steal %idle
8.92 0.12 2.27 0.65 0.00 88.05

Device: tps kB_read/s kB_wrtn/s kB_read kB_wrtn
sda 5.12 85.24 1.97 586069 13512
sdb 9.51 43.74 112.81 300771 775678
rrqm/s: 每秒进行 merge 的读操作数目。即 delta(rmerge)/s
wrqm/s: 每秒进行 merge 的写操作数目。即 delta(wmerge)/s
r/s: 每秒完成的读 I/O 设备次数。即 delta(rio)/s
w/s: 每秒完成的写 I/O 设备次数。即 delta(wio)/s
rsec/s: 每秒读扇区数。即 delta(rsect)/s
wsec/s: 每秒写扇区数。即 delta(wsect)/s
rkB/s: 每秒读K字节数。是 rsect/s 的一半，因为每扇区大小为512字节。(需要计算)
wkB/s: 每秒写K字节数。是 wsect/s 的一半。(需要计算)
avgrq-sz: 平均每次设备I/O操作的数据大小 (扇区)。delta(rsect+wsect)/delta(rio+wio)
avgqu-sz: 平均I/O队列长度。即 delta(aveq)/s/1000 (因为aveq的单位为毫秒)。
await: 平均每次设备I/O操作的等待时间 (毫秒)。即 delta(ruse+wuse)/delta(rio+wio)
svctm: 平均每次设备I/O操作的服务时间 (毫秒)。即 delta(use)/delta(rio+wio)
%util: 一秒中有百分之多少的时间用于 I/O 操作，或者说一秒中有多少时间 I/O 队列是非空的。即 delta(use)/s/1000 (因为use的单位为毫秒)
常用参数：
-d 1 #每1秒显示1次
-x #显示更详细信息
-c #显示cpu相关

常见用法
iostat -d -k 1 10 #查看TPS和吞吐量信息
iostat -d -x -k 1 10 #查看设备使用率、响应时间
iostat -c 1 10 #查看cpu状态

如果在测试过程中遇到某个进程的CPU利用率过高或者卡死而需要去调试该进程时，可以利用gdb命令生成coredump文件，然后再去调试coredump文件来定位问题。

那么如何使用gdb生成coredump文件呢？其实步骤很简单：

1. 安装好gdb，然后使用命令 'gdb'。（假设需要调试的进程号为 21509）

2. 使用 ‘attach 21590’命令将gdb附加到进程21509上。

3. 使用‘gcore core_name’命令生成coredump文件core_name。

4. 使用‘detach’命令断开连接。

5.使用‘q’命令退出gdb。

此时，在当前目录下就会产生一个名为core_name的coredump文件。下面就可以利用gdb工具来对该coredump文件进行调试了。

性能测试排查定位问题，分析调优过程中，会遇到要分析gc日志，人肉分析gc日志有时比较困难，相关图形化或命令行工具可以有效地帮助辅助分析。

Gc日志参数

通过在tomcat启动脚本中添加相关参数生成gc日志

-verbose.gc开关可显示GC的操作内容。打开它，可以显示最忙和最空闲收集行为发生的时间、收集前后的内存大小、收集需要的时间等。

打开 -xx:+ printGCdetails开关，可以详细了解GC中的变化。

打开 -XX: + PrintGCTimeStamps开关，可以了解这些垃圾收集发生的时间，自JVM启动以后以秒计量。

最后，通过 -xx: + PrintHeapAtGC开关了解堆的更详细的信息。

为了了解新域的情况，可以通过 -XX:=PrintTenuringDistribution开关了解获得使用期的对象权。

-Xloggc:$CATALINA_BASE/logs/gc.loggc日志产生的路径

XX:+PrintGCApplicationStoppedTime//输出GC造成应用暂停的时间

-XX:+PrintGCDateStamps// GC发生的时间信息

Gc日志

日志中显示了gc发生的时间，young区回收情况，整体回收情况，fullGC情况，回收所消耗时间等

常用JVM参数

分析gc日志后，经常需要调整jvm内存相关参数，常用参数如下

-Xms：初始堆大小，默认为物理内存的1/64(<1GB)；默认(MinHeapFreeRatio参数可以调整)空余堆内存小于40%时，JVM就会增大堆直到-Xmx的最大限制

-Xmx：最大堆大小，默认(MaxHeapFreeRatio参数可以调整)空余堆内存大于70%时，JVM会减少堆直到-Xms的最小限制

-Xmn：新生代的内存空间大小，注意：此处的大小是（eden+ 2 survivor space)。与jmap -heap中显示的New gen是不同的。整个堆大小=新生代大小+老生代大小+永久代大小。 
在保证堆大小不变的情况下，增大新生代后,将会减小老生代大小。此值对系统性能影响较大,Sun官方推荐配置为整个堆的3/8。

-XX:SurvivorRatio：新生代中Eden区域与Survivor区域的容量比值，默认值为8。两个Survivor区与一个Eden区的比值为2:8,一个Survivor区占整个年轻代的1/10。

-Xss：每个线程的堆栈大小。JDK5.0以后每个线程堆栈大小为1M,以前每个线程堆栈大小为256K。应根据应用的线程所需内存大小进行适当调整。在相同物理内存下,减小这个值能生成更多的线程。但是操作系统对一个进程内的线程数还是有限制的，不能无限生成，经验值在3000~5000左右。一般小的应用， 如果栈不是很深， 应该是128k够用的，大的应用建议使用256k。这个选项对性能影响比较大，需要严格的测试。和threadstacksize选项解释很类似,官方文档似乎没有解释,在论坛中有这样一句话:"-Xss is translated in a VM flag named ThreadStackSize”一般设置这个值就可以了。

-XX:PermSize：设置永久代(perm gen)初始值。默认值为物理内存的1/64。

-XX:MaxPermSize：设置持久代最大值。物理内存的1/4。

Gc日志分析工具

(1)GCHisto

http://java.net/projects/gchisto

直接点击gchisto.jar就可以运行，点add载入gc.log

统计了总共gc次数，youngGC次数，FullGC次数，次数的百分比，GC消耗的时间，百分比，平均消耗时间，消耗时间最小最大值等

统计的图形化表示

YoungGC,FullGC不同消耗时间上次数的分布图，勾选可以显示youngGC或fullGC单独的分布情况

整个时间过程详细的gc情况，可以对整个过程进行剖析

(2)GCLogViewer

http://code.google.com/p/gclogviewer/

点击run.bat运行

整个过程gc情况的趋势图，还显示了gc类型，吞吐量，平均gc频率，内存变化趋势等

Tools里还能比较不同gc日志

(3)HPjmeter

获取地址 http://www.hp.com/go/java 
参考文档 http://www.javaperformancetuning.com/tools/hpjtune/index.shtml

工具很强大，但只能打开由以下参数生成的GC log，-verbose:gc -Xloggc:gc.log,添加其他参数生成的gc.log无法打开。

(4)GCViewer

http://www.tagtraum.com/gcviewer.html

这个工具用的挺多的，但只能在JDK1.5以下的版本中运行，1.6以后没有对应。

(5)garbagecat

http://code.google.com/a/eclipselabs.org/p/garbagecat/wiki/Documentation

其它监控方法

Jvisualvm动态分析jvm内存情况和gc情况，插件：visualGC

jvisualvm还可以heapdump出对应hprof文件（默认存放路径：监控的服务器/tmp下），利用相关工具，比如HPjmeter可以对其进行分析

grep Full gc.log粗略观察FullGC发生频率

jstat –gcutil [pid] [intervel] [count]

jmap -histo pid可以观测对象的个数和占用空间 
jmap -heap pid可以观测jvm配置参数，堆内存各区使用情况

jprofiler,jmap dump出来用MAT分析

如果要分析的dump文件很大的话，就需要很多内存，很容易crash。

所以在启动时，我们应该加上一些参数：Java–Xms512M–Xmx1024M–Xss8M