Question

我被分配到性能调整 - 调试 - 故障排除任务。

场景：使用数据库在多台联网计算机上运行的多应用程序环境。操作系统是Unix，DB是Oracle。使用同步/异步通信跨应用程序实现业务逻辑。应用程序是多用户，在高峰时间有数百个呼叫中心用户。用户界面是基于Web的。

应用程序是第三方，我可以访问开发人员和源代码。我只有生产系统和功能测试环境，没有负载测试环境。

问题：性能不佳！我需要快速的结果。管理层疯了。

我得到了类似这样的症状示例：用户界面操作需要几分钟才能完成。对客户进行搜索通常需要6秒钟，但使用相同参数进行的后续搜索可能需要6分钟。

找到根本原因的策略是什么？

Answer 1

如果这是一个11小时的类型场景，并且这是一个你没有事先知识的系统，这里是我如何去做 - 下面的具体说明是针对unix newb，但是一般原则对于任何系统分类都是合理的：

创建一个文本文件，其中包含每个生产主机的名称。我们称之为prodhosts
在~/.ssh/authorized_keys的每一个prod_hosts上将您的公开密钥转到for i in `cat prodhosts` ; do echo $i ; ssh $i uptime ; done。如果您不熟悉ssh代理以及如何快速到处登录，请花10分钟阅读，或使用script that handles it for you。
检查所有服务器上的系统负载
```
for i in `cat prodhosts` ; do echo $i ; ssh $i df -h ; done
```
高负载平均值（一般来说，超过您拥有的核心数）表示服务器有问题。记下它们 - 你很快就会看到它们。
检查完整磁盘 - 这些是非常常见的
```
for i in `cat prodhosts` ; do echo $i ; ssh $i free -m ; done
```
任何处于或接近100％磁盘使用率的主机都会出现问题。记下以这种方式找到的任何问题服务器。
检查交换活动 - 交换是导致性能不佳的最常见原因（并且通常与高负载平均值的上述指标配对）。
```
             total       used       free     shared    buffers     cached
Mem:         15884      15766        117          0         61      14928
-/+ buffers/cache:        776      15107
Swap:        31743          0      31743
```
这会告诉你所有盒子的内存有多少，以及每次交换的内存量。以下是具有大约16GB RAM的健康系统：
```
used
```
您的问题框可能会在Swap的dmesg列中显示较大的数字。这是您的应用程序尝试使用的内存量，而不是您的计算机所没有的。
有了这些信息，您应该更好地了解95％的所有系统中瓶颈的位置（其余5％将被远程网络资源或小鬼减慢）。现在你做标准分类。从堆栈的底部开始 - 即如果你的负载很高且性能都很糟糕，那就从你的数据库开始吧，因为它的问题可能会在其他地方层层叠加（如果你的数据库正好嗡嗡作响，很明显先在别处看 - 但是当性能在线时总是对数据库产生怀疑）：
- 数据库 - 获取正在运行的所有正在运行的查询的日志，例如，400ms，在您可以承担的大量样本期间（理想情况下这些日志已经存在，否则将它们组合在一起并让数据收集一个小时左右）。将一些脚本归为一类，这些脚本可以规范化查询并确定哪些查询占用了系统上总的最多时间（同时还要留意那些耗时太长而且速度慢的其他所有内容的糟糕的一次性查询下）。您需要使用解释计划分析这些查询，并找出如何让它们更好地命中索引，或者如果可能的话，弄清楚如何从系统中完全删除它们。如果有DBA，请向DBA寻求帮助，如果可以，请使用现成的查询日志分析器。
- 应用程序 - 查看日志并注意任何疯狂的事情。应用程序和日志记录变化很大，因此这取决于系统。
- 操作系统（在任何方框上使用此功能） - 查看包装盒上{{1}}的输出 - 是否有任何警告？查看/ var / log中的日志 - 看到有趣的内容吗？似乎突然出现的任何日志？这些是你的问题点。

