java性能统计代码,java代码性能分析

如何集成Perf4j到Java应用程序中并生成性能数据

在实际部署的生产环境能够以较低的风险及成本实现对业务逻辑级别性能问题的追踪。本文将介绍如何集成 Perf4j 到 Java 应用程序中并生成性能数据。

网站建设哪家好，找创新互联！专注于网页设计、网站建设、微信开发、成都微信小程序、集团企业网站建设等服务项目。为回馈新老客户创新互联还提供了民和免费建站欢迎大家使用！

系统日志是应用程序问题诊断及运行维护的重要工具。Logback、Log4j 是常用于 Java 平台的日志记录 API. 目前大部分产品只是将系统重要参数、状态的变化及异常信息通过日志输出。本文将要介绍的 Perf4j 是一款专

门用于 Java 服务器端代码计时、记录日志和监控结果的开源工具包。Perf4j

对常用日志工具包进行了扩展，能够将得到的原始性能数据进行统计并发布到可定制的输出源，如控制台、日志文件、JMX 等。Perf4j

提供了多种方式与 Java 代码集成，开发和系统维人员能够灵活地将 Perf4j 的 API 嵌入到各种不同架构的应用程序中。

Perf4j 目前依托于开源项目协作平台 Codehaus 进行文档及代码管理，下一步该项目计划迁移到 Github

平台，以便更多的社区及开发人员可以参与到开发及维护中来。Perf4j 欢迎使用者提出新的功能需求并且鼓励将定制或扩展的代码贡献到 Perf4j

源码中。本文中示例代码使用的 Perf4j 版本是 0.9.16，读者需在下载类包或配置 Maven 时留意。

阅读文章之前，您要对 Java 注解、JMX、面向方面编程有一些了解。特别是 JConsole 的使用及 Spring AOP 的配置方式要较为熟悉。

文章首先阐明在何种应用场景下应优先考虑使用 Perf4j。然后是具体讲解 Pef4j 与应用程序的集成方式。最后会介绍如何将收集的数据生成便于分析的可视化图表。

应用场景

在 Java 平台上遇到性能问题时，如 CPU 占用过高、系统响应缓慢，通常的分析方法是使用 JVM

剖析工具在系统瓶颈临界点前一段时间抓取 CPU 占用分布，再对 CPU 占用率最高的几个方法排查。Perf4j

的优势在于能够持续跟踪统计所关注功能代码的执行效率，对于前后两个版本出现较大差异的方法进行深入分析，可以在开发周期中尽早发现问题。Perf4j 还可以用在产品环境中，从运营的早期开始，将其统计的数据做为系统的性能和健康指标长期监测。

首选 Perf4j 的应用场景：

Java 本地代码调用（JNI） 分布式系统、集群部署 面向服务体系结构（SOA） 远程方法调用（RMI）

开发人员必须将本地方法、远程方法及 Web services 的性能问题隔离出来，以防干扰对 Java 应用程序本身的分析。通过日志记录则是最简单的方式；采用分布式架构或集群部署的系统相对复杂，不同的网络环境、基础硬件和操作系统的差异、虚拟主机中资源与配置的差异等造成很难采用统一的工具来监测代码级别的性能指标。而日志记录则可以轻松加入到各种程序中，且是资源与时间成本最低的方式。Perf4j 提供了 CSV 格式的转换工具，开发人员可以借助第三方工具方便地将统计结果汇总分析。

集成到应用程序

下面将分两种方式具体讲述如何利用 Per4j 提供的 API。在实际的项目中，应根据现有的程序框架及监测目的灵活选择。另外，针对 WebSphere 应用服务器的自有日志系统，还必须采取额外的措施来确保 Perf4j 的正常工作。

对代码段计时

Perf4j 中 org.perf4j.StopWatch 是整个 API 中的基础工具。这是一个封装良好的计时器。可以把

StopWatch 嵌入到代码中任何地方。这种方式往往使得复杂的方法得到分解，从而有利于精确定位问题的根源。以下通过清单 1 和清单 2

来介绍其具体用法。

清单 1.StopWacth 基本用法

public static void basicStopWatch() throws

