linux性能分析

⑴ linux中查看虚拟内存和cpu占用率的命令是什么

top，free，cat/proc/meminfo，cat/proc/cpuinfo。

[root@centerlisdbproc]#dmidecode|grep-A16"MemoryDevice"|more[objectObject]。

查看内存使用情况：cat/proc/meminfo，查看CPU使用情况：cat /proc/cpuinfo。

在系统维护的过程中，随时可能有需要查看 CPU 使用率，并根据相应信息分析系统状况的需要。在 CentOS 中，可以通过 top 命令来查看 CPU 使用状况。

运行 top 命令后，CPU 使用状态会以全屏的方式显示，并且会处在对话的模式 -- 用基于 top 的命令，可以控制显示方式等等。退出 top 的命令为 q （在 top 运行中敲 q 键一次）。

top命令是Linux下常用的性能分析工具，能够实时显示系统中各个进程的资源占用状况，类似于Windows的任务管理器。

可以直接使用top命令后，查看%MEM的内容。可以选择按进程查看或者按用户查看，如想查看oracle用户的进程内存使用情况的话可以使用如下的命令：$ top -u oracle。

(1)linux性能分析扩展阅读：

一、查看内存占用：

1、free

# free -m。

以MB为单位显示内存使用情况。

# free -h。

以GB为单位显示内存使用情况。

# free -t。

以总和的形式查询内存的使用信息。

# free -s 5。

周期性的查询内存使用信息。

每5秒执行一次命令。

二、查看CPU使用情况：

1、top。

top后键入P看一下谁占用最大。

# top -d 5。

周期性的查询CPU使用信息。

每5秒刷新一次。

2、ps auxw（查看本机的进程所占cpu和mem的百分比情况）。

使用"ps auxw" 可以查看到本机的进程所占cpu和mem的百分比情况。

# ps auxw | head -1

%CPU 进程的cpu占用率。

%MEM 进程的内存占用率。

3、查看本机所有进程的CPU占比之和。

# cat cpu_per.sh

三、查看cpu信息（信息记录在/proc/cpuinfo中）

# 总核数 = 物理CPU个数 X 每颗物理CPU的核数。

# 总逻辑CPU数 = 物理CPU个数 X 每颗物理CPU的核数 X 超线程数。

⑵ 怎样分析linux的性能指标

LR

监控

UNIX/Linux

系统方法

一、准备工作：

1.

可以通过两种方法验证服务器上是否配置

rstatd

守护程序：

①使用

rup

命令，它用于报告计算机的各种统计信息，其中就包括

rstatd

的配置信息。使用命

令

rup

10.130.61.203,

此处

10.130.61.203

是要监视的

linux/Unix

服务器的

IP

，如果该命令返回相关的

统计信息。则表示已经配置并且激活了

rstatd

守护进程；若未返回有意义的统计信息，或者出现一

条错误报告，则表示

rstatd

守护进程尚未被配置或有问题。

②使用

find

命令

#find / -name rpc.rstatd,

该命令用于查找系统中是否存在

rpc.rstatd

文件，如果没有，说明系统没

有安装

rstatd

守护程序。

2

．

linux

需要下载

3

个包：

（

1

）

rpc.rstatd-4.0.1.tar.gz

（

2

）

rsh-0.17-14.i386.rpm

（

3

）

rsh-server-0.17-14.i386.rpm

3

．下载并安装

rstatd

如果服务器上没有安装

rstatd

程序（一般来说

LINUX

都没有安装）

，需要下载一个包才有这个服

务

,

包

名

字

是

rpc.rstatd-4.0.1.tar.gz.

这

是

一

个

源

码

,

需

要

编

译

,

下

载

并

安

装

rstatd

（

可

以

在

http://sourceforge.net/projects/rstatd

这个地址下载）下载后，开始安装，安装步骤如下：

tar -xzvf rpc.rstatd-4.0.1.tar.gz

cd rpc.rstatd-4.0.1/

./configure

—配置操作

make

—进行编译

make install

—开始安装

rpc.rstatd

—启动

rstatd

进程

“

rpcinfo -p

”命令来查看当前系统是否已经启动了

rstatd

守护进程

只要保证

Linux

机器上的进程里有

rstatd

和

xinetd

这二个服务就可以用

