性能分析与调优的原理及原则

性能分析与调优的原理 最近一直纠结性能分析与调优如何下手 先从硬件开始 还是先从代码或数据 库 从操作系统 CPU 调度 内存管理 进程调度 磁盘 I O 网络 协议 HTTP TCP IP 还是从应用程序代码 数据库调优 中间件配置等方面入 手 单一个中间件又分 web 中间件 apache IIS 应用中间件 tomcat weblogic webSphere 等 虽然都是中间件 每一样拎出来往深了学 都不是一朝一夕之功 但调优对于每一项的要求又不仅仅是 知道 或 会使用 这么简单 起码要达到 如何更好的使用 常看到性能测试书中说 性能测试不单单是性能测试工程师一个人的事儿 需 要 DBA 开发人员 运维人员的配合完成 但是在不少情况下性能测试是由性能 测试人员独立完成的 退一步就算由其它人员的协助 了解系统架构的各个模块对 于自身的提高也有很大帮助 同进也更能得到别人的尊重 再说性能调优之前 我们有必要再提一下进行测试的目的 或者我们进行性能 测试的初衷是什么 能力验证能力验证 验证某系统在一定条件具有什么样的能力 能力规划能力规划 如何使系统达到我们要求的性能能力 应用程序诊断应用程序诊断 比如内存泄漏 通过功能测试很难发现 但通过性能测试却很容易 发现 性能调优性能调优 满足用户需求 进一步进行系统分析找出瓶颈 优化瓶颈 提高系统整 体性能 一 一般系统的瓶颈一 一般系统的瓶颈 性能测试调优需要先发现瓶颈 那么系统一般会存在哪些瓶颈 1 硬件上的性能瓶颈 硬件上的性能瓶颈 一般指的是 CPU 内存 磁盘 I O 方面的问题 分为服务器硬件瓶颈 网络瓶颈 对局域网可以不考虑 服务器操作系统瓶颈 参数配置 中间件瓶颈 参数 配置 数据库 web 服务器等 应用瓶颈 SQL 语句 数据库设计 业务逻辑 算法等 2 应用软件上的性能瓶颈 应用软件上的性能瓶颈 一般指的是应用服务器 web 服务器等应用软件 还包括数据库系统 例如 中间件 weblogic 平台上配置的 JDBC 连接池的参数设置不合理 造成的瓶 颈 3 应用程序上的性能瓶颈 应用程序上的性能瓶颈 一般指的是开发人员新开发出来的应用程序 例如 程序架构规划不合理 程序本身设计有问题 串行处理 请求的处理线程不 够 造成系统在大量用户方位时性能低下而造成的瓶颈 4 操作系统上的性能瓶颈 操作系统上的性能瓶颈 一般指的是 windows UNIX Linux 等操作系统 例如 在进行性能测试 出现物理内存不足时 虚拟内存设置也不合理 虚拟内存 的交换效率就会大大降低 从而导致行为的响应时间大大增加 这时认为操作系统 上出现性能瓶颈 5 网络设备上的性能瓶颈 网络设备上的性能瓶颈 一般指的是防火墙 动态负载均衡器 交换机等设备 例如 在动态负载均衡器上设置了动态分发负载的机制 当发现某个应用服务器上 的硬件资源已经到达极限时 动态负载均衡器将后续的交易请求发送到其他负载较 轻的应用服务器上 在测试时发现 动态负载均衡器没有起到相应的作用 这时可 以认为网络瓶颈 性能测试出现的原因及其定位十分复杂 这里只是简单介绍常见的几种瓶颈类型和 特征 而性能测试所需要做的就是根据各种情况因素综合考虑 然后协助开发人员 DBA 运维人员一起定位性能瓶颈 二 一般性能调优步骤二 一般性能调优步骤 一般性能问题调优的步骤 1 步骤一 步骤一 确定问题 应用程序代码 在通常情况下 很多程序的性能问题都是写出来的 因此对于发现 瓶颈的模块 应该首先检查一下代码 数据库配置 经常引起整个系统运行缓慢 一些诸如 oracle 的大型数据库都是需 要 DBA 进行正确的参数调整才能投产的 操作系统配置 不合理就可能引起系统瓶颈 硬件设置 硬盘速度 内存大小等都是容易引起瓶颈的原因 因此这些都是分析的 重点 网络 网络负载过重导致网络冲突和网络延迟 2 步骤二 步骤二 分析问题 当确定了问题之后 我们要明确这个问题影响的是响应时间吞吐量 还是其他问题 是多数用户还是少数用户遇到了问题 如果是少数用户 这几个用户与其它用户的 操作有什么不用 系统资源监控的结果是否正常 CPU 的使用是否到达极限 I O 情况如何 问题是否集中在某一类模块中 是客户端还是服务器出现问题 系 统硬件配置是否够用 实际负载是否超过了系统的负载能力 是否未对系统进行 优化 通过这些分析及一些与系统相关的问题 可以对系统瓶颈有更深入的了解 进而分 析出真正的原因 3 步骤三 步骤三 确定调整目标和解决方案 提高系统吞吐量 缩短响应时间 更好地支持并发 4 步骤四 步骤四 测试解决方案 对通过解决方案调优后的系统进行基准测试 基准测试是指通过设计科学的测试 方法 测试工具和测试系统 实现对一类测试对象的某项性能指标进行定量的和可 对比的测试 5 步骤五 步骤五 分析调优结果 系统调优是否达到或者超出了预定目标 系统是整体性能得到了改善 还是以系统 某部分性能来解决其他问题 调优是否可以结束了 最后 如果达到了预期目标 调优工作就基本可以结束了 下面算是一个技巧 如面试官问到一个性能问题假设 我不知道性能问题出在哪儿时 可 以按照这个思路回答 查找瓶颈时按以下顺序 由易到难 服务器硬件瓶颈 网络瓶颈 对局域网 可以不考虑 服务器操作系统 瓶颈 参数配置 中间件瓶颈 参数配置 数据库 web 服务器等 应 用瓶颈 SQL 语句 数据库设计 业务逻辑 算法等 注 以上过程并不是每个分析中都需要的 要根据测试目的和要求来确定分析的 深度 对一些要求低的 我们分析到应用系统在将来大的负载压力 并发用户数 数据量 下 系统的硬件瓶颈在哪儿就够了 性能测试调优应该注意的要点 要点 1 在应用系统的设计开发过程中 应始终把性能放在考虑的范围内 要点 2 确定清晰明确的性能目标是关键 要点 3 必须保证调优后的程序运行正确 要点 4 系统的性能更大程度上取决于良好的设计 调优技巧只是一个辅助 手段 要点 5 调优过程是迭代渐进的过程 每一次调优的结果都要反馈到后续的 代码开发中去 要点 6 性能调优不能以牺牲代码的可读性和可维护性为代码 三 性能排查分析原则三 性能排查分析原则 分段排除法很有效 分析的信息来源 1 根据场景运行过程中的错误提示信息 2 根据测试结果收集到的监控指标数据 一 错误提示分析 一 错误提示分析 分析实例 1 Error Failed to connect to server 10060 Connection Error timed out Error Server has shut down the connection prematurely 分析 A 应用服务死掉 应用服务死掉 小用户时 程序上的问题 程序上处理数据库的问题 B 应用服务没有死 应用服务没有死 应用服务参数设置问题 例 在许多客户端连接 Weblogic 应用服务器被拒绝 而在服务器端没有错误显示 则有可能是 Weblogic 中的 server 元素的 AcceptBacklog 属性值设得过低 如果连 接时收到 connection refused 消息 说明应提高该值 每次增加 25 C 数据库的连接 数据库的连接 1 在应用服务的性能参数可能太小了 2 数据库启动的最大连接数 跟硬件的内 存有关 2 Error Page download timeout 120 seconds has expired 分析 可能是以下原因造成 A 应用服务参数设置太大导致服务器的瓶颈 B 页面中图片太多 C 在程序处理表的时候检查字段太大多 二 监控指标数据分析 二 监控指标数据分析 1 最大并发用户数 应用系统在当前环境 硬件环境 网络环境 软件环境 参数配置 下能承受的 最大并发用户数 在方案运行中 如果出现了大于 3 个用户的业务操作失败 或出现了服务器 shutdown 的情况 则说明在当前环境下 系统承受不了当前并发用户的负载压力 那么最大并发用户数就是前一个没有出现这种现象的并发用户数 如果测得的最大并发用户数到达了性能要求 且各服务器资源情况良好 业务操作 响应时间也达到了用户要求 那么 OK 否则 再根据各服务器的资源情况和业务 操作响应时间进一步分析原因所在 2 业务操作响应时间 分析方案运行情况应从平均事务响应时间图和事务性能摘要图开始 使用 事务性 能摘要 图 可以确定在方案执行期间响应时间过长的事务 细分事务并分析每个页面组件的性能 查看过长的事务响应时间是由哪些页面组件 引起的 问题是否与网络或服务器有关 如果服务器耗时过长 请使用相应的服务器图确定有问题的服务器度量并查明服务 器性能下降的原因 如果网络耗时过长 请使用 网络监视器 图确定导致性能瓶颈 的网络问题 2 5 10 原则原则 简单说 就是当用户能够在 2 秒以内得到响应时 会感觉系统的响 应很快 当用户在 2 5 秒之间得到响应时 会感觉系统的响应速度还可以 当用户 在 5 10 秒以内得到响应时 会感觉系统的响应速度很慢 但是还可以接受 而当 用户在超过 10 秒后仍然无法得到响应时 会感觉系统糟透了 或者认为系统已经 失去响应 而选择离开这个 Web 站点 或者发起第二次请求 3 服务器资源监控指标 内存 内存 1 UNIX 资源监控中指标内存页交换速率 Paging rate 如果该值偶尔走高 表明当时有线程竞争内存 如果持续很高 则内存可能是瓶颈 也可能是内存访问 命中率低 2 Windows 资源监控中 如果 Process Private Bytes 计数器和 Process Working Set 计数器的值在长时间内持续升高 同时 Memory Available bytes 计数器的值持 续降低 则很可能存在内存泄漏 内存资源成为系统性能的瓶颈的征兆 很高的换页率 high pageout rate 进程进入不活动状态 交换区所有磁盘的活动次数可高 可高的全局系统 CPU 利用率 内存不够出错 out of memory errors 处理器 处理器 1 UNIX 资源监控 Windows 操作系统同理 中指标 CPU 占用率 CPU utilization 如果该值持续超过 95 表明瓶颈是 CPU 可以考虑增加一个处理 器或换一个更快的处理器 如果服务器专用于 SQL Server 可接受的最大上限是 80 85 合理使用的范围在 60 至 70 2 Windows 资源监控中 如果 System Processor Queue Length 大于 2 而处理 器利用率 Processor Time 一直很低 则存在着处理器阻塞 CPU 资源成为系统性能的瓶颈的征兆 很慢的响应时间 slow response time CPU 空闲时间为零 zero percent idle CPU 过高的用户占用 CPU 时间 high percent user CPU 过高的系统占用 CPU 时间 high percent system CPU 长时间的有很长的运行进程队列 large run queue size sustained over time 磁盘磁盘I O 1 UNIX 资源监控 Windows 操作系统同理 中指标磁盘交换率 Disk rate 如果该参数值一直很高 表明 I O 有问题 可考虑更换更快的硬盘系统 2 Windows 资源监控中 如果 Disk Time 和 Avg Disk Queue Length 的值很高 而 Page Reads sec 页面读取操作速率很低 则可能存在磁盘瓶径 I O 资源成为系统性能的瓶颈的征兆 过高的磁盘利用率 high disk utilization 太长的磁盘等待队列 large disk queue length 等待磁盘 I O 的时间所占的百分率太高 large percentage of time waiting for disk I O 太高的物理 I O 速率 large physical I O rate not sufficient in itself 过低的缓存命中率 low buffer cache hit ratio not sufficient in itself 太长的运行进程队列 但 CPU 却空闲 large run queue with idle CPU 4 数据库服务器 SQL Server数据库 数据库 1 SQLServer 资源监控中指标缓存点击率 Cache Hit Ratio 该值越高越好 如果持续低于 80 应考虑增加内存 2 如果 Full Scans sec 全表扫描 秒 计数器显示的值比 1 或 2 高 则应分析你 的查询以确定是否确实需要全表扫描 以及 SQL 查询是否可以被优化 3 Number of Deadlocks sec 死锁的数量 秒 死锁对应用程序的可伸缩性非常 有害 并且会导致恶劣的用户体验 该计数器的值必须为 0 4 Lock Requests sec 锁请求 秒 通过优化查询来减少读取次数 可以减少该计 数器的值 Oracle数据库 数据库 1 如果自由内存接近于 0 而且库快存或数据字典快存的命中率小于 0 90 那么需 要增加 SHARED POOL SIZE