解惑

解己之惑,解人之惑

Impossible Is Nothing

今天才算切身的体会到这句话的含义。
最近在进行性能调优,前几天的机会已经非常的好了,从前天开始,很多请求丢失了,使用JMeter做压力测试,很多登陆后请求的页面转向登陆页面了,看了服务器的错误日志,很多都是数据库连接被关闭的问题,刚好前几天性能调优的时候修改了一些相关的东西,就把自己的那些修改都回滚了,但是测试的结果越来越差,到今天早上终于水落石出了:服务器的后台错误日志充斥了如下的错误:
The transaction log for database ‘tempdb’ is full.
上网搜索了下,说一般是磁盘空间不足引起的,远程登陆到数据库服务器一看,什么磁盘空间不足啊,就是没有,剩余磁盘空间为0!!!
把tempdb的数据全部清除,重启,重新测试,结果Perfect,前几天报的一些性能不佳的问题全部没有了,请求丢失的问题也没有了,登出的问题也没有了!
呵呵,一个问题引发无数的问题,在没有严重到磁盘空间满之前,还是其它的错误信息,最终才水落石出。
对了,我们用的数据库是SQL Server,无语

(Visited 81 times, 1 visits today)

7 Comments

  1. 不是SQL SERVER的问题,yours

  2. 呵呵,楼上的说对了

    我们的某种操作会引发tempdb疯狂增长,还没有找到根本的原因。
    下个星期有的忙了

  3. 呵呵,结果出来了。
    最终的原因有几个:
    1。有几个表没有主键,所以在进行更新操作的时候是page lock而不是row lock,而我们的自动测试是多用户多线程的,导致死锁引起temp log持续增加
    2。自动测试的有些case有问题,页面有JS的校验,但是测试脚本绕过了那些校验,到后来提交出错也导致temp log增加
    3。我们的一个存储过程在对于某些大数据用户的时候性能太差,需要很大的temp db空间,使用SQL Server Profiler监控的结果是一个存储过程的执行就导致temp log从0增加到5.87G :em35:

  4. 最后一个原因太牛了:em67:

  5. 呵呵,不是那个存储过程完全不行,而是对于某些特定用户,负责的数据太多了,真实环境不会有,在我们的测试环境下才有,因为我们这几个星期用脚本创建了太多的数据,呵呵

  6. PS:从目前的情况看,SQL Server还是可以的,不是那么烂 :em19:

  7. 个人感觉2005比2000强多了
    Jim Gray在其中的功劳应该很大
    不过现在他失踪了,不知道SQL SERVER会向哪个方向发展

发表评论

电子邮件地址不会被公开。 必填项已用*标注

© 2020 解惑

本主题由Anders Noren提供向上 ↑