LR

去监视了，通过以下

两点可以检查是否启动：

1

）检查是否启动

: rsh server

监听的

TCP

是

514

。

[root@mg04 root]# netstat -an |grep 514

tcp 0 0 0.0.0.0:514 0.0.0.0:* LISTEN

如果能看到

514

在监听说明

rsh

服务器已经启动。

2

）检查是否启动

: rstatd

输入命令

: rpcinfo -p

如果能看到类似如下信息：

程序版本协议端口

100001

5

udp

937

rstatd

100001

4

udp

937

rstatd

100001

3

udp

937

rstatd

100001

2

udp

937

rstatd

100001

1

udp

937

rstatd

那就说明

rstatd

服务启动了

,(

当然这里也可以用

ps ax

代替

)

4

．安装

rsh

和

rsh-server

两个服务包方法

a.

卸载

rsh

# rpm

–

q

rsh----------

查看版本号

# rpm

-e

版本号

---------

卸载该版本。

b

．安装

# rpm

–

ivh rsh-0.17-14.i386.rpm rsh-server-0.17-14.i386.rpm

在启动

rpc.rstatd

时，

会报错

“

Cannot register service: RPC: Unable to receive; errno = Ction refused

”

。

解决方法如下：

# /etc/init.d/portmap start

# /etc/init.d/nfs start

然后再次启动

rpc.rstatd

就好了。

5

．安装

xinetd

方法：

①查看

xinetd

服务：

[root@localhost ~]# rpm -q xinetd

xinetd-2.3.14-10.el5

②安装

xinetd

服务：

[root@localhost ~]# yum install xinetd

如果安装不起

xinetd

服务，执行下列操作命令后再次执行

yum install xinetd

命令进行安装：

yum clean packages

清除缓存目录下的软件包

yum clean headers

清除缓存目录下的

headers

yum clean oldheaders

清除缓存目录下旧的

headers

yum clean, yum clean all (= yum clean packages; yum clean oldheaders)

清除缓存目录下的软件包

及旧的

headers

。

6

．启动

xinetd

服务：

在有的系统中，通过如下命令重启：

# service xinetd reload

# /sbin/service xinetd rstart

在

suse linux

中如下操作：

cd /etc/init.d/xinetd restart

2

）

安装完成后配置

rstatd

目标守护进程

xinetd,

它的主配置文件是

/etc/xinetd.conf ,

它里面内容是

一些如下的基本信息：

#

# xinetd.conf

#

# Copyright (c) 1998-2001 SuSE GmbH Nuernberg, Germany.

# Copyright (c) 2002 SuSE Linux AG, Nuernberg, Germany.

#

defaults

{

log_type

= FILE /var/log/xinetd.log

log_on_success = HOST EXIT DURATION

log_on_failure = HOST ATTEMPT

#

only_from

= localhost

instances

= 30

cps

= 50 10

#

# The specification of an interface is interesting, if we are on a firewall.

# For example, if you only want to provide services from an internal

# network interface, you may specify your internal interfaces IP-Address.

#

#

interface

= 127.0.0.1

}

includedir /etc/xinetd.d

我们这里需要修改的是

/etc/xinetd.d/

下的三个

conf

文件

rlogin

,rsh,rexec

这三个配置文件

,

打这

三个文件里的

disable = yes

都改成

disable = no ( disabled

用在默认的

{}

中禁止服务

)

或是把

# default:

off

都设置成

on

这个的意思就是在

xinetd

启动的时候默认都启动上面的三个服务

!

说明：我自己在配置时，没有

disable = yes

这项，我就将

# default: off

改为：

default: on

，重启后

