【IT168 技术文章】

    常见的性能问题

    1.最重要的性能问题是应用程序设计及与数据库的交互
    应用程序设计：好的应用程序设计可能会获得优秀的响应时间（但不能确保），但差的应用程序设计很难获得好的性能。差的性能设计比如：不管怎么操作，让用户检索出大量结果集（比如50M）的程序运行效率不会高，大量数据的延迟会很明显。
    2.数据库设计
    物理和逻辑设计，涉及非常多的方面，俺也不懂，举一个简单的例子：一个测试问题，大数据量下列表展现（多表联合查询）问题不能满足性能需求。DBA修改了数据库设计采用汇总表去展现列表（单表查询），汇总表也方便创建索引。
    3.参数调整
    4.硬件环境（包括网络对性能的影响会比较大）
    5.其他，因素很多。

    就几个常见的性能问题，举例展开，性能问题非常多，也总结不全面，但可以经常回顾，分类汇总，逐步完善性能问题总结这部分工作。

    一、数据库交互过多

    ?       现象：单个操作发送给数据库sql的数据量过多，数据库延迟。

    ?       发现方法：采用监控工具分析程序与数据库的交互（sql数量和响应时间），比如P6spy及类似工具。

    ?       数据库交互与程序设计方式息息相关

    建议使用P6spy帮助去做数据库交互分析,截获页面操作的sql。

    二、列表效率低

    ?       列表查询未使用索引。

    ?       查询全部字段，而不是所需字段，带来额外的I/O和网络负担。

    ?       分页算法效率低，甚至未使用分页。

    1.查询未使用索引
    此问题比较常见，通过查看sql的执行时间和I/O。查看查询计划可以清楚看出sql是否索引查询，或者全表扫描
     select  ID  。。 from B   where xxx        
    2. 比如 Select xxx  from  where  UPPER(name)＝‘A’
    在字段上使用函数，导致不使用索引，虽然Oracle是有基于函数的索引。更好的方式  a.update现有数据  b.改程序，直接改存储模式为大写的数据。
    3.冗余字段的优化
    select  。。。    from A   where 。。。。比如 where 条件查询的字段的长度较大，创建索引效果后不明显，考虑增加了冗余的字段，进行标识，结合在冗余字段上创建索引会比较快。
    4.分页算法,遇到的状况也比较混乱。。。。。好的分页算法要推广，公用。

    三、查询结果集过大

    ?       返回全部的数据（建议从业务角度出发，分析返回全部的数据是否必要）

    ?       空查询（默认条件查询）
   
    ?       不规范的查询（where 1＝1）

    1.查询结果集（建议从业务角度优化系统）
    2.空查询（默认查询造成压力比较大，其实空查询可能是没有必要的）
    建议页面增加默认过滤条件
    3.Where 1＝1
    a、性能上的影响（可能会影响orale的查询计划）
    b、安全性的影响
    create table A tablespace tbs_temp as  select * from B where 1<>1
    create table A  as  select * from B where 1<>1
    Sybase不支持这样的语法，但是有：
    select * into A from B where 1 <> 1
    where 1 <> 1 ，复制表的结构，但注意这样没有主键
    4.不规范的查询sql很多，建议多参考部门的相关规范，从规范的角度出发去发现问题。

    四、复杂查询sql （大数据量测试）

    ?       复杂查询sql一定在大数据量下进行测试

    ?       结合操作和sql本身效率进行测试。

    ?       建议多与DBA配合

    如果你只使用小表进行测试（比如小于100条数据），那么在真实数据下会异常缓慢直至停滞。Sql的例子就不列出了，比较多，通常对于多表联合查询，复杂的sql都要在大数据量下测试。其实越复杂的东西越难维护和优化，建议对系统中复杂的sql都记录下来，可能是性能隐患。

    五、数据库连接池

    ?           未使用连接池，应用程序在建立数据库连接上消耗的时间较长，影响性能效率。

    ?           连接池配置参数不当（通过测试确定合适的值）
   
    六、并发事务处理和死锁问题
   
    ?         程序对事务并发处理上的错误。

    ?         资源争用引起锁阻塞和死锁。

    ?         SYBASE的锁模式为行锁，可以减小死锁发生的可能性。

    死锁或者锁阻塞，如何检查锁阻塞的大致步骤
    比如mysql 为例子
    1.Show  processlist，查看有locked的进程
    2.查看阻塞进程执行的sql
    3.关掉程序，或者杀死进程，解掉死锁，不建议杀死进程，可能导致不完整的数据。
    4.查看sql问题，单独确认问题
    5.优化sql或者查程序问题

    还以一个实际问题中，sybase锁阻塞的例子
    环境维护发现锁阻塞，发现很慢，检查到有问题的sql
    1. sp_lock 看到死锁
    2.查看阻塞进程信息 
    select  *  from  master..sysprocesses  where ipaddr =‘XXXX‘
    3.造成锁阻塞的进程是spid为  1  和 2 的
    使用dbcc  traceon(3604)
    dbcc sqltext(1)
    dbcc sqltext(2)
    查看到进程执行的sql
    select * from View（视图）   where ID = null （未列出原sql，仅举个例子）
    4.关掉程序，杀死进程，解掉死锁
    单独使用sql adv连接数据库，执行该sql，很慢。
    查看创建View的语法，sybase可以使用sp_helptext View，可以看到建视图的大致的sql是
    create view   as select xxxx   from A ,B  where A.ID*=B.ID and A.C=10
    查看sql的I/O和执行时间 set  statistics time,io on，查看到sql具体的执行时间和I/O
    5.简单看了一下，试着在C字段上增加了索引
    再查询响应时间变小了和查询计划变了，有问题的就是这个查看视图的sql了,可能是资源争用造成了死锁。

    七、页面过大，网络延迟

    ?         页面中图形多且大

    ?         使用比较大的控件等等

    ?         建议参数WEB前端性能优化，推荐Yslow工具

    中国雅虎有相关使用Yslow的一个很好的ppt。建议参考

    八、内存溢出、应用终止、服务器宕机等严重问题

    ?       批量对数据进行操作，会返回大量数据给应用服务器占用了较多的应用服务器的内存，可能会导致应用服务器内存溢出。
   
    ?       消耗服务器某种资源过多的操作可能会使服务器出现宕机和应用终止的情况。

    ?       检查应用程序日志和操作系统的日志或者core文件

    九、参数调整和日志级别设置

    服务器的参数调整不合理。完善性能环境检查的各种checklist。
    生产环境中日志级别应当设置的较高，不打印出sql语句和调试信息，额外的I/O会降低性能效率