1、对于新产品和维护版的老产品设计的用例应该注意些什么呢？

专家分析：新项目和维护项目从本质上看没有区别，维护产品，无非就是新增功能和缺陷修复两大类，和新项目相比，唯一需要注意的就是新增\修复的功能是否对其他部分有影响，这里就涉及到一个回归策略的问题——老功能要测多少。一般来说，需要和开发讨论确定受影响的范围，然后制定测试范围。当然最理想的情况就是整个系统全测，因为一旦系统复杂了，没有哪个开发能说清楚影响范围。

专家建议：“新产品”在了解需求的情况下，先设计测试用例，再测试，避免发生遗漏。“老产品”维护，若改变了需求，依然先设计（修改）测试用例，再测试，避免发生遗漏；若项目紧急可先测试，再修改测试用例。

2、做手机应用，流程不像是WEB的那样清楚，感觉应用除了主功能还有很多零碎的小功能。设计用例时容易遗漏。需要怎么样做更好呢。

专家分析：手机应用端测试是最适合应用场景分析方法的，场景设计需要经验的累积，不是简单学习知识就行的，建议使用思维导图，做个有心人，把平时测试的经验都记录下来，形成最适合的场景设计方法。

专家建议：手机测试考虑有各种手机的牌子、型号（还有现在的太阳能手机情况下）、停机、没电、内存容量等等。

3、怎样用简短的测试用例达到高覆盖率的测试？并且写用例时候采用非常清楚的描述好还是采用测试点描述让测试执行人自行发散测试思维？

专家分析：我们一般不做这样的考虑，用例需要有合适的颗粒度，并不是说一条用例覆盖的越多越好，如果一条用例如果颗粒度很大，覆盖了很多测试点，当前看起来很好，但过几天你还看得懂这条用例吗？而往往测试用例数量往往大大超过测试数量。

用例存在的目的，一个是沟通交流，让其他人能看懂你的测试思路，帮你评审，另一方面也是经验的累积，最终形成用例库，所以一定要体现用例设计思路。自行发散测试思维是要不得的，这样几年做下来，一点积累都没有，久而久之在测试界会被淘汰。

4、如何能把黑盒测试做精，做好，对于一些对测试不是特别重视的公司又如何开展较为完善的测试工作？然后黑盒测试必须要向白盒与性能走吗？

专家分析：可以向公司商议有关测试的重要性。若公司不同意，也尽量采用专业些的测试方法（工具）及bug管理等，便于引起公司的重视和认可。测试人员也要适应这种情况。首先就是了解公司对质量的诉求，比如现阶段对性能没什么要求，那就集中于将功能测试做好，同时要考虑提升测试的效率，比如自动化测试。在需求确认环节，尽量参与，比如针对每个需求写验收标准，然后再和开发一起进行需求讨论，把测试工作融入到整个开发过程中，那么测试的重要性就会和开发并列到一起了。

黑盒测试很难精通，比白盒难得多，白盒测试是测试中最简单最没有技术难度的一环。哪个价值大，应该清楚了吧。如果没有一定的代码基础，不建议你去做白盒。测试最有发展的还是黑盒测试。黑盒测试需要学习的东西很多，比如需求环节的测试需求分析，场景分析，设计阶段的用例设计方法，实现阶段的测试自动化，DFX测试技术等等。性能测试是很重要的发展通道，其实性能测试也属于黑盒，性能分析和优化才有点偏白盒。

在国内，功能占用的比例确实很高，但现在大部分公司的入职要求是要会点性能工具或者自动化工具的。

5、针对做嵌入式开发的公司，作为测试人员，主要需要学习哪些内容？数据库，自动化测试是否能用到？

专家分析：嵌入式来说，数据库可能不太会涉及，不过自动化依然很重要。嵌入式软件可以看做一个黑盒，测试最大的难度在于搭建测试环境，因为你要为这个黑盒搭建好输入、输出环境。一般来说，必须掌握最底层的一些知识，像单片机原理啊，认识芯片那些引脚啊，数转模啊，还有一些基本的汇编。从我了解的嵌入式软件测试来看，它是最容易实现自动化测试的。

6、黑盒测试可以做多久，应该怎样规划黑盒测试的职业生涯？

专家分析：黑盒测试来说其实研究透了，你也非常厉害，像自动化测试、性能测试它们有时候还是需要有些功能测试的功底的。

7、怎样写好黑盒测试用例，在不出现冗余的情况下达到覆盖面广？

专家分析：为何会有等价类划分、边界值、判定表等等工程方法？就是为了帮助大家写好用例的。

出现冗余举个最简单的例子：0-100之间取值（整数），可取0、55、100；若再取-1、1、99、101就是冗余。

8、测试用例是否一定要在测试开始之前写？ 每次写测试用例都要严格按照那些测试策略和方法吗？

专家分析：首先要知道写测试用例的目的是什么？测试每一阶段写的东西都有它的工程目的，放到特定的公司环境中，我们不应该想哪一步可以不做，而是想在这种情况下用哪种做法更有效。比如测试策略，它的主要目的是沟通，它描述了你会怎么去测，这是你用来和开发以及其他相关人沟通的，如果是我，我就会把它简化成一张EXCEL表，罗列测试点和测试方法，后面的测试用例也会集中在这张表上，然后再补全。这种建议对这个项目已经非常了解或者经验比较足在项目紧的情况下这么做。

9、有三年黑盒测试经验，但是没有开发经验，看不懂代码，是否只能一直做黑盒？ 黑盒测试有什么样的发展前景？如果要向白盒，自动化和性能测试发展该如何入手？

专家分析：看不懂代码可以慢慢学，其实并不难，看你自己是否有这个决心下这个功夫了。黑盒测试来说其实研究透了，你也非常厉害，像自动化测试、性能测试它们有时候还是需要有些功能测试的功底的。作为研发体系的一员，代码功底是必须的，否则没有发展通路。测试和开发同属于研发体系，研发体系的通用语言就是编程语言，就像你到国外工作，其他人都说英语，就你只会说中文，虽然别人也能听懂一二，但是总觉得你是个异类。想要做好测试，不逊色于任何开发人员的代码功底是必要的。

白盒：可以到相关测试论坛查阅资料。

