今天星期1 ,早上不敢睡懒觉,8:30就到局里了
看看是啥状况,果然不尽人意丫,不光后台的应用慢,前台居然有客户无法登陆系统,shit,赶快看后台到底在作什么,我晕,居然有26个离散读等待,4个latch free等待,兄弟,不是玩我吧,整个数据库的cpu持续是100%的使用率,这有点寒吧.
开始分析为什么这样了,居然发现一个每15分钟执行一次的job,对400w记录的大表进行6次全表,我ft,赶紧联系开发的人,商量了下,给这个东西加了个索引,性能马上上去一半;
在看看另外的,系统居然java thin odbc有30多个连接,其中有一半以上在等待离散读,汗!
马上检查,居然发现等待的语句是一样的,ft,看看表,这个表按照命名规则,应该是个小表,记录不会超过10000条,怎么会这么慢,要说硬盘也是很快的列,再看看,ft,居然有个表176w记录了,没有任何索引,怪不得,联系开发,居然又是把很多的垃圾数据丢在我的数据库中,并且,不删除,而且,开发还和我说,预计这个表中的记录条数不会多的,括弧,如果客户按照我们的流程干活的话,shit,客户按照我们的,那还会有性能问题吗?
讨论了半天,终于改了,现在,应用看起来还是不错的,运行的还比较满意,整个数据库的cpu使用率也下来了.
1 Comment to “济南出差第三日”
Write a comment
You need tologin.
有句话说：一个丑陋的程序员累死三个高级DBA。嘿嘿，现在才一个嘛，而且还没有光荣掉。