debugging - 性能分析策略

Question

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

场景:在使用数据库的多台联网机器上运行的多应用环境。 OS 是 Unix，DB 是 Oracle。使用同步/异步通信跨应用程序实现业务逻辑。应用程序是多用户的，高峰时间有数百个调用中心用户。用户界面是基于网络的。

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

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

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

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

Answer 1

如果这是第 11 小时类型的场景，并且这是一个您在没有先验知识的情况下进入的系统，那么我将如何处理它 - 下面的具体说明适用于 unix newb，但一般原则适用于任何系统分类:

创建一个文本文件，其中包含每个生产主机的名称。我们叫它prodhosts

获取您的公共(public) ssh key 到 ~/.ssh/authorized_keys在每一个 prod_hosts .如果您不熟悉 ssh 代理以及如何在任何地方快速登录，请花 10 分钟阅读它，或使用 script that handles it for you .

检查所有服务器上的系统负载

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

这将告诉您所有盒子有多少内存，以及它们每个交换多少。以下是具有大约 16GB RAM 的健康系统的外观:

             total       used       free     shared    buffers     cached
Mem:         15884      15766        117          0         61      14928
-/+ buffers/cache:        776      15107
Swap:        31743          0      31743

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

有了这些信息，您应该更好地了解 95% 的系统中的瓶颈在哪里(剩余的 5% 会被远程网络资源或小 Sprite 拖慢)。现在您进行标准分类。从堆栈的底部开始——也就是说，如果你的数据库到处都是高负载和糟糕的性能，那么从你的数据库开始，因为它的问题很可能在其他地方层出不穷(如果你的数据库运行良好，显然先看看其他地方——但是当性能很重要时，请始终怀疑数据库):

数据库 - 获取正在运行的所有查询的日志，这些查询占用了 400 毫秒，在您可以承受的尽可能大的样本周期内(理想情况下这些日志已经存在，否则将它们放在一起并让数据收集小时左右)。编写一些规范化查询的脚本，并找出哪些查询在您的系统上占用的总时间最多(还要注意那些花费太长时间并减慢其他一切的蹩脚的 1-off 查询)。您需要使用解释计划来分析这些查询，并找出如何让它们更好地命中索引，或者找出如何在可能的情况下将它们从系统中完全删除。如果您有 DBA，请向您的 DBA 寻求帮助，如果可以，请使用现成的查询日志分析器。

应用程序 - 查看日志并注意任何疯狂的事情。应用程序和日志记录千差万别，因此这非常依赖于系统。

操作系统(在任何机器上使用它) - 查看 dmesg 的输出在您的盒子上 - 有任何警告吗？查看/var/log 中的日志 - 看到什么有趣的事情了吗？任何日志似乎都爆裂了？这些是你的问题点。

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