自动化：可以看看风过无息、赵旭斌、陈能技三位牛人的书、博客、视频。群里也可以请教下高手，比如热心肠的超级奶爸等。

性能：可以看看卖烧烤的鱼、云层、于涌两位牛人的书、博客。群里也可以请教下高手，比如热心肠的超级奶爸等。

白盒、自动化、性能都是需要些开发基础的。

10、对于较复杂流程的测试用例如何进行测试用例编写？

专家分析：复杂的测试流程建议先画个流程图，再根据流程图编写测试用例。

　软件测试过程中，我们应注意和遵循一系列的具体原则，在ISTQB 软件测试基础认证大纲上，列出了7 项原则，但其中最后一项原则“不存在缺陷（就是有用系统）”的谬论不能算是一项合格的原则，所以可以认可的原则是6 项。除此之外，在这里还列出作者认为比较重要的7 项原则，合起来共13 项原则。

　　1、ISTQB 的6 项原则

　　1）原则1——测试显示缺陷的存在，但不能证明系统不存在缺陷。测试可以减少软件中存在未被发现缺陷的可能性，但即使测试没有发现任何缺陷，也不能证明软件或系统是完全正确的。

　　2）原则2——穷尽测试是不可能的。由于有太多的输入组合、有太多的路径，而且时间是有限的，无法做到完全的测试（100%测试覆盖率）。通过运用风险分析和不同系统功能的测试优先级，来确定测试的关注点，从而替代穷尽测试。

　　3）原则3——测试尽早介入。软件项目一启动，软件测试就应开始，也就是从项目启动的第一天开始，测试人员就应参与项目的各种活动和开展对应的测试活动。测试工作进行得越早，软件开发的劣质成本就越低，并能更好地保证软件质量。例如，在代码完成之前，可以进行各种静态测试，主导或积极参与需求文档、产品规格说明书等的评审，将问题消灭在萌芽阶段。

　　4）原则4——缺陷集群性。版本发布前进行测试所发现的大部分缺陷和软件运行失效是由于少数软件模块引起的。一段程序中发现的错误数越多，意味着这段程序的质量越不好。错误集中发生的现象，可能和程序员的编程水平、经验和习惯有很大的关系，也可能是程序员在写代码时情绪不够好或不在状态等。如果在同样的测试效率和测试能力的条件下，缺陷发现得越多，漏掉的缺陷就越多。这也就是著名的Myers 反直觉原则：在测试中发现缺陷多的地方，会有更多的缺陷没被发现。假定测试能力不变，通过测试会发现产品中90％的缺陷。如果在模块A 发现了180 个缺陷，在模块B 发现了45 个缺陷，意味着模块A 还有20 个缺陷没被发现，而模块B 只有5个缺陷未被发现。所以，对发现错误较多的程序段，应进行更深入的测试。

　　5）原则5——杀虫剂悖论。采用同样的测试用例多次重复进行测试，最后将不再能发现新的缺陷。为了克服这种“杀虫剂悖论”，测试用例需要进行定期评审和修改，同时需要不断地增加新的不同的测试用例来测试软件或系统的不同部分，从而发现潜在的更多的缺陷。

　　6）原则6——测试活动依赖于测试背景。针对不同的测试背景，进行的测试活动也是不同的。比如，对要求安全放在第一位的软件进行测试，与对一般的电子商务软件的测试是不一样的。

　　2、其他重要的7 项原则

　　1）持续地测试、持续地反馈。软件测试贯穿着整个软件开发生命周期，随时发现需求、设计或代码中问题，及时将发现的问题反馈给用户、产品设计人员、开发人员等，主动、积极地交流，持续提高软件产品质量，这在敏捷测试中更为重要。

　　2）80/20 原则。在有限的时间和资源下进行测试，找出软件中所有的错误和缺陷是不可能的，因此测试总是存在风险的。测试的一个重要目标是尽量减少风险，抓住重点进行更多的测试。根据80/20 原则，即帕累托法则（Pareto Principle），用户80％的时间在使用软件产品中20％的功能。“重点测试”就是测试这20％的功能，而其他80％的功能属于优先级低的测试范围，占测试20%的资源。

　　3）建立清晰的阶段性目标。饭要一口一口地吃，不能一口就吃成胖子。测试的目标也要逐步达到，不可能在某一瞬间就达到。根据软件开发生命周期的不同阶段性任务，我们要决定相应的测试目标和任务。如在需求分析阶段，要参与需求评审以全面理解用户需求、发现需求的问题；在功能测试执行阶段，测试人员不仅要对新功能进行测试，而且要有效地完成回归测试。

　　4）测试独立性。测试在一定程度上带有“挑剔性”，心理状态是测试自己程序的障碍。同时，对于需求规格说明的错误理解也很难在程序员本人进行测试时被发现。程序员应避免测试自己的程序，为达到最佳的效果，应由独立的测试小组、第三方来完成测试。

　　5）确保可测试性。事先定义好产品的质量特性指标，测试时才能有据可依。有了具体的指标要求，才能依据测试的结果对产品的质量进行客观的分析和评估，才能使软件产品具有良好的可测试性。例如，进行性能测试前，产品规格说明书就已经清楚定义了各项性能指标。同样，测试用例应确定预期输出结果，如果无法确定所期望的测试结果，则无法进行正确与否的校验。

　　6）计划是一个过程。虽然通过文档来描述软件测试计划，并最后归档，但计划是一个过程，是指导各项软件测试活动的持续过程。在项目开始时很难将所有的测试点、测试风险等都了解清楚，随着时间推移，通过需求和设计的评审和探索式测试，对产品的理解越来越深，对测试的需求和风险越来越了解，可以进一步细化、不断丰富测试计划。其次，计划赶不上变化，软件产品的需求常会发生变化，测试计划不得不因此做出调整。所以，测试计划是适应实际测试状态不断变化而进行调整的一个过程。

　　7）一切从用户角度出发。在所有测试活动的过程中，测试人员都应该从客户的需求出发，想用户所想。正如我们所知，软件测试的目标就是验证产品开发的一致性和确认产品是否满足客户的需求，与之对应的任何产品质量特性都应追溯到用户需求。测试人员要始终站在用户的角度去思考、分析产品特性，多问问类似下面这样的问题：