InterruptedException{ // 创建 StopWacth 时开始计时，之后也可以用 stopWatch.start()

重新设定计时开始时间点 StopWatch stopWatch = new StopWatch("TransactionA"); //

执行需要计时的代码 Thread.sleep(2 * 1000L); String result = stopWatch.stop();

System.out.print(result); }

清单 1 中最后输出的结果示例：start[1340442785756] time[1995]

tag[TransactionA]。在构造函数中设定 tag[TransactionA]

用来区分不同的业务逻辑，可以把它看成是性能分析中的事务（Transaction）。

如果需要将多段代码分开统计，可采用 LoggingStopWatch 类的 lap() 方法定义多个事务。

清单 2.LoggingStopWatch 用法

public static void loggingStopWacth()

throws InterruptedException{ LoggingStopWatch stopWatch = new

LoggingStopWatch(); // 设定阈值，小于此阈值的结果将不会被记录下来

stopWatch.setTimeThreshold(1*1000L); Thread.sleep(2 * 1000L); //

停止当前计时，开始新的起始时间点 stopWatch.lap("TransactionB"); Thread.sleep(500L);

stopWatch.stop("TransactionC"); }

清单 2 中使用了 LoggingStopWatch 类，其 stop() 方法只是将执行时间数据通过

System.err.println() 输出。若与 Log4j 框架集成，则需要使用 LoggingStopWatch 的子类

Log4JStopWatch, 目前 Perf4j 还支持 Apache Commons

Logging、java.util.logginLogback，对应使用 CommonsLogStopWatch、

JavaLogStopWatch、Slf4JStopWatch。

如何优化JAVA程序设计和编码，提高JAVA性能

通过使用一些辅助性工具来找到程序中的瓶颈，然后就可以对瓶颈部分的代码进行优化。一般有两种方案：即优化代码或更改设计方法。我们一般会选择后者，因为不去调用以下代码要比调用一些优化的代码更能提高程序的性能。而一个设计良好的程序能够精简代码，从而提高性能。 下面将提供一些在JAVA程序的设计和编码中，为了能够提高JAVA程序的性能，而经常采用的一些方法和技巧。 1．对象的生成和大小的调整。 JAVA程序设计中一个普遍的问题就是没有好好的利用JAVA语言本身提供的函数，从而常常会生成大量的对象（或实例）。由于系统不仅要花时间生成对象，以后可能还需花时间对这些对象进行垃圾回收和处理。因此，生成过多的对象将会给程序的性能带来很大的影响。 例1：关于String,StringBuffer，+和append JAVA语言提供了对于String类型变量的操作。但如果使用不当，会给程序的性能带来影响。如下面的语句： Stringname=newString("HuangWeiFeng");System.out.println(name+"ismyname"); 看似已经很精简了，其实并非如此。为了生成二进制的代码，要进行如下的步骤和操作： (1)生成新的字符串newString（STR_1);(2)复制该字符串; (3)加载字符串常量"HuangWeiFeng"（STR_2);(4)调用字符串的构架器（Constructor）;(5)保存该字符串到数组中（从位置0开始）; (6)从java.io.PrintStream类中得到静态的out变量; (7)生成新的字符串缓冲变量newStringBuffer(STR_BUF_1);(8)复制该字符串缓冲变量; (9)调用字符串缓冲的构架器（Constructor）;(10)保存该字符串缓冲到数组中（从位置1开始）; (11)以STR_1为参数，调用字符串缓冲(StringBuffer)类中的append方法;(12)加载字符串常量"ismyname"(STR_3); (13)以STR_3为参数，调用字符串缓冲(StringBuffer)类中的append方法;(14)对于STR_BUF_1执行toString命令; (15)调用out变量中的println方法，输出结果。 由此可以看出，这两行简单的代码，就生成了STR_1,STR_2,STR_3,STR_4和STR_BUF_1五个对象变量。这些生成的类的实例一般都存放在堆中。堆要对所有类的超类，类的实例进行初始化，同时还要调用类极其每个超类的构架器。而这些操作都是非常消耗系统资源的。因此，对对象的生成进行限制，是完全有必要的。 经修改，上面的代码可以用如下的代码来替换。 StringBuffername=newStringBuffer("HuangWeiFeng"); System.out.println(name.append("ismyname.").toString()); 系统将进行如下的操作： (1)生成新的字符串缓冲变量newStringBuffer(STR_BUF_1);(2)复制该字符串缓冲变量; (3)加载字符串常量"HuangWeiFeng"(STR_1);(4)调用字符串缓冲的构架器（Constructor）;(5)保存该字符串缓冲到数组中（从位置1开始）; (6)从java.io.PrintStream类中得到静态的out变量;(7)加载STR_BUF_1; (8)加载字符串常量"ismyname"(STR_2); (9)以STR_2为参数，调用字符串缓冲(StringBuffer)实例中的append方法;(10)对于STR_BUF_1执行toString命令(STR_3);(11)调用out变量中的println方法，输出结果。 由此可以看出，经过改进后的代码只生成了四个对象变量：STR_1,STR_2,STR_3和STR_BUF_1.你可能觉得少生成一个对象不会对程序的性能有很大的提高。但下面的代码段2的执行速度将是代码段1的2倍。因为代码段1生成了八个对象，而代码段2只生成了四个对象。 代码段1： Stringname=newStringBuffer("HuangWeiFeng");name+="ismy";name+="name"; 代码段2： StringBuffername=newStringBuffer("HuangWeiFeng");name.append("ismy"); name.append("name.").toString(); 因此，充分的利用JAVA提供的库函数来优化程序，对提高JAVA程序的性能时非常重要的.其注意点主要有如下几方面； (1)尽可能的使用静态变量（StaticClassVariables）

