站点主题更新

在经历久久的不愿[多半原因是推脱+懒惰在作祟]去修改站点主题的情况下,今天还是最终换了个主题,在此感谢主题作者,胖子马,多谢你的辛勤劳动!

同时记下自己修改的几个地方:

1 修改了本主题下sidebar.php配置文件里的<div id="J_floatDiv">部分,去掉了主页上显示的几个特殊的"gsdgdfgdfh"字符;

2 屏蔽了站点备案,通过修改functions.php来实现;

3 自定义了几个一级菜单,在后台的外观-菜单下来实现的;

4 最为满意的一点就是,将WordPress给汉化了,最初安装的是英文版,现在汉化了,顺带借用了胖子马的这款主题。

说明一点:在满足胖子马的申明下,我在站点页脚的部分保留了胖子马的链接。同时,胖子马的这款主题修复BUG也很快,很快就给出了关于翻页的BUG修复方案,表示支持!接下来,还有一些工作要继续完善,未完待续。

 

开始三个月的欧洲差旅生活

     非技术帖一篇。

     简单记录下这次的差旅生活,北京时间4月22号13:20分从厦门出发,经北京中转到比利时首都布鲁塞尔,最后于当地时间4月23号上午11点到达目的地德国汉堡,开始为期3个月的客户现场实施灾备工作。

     穿插题外话:已经好几年都没有这么长时间出差了,记忆中最近的一次长期出差应该是在2009年,当时从北京到重庆客户现场实施一个银行的外币改造项目,周期半年,再往前数,应该就是07年在沈阳出差的那个项目了。

     而这次的灾备项目周期也不短,为期三个月呢,也就是说要在汉堡呆仨月,不仅工作任务重,项目大,事情多,而且更要快速调整时差,适应这发达的资本主义国家的生活和饮食习惯,以及这汉堡都快5月份了,还贼冷贼冷的天儿。当然,从来了这几天以后,发现这些问题应该都不能叫个事儿,嘿嘿。

     总体感觉,先抑后扬,汉堡的天气比较冷,昼夜温差大,天气真的跟小女人的秉性差不多【在我码出这些文字的时候,窗外已经在下小颗粒的冰雹了,早上出门时还一片晴空,红日当头呢】,房东的那个WiFi也非常不给力,暖气基本到了晚上11点左右,就莫名其妙的凉快了下来。

     那好的地方当然很多了,比如,这边的人都非常文明和礼貌,公交车里绝对不会有像国内那种大声说话,绰着电话在那儿大声嚷嚷的热闹非凡的景象,有的是安静、秩序、真的和谐。

     再比方说,尊重,跟客户闲聊的时候,得知他们部门上上周接待一个当地的初二实习生,他们整个部门都着正装,很正式的接见,回答实习生的所有问题。这要是在天朝,一定以为是在听笑话了吧?

     风景也不错,那就附上昨天下午到汉堡市中心的阿尔斯特湖边用手机抓拍的几张图片:

     <白云、帆船、湖光粼粼>


        <湖边开放草坪>

 

 

 

 

 

 

 

 

 

 

 

 

 

   

关于AWR报告中几个命中率指标的初步解释

            从Oracle 10g开始,Oracle给广大DBA提供了一个性能优化的利器,那便是Automatic Workload Repository性能报告。

            在拿到一份AWR性能报告后,通过分析AWR报告来定位数据库性能问题时,在AWR报告的报告头中,我们会看到类似如下的一些命中率指标:

Instance Efficiency Percentages [Target 100%]

 

Buffer Nowait %: 99.87 Redo NoWait %: 99.95
Buffer Hit %: 95.89 In-memory Sort %: 100.00
Library Hit %: 86.87 Soft Parse %: 99.26
Execute to Parse %: 91.37 Latch Hit %: 99.73
Parse CPU to Parse Elapsd %: 53.78 % Non-Parse CPU: 98.18

 

           那么,这些关于Oracle内存的几个关键指标以及Instance效率的几个指标又该如何理解呢?

           1 这几个指标重要,但是通过这些命中率指标并非就可以定位到问题的关键所在。如上,我们看到各项指标基本都很高,除Parse CPU to Parse Elapsd %:只有53.78%之外,但是,该统计数据是来自于一则生产环境下出现严重性能问题的一个小时采样数据。

           2 分别对上述表格中各项指标作一初步解释:

               ① Buffer Nowait %:表示会话向Database Buffer Cache【数据高速缓冲区】 申请1个缓存时不等待的比例;

               ② Buffer Hit %:表示数据高速缓冲区的命中率,也叫Cache Hit Ratio。该指标要分实际业务系统类型来分析,如OLAP系统,该值可能为20%就算合理,而对于OLTP系统来讲,理想值应该在90%以上。当然,并非该值达到100%就没问题了,系统中可能依然难以避免物理读等待。计算脚本:

SELECT (1 - (phys.value / (db.value + cons.value))) * 100 AS "Buffer Cache Hit Ratio"                                            
FROM   v$sysstat phys,                                    
       v$sysstat db,                                      
       v$sysstat cons                                     