　　这个新功能对客户的价值是什么？

　　客户会如何使用这个新功能？

　　客户在使用这个功能时，会进行什么样的操作？

　　按目前设计，用户觉得方便、舒服吗？

　　如果发现缺陷，去判断软件缺陷对用户的影响程度，系统中最严重的错误是那些导致程序无法满足用户需求的缺陷。软件测试，就是揭示软件中所存在的逻辑错误、低性能、不一致性等各种影响客户满意度的问题，一旦修正这些错误就能更好地满足用户需求和期望。

敲个命令都没反应。 TOP命令显示的是一些Oracle session占用CPU资源太多。 杯具的是在服务器上连sqlplus 都进不去了，命令都没反应。 只好把服务器重启了。 重启之后再看了一下，是一个同事测试的SQL 有问题。 一条SQL 占用CPU 就30%。

       在研究这个问题的时候，也google到了一些Linux 下的监控事项，整理如下。 

一.  Linux 性能监控的概述

       系统由若干子系统构成，通常修改一个子系统有可能影响到另外一个子系统，甚至会导致整个系统不稳定、崩溃。所以说优化、监测、测试通常是连在一起的，而且是一个循环而且长期的过程，通常监测的子系统有以下这些：

（1）.      CPU

（2）.      Memory

（3）.      IO

（4）.      Network

       这些子系统互相依赖，了解这些子系统的特性，监测这些子系统的性能参数以及及时发现可能会出现的瓶颈对系统优化很有帮助。

1.1  应用类型

       不同的系统用途也不同，要找到性能瓶颈需要知道系统跑的是什么应用、有些什么特点，比如 web server 对系统的要求肯定和 file server 不一样，所以分清不同系统的应用类型很重要，通常应用可以分为两种类型：

       （1）IO 相关，IO 相关的应用通常用来处理大量数据，需要大量内存和存储，频繁 IO 操作读写数据，而对 CPU 的要求则较少，大部分时候 CPU 都在等待硬盘，比如，数据库服务器、文件服务器等。

       （2）CPU 相关，CPU 相关的应用需要使用大量 CPU，比如高并发的 web/mail 服务器、图像/视频处理、科学计算等都可被视作 CPU 相关的应用。

看看实际中的例子，第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

 0  4    140 1962724 335516 4852308  0    0   388 65024 1442  563  0  2 47 52  0

 0  4    140 1961816 335516 4853868  0    0   768 65536 1434  522  0  1 50 48  0

 0  4    140 1960788 335516 4855300  0    0   768 48640 1412  573  0  1 50 49  0

 0  4    140 1958528 335516 4857280  0    0  1024 65536 1415  521  0  1 41 57  0

 0  5    140 1957488 335516 4858884  0    0   768 81412 1504  609  0  2 50 49  0

第2个是 CPU 做大量计算时表现出来的特征：

$ 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

 4  0    140 3625096 334256 3266584  0    0     0    16 1054  470 100 0  0  0  0

 4  0    140 3625220 334264 3266576  0    0     0    12 1037  448 100 0  0  0  0

 4  0    140 3624468 334264 3266580  0    0     0   148 1160  632 100 0  0  0  0

 4  0    140 3624468 334264 3266580  0    0     0     0 1078  527 100 0  0  0  0

 4  0    140 3624712 334264 3266580  0    0     0    80 1053  501 100 0  0  0  0

       上面两个例子最明显的差别就是 id 一栏，代表 CPU 的空闲率，拷贝文件时候 id 维持在 50％ 左右，CPU 大量计算的时候 id 基本为 0。

1.2  底线

       事先建立一个底线，如果性能监测得到的统计数据跨过这条线，我们就可以说这个系统性能差，如果数据能保持在线内我们就说性能好。建立这样底线需要知道一些理论、额外的负载测试和系统管理员多年的经验。如果自己没有多年的经验，有一个简单划底线的办法就是：把这个底线建立在自己对系统的期望上。自己期望这个系统有个什么样的性能，这是一个底线，如果没有达到这个要求就是性能差。

1.3  监测工具

工具	简单介绍
top	查看进程活动状态以及一些系统状况
vmstat	查看系统状态、硬件和系统信息等
iostat	查看CPU 负载，硬盘状况
sar	综合工具，查看系统状况
mpstat	查看多处理器状况
netstat	查看网络状况
iptraf	实时网络状况监测
tcpdump	抓取网络数据包，详细分析
mpstat	查看多处理器状况
tcptrace	数据包分析工具
netperf	网络带宽工具
dstat	综合工具，综合了 vmstat, iostat, ifstat, netstat 等多个信息

二. CPU

       CPU 的占用主要取决于什么样的资源正在 CPU 上面运行，比如拷贝一个文件通常占用较少 CPU，因为大部分工作是由 DMA（Direct Memory Access）完成，只是在完成拷贝以后给一个中断让 CPU 知道拷贝已经完成；科学计算通常占用较多的 CPU，大部分计算工作都需要在 CPU 上完成，内存、硬盘等子系统只做暂时的数据存储工作。要想监测和理解 CPU 的性能需要知道一些的操作系统的基本知识，比如：中断、进程调度、进程上下文切换、可运行队列等。    这里用个例子来简单介绍一下这些概念和他们的关系，CPU每时每刻都有工作在做（进程、线程）并且自己有一张工作清单（可运行队列），由老板（进程调度）来决定他该干什么，他需要和老板沟通以便得到老板的想法并及时调整自己的工作（上下文切换），部分工作做完以后还需要及时向老板汇报（中断），所以打工仔（CPU）除了做自己该做的工作以外，还有大量时间和精力花在沟通和汇报上。

       CPU 也是一种硬件资源，和任何其他硬件设备一样也需要驱动和管理程序才能使用，我们可以把内核的进程调度看作是 CPU 的管理程序，用来管理和分配 CPU 资源，合理安排进程抢占 CPU，并决定哪个进程该使用 CPU、哪个进程该等待。操作系统内核里的进程调度主要用来调度两类资源：进程（或线程）和中断，进程调度给不同的资源分配了不同的优先级，优先级最高的是硬件中断，其次是内核（系统）进程，最后是用户进程。每个 CPU 都维护着一个可运行队列，用来存放那些可运行的线程。线程要么在睡眠状态（blocked 正在等待 IO）要么在可运行状态，如果 CPU 当前负载太高而新的请求不断，就会出现进程调度暂时应付不过来的情况，这个时候就不得不把线程暂时放到可运行队列里。