如果类中的变量不会随他的实例而变化，就可以定义为静态变量，从而使他所有的实例都共享这个变量。 例： publicclassfoo{ SomeObjectso=newSomeObject();} 就可以定义为：publicclassfoo{ staticSomeObjectso=newSomeObject();} (2)不要对已生成的对象作过多的改变。 对于一些类(如：String类)来讲，宁愿在重新生成一个新的对象实例，而不应该修改已经生成的对象实例。例： Stringname="Huang";name="Wei";name="Feng"; 上述代码生成了三个String类型的对象实例。而前两个马上就需要系统进行垃圾回收处理。如果要对字符串进行连接的操作，性能将得更差，因为系统将不得为此生成更多得临时变量，如上例1所示。 (3)生成对象时，要分配给它合理的空间和大小JAVA中的很多类都有它的默认的空间分配大小。对于StringBuffer类来讲，默认的分配空间大小是16个字符。如果在程序中使用StringBuffer的空间大小不是16个字符，那么就必须进行正确的初始化。 (4)避免生成不太使用或生命周期短的对象或变量。对于这种情况，因该定义一个对象缓冲池。以为管理一个对象缓冲池的开销要比频繁的生成和回收对象的开销小的多。 (5)只在对象作用范围内进行初始化。JAVA允许在代码的任何地方定义和初始化对象。这样，就可以只在对象作用的范围内进行初始化。从而节约系统的开销

请JAVA高手分析下哪种代码更具性能

必须ProductClass pc = productClassService.queryByAlias("product");

i f (pc != null) {

this.setProductClass(pc);

}

查出来的数据就算你不显式的创建对象，他还是会返回一个对象的，他所作的只是一个小小的赋值操作，而你要查两次数据库来完成一个对象的操作，非常不可取，性能也很不好

如何看一段JAVA代码耗了多少内存

使用java自带的性能分析工具jvisualvm , 可以方便的查看内存, 对象, 线程等多种信息.

win+R    然后输入   jvisualvm  回车即可

效果如下图

java里测试添加的命令语句是什么

ava性能调试命令

java性能调试命令_性能测试--十个命令迅速发现性能问题

投机启示录

原创

关注

0点赞·85人阅读

十个命令迅速发现性能问题

uptime

dmesg | tail

vmstat 1

mpstat -P ALL 1

pidstat 1

iostat -xz 1

free -m

sar -n DEV 1

sar -n TCP,ETCP 1

top

1. uptime

$ uptime

23:51:26 up 21:31, 1 user, load average: 30.02, 26.43, 19.02

