1、系统工作负载：
系统工作负载的完整准确的定义对于预测或理解它的性能是很关键的。在衡量系统性能时，工作负载的不同可能会比 CPU 时钟速度或随机访问存储器（RAM）大小不同带来更多的变化。工作负载的定义不仅必须包含向系统发送的请求的类型和速率，还要包含将要执行的确切软件包和内部应用程序，包括系统将在后台处理的工作也很重要。例如，如果一个系统包含通过 NFS 加载且由其它系统频繁访问的文件系统，那么处理那些访问很可能是总体工作负载中非常重要的一部分，即使该系统不是正式的服务器也是如此。已进行标准化从而允许在不同系统之间进行比较的工作负载称为基准程序。但是，很少有实际的工作负载能完全符合基准程序的精确算法和环境。即使是那些最初从实际的应用程序发展而来的行业标准基准程序也已经过简化和均匀化，从而使它们可移植到大量的硬件平台上。使用行业标准基准程序唯一有效的方法是减小将接受严肃评估的候选系统的范围。因此，在尝试理解系统的工作负载和性能时不应该只依赖基准测试结果。
可以将工作负载分为以下类别：
多用户
由多个用户通过各自的终端提交的工作组成的工作负载。通常，这种工作负载的性能目标有两种可能，即在保留指定的最坏情况响应时间条件下最大化系统吞吐量，或者对于固定不变的工作负载获得尽可能快的响应时间。
服务器
由来源于其它系统的请求组成的工作负载。例如，文件服务器的工作负载主要是磁盘读写请求。它是多用户工作负载（加上 NFS 或其它 I/O 活动）的磁盘 I/O 部分，所以适用同样的目标，即在给定的相应时间限制下最大化吞吐量。其它的服务器工作负载由诸如数学计算密集的程序、数据库事务、打印机作业之类的项组成。
工作站
由单独的用户通过键盘提交工作和在该系统的显示器上接收结果组成的工作负载。通常这种工作负载的最高优先级性能目标是使用户请求的响应时间最短。
性能目标
在定义了系统必须处理的工作负载后，可以选择性能标准并根据这些标准设定性能目标。计算机系统的总体性能标准是响应时间和吞吐量。
响应时间是提交请求和返回该请求的响应之间使用的时间。示例包括：
- 数据库查询花费的时间
- 将字符回显到终端上花费的时间
- 访问 Web 页面花费的时间
吞吐量是对单位时间内完成的工作量的量度。示例包括：
- 每分钟的数据库事务
- 每秒传送的文件千字节数
- 每秒读或写的文件千字节数
- 每分钟的 Web 服务器命中数
这些度量之间的关系很复杂。有时可能以响应时间为代价而得到较高的吞吐量，而有时候又要以吞吐量为代价得到较好的响应时间。在其它情况下，一个单独的更改可能对两者都有提高。可接受的性能基于合理的吞吐量与合理的响应时间相结合。
在规划或调谐任何系统中，当处理特定的工作负载时一定要保证对响应时间和吞吐量都有明确的目标。否则，有可能存在一种风险，那就是您花费了分析时间和物力改善的仅仅是系统性能中一个次要的方面。
2、性能调谐过程介绍：
性能调谐主要是资源管理问题和正确的系统参数设置。调谐工作负载和系统以有效利用资源由下列步骤组成：
1. 识别系统中的工作负载
2. 设置目标：
a. 确定如何评测结果
b. 量化目标和区分目标的优先级
3. 识别限制系统性能的关键资源
4. 最小化工作负载的关键资源要求：
a. 如果可选择的话，使用最适当的资源
b. 减少个别程序或系统函数对关键资源的要求
c. 结构化资源的并行使用
5. 修改资源的分配以反映优先级
a. 更改个别程序的优先级或资源限制
b. 更改系统资源管理参数的设置
6. 重复步骤 3 到步骤 5 直到满足目标（或者资源饱和）
7. 如果必要的话，使用其它资源
3、识别工作负载：
系统执行的所有工作都必须能够识别。特别是在 LAN 连接的系统中，通过系统的用户之间仅有的非正式协议，可以轻松地开发出一组复杂的交叉安装的文件系统。这些文件系统必须被识别出来并作为任何调谐活动的一部分进行考虑。
对于多用户工作负载，分析员必须量化一般情况和高峰期的请求率。确定用户实际与终端交互时间的实际比例也是很重要的。
该识别阶段中的一个要素是决定必须对生产系统进行评估和调谐活动，还是在另一系统上（或"切换"）用实际工作负载的模拟型式来完成评估和调谐活动。分析员必须针对非生产环境的灵活性权衡来自于生产环境结果的较大可靠性，分析员可在非生产环境中进行试验，当然试验所冒的风险是性能下降或更糟。
4、设置目标的重要性：
虽然可以根据可测数量设置目标，但实际希望的结果往往带有主观性，比如令人满意的响应时间。进一步讲，分析员必须抵挡住调谐可测量的东西而不是对他而言是重要东西的诱惑。如果没有系统提供的评估能符合所要求的改进，那么就必须对该评估进行设计。
量化目标最有价值的方面不是选择达到的数字，而是对（通常）多个目标的相对重要性进行公开判定。如果这些优先级没有事先设定且不是每个相关的人都理解的话，分析员在没有进行频繁咨询之前不能作出任何折衷的决定。分析员还容易对用户的反应或管理性能中一些已经被忽略的方面而感到吃惊。如果系统的支持和使用跨过了组织的边界，您可能需要供应商和用户之间的书面服务级协议，可确保对性能目标和优先级有一个清楚而共同的理解。
5、识别关键资源：
通常，给定工作负载的性能可由一两种关键系统资源的可用性和速度决定。分析员必须正确识别出那些资源，否则会冒险陷入无休止的尝试出错操作。
系统具有物理资源和逻辑资源。关键的物理资源通常比较容易识别，因为较多的系统性能工具可用来评估物理资源的利用率。通常最影响性能的物理资源如下：
- CPU 周期
- 内存
- I/O 总线
- 不同的适配器
- 磁盘臂
- 磁盘空间
- 网络访问
逻辑资源不太容易识别。逻辑资源通常是对物理资源进行分区的编程抽象。进行分区的目的是共享和管理物理资源。
构建于其上的物理资源和逻辑资源的一些示例如下：
1、CPU
a:处理器时间片
2、内存
a:页面帧
b:堆栈
c:缓冲区
d:队列
e:表
f:锁和信号量
3、磁盘空间
a:逻辑卷
b:文件系统
c:文件
d:分区
4、网络访问
a:会话
b:信息包
c:通道
了解逻辑资源和物理资源是很重要的。因为缺少逻辑资源线程可能阻塞，就像因为缺少物理资源而阻塞一样，扩展下层物理资源未必能保证创建附加的逻辑资源。例如，考虑使用 NFS 块 I/O 守护程序 biod。客户机上的一个 biod 守护程序要求处理每个暂挂的 NFS 远程 I/O 请求。因此，biod 守护程序的数量限制了能同时运行的 NFS I/O 操作的数量。当缺少 biod 守护程序时，系统检测会指示 CPU 和通信链路只使用了很少一部分。您可能有系统未充分利用（并且很慢）的假象，事实上这时是因为缺少 biod 守护程序从而限制了其余的资源。biod 守护程序使用处理器周期和内存，但您不能简单地通过添加实内存或将它转移到一个更快的 CPU 上来修正这个问题。解决方案是创建更多的逻辑资源（biod 守护程序）。
在应用程序开发过程中可能不经意间创建逻辑资源和瓶颈。传递数据或控制设备的方法可以有效地创建一个逻辑资源。当偶然创建这样的资源时，通常没有工具可监视它们的使用，也没有接口控制它们的分配。它们的存在可能不会引起重视，直到某个特定性能问题出现时就会突出它们的重要性。
最小化关键资源要示：
下面讨论在三个级别上考虑最小化工作负载的关键资源要求。
使用适当的资源：
决定在一个资源上使用另一个资源时应该理智地考虑并且头脑中要有明确的目标。在应用程序开发过程中有一个选择资源的示例，即通过增加内存消耗来减少 CPU 的消耗来达到一个平衡。用于演示资源选择的公共的系统配置决策为：是将文件放置在单独的本地工作站上，还是放置在远程服务器上。
减少关键资源的要求：
对于本地开发的应用程序，可用多种方法检查程序以便其更有效地执行相同的功能或除去不需要的功能。在系统管理级别上，争用关键资源的低优先级工作负载可以移动到其它系统中、在其它时间运行或由"工作负载管理器"控制。
结构化资源的并行使用：
因为工作负载需要运行多个系统资源，从而可以利用这样的事实，即资源是独立的且可以并行使用。例如，操作系统预读算法检测到程序在顺序访问文件的事实，因此它调度并行执行的其它顺序读取操作，同时应用程序还处理先前的数据。并行也用于系统管理。例如，如果某个应用程序同时访问两个或多个文件且如果同时访问的这些文件存放在不同的驱动器上，那么添加一个额外的磁盘驱动器可能会提高磁盘 I/O 的速率。
资源分配优先级：
操作系统提供了一些方法来区分活动的优先级。有些在系统级别上设置，比如磁盘调步。其它的例如进程优先级可由单个用户设置以反映连接到特定任务上的重要性。
重复调谐步骤：
性能分析的一个公认的真理是接下来总有瓶颈出现。减少某个资源的使用意味着另一资源限制了吞吐量或响应时间。例如，假设我们的系统中有下列的利用率级别：
CPU：90% 磁盘：70% 内存：60%
这个工作负载是 CPU 受限的。如果成功的调谐工作负载使得 CPU 负载从 90% 降到 45%，则可望在性能上有两倍的改善。不幸的是现在的工作负载是 I/O 受限的，它有下列的近似利用率：
CPU：45% 磁盘：90% 内存：60%
改善后的 CPU 利用率允许程序立刻提交磁盘请求，但接下来我们会受到由磁盘驱动器的容量施加的限制。性能改善也许是 30% 而不是预期的 100%。
总是存在一个新的关键资源。重要的问题是使用手边的资源是否已经满足性能目标。
注意: 用 vmtune、schedtune 和其它调谐命令产生的不正当系统调谐可能导致意外的系统行为，例如降低系统或应用程序的性能或系统暂停。更改仅应在性能分析识别出瓶颈时才适用。
注:
对于性能相关的调谐设置，不存在什么一般建议。
应用额外的资源
在前述所有的方法都用尽后如果系统性能仍不能满足它的目标，则必须增强或扩展关键资源。如果关键资源是逻辑资源且下层物理资源足够，则无需额外代价就可以扩展逻辑资源。如果关键资源是物理资源，分析员必须研究一些额外的问题：
a:必须增强或扩展关键资源到什么程度才可以终止瓶颈？
b:系统性能会满足它的目标吗？或另外的资源会首先饱和吗？
c:如果有一串关键资源的话，增强或扩展所有这些资源或与另一系统划分当前工作负载是否更节省成本呢？
连续的系统性能监视的优点
连续的系统性能监视可以执行以下任务：
往往会在潜在的问题产生负作用之前就检测到它们
检测影响用户生产力的问题
在问题首次发生时收集数据
允许您建立比较基准
成功的监视包括以下内容：
从操作系统中定期获取关于性能的信息
存储信息以留作将来问题诊断之用
显示有益于系统管理员的信息
检测要求额外数据收集或响应系统管理员的指示收集此类数据的情况，或者二者均检测
收集和存储必需的详细数据
跟踪对系统和应用程序所做的更改
报告的性能问题的类型
报告性能问题时，缩小可能性列表对确定性能问题的种类是很有帮助的。下面是潜在的性能问题类型的列表：
特定程序运行缓慢
在一天的特定时间所有程序都运行缓慢
在不可预测的时间所有程序都运行缓慢
单用户运行的所有程序速度缓慢
大量 LAN 连接的系统的速度同时减慢
特定服务或设备上的所有程序速度偶尔减慢
远程连接时的所有程序运行缓慢
（1）特定程序运行缓慢
尽管这种情况看来微不足道，但还是有问题要回答：
程序一直运行缓慢吗？
如果程序刚开始运行变慢，原因可能是近期对程序作了改动。
源代码是否改过，或者是否安装过新版本？
如果是，与程序员或供应商协商解决。
改过某些环境属性吗？
如果程序（包括自身的可执行程序）使用的文件已经移动了，则现在可能会产生先前并不存在的网络延迟。或者，文件可能会争用先前位于不同磁盘上的单个磁盘存取器。
如果系统管理员更改了系统调谐参数，则程序可能受到先前并不存在的约束。例如，如果系统管理员更改了计算优先级的方法，那么惯于在后台快速运行的程序现在可能会慢下来，而前台程序则运行加快。
程序是用 perl、awk、csh 或者某些其它解释语言编写的吗？
不幸的是，解释语言并未由编译器优化。同样，在诸如 perl 或 awk 的语言中很容易用一些字符来请求一个计算或 I/O 非常密集的操作。通常有必要进行此类程序的台面检验或非正式同等检验，着重注意每一步操作隐含的迭代次数。
程序是否始终以同样的速度运行，还是有时候运行变快？
文件系统使用部分系统内存来保存供以后引用的文件页面。如果一个有磁盘限制的程序紧接着运行两次，第二次通常会比第一次运行速度快。类似的行为可通过使用 NFS 的程序看到。这种情况也发生在大程序中，如编译器。程序的算法可能不是有磁盘限制的，但是装入可执行的大程序所需时间也许会使第一次执行程序比随后执行长得多。
如果程序一直运行缓慢，或者在其环境没有任何明显变化的情况下减慢，则请查看它的资源相关性