在您完成快速且松散的黑客攻击以使系统恢复稳定状态后，请坐下来与“管理”人员讨论监控，日志分析以及系统管理员交易的所有标准工具应该有所帮助防止你所在的场景发生。阅读Nagios，Munin，rsyslog等，或雇用可以自动化数据中心及其监控的人员。此外，如果该应用程序的第三方，请与他们讨论他们希望您如何处理此类情况 - 如果这是一种现成的产品，他们应该有成功运行其应用程序所需的要求指南。如果您聘请了一家随机承包公司进行建设，请考虑向管理层推荐他们雇用了解他们正在做什么的人。

Answer 2

检查cpu利用率是否低，似乎是数据库问题，分析查询并查找顺序扫描，可能只缺少索引。

检查哪个组件空闲，可能存在某种超时或缺少资源。

其他任何东西取决于应用程序的体系结构。你肯定需要一个测试环境来设置一个不错的基准测试，或者让经理（购买这些东西）支付第三方支持。

Answer 3

运行sysinternals文件监视器和进程监视器以查找过多的I / O.当性能在运行特定报告或程序时拖拽时最容易完成。与Oracle DBA合作监控数据库性能。与sysadmin合作监视Oracle表所在的磁盘。您正在寻找执行不佳的查询，导致全表扫描，矩阵结果等。让sysadmin / netadmin监控网络饱和。

将生产数据和代码复制到另一个隔离的测试系统并测量性能。查看CPU和磁盘性能通过屋顶的位置。

请注意，FileMonitor输出为.csv格式，很快就会压倒Excel。但Excel可以将.csv视为外部数据源，您可以将其连接到数据透视表。只需使用数据透视表向导，指向报告文件（.txt）并测量应用程序名称，数据集文件名和读/写字节。您将很快找到使用I / O锤击的文件。有时解决方案很简单，例如使用事务包装数千个数据库更新。

Answer 4

查看CPU负载高的机器 - 这样您就可以确定数据库端或UI代码中是否存在问题（后者不太可能，但仍值得检查）。还要检查是否有任何机器内存不足（检查这种情况的方式取决于编程语言），即如果减速是由持续的虚拟内存交换引起的。

将生产数据复制到测试系统，并验证即使没有高负载，对数据的访问是否也很慢。如果是 - 很可能是一个糟糕的数据库设计。如果不是（即如果它仅在负载下变慢），那么事情就更复杂了。如果CPU负载较低，但系统负载较重会导致速度减慢，则可能存在锁定和不必要的阻塞问题。如果CPU负载很高，这可能表明数据库设计不理想或结果缓存不佳（尽管通常数据库本身应该这样做）。

签入日志或要求开发人员记录所有SQL查询查询及其运行时。如果“all”太多，请让他们只记录那些花费超过3秒的人来完成。手动运行慢查询并要求Oracle解释它在做什么。

手动检查数据库中是否有明显缺失索引的表。如果没有多少表，通常可以比查找慢速查询的速度更快。

Answer 5

行。我已经完成了这个，the basic method I use is this。

以下是the kind of results that are ultimately possible的示例。

那就是说，这只是一个开始。

会出现多个问题，您找到并修复的每个问题都会显着改善，但您无法完成。你必须得到大部分。

最大的问题是你会找出性能不佳的原因，并且它将要求一个或多个应用程序以不同的方式编码一点（或很多）。您将遇到“拥有”代码以进行这些更改的程序员的阻力。它可能很好地违反了他们正确设计代码的感觉，这是一种难以克服的强烈感觉。

举一个例子，我处理了一个严重性能问题的应用程序，该问题被认为是公司威胁。一如既往，对于问题是什么，还有Wild-XX-Guesses，人们也非常愿意在这些猜测中投入时间和金钱。 真正的问题是决定使用XML作为应用程序各部分之间的通信格式，并且大部分时间用于生成和解析XML，即使应用程序的两个部分也是如此碰巧在同一个过程，可以直接交换信息。要改变这一点需要改变设计，这不是一件难事。困难的是让程序员接受这部分必须采用不同的方式。

根据我的经验，最严重的性能问题是由抽象和数据结构的过于笼统的方法引起的，这些方法已被虔诚地教授，而且程序员极不情愿重新考虑。

这是我尚未想出如何克服的部分。

绩效分析策略

5 个答案: