系统慢得一批？看数据库运维老司机如何做优化
|
优化后
 优化阶段二(针对语句) 再次分析解决大面积语句阻塞的系统，发现现在的情况，主要有如下几个： 内存某些时候还是存在波动，但整体IO 内存已经不是瓶颈。 系统中有SLEEPING的程序阻塞时间长 部分功能语句依然慢，消耗的资源很高。 再次对系统调研：
调研后，我遇到了最常见也是最大的问题： 语句慢由于程序。在HIS的优化案例中就是因为程序大量使用自定义函数，我们没法改，我们巧妙的绕过。那么这次我们如何绕过? 一：报表 分析中发现程序系统中消耗最多资源的主要是报表。 报表通过一系列复杂的查询插入到物理临时表，啥叫物理临时表? 就是非#temp 而是真真正正的插入到表中，用完在delete! 插入在删除，中间还有跟业务表关联操作，导致报表也会阻塞业务! 插入删除的数据量是多少? 你们猜一下?? 千万级别.... 二：接口 接口程序中频繁调用业务数据并发更新频繁，导致业务受阻。 三：问题代码 代码的问题主要有两个： 代码较复杂，需要细致优化。 程序中存在连接泄露，简单理解成程序报错后事务不能有效处理，导致事务未提交阻塞系统。
针对第一部分报表，语句更是复杂至极，这东西不是短期就可以优化的，考虑分出去; 针对第二部分接口，修改接口视图，包括写法优化、添加索引、调用频率等; 针对第三部分业务语句进行细致优化，查询提示，计划向导、重编译等等手段。 优化阶段三(报表分离) 经过前两个阶段的优化一般系都会明显好转，只剩报表没有处理，和一部分高消耗的频繁接口查询，这部分我们采用报表分离的方式去解决。 这里面我们遇到一个问题，报表要写物理表。用2012 自带的AlwaysOn是没有办法实现的(辅助节点只能读)。 使用发布订阅，又不能同时满足数据安全和业务连续的要求，客户又不满意。 我们想到是否可以把写入物理表变成写入#temp 临时表? 软件厂商给出的结论是：不可能.... 那这里面我们使用了第三方的产品Moebius集群(这里真的不是广告....) 如何实现： 多活集群，几个节点数据实时一致，这样的基本知识就不普及了...集群介绍也免了; 首先程序只有一个连接字符串没法把报表指向到辅助服务器，我们只能通过Moebius集群的前端调度引擎，定制规则把报表所使用的存储过程定点指向到第二台服务器，解决了程序不能分离的问题。 其次Moebius集群可以实现两个节点都可写，以满足辅助节点报表查询写入物理表的需要。 （编辑：衡阳站长网） 【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容! |