这是一种用来快速查看系统平均负载的方法，它表明了系统中有多少要运行的任务(进程)。在 Linux 系统中，这些数字包含了需要在 CPU 中运行的进程以及正在等待 I/O(通常是磁盘 I/O)的进程。它仅仅是对系统负载的一个粗略展示，稍微看下即可。你还需要其他工具来进一步了解具体情况。

这三个数字展示的是一分钟、五分钟和十五分钟内系统的负载总量平均值按照指数比例压缩得到的结果。从中我们可以看到系统的负载是如何随时间变化的。比方你在检查一个问题，然后看到 1 分钟对应的值远小于 15 分钟的值，那么可能说明这个问题已经过去了，你没能及时观察到。

在上面这个例子中，系统负载在随着时间增加，因为最近一分钟的负载值超过了 30，而 15 分钟的平均负载则只有 19。这样显著的差距包含了很多含义，比方 CPU 负载。若要进一步确认的话，则要运行 vmstat 或 mpstat 命令。

2. dmesg | tail

$ dmesg | tail

[1880957.563150] perl invoked oom-killer: gfp_mask=0x280da, order=0, oom_score_adj=0

[...]

[1880957.563400] Out of memory: Kill process 18694 (perl) score 246 or sacrifice child

[1880957.563408] Killed process 18694 (perl) total-vm:1972392kB, anon-rss:1953348kB, file-rss:0kB

[2320864.954447] TCP: Possible SYN flooding on port 7001. Dropping request. Check SNMP counters.

这条命令显式了最近的 10 条系统消息，如果它们存在的话。查找能够导致性能问题的错误。上面的例子包含了 oom-killer，以及 TCP 丢弃一个请求。

千万不要错过这一步！dmesg 命令永远值得一试

3. vmstat 1

$ vmstat 1

procs ---------memory---------- ---swap-- -----io---- -system-- ------cpu-----

r b swpd free buff cache si so bi bo in cs us sy id wa st

34 0 0 200889792 73708 591828 0 0 0 5 6 10 96 1 3 0 0

32 0 0 200889920 73708 591860 0 0 0 592 13284 4282 98 1 1 0 0

32 0 0 200890112 73708 591860 0 0 0 0 9501 2154 99 1 0 0 0

32 0 0 200889568 73712 591856 0 0 0 48 11900 2459 99 0 0 0 0

32 0 0 200890208 73712 591860 0 0 0 0 15898 4840 98 1 1 0 0

vmstat(8) 是虚拟内存统计的简称，其是一个常用工具(几十年前为了 BSD 所创建)。其在每行打印一条关键的服务器的统计摘要。

vmstat 命令指定一个参数 1 运行，来打印每一秒的统计摘要。(这个版本的 vmstat)输出的第一行的那些列，显式的是开机以来的平均值，而不是前一秒的值。现在，我们跳过第一行，除非你想要了解并记住每一列。

检查这些列：

r：CPU 中正在运行和等待运行的进程的数量。其提供了一个比平均负载更好的信号来确定 CPU 是否饱和，因为其不包含 I/O。解释：“r”的值大于了 CPU 的数量就表示已经饱和了。

free：以 kb 为单位显式的空闲内存。如果数字位数很多，说明你有足够的空闲内存。“free -m” 命令，是下面的第七个命令，其可以更好的说明空闲内存的状态。

si, so：Swap-ins 和 swap-outs。如果它们不是零，则代表你的内存不足了。

us, sy, id, wa, st：这些都是平均了所有 CPU 的 CPU 分解时间。它们分别是用户时间(user)、系统时间(内核)(system)、空闲(idle)、等待 I/O(wait)、以及占用时间(stolen)(被其他访客，或使用 Xen，访客自己独立的驱动域)。

CPU 分解时间将会通过用户时间加系统时间确认 CPU 是否为忙碌状态。等待 I/O 的时间一直不变则表明了一个磁盘瓶颈；这就是 CPU 的闲置，因为任务都阻塞在等待挂起磁盘 I/O 上了。你可以把等待 I/O 当成是 CPU 闲置的另一种形式，其给出了为什么 CPU 闲置的一个线索。

对于 I/O 处理来说，系统时间是很重要的。一个高于 20% 的平均系统时间，可以值得进一步的探讨：也许内核在处理 I/O 时效率太低了。

在上面的例子中，CPU 时间几乎完全花在了用户级，表明应用程序占用了太多 CPU 时间。而 CPU 的平均使用率也在 90% 以上。这不一定是一个问题；检查一下“r”列中的饱和度。

4. mpstat -P ALL 1

$ mpstat -P ALL 1

Linux 3.13.0-49-generic (titanclusters-xxxxx) 07/14/2015 _x86_64_ (32 CPU)

07:38:49 PM CPU %usr %nice %sys %iowait %irq %soft %steal %guest %gnice %idle

07:38:50 PM all 98.47 0.00 0.75 0.00 0.00 0.00 0.00 0.00 0.00 0.78

07:38:50 PM 0 96.04 0.00 2.97 0.00 0.00 0.00 0.00 0.00 0.00 0.99

07:38:50 PM 1 97.00 0.00 1.00 0.00 0.00 0.00 0.00 0.00 0.00 2.00

07:38:50 PM 2 98.00 0.00 1.00 0.00 0.00 0.00 0.00 0.00 0.00 1.00

07:38:50 PM 3 96.97 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 3.03

[...]

这个命令打印每个 CPU 的 CPU 分解时间，其可用于对一个不均衡的使用情况进行检查。一个单独 CPU 很忙碌则代表了正在运行一个单线程的应用程序。

5. pidstat 1

$ pidstat 1

Linux 3.13.0-49-generic (titanclusters-xxxxx) 07/14/2015 _x86_64_ (32 CPU)

07:41:02 PM UID PID %usr %system %guest %CPU CPU Command

07:41:03 PM 0 9 0.00 0.94 0.00 0.94 1 rcuos/0

07:41:03 PM 0 4214 5.66 5.66 0.00 11.32 15 mesos-slave

07:41:03 PM 0 4354 0.94 0.94 0.00 1.89 8 java

07:41:03 PM 0 6521 1596.23 1.89 0.00 1598.11 27 java

07:41:03 PM 0 6564 1571.70 7.55 0.00 1579.25 28 java

07:41:03 PM 60004 60154 0.94 4.72 0.00 5.66 9 pidstat

07:41:03 PM UID PID %usr %system %guest %CPU CPU Command

07:41:04 PM 0 4214 6.00 2.00 0.00 8.00 15 mesos-slave

07:41:04 PM 0 6521 1590.00 1.00 0.00 1591.00 27 java

07:41:04 PM 0 6564 1573.00 10.00 0.00 1583.00 28 java

07:41:04 PM 108 6718 1.00 0.00 0.00 1.00 0 snmp-pass

07:41:04 PM 60004 60154 1.00 4.00 0.00 5.00 9 pidstat

pidstat 命令有点像 top 命令对每个进程的统计摘要，但循环打印一个滚动的统计摘要来代替 top 的刷屏。其可用于实时查看，同时也可将你所看到的东西(复制粘贴)到你的调查记录中。

上面的例子表明两个 Java 进程正在消耗 CPU。%CPU 这列是所有 CPU 合计的；1591% 表示这个 Java 进程消耗了将近 16 个 CPU。

6. iostat -xz 1

$ iostat -xz 1

Linux 3.13.0-49-generic (titanclusters-xxxxx) 07/14/2015 _x86_64_ (32 CPU)

avg-cpu: %user %nice %system %iowait %steal %idle

73.96 0.00 3.73 0.03 0.06 22.21

Device: rrqm/s wrqm/s r/s w/s rkB/s wkB/s avgrq-sz avgqu-sz await r_await w_await svctm %util

xvda 0.00 0.23 0.21 0.18 4.52 2.08 34.37 0.00 9.98 13.80 5.42 2.44 0.09

xvdb 0.01 0.00 1.02 8.94 127.97 598.53 145.79 0.00 0.43 1.78 0.28 0.25 0.25

xvdc 0.01 0.00 1.02 8.86 127.79 595.94 146.50 0.00 0.45 1.82 0.30 0.27 0.26

dm-0 0.00 0.00 0.69 2.32 10.47 31.69 28.01 0.01 3.23 0.71 3.98 0.13 0.04

dm-1 0.00 0.00 0.00 0.94 0.01 3.78 8.00 0.33 345.84 0.04 346.81 0.01 0.00

dm-2 0.00 0.00 0.09 0.07 1.35 0.36 22.50 0.00 2.55 0.23 5.62 1.78 0.03

[...]

这是用于查看块设备(磁盘)情况的一个很棒的工具，无论是对工作负载还是性能表现来说。查看个列：

r/s, w/s, rkB/s, wkB/s：这些分别代表该设备每秒的读次数、写次数、读取 kb 数，和写入 kb 数。这些用于描述工作负载。性能问题可能仅仅是由于施加了过大的负载。

await：以毫秒为单位的 I/O 平均消耗时间。这是应用程序消耗的实际时间，因为它包括了排队时间和处理时间。比预期更大的平均时间可能意味着设备的饱和，或设备出了问题。

avgqu-sz：向设备发出的请求的平均数量。值大于 1 说明已经饱和了(虽说设备可以并行处理请求，尤其是由多个磁盘组成的虚拟设备。)

%util：设备利用率。这个值是一个显示出该设备在工作时每秒处于忙碌状态的百分比。若值大于 60％，通常表明性能不佳(可以从 await 中看出)，虽然它取决于设备本身。值接近 100% 通常意味着已饱和。

如果该存储设备是一个面向很多后端磁盘的逻辑磁盘设备，则 100% 利用率可能只是意味着当前正在处理某些 I/O 占用，然而，后端磁盘可能远未饱和，并且可能能够处理更多的工作。

请记住，磁盘 I/O 性能较差不一定是程序的问题。许多技术通常是异步 I/O，使应用程序不会被阻塞并遭受延迟(例如，预读，以及写缓冲)。

7. free -m

$ free -m

total used free shared buffers cached

Mem: 245998 24545 221453 83 59 541

-/+ buffers/cache: 23944 222053

Swap: 0 0 0

右边的两列显式：

buffers：用于块设备 I/O 的缓冲区缓存。

cached：用于文件系统的页面缓存。

我们只是想要检查这些不接近零的大小，其可能会导致更高磁盘 I/O(使用 iostat 确认)，和更糟糕的性能。上面的例子看起来还不错，每一列均有很多 M 个大小。

比起第一行，-/+ buffers/cache 提供的内存使用量会更加准确些。Linux 会把暂时用不上的内存用作缓存，一旦应用需要的时候就立刻重新分配给它。所以部分被用作缓存的内存其实也算是空闲的内存。为了解释这一点， 甚至有人专门建了个网站： linuxatemyram。

如果你在 Linux 上安装了 ZFS，这一点会变得更加困惑，因为 ZFS 它自己的文件系统缓存不算入free -m。有时候发现系统已经没有多少空闲内存可用了，其实内存却都待在 ZFS 的缓存里。

8. sar -n DEV 1

$ sar -n DEV 1

Linux 3.13.0-49-generic (titanclusters-xxxxx) 07/14/2015 _x86_64_ (32 CPU)

12:16:48 AM IFACE rxpck/s txpck/s rxkB/s txkB/s rxcmp/s txcmp/s rxmcst/s %ifutil

12:16:49 AM eth0 18763.00 5032.00 20686.42 478.30 0.00 0.00 0.00 0.00

12:16:49 AM lo 14.00 14.00 1.36 1.36 0.00 0.00 0.00 0.00

12:16:49 AM docker0 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00

12:16:49 AM IFACE rxpck/s txpck/s rxkB/s txkB/s rxcmp/s txcmp/s rxmcst/s %ifutil

12:16:50 AM eth0 19763.00 5101.00 21999.10 482.56 0.00 0.00 0.00 0.00

12:16:50 AM lo 20.00 20.00 3.25 3.25 0.00 0.00 0.00 0.00

12:16:50 AM docker0 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00

