性能分析策略

Question

我被分配到一项性能调优调试故障排除任务。

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

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

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

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

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

Answer 1

如果这是一个11小时类型的场景，并且这是一个您在没有事先知识的情况下走向的系统，那么我将如何处理它-以下是针对unix newb的特定说明，但一般原则对于任何系统分类都是合理的：

1. 创建一个文本文件，其中包含您的每台生产主机的名称。让我们称它为prodhosts
2. Get您的公共ssh密钥到每个prod_hosts上的~/.ssh/authorized_keys上。如果您不熟悉ssh代理以及如何快速登录到任何地方，可以花10分钟阅读它，或者在所有服务器上使用script that handles it for you.
3. Check系统加载

for i in cat prodhosts；do echo $i；ssh $i uptime；done

较高的平均负载(通常情况下，超过您拥有的核心数量)表示服务器有问题。记下它们-您很快就会看到它们。

• 检查磁盘是否已满-这些非常常见

for i in cat prodhosts；do echo $i；ssh $i df -h；done

任何达到或接近100%磁盘使用率的主机都会出现问题。记下你用这种方式发现的任何问题服务器。

• 检查交换活动-交换是导致性能不佳的最常见原因(通常与上面的高平均负载指标配对)。

for i in cat prodhosts；do echo $i；ssh $i free -m；done

这将告诉您所有计算机有多少内存，以及它们各自交换了多少内存。下面是一个拥有大约16 of的健康系统：

已用可用共享缓存总内存: 15884 15766 117 0 61 14928 -/+缓冲区/缓存: 776 15107交换: 31743 0 31743

您的问题框很可能会在交换的used列中有一个很高的数字。这是您的应用程序正在尝试使用而您的计算机没有的内存量。

• 有了这些信息，您应该更好地了解95%的系统中的瓶颈所在(剩下的5%会因远程网络资源或gremlins而变慢)。现在，您执行标准分流。从堆栈的底部开始-也就是说，如果您到处都有高负载和糟糕的性能，那么从您的数据库开始，因为它的问题很可能会级联到其他地方(如果您的数据库运行良好，显然先看看其他地方-但当性能处于危险境地时，请始终对数据库持怀疑态度)：

- Database - get a log of all queries being run that take over, say, 400ms, in as large of a sample period as you can afford to take (ideally these logs will already exist, otherwise get them together and let the data collect for an hour or so). Hack together some scripts that normalize the queries and figure out which queries take up the most _total_ time on your system (also be on the lookout for crappy 1-off queries that take way too long and slow everything else down). You'll want to analyze those queries with an explain plan and figure out how to get them to hit indexes better, or figure out how to remove them from your system altogether if possible. Ask your DBA for help if you have one, and use an off-the-shelf query log analyzer if you can.
- Application - look through the logs and watch out for anything crazy. Apps and logging vary wildly, so this is very system-dependent.
- Operating System (use this on any box) - look at the output of `dmesg` on your box - does it have any warnings? Look through the logs in /var/log - see anything interesting? Any logs that are bursting at the seems? Those are your problem points.

​

在您完成了快速和松散的黑客攻击以使系统恢复到稳定状态之后，请坐下来与“管理层”讨论监控、日志分析和sysadmin行业的所有标准工具，这些工具应该有助于防止类似您所处的情况的发生。阅读有关Nagios、Munin、rsyslog等的内容，或者聘请可以自动化您的数据中心及其监控的人。此外，如果应用程序的第三方，请与他们讨论他们希望您如何处理这种情况-如果这是一个现成的产品，他们应该有成功运行应用程序所需的指导原则。如果你雇佣了一家随机的合同公司来建造它，考虑向管理层推荐他们雇佣知道他们在做什么的人。

Answer 2

检查cpu使用率如果很低可能是数据库问题，分析查询并查找顺序扫描，可能只缺少一个索引。

检查哪个组件空闲，可能存在某种类型的超时或丢失资源。

其他任何内容都取决于应用程序的体系结构。你肯定需要一个测试环境来建立一个像样的基准测试，或者让经理(购买了这些东西)支付第三方支持的费用。

Answer 3

运行系统内部文件监视器和进程监视器来查找过多的I/O。当运行特定报告或程序时性能下降时，最容易做到这一点。与您的Oracle DBA合作，监控数据库性能。与sysadmin合作，监视Oracle表所在的磁盘。您正在寻找执行不佳的查询，这会导致全表扫描、矩阵结果等。让sysadmin/netadmin监控网络饱和度。

将生产数据和代码复制到另一个独立的测试系统，并测量性能。了解CPU和磁盘性能达到顶峰的程度。

请注意，FileMonitor输出为.csv格式，很快就会淹没Excel。但是，Excel可以将该.csv视为外部数据源，您可以将其连接到透视表。只需使用数据透视表向导，指向报表文件(.txt)，然后测量应用程序名称、数据集文件名和读取/写入的字节数。您很快就会找到正在遭受I/O攻击的文件。有时，解决方案很简单，比如在一个事务中包装数千个数据库更新。