可以从以下几个方面监控CPU的信息：

（1）中断；

（2）上下文切换；

（3）可运行队列；

（4）CPU 利用率。

2.1 底线

通常我们期望我们的系统能到达以下目标：

       （1）CPU 利用率，如果 CPU 有 100％ 利用率，那么应该到达这样一个平衡：65％－70％ User Time，30％－35％ System Time，0％－5％ Idle Time；

       （2）上下文切换，上下文切换应该和 CPU 利用率联系起来看，如果能保持上面的 CPU 利用率平衡，大量的上下文切换是可以接受的；

       （3）可运行队列，每个可运行队列不应该有超过1－3个线程（每处理器），比如：双处理器系统的可运行队列里不应该超过6个线程。

2.2  vmstat

       vmstat 是个查看系统整体性能的小工具，小巧、即使在很 heavy 的情况下也运行良好，并且可以用时间间隔采集得到连续的性能数据。

$ 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

 2  1    140 2787980 336304 3531996  0    0     0   128 1166 5033  3  3 70 25  0

 0  1    140 2788296 336304 3531996  0    0     0     0 1194 5605  3  3 69 25  0

 0  1    140 2788436 336304 3531996  0    0     0     0 1249 8036  5  4 67 25  0

 0  1    140 2782688 336304 3531996  0    0     0     0 1333 7792  6  6 64 25  0

 3  1    140 2779292 336304 3531992  0    0     0    28 1323 7087  4  5 67 25  0

参数介绍：

（1）.      r，可运行队列的线程数，这些线程都是可运行状态，只不过 CPU 暂时不可用；

（2）.      b，被 blocked 的进程数，正在等待 IO 请求；

（3）.      in，被处理过的中断数

（4）.      cs，系统上正在做上下文切换的数目

（5）.      us，用户占用 CPU 的百分比

（6）.      sys，内核和中断占用 CPU 的百分比

（7）.      wa，所有可运行的线程被 blocked 以后都在等待 IO，这时候 CPU 空闲的百分比

（8）.      id，CPU 完全空闲的百分比

举两个现实中的例子来实际分析一下：

$ 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

 4  0    140 2915476 341288 3951700  0    0     0     0 1057  523 19 81  0  0  0

 4  0    140 2915724 341296 3951700  0    0     0     0 1048  546 19 81  0  0  0

 4  0    140 2915848 341296 3951700  0    0     0     0 1044  514 18 82  0  0  0

 4  0    140 2915848 341296 3951700  0    0     0    24 1044  564 20 80  0  0  0

 4  0    140 2915848 341296 3951700  0    0     0     0 1060  546 18 82  0  0  0

从上面的数据可以看出几点：

（1）.      interrupts（in）非常高，context switch（cs）比较低，说明这个 CPU 一直在不停的请求资源；

（2）.      user time（us）一直保持在 80％ 以上，而且上下文切换较低（cs），说明某个进程可能一直霸占着 CPU；

（3）.      run queue（r）刚好在4个。

$ 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

14  0    140 2904316 341912 3952308  0    0     0   460 1106 9593 36 64  1  0  0

17  0    140 2903492 341912 3951780  0    0     0     0 1037 9614 35 65  1  0  0

20  0    140 2902016 341912 3952000  0    0     0     0 1046 9739 35 64  1  0  0

17  0    140 2903904 341912 3951888  0    0     0    76 1044 9879 37 63  0  0  0

16  0    140 2904580 341912 3952108  0    0     0     0 1055 9808 34 65  1  0  0

从上面的数据可以看出几点：

（1）.      context switch（cs）比 interrupts（in）要高得多，说明内核不得不来回切换进程；

（2）.      进一步观察发现 system time（sy）很高而 user time（us）很低，而且加上高频度的上下文切换（cs），说明正在运行的应用程序调用了大量的系统调用（system call）；

（3）.      run queue（r）在14个线程以上，按照这个测试机器的硬件配置（四核），应该保持在12个以内。

我上午CPU 100%时的信息：

top - 11:49:08 up 50 days, 22:25,  6 users,  load average: 59.79, 59.98, 60.50

Tasks: 200 total,  61 running, 139 sleeping,   0 stopped,   0 zombie

Cpu0  : 26.5%us, 73.5%sy,  0.0%ni,  0.0%id,  0.0%wa,  0.0%hi,  0.0%si,  0.0%st

Cpu1  : 25.0%us, 75.0%sy,  0.0%ni,  0.0%id,  0.0%wa,  0.0%hi,  0.0%si,  0.0%st

Mem:   1939780k total,  1744412k used,   195368k free,    95704k buffers

Swap:  4401800k total,   662836k used,  3738964k free,   811124k cached

[root@localhost ~]# vmstat 2 10

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

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

58  1 662836 195988  95428 810740    0    0     4   106    4    1 23  4 72  1  0

59  1 662836 195988  95448 810732    0    0     0   128  235  221 28 72  0  0  0

59  1 662836 195988  95448 810768    0    0     0     0  216  209 28 72  0  0  0

2.3  mpstat

       mpstat 和 vmstat 类似，不同的是 mpstat 可以输出多个处理器的数据。

注意：需要安装sysstat 包后才有这个命令，可以使用yum安装：

       #yum install sysstat

       sysstat 包含iostat、mpstat、sar、命令。

[root@localhost gmail]# export LANG=en_US

[root@localhost gmail]# mpstat -P ALL    

Linux 2.6.18-8.el5xen (localhost.localdomain)   02/21/2011

10:20:16 PM  CPU   %user   %nice    %sys %iowait    %irq   %soft  %steal   %idle    intr/s

10:20:16 PM  all   11.49    0.00    2.58    1.04    0.01    0.13    0.01   84.74    314.61

10:20:16 PM    0   15.73    0.00    2.56    0.55    0.02    0.23    0.01   80.89    241.09

10:20:16 PM    1    7.25    0.00    2.60    1.53    0.00    0.02    0.01   88.59     73.52

