绩效分析策略

如果这是一个11小时类型的场景,而且这是一个您在没有事先了解的情况下要使用的系统,下面是我将如何进行的详细说明-下面是针对Unix新手的特定说明,但是对于任何系统分类来说,一般原则都是合理的:

1. 使用其中每个生产主机的名称创建一个文本文件。让我们称之为 prodhosts
2. 获取公共ssh密钥 ~/.ssh/authorized_keys 在每一个 prod_hosts . 如果您不熟悉ssh代理以及如何快速地在任何地方登录,请花10分钟时间阅读,或者使用 script that handles it for you .

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

   for i in `cat prodhosts` ; do echo $i ; ssh $i uptime ; done
   

   高负载平均值(一般来说,比您拥有的核心数量还要多)表示服务器有问题。把它们记下来-你很快就会看到的。

4. 检查磁盘是否已满-这些是非常常见的

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

   任何达到或接近100%磁盘使用率的主机都将是一个问题。记录下您以这种方式发现的任何问题服务器。

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

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

   这将告诉你所有的盒子都有多少内存,以及每个盒子交换了多少内存。下面是一个拥有16GB内存的健康系统的样子:

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

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

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

   • 数据库-获取一个正在运行的所有查询的日志,这些查询将在一个足够长的采样周期内接管,例如400毫秒(理想情况下,这些日志将已经存在,否则将它们聚集在一起,让数据收集一个小时左右)。将一些规范化查询的脚本拼凑在一起,找出最需要的查询 全部的 系统上的时间(也要注意那些耗时太长、速度慢的糟糕的一次性查询)。您将希望使用一个解释计划来分析这些查询,并找出如何让它们更好地命中索引,或者尽可能地找出如何将它们从系统中完全删除。如果有,请向DBA寻求帮助,如果可以,请使用现成的查询日志分析器。
   • 应用程序-查看日志,注意任何疯狂的事情。应用程序和日志记录变化很大,因此这非常依赖于系统。
   • 操作系统(在任何框中使用此选项)-查看 dmesg 在你的盒子上-有什么警告吗?查看/var/log中的日志-看到有什么有趣的吗?有没有原木在表面爆裂?这些是你的问题点。

在您完成了快速而松散的黑客攻击以使系统恢复到稳定状态之后,坐下来与“管理层”讨论监视、日志分析以及系统管理行业的所有标准工具,这些工具应该有助于防止出现像您所处的场景。阅读Nagios、Munin、Rsyslog等,或聘请能够为您自动化数据中心及其监控的人员。此外,如果应用程序的第三方,与他们讨论他们希望你如何处理这种情况-如果这是现成的产品,他们应该有指导方针,为成功运行他们的应用程序所必需的要求。如果是你雇了一家随机承包公司来建造的,考虑向管理层推荐他们雇用知道自己在做什么的人。

检查CPU利用率如果它是低的,它似乎是一个数据库问题,分析查询和寻找顺序扫描,可能只有一个索引丢失。

检查哪个组件处于空闲状态,可能存在某种超时或缺少资源。

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

运行SysInternals文件监视器和进程监视器以查找过量的I/O。最容易在运行特定报告或程序时执行性能拖动。与Oracle DBA合作监视数据库性能。与sysadmin合作监视Oracle表所驻留的磁盘。您正在寻找执行不良的查询,这些查询会导致完整的表扫描、矩阵结果等。让sysadmin/netadmin监视网络饱和。

将生产数据和代码复制到另一个独立的测试系统并测量性能。看看CPU和磁盘的性能如何。

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

看看哪台机器的CPU负载很高,这样你就可以知道问题是在数据库方面还是在UI代码中(后者不太可能,但仍然值得检查)。还要检查是否有任何机器的内存不足(检查这一点的方法取决于编程语言),也就是说,是否由于持续的虚拟内存交换而导致速度减慢。

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

签入日志或要求开发人员记录所有SQL查询及其运行时。如果“全部”太多,请他们只记录那些需要3秒以上才能完成的。手动运行慢速查询,并要求Oracle解释它在做什么。

手动检查数据库中是否有明显缺少索引的表。如果没有太多的表,您通常可以更快地完成这项工作,而不是查找查询速度较慢的表。

好啊。我已经做到了,而且 the basic method I use is this .

下面是一个例子 the kind of results that are ultimately possible .

也就是说,这只是开始。

会有多个问题,每一个你发现和修复的问题都会显著改善,但你不会完成。你必须得到大部分。

最大的问题是你会找出一个表现不佳的原因, 它将要求对一个或多个应用程序进行稍微(或大量)不同的编码。对于那些“拥有”代码来进行这些更改的程序员来说,您将遇到阻力。这很可能违背了他们正确设计代码的意识,这是一种难以克服的感觉。

例如,我在一个有严重性能问题的应用程序上工作,该问题被认为是公司的威胁。正如往常一样,对于问题是什么,人们有着疯狂的XX猜测,人们只愿意在这些猜测上投入时间和金钱。这个 真实的 问题在于决定使用XML作为应用程序各部分之间的通信格式,而大多数时间都是在生成和解析XML, 即使应用程序的两个部分恰好处于同一进程中 可以直接交换信息。要改变这一点,需要改变设计,这并不是一件困难的事情。困难的是让程序员接受这一部分必须以不同的方式完成。

在我的经验中,最严重的性能问题是由抽象和数据结构的过于一般的方法引起的,这些方法已经被认真地教过,而且程序员非常不愿意重新考虑。

这是我还没弄明白如何克服的部分。