(cd /etc/init.d/./xinetd restart

）通过

netstat -an |grep 514

查看，没有返回。然后，我就手动在三个文

件中最后一行加入

disable

=

no

，再重启

xinetd

，再使用

netstat

-an

|grep

514

查看，得到

tcp

0

0

0.0.0.0:514 0.0.0.0:* LISTEN

结果，表明

rsh

服务器已经启动。

看到网上有的地方说使用如下命令：

# service xinetd reload

# /sbin/service xinetd rstart

不知道是在什么系统用的。

二、监控

linux

资源：

在

controller

中，将

System resource Graphs

中的

Unix resources

拖到右侧的监控区域中，并单击

鼠标右键选择“

Add

Measurements

”

,

在弹出的对话框中输入被监控的

linux

系统的

IP

地址，然后选

择需要监控的性能指标，并点击“确定”

，出现如下结果：

Monitor name :UNIX Resources. Cannot initialize the monitoring on 10.10.15.62.

Error while creating the RPC client. Ensure that the machine can be connected and that it runs the

rstat daemon (use rpcinfo utility for this verification).

Detailed error: RPC: Failed to create RPC client.

RPC-TCP: Failed to establish RPC server address.

RPC-TCP: Failed to communicate with the portmapper on host '10.10.15.62'.

RPC: RPC call failed.

RPC-TCP: recv()/recvfrom() failed.

RPC-TCP: Timeout reached. (entry point: CFactory::Initialize). [MsgId: MMSG-47190]

检查原因，发现是

Linux

系统中的防火墙开启了并且阻挡了

LoadRunner

监控

Linux

系统的资源，

因此要将防火墙关闭。

关闭防火墙：

[root@localhost ~]# /etc/init.d/iptables stop;

三、监控

UNIX

lr

监控

UNIX

，

UNIX

先启动一

rstatd

服务

以下是在

IBM AIX

系统中启动

rstatd

服务的方法：

1

．使用

telnet

以

root

用户的身份登录入

AIX

系统

2

．在命令行提示符下输入：

vi /etc/inetd.conf

3

．查找

rstatd

，找到

#rstatd

sunrpc_udp

udp

wait

root /usr/sbin/rpc.rstatd rstatd 100001 1-3

4

、将

#

去掉

5

、

:wq

保存修改结果

6

、命令提示符下输入：

refresh

–

s inetd

重新启动服务。

这样使用

loadrunner

就可以监视

AIX

系统的性能情况了。

注：在

HP UNIX

系统上编辑完

inetd.conf

后，重启

inetd

服务需要输入

inetd -c

UNIX

上也可以用

rup

命令查看

rstatd

程序是否被配置并激活

若

rstatd

程序已经运行，

重启时，

先查看进程

ps -ef |grep inet

，

然后杀掉进程，

再

refresh

–

s inetd

进行重启。

⑶ 如何用九条命令在一分钟内检查Linux服务器性能

一、uptime命令

这个命令可以快速查看机器的负载情况。在Linux系统中，这些数据表示等待CPU资源的进程和阻塞在不可中断IO进程（进程状态为D）的数量。这些数据可以让我们对系统资源使用有一个宏观的了解。

命令的输出分别表示1分钟、5分钟、15分钟的平均负载情况。通过这三个数据，可以了解服务器负载是在趋于紧张还是趋于缓解。如果1分钟平均负载很高，而15分钟平均负载很低，说明服务器正在命令高负载情况，需要进一步排查CPU资源都消耗在了哪里。反之，如果15分钟平均负载很高，1分钟平均负载较低，则有可能是CPU资源紧张时刻已经过去。

上面例子中的输出，可以看见最近1分钟的平均负载非常高，且远高于最近15分钟负载，因此我们需要继续排查当前系统中有什么进程消耗了大量的资源。可以通过下文将会介绍的vmstat、mpstat等命令进一步排查。

二、dmesg命令

该命令会输出系统日志的最后10行。示例中的输出，可以看见一次内核的oom kill和一次TCP丢包。这些日志可以帮助排查性能问题。千万不要忘了这一步。

三、vmstat命令

vmstat(8) 命令，每行会输出一些系统核心指标，这些指标可以让我们更详细的了解系统状态。后面跟的参数1，表示每秒输出一次统计信息，表头提示了每一列的含义，这几介绍一些和性能调优相关的列：

r：等待在CPU资源的进程数。这个数据比平均负载更加能够体现CPU负载情况，数据中不包含等待IO的进程。如果这个数值大于机器CPU核数，那么机器的CPU资源已经饱和。

free：系统可用内存数（以千字节为单位），如果剩余内存不足，也会导致系统性能问题。下文介绍到的free命令，可以更详细的了解系统内存的使用情况。

si，so：交换区写入和读取的数量。如果这个数据不为0，说明系统已经在使用交换区（swap），机器物理内存已经不足。

us, sy, id, wa, st：这些都代表了CPU时间的消耗，它们分别表示用户时间（user）、系统（内核）时间（sys）、空闲时间（idle）、IO等待时间（wait）和被偷走的时间（stolen，一般被其他虚拟机消耗）。

上述这些CPU时间，可以让我们很快了解CPU是否出于繁忙状态。一般情况下，如果用户时间和系统时间相加非常大，CPU出于忙于执行指令。如果IO等待时间很长，那么系统的瓶颈可能在磁盘IO。

示例命令的输出可以看见，大量CPU时间消耗在用户态，也就是用户应用程序消耗了CPU时间。这不一定是性能问题，需要结合r队列，一起分析。

四、mpstat命令

该命令可以显示每个CPU的占用情况，如果有一个CPU占用率特别高，那么有可能是一个单线程应用程序引起的。

五、pidstat命令

pidstat命令输出进程的CPU占用率，该命令会持续输出，并且不会覆盖之前的数据，可以方便观察系统动态。如上的输出，可以看见两个JAVA进程占用了将近1600%的CPU时间，既消耗了大约16个CPU核心的运算资源。

六、iostat命令

r/s, w/s, rkB/s, wkB/s：分别表示每秒读写次数和每秒读写数据量（千字节）。读写量过大，可能会引起性能问题。

await：IO操作的平均等待时间，单位是毫秒。这是应用程序在和磁盘交互时，需要消耗的时间，包括IO等待和实际操作的耗时。如果这个数值过大，可能是硬件设备遇到了瓶颈或者出现故障。

avgqu-sz：向设备发出的请求平均数量。如果这个数值大于1，可能是硬件设备已经饱和（部分前端硬件设备支持并行写入）。

%util：设备利用率。这个数值表示设备的繁忙程度，经验值是如果超过60，可能会影响IO性能（可以参照IO操作平均等待时间）。如果到达100%，说明硬件设备已经饱和。

如果显示的是逻辑设备的数据，那么设备利用率不代表后端实际的硬件设备已经饱和。值得注意的是，即使IO性能不理想，也不一定意味这应用程序性能会不好，可以利用诸如预读取、写缓存等策略提升应用性能。

七、free命令

free命令可以查看系统内存的使用情况，-m参数表示按照兆字节展示。最后两列分别表示用于IO缓存的内存数，和用于文件系统页缓存的内存数。需要注意的是，第二行-/+ buffers/cache，看上去缓存占用了大量内存空间。

这是Linux系统的内存使用策略，尽可能的利用内存，如果应用程序需要内存，这部分内存会立即被回收并分配给应用程序。因此，这部分内存一般也被当成是可用内存。

如果可用内存非常少，系统可能会动用交换区（如果配置了的话），这样会增加IO开销（可以在iostat命令中提现），降低系统性能。

八、sar命令

sar命令在这里可以查看网络设备的吞吐率。在排查性能问题时，可以通过网络设备的吞吐量，判断网络设备是否已经饱和。如示例输出中，eth0网卡设备，吞吐率大概在22 Mbytes/s，既176 Mbits/sec，没有达到1Gbit/sec的硬件上限。

sar命令在这里用于查看TCP连接状态，其中包括：

active/s：每秒本地发起的TCP连接数，既通过connect调用创建的TCP连接；

passive/s：每秒远程发起的TCP连接数，即通过accept调用创建的TCP连接；

retrans/s：每秒TCP重传数量；

TCP连接数可以用来判断性能问题是否由于建立了过多的连接，进一步可以判断是主动发起的连接，还是被动接受的连接。TCP重传可能是因为网络环境恶劣，或者服务器压

九、top命令

top命令包含了前面好几个命令的检查的内容。比如系统负载情况（uptime）、系统内存使用情况（free）、系统CPU使用情况（vmstat）等。因此通过这个命令，可以相对全面的查看系统负载的来源。同时，top命令支持排序，可以按照不同的列排序，方便查找出诸如内存占用最多的进程、CPU占用率最高的进程等。

但是，top命令相对于前面一些命令，输出是一个瞬间值，如果不持续盯着，可能会错过一些线索。这时可能需要暂停top命令刷新，来记录和比对数据。

⑷ linux 性能优化-- cpu 切换以及cpu过高

本文先介绍了cpu上下文切换的基础知识，以及上下文切换的类型（进程，线程等切换）。然后介绍了如何查看cpu切换次数的工具和指标的解释。同时对日常分析种cpu过高的情况下如何分析和定位的方法做了一定的介绍，使用一个简单的案例进行分析，先用top，pidstat等工具找出占用过高的进程id，然后通过分析到底是用户态cpu过高，还是内核态cpu过高，并用perf 定位到具体的调用函数。（来自极客时间课程学习笔记）

1、多任务竞争CPU，cpu变换任务的时候进行CPU上下文切换(context switch)。CPU执行任务有4种方式：进程、线程、或者硬件通过触发信号导致中断的调用。

2、当切换任务的时候，需要记录任务当前的状态和获取下一任务的信息和地址(指针)，这就是上下文的内容。因此，上下文是指某一时间点CPU寄存器(CPU register)和程序计数器(PC)的内容, 广义上还包括内存中进程的虚拟地址映射信息.

3、上下文切换的过程：

4、根据任务的执行形式，相应的下上文切换，有进程上下文切换、线程上下文切换、以及中断上下文切换三类。

5、进程和线程的区别：
进程是资源分配和执行的基本单位；线程是任务调度和运行的基本单位。线程没有资源，进程给指针提供虚拟内存、栈、变量等共享资源，而线程可以共享进程的资源。

6、进程上下文切换：是指从一个进程切换到另一个进程。

(1)进程运行态为内核运行态和进程运行态。内核空间态资源包括内核的堆栈、寄存器等；用户空间态资源包括虚拟内存、栈、变量、正文、数据等

(2)系统调用(软中断)在内核态完成的，需要进行2次CPU上下文切换(用户空间-->内核空间-->用户空间)，不涉及用户态资源，也不会切换进程。

(3)进程是由内核来管理和调度的，进程的切换只能发生在内核态。所以，进程的上下文不仅包括了用户空间的资源，也包括内核空间资源。

(4)进程的上下文切换过程：

(5)、下列将会触发进程上下文切换的场景：

7、线程上下文切换：

8、中断上下文切换
快速响应硬件的事件，中断处理会打断进程的正常调度和执行。同一CPU内，硬件中断优先级高于进程。切换过程类似于系统调用的时候，不涉及到用户运行态资源。但大量的中断上下文切换同样可能引发性能问题。

重点关注信息：

系统的就绪队列过长，也就是正在运行和等待 CPU 的进程数过多，导致了大量的上下文切换，而上下文切换又导致了系统 CPU 的占用率升高。

这个结果中有两列内容是我们的重点关注对象。一个是 cswch ，表示每秒自愿上下文切换（voluntary context switches）的次数，另一个则是 nvcswch ，表示每秒非自愿上下文切换（non voluntary context switches）的次数。

linux的中断使用情况可以从 /proc/interrupts 这个只读文件中读取。/proc 实际上是 Linux 的一个虚拟文件系统，用于内核空间与用户空间之间的通信。/proc/interrupts 就是这种通信机制的一部分，提供了一个只读的中断使用情况。

重调度中断（RES），这个中断类型表示，唤醒空闲状态的 CPU 来调度新的任务运行。这是多处理器系统（SMP）中，调度器用来分散任务到不同 CPU 的机制，通常也被称为处理器间中断（Inter-Processor Interrupts，IPI）。

这个数值其实取决于系统本身的 CPU 性能。如果系统的上下文切换次数比较稳定，那么从数百到一万以内，都应该算是正常的。但当上下文切换次数超过一万次，或者切换次数出现数量级的增长时，就很可能已经出现了性能问题。这时，需要根据上下文切换的类型，再做具体分析。

比方说：

首先通过uptime查看系统负载，然后使用mpstat结合pidstat来初步判断到底是cpu计算量大还是进程争抢过大或者是io过多，接着使用vmstat分析切换次数，以及切换类型，来进一步判断到底是io过多导致问题还是进程争抢激烈导致问题。

CPU 使用率相关的重要指标：

性能分析工具给出的都是间隔一段时间的平均 CPU 使用率，所以要注意间隔时间的设置，特别是用多个工具对比分析时，你一定要保证它们用的是相同的间隔时间。比如，对比一下 top 和 ps 这两个工具报告的 CPU 使用率，默认的结果很可能不一样，因为 top 默认使用 3 秒时间间隔，而 ps 使用的却是进程的整个生命周期。

top 和 ps 是最常用的性能分析工具：

这个输出结果中，第三行 %Cpu 就是系统的 CPU 使用率，top 默认显示的是所有 CPU 的平均值，这个时候你只需要按下数字 1 ，就可以切换到每个 CPU 的使用率了。继续往下看，空白行之后是进程的实时信息，每个进程都有一个 %CPU 列，表示进程的 CPU 使用率。它是用户态和内核态 CPU 使用率的总和，包括进程用户空间使用的 CPU、通过系统调用执行的内核空间 CPU 、以及在就绪队列等待运行的 CPU。在虚拟化环境中，它还包括了运行虚拟机占用的 CPU。

预先安装 stress 和 sysstat 包，如 apt install stress sysstat。

stress 是一个 Linux 系统压力测试工具，这里我们用作异常进程模拟平均负载升高的场景。而 sysstat 包含了常用的 Linux 性能工具，用来监控和分析系统的性能。我们的案例会用到这个包的两个命令 mpstat 和 pidstat。

下面的 pidstat 命令，就间隔 1 秒展示了进程的 5 组 CPU 使用率，

包括：

perf 是 Linux 2.6.31 以后内置的性能分析工具。它以性能事件采样为基础，不仅可以分析系统的各种事件和内核性能，还可以用来分析指定应用程序的性能问题。

第一种常见用法是 perf top，类似于 top，它能够实时显示占用 CPU 时钟最多的函数或者指令，因此可以用来查找热点函数，使用界面如下所示：

输出结果中，第一行包含三个数据，分别是采样数（Samples）如2K、事件类型（event）如cpu-clock:pppH和事件总数量（Event count）如：371909314。

第二种常见用法，也就是 perf record 和 perf report。 perf top 虽然实时展示了系统的性能信息，但它的缺点是并不保存数据，也就无法用于离线或者后续的分析。而 perf record 则提供了保存数据的功能，保存后的数据，需要你用 perf report 解析展示。

1.启动docker 运行进程：

2.ab工具测试服务器性能
ab（apache bench）是一个常用的 HTTP 服务性能测试工具，这里用来模拟 Ngnix 的客户端。

3.分析过程

CPU 使用率是最直观和最常用的系统性能指标，在排查性能问题时，通常会关注的第一个指标。所以更要熟悉它的含义，尤其要弄清楚:

这几种不同 CPU 的使用率。比如说：

碰到 CPU 使用率升高的问题，你可以借助 top、pidstat 等工具，确认引发 CPU 性能问题的来源；再使用 perf 等工具，排查出引起性能问题的具体函数.

⑸ 怎样分析linux的性能指标

一、处理器参数
这是一个很简单的参数，它直观的描述了每个CPU的利用率。在xSeries架构中，如果CPU的利用率长时间的超过80％，就可能是出现了处理器的瓶颈。
Runable processes
这个值描述了正在准备被执行的进程，在一个持续时间里这个值不应该超过物理CPU数量的10倍，否则CPU方面就可能存在瓶颈。
Blocked
描述了那些因为等待I/O操作结束而不能被执行的进程，Blocked可能指出你正面临I/O瓶颈。
User time
描述了处理用户进程的百分比，包括nice time。如果User time的值很高，说明系统性能用在处理实际的工作。
System time
描述了CPU花费在处理内核操作包括IRQ和软件中断上面的百分比。如果system time很高说明系统可能存在网络或者驱动堆栈方面的瓶颈。一个系统通常只花费很少的时间去处理内核的操作。
Idle time
描述了CPU空闲的百分比。
Nice time
描述了CPU花费在处理re-nicing进程的百分比。
Context switch
系统中线程之间进行交换的数量。
Waiting
CPU花费在等待I/O操作上的总时间，与blocked相似，一个系统不应该花费太多的时间在等待I/O操作上，否则你应该进一步检测I/O子系统是否存在瓶颈。
Interrupts
Interrupts值包括硬Interrupts和软Interrupts，硬Interrupts会对系统性能带
来更多的不利影响。高的Interrupts值指出系统可能存在一个软件的瓶颈，可能是内核或者驱动程序。注意Interrupts值中包括CPU时钟导
致的中断（现代的xServer系统每秒1000个Interrupts值）。
二、内存参数
Free memory
相比其他操作系统，Linux空闲内存的值不应该做为一个性能参考的重要指标，因为就像我们之前提到过的，Linux内核会分配大量没有被使用的内存作为文件系统的缓存，所以这个值通常都比较小。
Swap usage
这个值描述了已经被使用的swap空间。Swap
usage只表示了Linux管理内存的有效性。对识别内存瓶颈来说，Swap In/Out才是一个比较又意义的依据，如果Swap
In/Out的值长期保持在每秒200到300个页面通常就表示系统可能存在内存的瓶颈。
Buffer and cache
这个值描述了为文件系统和块设备分配的缓存。注意在Red Hat Enterprise Linux
3和更早一些的版本中，大部分空闲内存会被分配作为缓存使用。在Red Hat Enterprise Linux
4以后的版本中,你可以通过修改/proc/sys/vm中的page_cache_tuning来调整空闲内存中作为缓存的数量。
Slabs
描述了内核使用的内存空间，注意内核的页面是不能被交换到磁盘上的。
Active versus inactive memory
提供了关于系统内存的active内存信息，Inactive内存是被kswapd守护进程交换到磁盘上的空间。
三、网络参数
Packets received and sent
这个参数表示了一个指定网卡接收和发送的数据包的数量。
Bytes received and sent
这个参数表示了一个指定网卡接收和发送的数据包的字节数。
Collisions per second
这个值提供了发生在指定网卡上的网络冲突的数量。持续的出现这个值代表在网络架构上出现了瓶颈，而不是在服务器端出现的问题。在正常配置的网络中冲突是非常少见的，除非用户的网络环境都是由hub组成。
Packets dropped
这个值表示了被内核丢掉的数据包数量，可能是因为防火墙或者是网络缓存的缺乏。
Overruns
Overruns表达了超出网络接口缓存的次数，这个参数应该和packets dropped值联系到一起来判断是否存在在网络缓存或者网络队列过长方面的瓶颈。
Errors
这个值记录了标志为失败的帧的数量。这个可能由错误的网络配置或者部分网线损坏导致，在铜口千兆以太网环境中部分网线的损害是影响性能的一个重要因素。
四、块设备参数
Iowait
CPU等待I/O操作所花费的时间。这个值持续很高通常可能是I/O瓶颈所导致的。
Average queue length
I/O请求的数量，通常一个磁盘队列值为2到3为最佳情况，更高的值说明系统可能存在I/O瓶颈。
Average wait
响应一个I/O操作的平均时间。Average wait包括实际I/O操作的时间和在I/O队列里等待的时间。
Transfers per second
描述每秒执行多少次I/O操作（包括读和写）。Transfers per second的值与kBytes per second结合起来可以帮助你估计系统的平均传输块大小，这个传输块大小通常和磁盘子系统的条带化大小相符合可以获得最好的性能。
Blocks read/write per second
这个值表达了每秒读写的blocks数量，在2.6内核中blocks是1024bytes，在早些的内核版本中blocks可以是不同的大小，从512bytes到4kb。
Kilobytes per second read/write
按照kb为单位表示读写块设备的实际数据的数量。

⑹ linux系统怎么对JAVA应用程序进行性能分析

• 分析CPU占用的方法和手段：

1. top命令：可以查看实时的CPU使用情况。

2. ps -ef命令：可以查看雹凳纤进程以及进程中线程的当前CPU使用情况以及属于当前状态的采样数据。

3. jstack：Java提供的命令。可以查看某个进程的当前线程栈运行情况。根据这个命令的输出可以定位某个进程的所有线程的当前运行状态、运行代码，以及是否死锁等等粗宽。

4. pstack：Linux命令。可以查看某个进程的当前线程栈运行情况

• 分析内存性能的方法和技巧：

1.top命令：可以查看实时的内存使用情况。

2.jmap -histo:live [pid]，然后分析具体的对象源仿数目和占用内存大小，从而定位代码。

jmap -mp:live,format=b,file=xxx.xxx [pid]，然后利用MAT工具分析是否存在内存泄漏等等。