[root@localhost gmail]# mpstat -P ALL 1

Linux 2.6.18-8.el5xen (localhost.localdomain)   02/21/2011

10:20:18 PM  CPU   %user   %nice    %sys %iowait    %irq   %soft  %steal   %idle    intr/s

10:20:19 PM  all    0.00    0.00    0.00    0.00    0.00    0.00    0.00  100.00    136.63

10:20:19 PM    0    0.00    0.00    0.00    0.00    0.00    0.00    0.00  100.00     86.14

10:20:19 PM    1    0.00    0.00    0.00    0.00    0.00    0.00    0.00  100.00     50.50

10:20:19 PM  CPU   %user   %nice    %sys %iowait    %irq   %soft  %steal   %idle    intr/s

10:20:20 PM  all    0.00    0.00    0.00    0.47    0.00    0.00    0.00   99.53    105.00

10:20:20 PM    0    0.00    0.00    0.00    0.00    0.00    0.00    0.00  100.00     79.00

10:20:20 PM    1    0.00    0.00    0.00    0.90    0.00    0.00    0.00   99.10     26.00

2.4  ps

查看某个程序、进程占用了多少 CPU 资源:

[root@localhost gmail]#  while :; do ps -eo pid,ni,pri,pcpu,psr,comm | grep 'oracle'; sleep 1; done

  PID  NI PRI %CPU PSR COMMAND

 3668   0  24  0.0   0 oracle

 3670   0  21  0.0   0 oracle

 3672   0  24  0.0   0 oracle

 3674   0  23  0.0   0 oracle

 3676   0  24  0.0   1 oracle

 3678   0  23  0.0   0 oracle

 3680   0  21  0.0   1 oracle

 3682   0  24  0.0   1 oracle

 3684   0  24  0.0   0 oracle

 3686   0  21  0.0   0 oracle

三. Memory

       这里的讲到的 “内存” 包括物理内存和虚拟内存，虚拟内存（Virtual Memory）把计算机的内存空间扩展到硬盘，物理内存（RAM）和硬盘的一部分空间（SWAP）组合在一起作为虚拟内存为计算机提供了一个连贯的虚拟内存空间，好处是我们拥有的内存 ”变多了“，可以运行更多、更大的程序，坏处是把部分硬盘当内存用整体性能受到影响，硬盘读写速度要比内存慢几个数量级，并且 RAM 和 SWAP之间的交换增加了系统的负担。

       在操作系统里，虚拟内存被分成页，在 x86 系统上每个页大小是 4KB。 Linux 内核读写虚拟内存是以 “页” 为单位操作的，把内存转移到硬盘交换空间（SWAP）和从交换空间读取到内存的时候都是按页来读写的。内存和 SWAP 的这种交换过程称为页面交换（Paging），值得注意的是 paging 和 swapping 是两个完全不同的概念，国内很多参考书把这两个概念混为一谈，swapping 也翻译成交换，在操作系统里是指把某程序完全交换到硬盘以腾出内存给新程序使用，和 paging 只交换程序的部分（页面）是两个不同的概念。纯粹的 swapping 在现代操作系统中已经很难看到了，因为把整个程序交换到硬盘的办法既耗时又费力而且没必要，现代操作系统基本都是 paging 或者 paging/swapping 混合，swapping 最初是在 Unix system V 上实现的。

在这里只介绍和性能监测有关的两个内核进程：kswapd 和 pdflush。

       （1）kswapd daemon 用来检查 pages_high 和 pages_low，如果可用内存少于 pages_low，kswapd 就开始扫描并试图释放 32个页面，并且重复扫描释放的过程直到可用内存大于 pages_high 为止。

       扫描的时候检查3件事：

       1）如果页面没有修改，把页放到可用内存列表里；

       2）如果页面被文件系统修改，把页面内容写到磁盘上；

       3）如果页面被修改了，但不是被文件系统修改的，把页面写到交换空间。

       （2）pdflush daemon 用来同步文件相关的内存页面，把内存页面及时同步到硬盘上。比如打开一个文件，文件被导入到内存里，对文件做了修改后并保存后，内核并不马上保存文件到硬盘，由 pdflush 决定什么时候把相应页面写入硬盘，这由一个内核参数 vm.dirty_background_ratio 来控制，比如下面的参数显示脏页面（dirty pages）达到所有内存页面10％的时候开始写入硬盘。

# /sbin/sysctl -n vm.dirty_background_ratio

10

3.1  vmstat

# 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

 0  3 252696   2432    268   7148 3604 2368  3608  2372  288  288  0  0 21 78  1

 0  2 253484   2216    228   7104 5368 2976  5372  3036  930  519  0  0  0 100  0

 0  1 259252   2616    128   6148 19784 18712 19784 18712 3821 1853  0  1  3 95  1

 1  2 260008   2188    144   6824 11824 2584 12664  2584 1347 1174 14  0  0 86  0

 2  1 262140   2964    128   5852 24912 17304 24952 17304 4737 2341 86 10  0  0  4

部分参数说明：

（1）.      swpd，已使用的 SWAP 空间大小，KB 为单位；

（2）.      free，可用的物理内存大小，KB 为单位；

（3）.      buff，物理内存用来缓存读写操作的 buffer 大小，KB 为单位；

（4）.      cache，物理内存用来缓存进程地址空间的 cache 大小，KB 为单位；

（5）.      si，数据从 SWAP 读取到 RAM（swap in）的大小，KB 为单位；

（6）.      so，数据从 RAM 写到 SWAP（swap out）的大小，KB 为单位；

（7）.      bi，磁盘块从文件系统或 SWAP 读取到 RAM（blocks in）的大小，block 为单位；

（8）.      bo，磁盘块从 RAM 写到文件系统或 SWAP（blocks out）的大小，block 为单位；

上面是一个频繁读写交换区的例子，可以观察到以下几点：

（1）.      物理可用内存 free 基本没什么显著变化，swapd 逐步增加，说明最小可用的内存始终保持在 256MB(物理内存大小) * 10％ = 2.56MB 左右，当脏页达到10％的时候（vm.dirty_background_ratio ＝ 10）就开始大量使用 swap；

（2）.      buff 稳步减少说明系统知道内存不够了，kwapd 正在从 buff 那里借用部分内存；

