|
||
|
摘要：
前几天接到上级领导的安排，让我去帮忙看看中航油数据库CPU高负荷的情况。在那边和同事黄老分析了索引碎片和表的健壮性等常规问题。没发现可能造成这回高负荷的原因，拿了SQL Server Profiler回来分析后，发现了如下图的情况：频繁的AuditLogout事件造成了CPU时间的大量占用。当有数据库连接建立时，会触发Audit login 事件；而当有某个数据库连接关闭时，将触发Audit logout 事件。为什么会频繁发生AuditLogout事件，当时还没有分析出来。先采用临时方案解决这个问题，就是加大连接池的数量，加长连接池的时间。在ASP.NET Web.config里面的数据库连 阅读全文
posted @ 2012-01-18 14:07 jadesun 阅读(2657) 评论(1) 推荐(0) 编辑
摘要：
近期公文反映会比较慢，和珊姐做了一下监控，返回的监视结果如下。 数据库服务器的CPU消耗时间如下图(2011-08-10 至 2011-08-18号)： 从数据库服务器的CPU消耗时间来看，08-10至08-18号的CPU时间占用始终没有超过20%，服务器的性能很好。但是这段时间频繁的产生性能问题，很诡异。 继续分析珊姐提供的SQL SERVER PROFILE文件。 从Sql Server Profile的监视结果来看，CPU耗时不高，逻辑读也很低，就是总时间消耗得很厉害。这些名词的作用解释如下： CPU时间是等待锁等资源释放、解析、编译查询所需的处理器... 阅读全文
posted @ 2011-08-30 13:47 jadesun 阅读(996) 评论(2) 推荐(0) 编辑
摘要：
同事小红在周五时发了一个SQL优化的事项，因为周五在给新员工培训，所以到今天才给她完成了优化的工作。优化的思路后面再补上，先把优化的脚本发上来。 原来的语句执行时间 DBCC FREEPROCCACHE DBCC DROPCLEANBUFFERS SET STATISTICS TIME ON SELECT cnvcLeadEname FROM tbApproval WHEREcndSpeedTime < cndReplyTime and cnvcReturnFlag = '0' AND cniCommonPartId in ( SELECT cniid FROM tbCo 阅读全文
posted @ 2011-07-31 18:10 jadesun 阅读(396) 评论(11) 推荐(0) 编辑
摘要：
有一个项目的选型，采用了微软提供的ORM框架Entity FrameWork 4.1。经过这些天和同事们的验证和搭建，昨天出来了一个初步的版本。针对该版本我们做了一次并发测试，测试的策略是这样的： 1：LoadRunner模拟一个用户打开页面，该页面中执行一个联表查询，由Entity FrameWork提供出来的数据库操作方法来执行，该方法查询出对象集后，Entity FrameWork将对该对象... 阅读全文
posted @ 2011-07-26 11:56 jadesun 阅读(1864) 评论(3) 推荐(0) 编辑
摘要：
针对大型解决方案的架构设计有了一些进展，继续来做一下总结。 根据项目组中同事提供北京格瑞趋势的资料，我和他们进行了联系，根据他们提供的解决方案，发现能完全满足我们的业务要求。这个产品的简介如下： 1、Moebius采用无共享磁盘架构的设计，结构灵活简单，方便用户将多个中小型服务器组成集群替代大型服务器，实现更高的综合性能；采用和SQL Server高度集成的设计方式，将Moebius 集群的管理工具集成到SQL Server Management Studio中，方便用户操作，轻松部署、维护、管理集群。 2、传统的数据库集群都是保证业务持续可用的，有一个主节点，一个备用节点，如MSCS或者第. 阅读全文
posted @ 2011-07-26 11:44 jadesun 阅读(457) 评论(0) 推荐(0) 编辑
摘要：
周四在新大厦办公，正好遇上老董反映公文查询失败的问题。和小红监视了该查询语句在高峰期间，查询耗时需要40多秒，所以有必要整一整它了。 公文查询功能由于数据的原因，我不能在本地调试，全得由珊姐执行测试的思路。珊姐在执行老董的相关查询之后，返回的系统信息如下： (28 行受影响) 表'tbCommonPart'。扫描计数1，逻辑读取1690869 次，物理读取0 次，预读1 次，lob 逻辑读取0 次，lob 物理读取0 次，lob 预读0 次。 表'Worktable'。扫描计数14，逻辑读取10570670 次，物理读取0 次，预读0 次，lob 逻辑读取0 次 阅读全文
posted @ 2011-07-26 11:43 jadesun 阅读(256) 评论(0) 推荐(0) 编辑
摘要：
自从上回参加培训以后，负载均衡的想法一直在脑子里面挂着。以前的公司和天涯网络社区有业务合作，曾经和他们的技术总监进行过交流，他介绍过天涯的架构，记忆中最深的一句话是，“设计之初就要自问：随着数据规模增加和流量增长能否通过增加新服务器（DB/WEB）解决性能问题”。近期和德哥都在进行一些尝试，形成了下面这样可实现并且低成本的架构图。给各位老大看看缺陷和可提升的地方在哪里，因为我接触这块的信息不多，可使用的方案也就缺乏，让各位老大提一些意见来完善它。 WEB层面： 1，采用Nginx 做WEB服务器的负载均衡控制，为了避免 Nginx 代理服务器的崩溃造成的WEB服务器无法访问，并提高它的可靠性. 阅读全文
posted @ 2011-07-08 09:39 jadesun 阅读(552) 评论(0) 推荐(0) 编辑
摘要：
这两天事情多，没有把这个优化的贴子继续下去。由于集团那边对性能的要求有所提高，所以继续对该功能做优化。
我很认同黄老的想法。第一个是用冗余设计来提升性能。我补充一些，就是做冗余设计时要小心变成过度设计，从而消耗了成本。最近也在想扩展性、性能、成本之间平衡的事，有一个疑问，我们到底要做到什么程度才够？
在项目的后期，大幅度的修改表结构和DA的代码，不利于验收。但这时候我们可以把一些优化的思想沉淀下来，给新的项目参考。所以海航和中航油的优化，都是我们很好的交流媒介。黄老可要继续跟贴啊，也欢迎其它同学参与进来。 阅读全文
posted @ 2011-07-06 17:14 jadesun 阅读(340) 评论(0) 推荐(0) 编辑
摘要：
公文流转优化方案的第三弹，目标是公文跟踪中的“本部门呈报”功能。该功能文秘的使用频繁，而且性能影响很大，早就看它不顺眼了。终于狠下心来解决它。 使用集团机要秘书的账号，模拟查询。SQL SERVER PROFILE 的截图如下： 逻辑读1889568次，将近200万次的逻辑读。测试服务器 10.20.143.166 通过对存储过程的分析，找出核心的SQL语句，执行的效果如下： SET STATISTICS IO ON SET STATISTICS TIME ON SELECT cniId, cnvcTitle, cndSendTime, cnvcSecretaryKind, cnvcSecN. 阅读全文
posted @ 2011-07-06 17:07 jadesun 阅读(374) 评论(0) 推荐(0) 编辑
摘要：
测试数据库： 10.20.143.153;database=dbhnaoa3;uid=sa;pwd=tab,955@loct，目的优化 sp_CreatGetDocuToDoCount 存储过程。 拆分存储过程中的SQL语句，语句一： DBCC FREEPROCCACHE DBCC DROPCLEANBUFFERS SET STATISTICS IO ON SET STATISTICS TIME ON SELECT cnvcLeadEname,Count(cnvcLeadEname) AS iCount FROM DBHNAOA3_2010.dbo.tbAllot tbA WHERE (tb. 阅读全文
posted @ 2011-07-06 17:04 jadesun 阅读(262) 评论(0) 推荐(0) 编辑 |
||