这个工具可以被用来检查网络接口的吞吐量：rxkB/s 和 txkB/s，以及是否达到限额。上面的例子中，eth0 接收的流量达到 22Mbytes/s，也即 176Mbits/sec(限额是 1Gbit/sec)

我们用的版本中还提供了 %ifutil 作为设备使用率(接收和发送的最大值)的指标。我们也可以用 Brendan 的 nicstat 工具计量这个值。一如 nicstat，sar 显示的这个值是很难精确取得的，在这个例子里面，它就没在正常的工作(0.00)。

9. sar -n TCP,ETCP 1

$ sar -n TCP,ETCP 1

Linux 3.13.0-49-generic (titanclusters-xxxxx) 07/14/2015 _x86_64_ (32 CPU)

12:17:19 AM active/s passive/s iseg/s oseg/s

12:17:20 AM 1.00 0.00 10233.00 18846.00

12:17:19 AM atmptf/s estres/s retrans/s isegerr/s orsts/s

12:17:20 AM 0.00 0.00 0.00 0.00 0.00

12:17:20 AM active/s passive/s iseg/s oseg/s

12:17:21 AM 1.00 0.00 8359.00 6039.00

12:17:20 AM atmptf/s estres/s retrans/s isegerr/s orsts/s

12:17:21 AM 0.00 0.00 0.00 0.00 0.00

这是一些关键的 TCP 指标的汇总视图。这些包括：

active/s：每秒本地发起 TCP 连接数(例如，通过 connect())。

passive/s：每秒远程发起的 TCP 连接数(例如，通过 accept())。

retrans/s：每秒重传 TCP 次数。

active 和 passive 的连接数往往对于描述一个粗略衡量服务器负载是非常有用的：新接受的连接数(passive)，下行连接数(active)。可以理解为 active 连接是对外的，而 passive 连接是对内的，虽然严格来说并不完全正确(例如，一个 localhost 到 localhost 的连接)。

重传是出现一个网络和服务器问题的一个征兆。其可能是由于一个不可靠的网络(例如，公网)造成的，或许也有可能是由于服务器过载并丢包。上面的例子显示了每秒只有一个新的 TCP 连接。

10. top

$ top

top - 00:15:40 up 21:56, 1 user, load average: 31.09, 29.87, 29.92

Tasks: 871 total, 1 running, 868 sleeping, 0 stopped, 2 zombie

%Cpu(s): 96.8 us, 0.4 sy, 0.0 ni, 2.7 id, 0.1 wa, 0.0 hi, 0.0 si, 0.0 st

KiB Mem: 25190241+total, 24921688 used, 22698073+free, 60448 buffers

KiB Swap: 0 total, 0 used, 0 free. 554208 cached Mem

PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND

20248 root 20 0 0.227t 0.012t 18748 S 3090 5.2 29812:58 java

4213 root 20 0 2722544 64640 44232 S 23.5 0.0 233:35.37 mesos-slave

66128 titancl+ 20 0 24344 2332 1172 R 1.0 0.0 0:00.07 top

5235 root 20 0 38.227g 547004 49996 S 0.7 0.2 2:02.74 java

4299 root 20 0 20.015g 2.682g 16836 S 0.3 1.1 33:14.42 java

1 root 20 0 33620 2920 1496 S 0.0 0.0 0:03.82 init

2 root 20 0 0 0 0 S 0.0 0.0 0:00.02 kthreadd

3 root 20 0 0 0 0 S 0.0 0.0 0:05.35 ksoftirqd/0

5 root 0 -20 0 0 0 S 0.0 0.0 0:00.00 kworker/0:0H

6 root 20 0 0 0 0 S 0.0 0.0 0:06.94 kworker/u256:0

8 root 20 0 0 0 0 S 0.0 0.0 2:38.05 rcu_sched

top 命令包含了很多我们之前已经检查过的指标。可以方便的执行它来查看相比于之前的命令输出的结果有很大不同，这表明负载是可变的。

top 的一个缺点是，很难看到数据随时间变动的趋势。vmstat 和 pidstat 提供的滚动输出会更清楚一些。如果你不以足够快的速度暂停输出(Ctrl-S 暂停，Ctrl-Q 继续)，一些间歇性问题的线索也可能由于被清屏而丢失。