（3）.      kswapd 持续把脏页面写到 swap 交换区（so），并且从 swapd 逐渐增加看出确实如此。根据上面讲的 kswapd 扫描时检查的三件事，如果页面被修改了，但不是被文件系统修改的，把页面写到 swap，所以这里 swapd 持续增加。

四. IO

       磁盘通常是计算机最慢的子系统，也是最容易出现性能瓶颈的地方，因为磁盘离 CPU 距离最远而且 CPU 访问磁盘要涉及到机械操作，比如转轴、寻轨等。访问硬盘和访问内存之间的速度差别是以数量级来计算的，就像1天和1分钟的差别一样。要监测 IO 性能，有必要了解一下基本原理和 Linux 是如何处理硬盘和内存之间的 IO 的。

4.1 内存页

在第三节Memory中提到了内存和硬盘之间的 IO 是以页为单位来进行的，在 Linux 系统上1页的大小为 4K。可以用以下命令查看系统默认的页面大小：

$ /usr/bin/time -v date

       ...

       Page size (bytes): 4096

       ...

4.2 缺页中断

       Linux 利用虚拟内存极大的扩展了程序地址空间，使得原来物理内存不能容下的程序也可以通过内存和硬盘之间的不断交换（把暂时不用的内存页交换到硬盘，把需要的内存页从硬盘读到内存）来赢得更多的内存，看起来就像物理内存被扩大了一样。事实上这个过程对程序是完全透明的，程序完全不用理会自己哪一部分、什么时候被交换进内存，一切都有内核的虚拟内存管理来完成。当程序启动的时候，Linux 内核首先检查 CPU 的缓存和物理内存，如果数据已经在内存里就忽略，如果数据不在内存里就引起一个缺页中断（Page Fault），然后从硬盘读取缺页，并把缺页缓存到物理内存里。缺页中断可分为主缺页中断（Major Page Fault）和次缺页中断（Minor Page Fault），要从磁盘读取数据而产生的中断是主缺页中断；数据已经被读入内存并被缓存起来，从内存缓存区中而不是直接从硬盘中读取数据而产生的中断是次缺页中断。

       上面的内存缓存区起到了预读硬盘的作用，内核先在物理内存里寻找缺页，没有的话产生次缺页中断从内存缓存里找，如果还没有发现的话就从硬盘读取。很显然，把多余的内存拿出来做成内存缓存区提高了访问速度，这里还有一个命中率的问题，运气好的话如果每次缺页都能从内存缓存区读取的话将会极大提高性能。要提高命中率的一个简单方法就是增大内存缓存区面积，缓存区越大预存的页面就越多，命中率也会越高。

       下面的 time 命令可以用来查看某程序第一次启动的时候产生了多少主缺页中断和次缺页中断：

$ /usr/bin/time -v date

        ...

        Major (requiring I/O) page faults: 1

        Minor (reclaiming a frame) page faults: 260

        ...

4.3  File Buffer Cache

       从上面的内存缓存区（也叫文件缓存区 File Buffer Cache）读取页比从硬盘读取页要快得多，所以 Linux 内核希望能尽可能产生次缺页中断（从文件缓存区读），并且能尽可能避免主缺页中断（从硬盘读），这样随着次缺页中断的增多，文件缓存区也逐步增大，直到系统只有少量可用物理内存的时候 Linux 才开始释放一些不用的页。我们运行 Linux 一段时间后会发现虽然系统上运行的程序不多，但是可用内存总是很少，这样给大家造成了 Linux 对内存管理很低效的假象，事实上 Linux 把那些暂时不用的物理内存高效的利用起来做预存（内存缓存区）呢。下面是一台 Sun 服务器上的物理内存和文件缓存区的情况：

$ cat /proc/meminfo

MemTotal:      8182776 kB

MemFree:       3053808 kB

Buffers:        342704 kB

Cached:        3972748 kB

       这台服务器总共有 8GB 物理内存（MemTotal），3GB 左右可用内存（MemFree），343MB 左右用来做磁盘缓存（Buffers），4GB 左右用来做文件缓存区（Cached），可见 Linux 真的用了很多物理内存做 Cache，而且这个缓存区还可以不断增长。

4.4 页面类型

Linux 中内存页面有三种类型：

（1）.      Read pages，只读页（或代码页），那些通过主缺页中断从硬盘读取的页面，包括不能修改的静态文件、可执行文件、库文件等。当内核需要它们的时候把它们读到内存中，当内存不足的时候，内核就释放它们到空闲列表，当程序再次需要它们的时候需要通过缺页中断再次读到内存。

（2）.      Dirty pages，脏页，指那些在内存中被修改过的数据页，比如文本文件等。这些文件由 pdflush 负责同步到硬盘，内存不足的时候由 kswapd 和 pdflush 把数据写回硬盘并释放内存。

（3）.      Anonymous pages，匿名页，那些属于某个进程但是又和任何文件无关联，不能被同步到硬盘上，内存不足的时候由 kswapd 负责将它们写到交换分区并释放内存。

4.5  IO’s Per Second（IOPS）

       每次磁盘 IO 请求都需要一定的时间，和访问内存比起来这个等待时间简直难以忍受。在一台 2001 年的典型 1GHz PC 上，磁盘随机访问一个 word 需要 8,000,000 nanosec = 8 millisec，顺序访问一个 word 需要 200 nanosec；而从内存访问一个 word 只需要 10 nanosec.（数据来自：Teach Yourself Programming in Ten Years）这个硬盘可以提供 125 次 IOPS（1000 ms / 8 ms）。

4.6  顺序 IO 和 随机 IO

       IO 可分为顺序 IO 和 随机 IO 两种，性能监测前需要弄清楚系统偏向顺序 IO 的应用还是随机 IO 应用。

       （1）顺序 IO 是指同时顺序请求大量数据，比如数据库执行大量的查询、流媒体服务等，顺序 IO 可以同时很快的移动大量数据。可以这样来评估 IOPS 的性能，用每秒读写 IO 字节数除以每秒读写 IOPS 数，rkB/s 除以 r/s，wkB/s 除以 w/s. 下面显示的是连续2秒的 IO 情况，可见每次 IO 写的数据是增加的（45060.00 / 99.00 = 455.15 KB per IO，54272.00 / 112.00 = 484.57 KB per IO）。

       相对随机 IO 而言，顺序 IO 更应该重视每次 IO 的吞吐能力（KB per IO）：