WHERE  phys.name  = 'physical reads'                      
AND    db.name    = 'db block gets'                       
AND    cons.name  = 'consistent gets';                    

               ③ Library Hit %:Library Cache Hit Ration【库高速缓冲区命中率】,表示向共享池的Library Cache中申请1个Library Cache Object对象时,其已经在Library Cache中存在的比例。该指标的一个合理值应该达到95%以上。计算脚本:

SELECT (1 -(Sum(reloads)/(Sum(pins) + Sum(reloads)))) * 100 AS "Library Cache Hit Ratio"                                              
FROM   v$librarycache;                                      

               ④ Execute to Parse %:表示执行解析比,目标是希望一次解析多次执行,计算公式=[1-(parse count (total)/(execute count)]%=[1-1257816/14576118]%=91.37%,其中parse count (total)来源于V$SYSSTAT中的parse count (total)字段值,execute count则取值于execute count的字段值。同时在同一份AWR报告中,parse count (total)execute count的值可以从AWR报告的Instance Activity Stats章节中获取,如下摘录

Instance Activity Stats

  • Ordered by statistic name
Statistic Total per Second per Trans
Batched IO (bound) vector count 560,211 157.69 28.15
CPU used by this session 1,434,831 403.88 72.10
。。。。。 。。。 。。。 。。。
execute count 14,576,118 4,102.96 732.43
。。。。。 。。。 。。。 。。。
parse count (describe) 9 0.00 0.00
parse count (failures) 28 0.01 0.00
parse count (hard) 9,364 2.64 0.47
parse count (total) 1,257,816 354.06 63.20
parse time cpu 26,723 7.52 1.34
parse time elapsed 49,687 13.99 2.50
redo entries 7,072,485 1,990.80 355.38
redo log space requests 3,665 1.03 0.18
。。。。。 。。。 。。。 。。。
sorts (disk) 7 0.00 0.00
sorts (memory) 22,108,325 6,223.16 1,110.92
。。。。。 。。。 。。。 。。。
。。。。。 。。。 。。。 。。。
write clones created in foreground 2,243 0.63 0.11

               ⑤ Parse CPU to Parse Elapsd %:该指标表示解析消耗的CPU时间与解析消耗的总时间的比值,目标同样是100%。我们当然希望解析的过程中,时间都消耗在CPU上,而不希望在解析的过程中,出现其他等待事件而拉长解析消耗的总时间。如果该指标偏低的话,说明在解析的过程中,除了消耗CPU资源外,还有其它等待事件,如等待共享池对象、闩锁。计算公式=[parse time cpu/parse time elapsed]%,parse time cpu和parse time elapsed同样来自于V$SYSSTAT,也可以参照AWR报告中Instance Activity Stats章节中的数据,如:Parse CPU to Parse Elapsd %:=[26723/49687]%=53.78%。

               ⑥ Redo NoWait %:表示会话写Redo Entry时不等待的比例。计算公式=[1-redo log space requests/redo entries]%,同样该两项指标来自于V$SYSSTAT字典表,也可以参照AWR报告中Instance Activity Stats章节中的数据,如Redo NoWait %:=[1-3665/7072485]%=[1-0.0005]%=99.95%。

                ⑦ In-memory Sort %:表示在内存中排序的比例。计算公式=[1-sorts (disk)/sorts (memory)]%,同样该两项指标来自于V$SYSSTAT字典表,也可以参照AWR报告中Instance Activity Stats章节中的数据,如In-memory Sort %:=[1-7/22108325]%=99.9999%。

         

               ⑧ Soft Parse %:表示软解析比例。计算公式=【1-parse count (hard)/parse count (total)】,同样该两项指标来自于V$SYSSTAT字典表,也可以参照AWR报告中Instance Activity Stats章节中的数据,如Soft Parse %:=[1-9364/1257816]%=99.26%。         

               ⑨ Latch Hit %:表示以 willing-to-wait 方式去获取内存栓锁的命中率指标,通常这个指标要求至少在99%以上,否则,很有可能意味着大量栓锁等待,影响性能。该值来源于V$LATCH字典表中的GETS和MISSES字段值计算脚本:

SELECT (1 - (Sum(misses) / Sum(gets))) * 100 AS "Latch Hit Ratio"                               
FROM   v$latch;                              

               ⑩ % Non-Parse CPU:表示除解析之外CPU的使用率,计算公式=【1-(parse time cpu)/(CPU used by this session)】%。同样该两项指标来自于V$SYSSTAT字典表,也可以参照AWR报告中Instance Activity Stats章节中的数据,如% Non-Parse CPU:=[1-26723/1434831]%=98.18%。        

同时遭遇row cache lock和enq: US – contention的等待事件

        上周五,接到项目组同事电话通知,说某客户应用系统无法登陆。我在应用服务器端用PL/SQL Developer尝试连接数据库服务器时,报错“ORA-00018:maximum number of sessions exceeded”,显然又是连接数不够用了。

         就电话回复同事说,赶紧检查一下各应用服务器的连接情况,原因是数据库连接数又不够用了。结果,同事接完电话之后,直接关闭了其中的一台IIS应用服务器,然后再启动这台IIS应用服务器。结果是,应用系统恢复了使用,大约20分钟后,却带了整个数据库的性能急剧下降,数据库Hung住,几乎不可用的状态。

        这是一套Windows 2003+10.2.0.5 X64的双节点RAC系统,接下来,就迅速抓取AWR报告,进行问题的定位:

        节点1的报告头:

  Snap Id Snap Time Sessions Cursors/Session
Begin Snap: 6981 01-3月 -13 14:00:17 64 14.9
End Snap: 6982 01-3月 -13 15:00:13 186 17.2
Elapsed:   59.94 (mins)    
DB Time:   2,215.01 (mins)    

        节点2的报告头:

  Snap Id Snap Time Sessions Cursors/Session
Begin Snap: 6981 01-3月 -13 14:00:14 65 14.2
End Snap: 6982 01-3月 -13 15:14:21 178 25.0
Elapsed:   74.12 (mins)    
DB Time:   2,991.16 (mins)    

        从上可以看到,在每个节点上,这一时段的数据库负载都很高,至少要比正常业务期间负载高出很多。同时,也看到,数据库连接数出现较为不太正常的连接。

       节点1的Top 5事件

Event Waits Time(s) Avg Wait(ms) % Total Call Time Wait Class
db file sequential read 210,093 48,731 232 36.7 User I/O
enq: US – contention 73,040 36,420 499 27.4 Other
log file sync 146,401 14,330 98 10.8 Commit
row cache lock 11,636 13,801 1,186 10.4 Concurrency
CPU time   9,314   7.0  

        节点2的Top 5事件:

Event Waits Time(s) Avg Wait(ms) % Total Call Time Wait Class
row cache lock 33,305 49,524 1,487 27.6 Concurrency
enq: US – contention 94,368 46,710 495 26.0 Other
db file sequential read 450,346 38,795 86 21.6 User I/O
CPU time   16,797   9.4  
direct path write temp 18,587 13,857 746 7.7 User I/O

        看到,在2个节点上均出现了row cache lock和enq: US – contention的等待事件,尤其是第2个节点上更为严重。对于row cache lock等待事件,之前曾遇到过相关案例,原因同样是由于高并发的RAC环境下,sequence没有CACHE,迅速定位并解决了这个问题。

        那么,这个enq: US – contention等待事件究竟是什么呢?Google之,找到了类似的案例:异常终止会话导致系统被Hung,以及ITPUB上的一篇帖子:row cache lock+us contention=宕机
        原来,导致enq: US – contention等待事件的原因是Undo表空间不够导致的。结合上述案例的提示,原来是因为同事直接停止IIS应用服务器,导致Oracle需要回滚之间的事务,这样,如果之前的事务比较大的话,那么整个回滚的时间也将越长。同时,还有一种可能就是,当初的ACTIVE事务因为停止IIS导致了被强制终止,这样一来,该事务占有的回滚段资源没有释放出来。等到IIS重启之后,新连接上来的会话因为事务操作,需要分配新的UNDO表空间,结果导致了enq: US – contention等待事件。

        参照上述的两则案例,找出紧急解决办法,由于是RAC,这里交叉重启了2个节点,最后问题得到解决。         

再次征服厦门国际马拉松全程比赛

       继去年首次参加并完成对2012厦门全程马拉松赛的挑战后,于2013年1月5日再次挑战厦门国际马拉松全程比赛,在此做简单记录。

       成绩比去年稍有提高,去年耗时6时36分,今年在6个小时内完成了比赛,成绩是5时56分,稍有遗憾的是两次参赛,均未顺利获取成绩证书。去年的成绩单是同事代领的,结果他把成绩单落在酒店了,而今年直接忘记去领成绩单了。

       过程回顾:同去年一样,前半程很轻松,甚至在10公里计时器处等后勤同事还意外消耗了有5分钟左右【前10公里穿运动长裤跑的,里面还加穿1条运动短裤,在比赛的过程中感觉很热,就电话约同事在10公里处等我脱裤子再跑,让他帮我拿一下裤子,O(∩_∩)O哈哈~】。没有再出现像去年在22公里到24公里赛程之间的疲劳期,估计也是得益于自己平常晨跑的结果吧。

       赛后感想:

       ①   全程马拉松并不难,不要被40多公里的赛程所吓倒,一咬牙就过去了,真的是这样!

       ②   对于大众而言,成绩并不重要,重要的是参与比赛和日常锻炼身体,尤其是对搞计算机这个行当的人来说更应多锻炼。IT圈时不时蹦出来个“张三李四因工作劳累猝死”之类的消息,确实令人胆寒,我们除了能为那些因为工作而累垮累死的前驱们扼腕叹息之外,我想我们需要做的也能做的就是平时多锻炼身体、珍爱生命、努力工作、热爱生活。

       在这里,给自己参加2014年厦门全程马拉松订一个目标,成绩再提升半小时,争取在5至5个半小时内完成比赛!希望到时候自己可以健健康康的参加比赛,顺顺利利的完成比赛!

       顺祝:自己在2013年里身体健康工作顺利,也祝各位网友在2013年内身体“杠杠”的好,Money多多的来!