在DB2数据库HADR监控中发现,每天有一段时间,有很多应用处于commit active状态,对应用性能有影响
成都做网站、网站制作的关注点不是能为您做些什么网站,而是怎么做网站,有没有做好网站,给创新互联公司一个展示的机会来证明自己,这并不会花费您太多时间,或许会给您带来新的灵感和惊喜。面向用户友好,注重用户体验,一切以用户为中心。
猜测可能是两种原因造成
日志写的慢
网络通信慢
到底是哪个原因那?用监控数据来说话。
以每5秒钟一次的频率,运行下面的SQL
INSERT INTO temp1 select CURRENT_TIMESTAMP, LOCK_WAIT_TIME ,LOG_DISK_WAIT_TIME,TOTAL_COMMIT_TIME from TABLE(MON_GET_WORKLOAD('',-2)) AS t;
一起运行的还有下面的这个SQL
INSERT INTO temp2 select CURRENT_TIMESTAMP,LOG_WRITE_TIME,LOG_WRITES,LOG_HADR_WAIT_TIME,LOG_HADR_WAITS_TOTAL from table(mon_get_transaction_log(-1)) as t;
表函数的监控,得到的是一个累积值,想办法得到每5秒钟的差值,就可以看到哪一段时间内,数据发生了异常
来自表temp1的数据
TIMESTAMP / LOCK_WAIT_TIME /LOG_DISK_WAIT_TIME/TOTAL_COMMIT_TIME
17:39:16, 0, 2, 3,
17:39:21, 0, 2, 2,
17:39:26, 0, 2, 2,
17:39:31, 0, 4, 4,
17:39:37, 0, 2, 2,
17:39:42, 0, 9, 9,
17:39:47, 0, 3, 3,
17:39:52, 79, 99, 99, <====
17:39:58, 0, 3, 3,
17:40:03, 0, 2, 2,
17:40:08, 1, 4, 4
LOG_DISK_WAIT_TIME和日志写时间,还可能和HADR通信时间相关,在HADR环境下,SYNC或者NEARSYNC模式,Primary端的transaction需要获得Standby端的确认信息以后才能Commit,这个地方就涉及到了HADR的通信。
下一步就要看对于一个transaction,日志写平均需要多长时间,HADR通信需要多长时间
来自表temp2的数据
Log write Time per IOs = LOG_WRITE_TIME(把日志写到磁盘上的时间,单位是微妙) / LOG_WRITES (日志写的次数)
AVG HADR Wait time = LOG_HADR_WAIT_TIME (等待HADR把日志发送完成的时间)/ LOG_HADR_WAITS_TOTAL (总等待次数)
TIMESTAMP /Log write Time per IOs /AVG HADR Wait time
17:39:16, 0.310, 0.041
17:39:21, 0.298, 0.042
17:39:26, 0.308, 0.040
17:39:32, 0.302, 0.072
17:39:37, 0.294, 0.042
17:39:42, 0.342, 0.805<===
17:39:47, 0.326, 0.058
17:39:52, 0.334, 0.485<===
17:39:57, 0.344, 0.064
17:40:02, 0.299, 0.046
通过数据可以看到日志写的时间,没有发生多大的变化,但是HADR的平均等待时间相差很大,下面就需要详细的调查网络问题。
本文标题:DB2HADR性能分析
当前链接:http://lswzjz.com/article/ghpphj.html