$ iostat -kx 1

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

           0.00    0.00    2.50   25.25    0.00   72.25

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

sdb       24.00 19995.00 29.00 99.00  4228.00 45060.00   770.12    45.01  539.65   7.80  99.80

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

           0.00    0.00    1.00   30.67    0.00   68.33

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

sdb        3.00 12235.00  3.00 112.00   768.00 54272.00   957.22   144.85  576.44   8.70 100.10

       （2）随机 IO 是指随机请求数据，其 IO 速度不依赖于数据的大小和排列，依赖于磁盘的每秒能 IO 的次数，比如 Web 服务、Mail 服务等每次请求的数据都很小，随机 IO 每秒同时会有更多的请求数产生，所以磁盘的每秒能 IO 多少次是关键。

$ iostat -kx 1

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

           1.75    0.00    0.75    0.25    0.00   97.26

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

sdb        0.00    52.00  0.00 57.00     0.00   436.00    15.30     0.03    0.54   0.23   1.30

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

           1.75    0.00    0.75    0.25    0.00   97.24

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

sdb        0.00    56.44  0.00 66.34     0.00   491.09    14.81     0.04    0.54   0.19   1.29

       按照上面的公式得出：436.00 / 57.00 = 7.65 KB per IO，491.09 / 66.34 = 7.40 KB per IO. 与顺序 IO 比较发现，随机 IO 的 KB per IO 小到可以忽略不计，可见对于随机 IO 而言重要的是每秒能 IOPS 的次数，而不是每次 IO 的吞吐能力（KB per IO）。

4.7 SWAP

       当系统没有足够物理内存来应付所有请求的时候就会用到 swap 设备，swap 设备可以是一个文件，也可以是一个磁盘分区。不过要小心的是，使用 swap 的代价非常大。如果系统没有物理内存可用，就会频繁 swapping，如果 swap 设备和程序正要访问的数据在同一个文件系统上，那会碰到严重的 IO 问题，最终导致整个系统迟缓，甚至崩溃。swap 设备和内存之间的 swapping 状况是判断 Linux 系统性能的重要参考，我们已经有很多工具可以用来监测 swap 和 swapping 情况，比如：top、cat /proc/meminfo、vmstat 等：

$ cat /proc/meminfo

MemTotal:      8182776 kB

MemFree:       2125476 kB

Buffers:        347952 kB

Cached:        4892024 kB

SwapCached:        112 kB

...

SwapTotal:     4096564 kB

SwapFree:      4096424 kB

...

$ 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

 1  2 260008   2188    144   6824 11824 2584 12664  2584 1347 1174 14  0  0 86  0

 2  1 262140   2964    128   5852 24912 17304 24952 17304 4737 2341 86 10  0  0

五. network

       网络的监测是所有 Linux 子系统里面最复杂的，有太多的因素在里面，比如：延迟、阻塞、冲突、丢包等，更糟的是与 Linux 主机相连的路由器、交换机、无线信号都会影响到整体网络并且很难判断是因为 Linux 网络子系统的问题还是别的设备的问题，增加了监测和判断的复杂度。现在我们使用的所有网卡都称为自适应网卡，意思是说能根据网络上的不同网络设备导致的不同网络速度和工作模式进行自动调整。我们可以通过 ethtool 工具来查看网卡的配置和工作模式：

# /sbin/ethtool eth0

Settings for eth0:

        Supported ports: [ TP ]

        Supported link modes:   10baseT/Half 10baseT/Full

                                100baseT/Half 100baseT/Full

                                1000baseT/Half 1000baseT/Full

        Supports auto-negotiation: Yes

        Advertised link modes:  10baseT/Half 10baseT/Full

                                100baseT/Half 100baseT/Full

                                1000baseT/Half 1000baseT/Full

        Advertised auto-negotiation: Yes

        Speed: 100Mb/s

        Duplex: Full

        Port: Twisted Pair

        PHYAD: 1

        Transceiver: internal

        Auto-negotiation: on

        Supports Wake-on: g

        Wake-on: g

        Current message level: 0x000000ff (255)

        Link detected: yes

       上面给出的例子说明网卡有 10baseT，100baseT 和 1000baseT 三种选择，目前正自适应为 100baseT（Speed: 100Mb/s）。可以通过 ethtool 工具强制网卡工作在 1000baseT 下：

# /sbin/ethtool -s eth0 speed 1000 duplex full autoneg off

5.1  iptraf

       两台主机之间有网线（或无线）、路由器、交换机等设备，测试两台主机之间的网络性能的一个办法就是在这两个系统之间互发数据并统计结果，看看吞吐量、延迟、速率如何。iptraf 就是一个很好的查看本机网络吞吐量的好工具，支持文字图形界面，很直观。下面图片显示在 100 mbps 速率的网络下这个 Linux 系统的发送传输率有点慢，Outgoing rates 只有 66 mbps.

# iptraf -d eth0

5.2  netperf

       netperf 运行在 client/server 模式下，比 iptraf 能更多样化的测试终端的吞吐量。先在服务器端启动 netserver：

# netserver

Starting netserver at port 12865

Starting netserver at hostname 0.0.0.0 port 12865 and family AF_UNSPEC

然后在客户端测试服务器，执行一次持续10秒的 TCP 测试：

# netperf -H 172.16.38.36 -l 10

TCP STREAM TEST from 0.0.0.0 (0.0.0.0) port 0 AF_INET to 172.16.38.36 (172.16.38.36) port 0 AF_INET

Recv   Send    Send

Socket Socket  Message  Elapsed

Size   Size    Size     Time     Throughput

bytes  bytes   bytes    secs.    10^6bits/sec  

 87380  16384  16384    10.32      93.68

       从以上输出可以看出，网络吞吐量在 94mbps 左右，对于 100mbps 的网络来说这个性能算的上很不错。上面的测试是在服务器和客户端位于同一个局域网，并且局域网是有线网的情况，你也可以试试不同结构、不同速率的网络，比如：网络之间中间多几个路由器、客户端在 wi-fi、VPN 等情况。

       netperf 还可以通过建立一个 TCP 连接并顺序地发送数据包来测试每秒有多少 TCP 请求和响应。下面的输出显示在 TCP requests 使用 2K 大小，responses 使用 32K 的情况下处理速率为每秒243：

# netperf -t TCP_RR -H 172.16.38.36 -l 10 -- -r 2048,32768

TCP REQUEST/RESPONSE TEST from 0.0.0.0 (0.0.0.0) port 0 AF_INET to 172.16.38.36 (172.16.38.36) port 0 AF_INET

Local /Remote

Socket Size   Request  Resp.   Elapsed  Trans.

Send   Recv   Size     Size    Time     Rate

bytes  Bytes  bytes    bytes   secs.    per sec   

16384  87380  2048     32768   10.00     243.03

16384  87380

5.3  iperf

       iperf 和 netperf 运行方式类似，也是 server/client 模式，先在服务器端启动 iperf：

# iperf -s -D

------------------------------------------------------------

Server listening on TCP port 5001

TCP window size: 85.3 KByte (default)

------------------------------------------------------------

Running Iperf Server as a daemon

The Iperf daemon process ID : 5695

       然后在客户端对服务器进行测试，客户端先连接到服务器端（172.16.38.36），并在30秒内每隔5秒对服务器和客户端之间的网络进行一次带宽测试和采样：

# iperf -c 172.16.38.36 -t 30 -i 5

------------------------------------------------------------

Client connecting to 172.16.38.36, TCP port 5001

TCP window size: 16.0 KByte (default)

------------------------------------------------------------

[  3] local 172.16.39.100 port 49515 connected with 172.16.38.36 port 5001

[ ID] Interval       Transfer     Bandwidth

[  3]  0.0- 5.0 sec  58.8 MBytes  98.6 Mbits/sec

[ ID] Interval       Transfer     Bandwidth

[  3]  5.0-10.0 sec  55.0 MBytes  92.3 Mbits/sec

[ ID] Interval       Transfer     Bandwidth

[  3] 10.0-15.0 sec  55.1 MBytes  92.4 Mbits/sec

[ ID] Interval       Transfer     Bandwidth

[  3] 15.0-20.0 sec  55.9 MBytes  93.8 Mbits/sec

[ ID] Interval       Transfer     Bandwidth

[  3] 20.0-25.0 sec  55.4 MBytes  92.9 Mbits/sec

[ ID] Interval       Transfer     Bandwidth

[  3] 25.0-30.0 sec  55.3 MBytes  92.8 Mbits/sec

[ ID] Interval       Transfer     Bandwidth

[  3]  0.0-30.0 sec    335 MBytes  93.7 Mbits/sec

5.4  tcpdump 和 tcptrace

       tcmdump 和 tcptrace 提供了一种更细致的分析方法，先用 tcpdump 按要求捕获数据包把结果输出到某一文件，然后再用 tcptrace 分析其文件格式。这个工具组合可以提供一些难以用其他工具发现的信息：

# /usr/sbin/tcpdump -w network.dmp

tcpdump: listening on eth0, link-type EN10MB (Ethernet), capture size 96 bytes

511942 packets captured

511942 packets received by filter

0 packets dropped by kernel

# tcptrace network.dmp

1 arg remaining, starting with 'network.dmp'

Ostermann's tcptrace -- version 6.6.7 -- Thu Nov  4, 2004

511677 packets seen, 511487 TCP packets traced

elapsed wallclock time: 0:00:00.510291, 1002714 pkts/sec analyzed

trace file elapsed time: 0:02:35.836372

TCP connection info:

  1: zaber:54581 - boulder:111 (a2b)                   6>    5<  (complete)

  2: zaber:833 - boulder:32774 (c2d)                   6>    5<  (complete)

  3: zaber:pcanywherestat - 172.16.39.5:53086 (e2f)    2>    3<

  4: zaber:716 - boulder:2049 (g2h)                  347>  257<

  5: 172.16.39.100:58029 - zaber:12865 (i2j)           7>    5<  (complete)

  6: 172.16.39.100:47592 - zaber:36814 (k2l)        255380> 255378<  (reset)

  7: breakpoint:45510 - zaber:7012 (m2n)               9>    5<  (complete)

  8: zaber:35813 - boulder:111 (o2p)                   6>    5<  (complete)

  9: zaber:837 - boulder:32774 (q2r)                   6>    5<  (complete)

 10: breakpoint:45511 - zaber:7012 (s2t)               9>    5<  (complete)

 11: zaber:59362 - boulder:111 (u2v)                   6>    5<  (complete)

 12: zaber:841 - boulder:32774 (w2x)                   6>    5<  (complete)

 13: breakpoint:45512 - zaber:7012 (y2z)               9>    5<  (complete)

       tcptrace 功能很强大，还可以通过过滤和布尔表达式来找出有问题的连接，比如，找出转播大于100 segments 的连接：

# tcptrace -f'rexmit_segs>100' network.dmp

如果发现连接 ＃10 有问题，可以查看关于这个连接的其他信息：

# tcptrace -o10 network.dmp

下面的命令使用 tcptrace 的 slice 模式，程序自动在当前目录创建了一个 slice.dat 文件，这个文件包含了每隔15秒的转播信息:

# tcptrace -xslice network.dmp

# cat slice.dat

date                segs    bytes  rexsegs rexbytes      new   active

--------------- -------- -------- -------- -------- -------- --------

16:58:50.244708    85055  4513418        0        0        6        6

16:59:05.244708   110921  5882896        0        0        0        2

16:59:20.244708   126107  6697827        0        0        1        3

16:59:35.244708   151719  8043597        0        0        0        2

16:59:50.244708    37296  1980557        0        0        0        3

17:00:05.244708       67     8828        0        0        2        3

17:00:20.244708      149    22053        0        0        1        2

17:00:35.244708       30     4080        0        0        0        1

17:00:50.244708       39     5688        0        0        0        1

17:01:05.244708       67     8828        0        0        2        3

17:01:11.081080       37     4121        0        0        1        3

声明：转载须注明出处和作者oolong。

详见附件

其实很早就出到第二版了，不过第二版和公司比较有关系，所以没传上来