mysql卡死,大部分线程长时间处于sending data状态

  • A+
所属分类:数据库技术
首先说明一下,这是个无头的案子,虽然问题貌似解决了,不过到现在我也没有答案,只是把这个问题拿出来晾晾
有台服务器,访问量挺大,每天近250w动态pv,数据库查询平均每秒近600次
另一台服务器,跑的程序跟这台一样,不过只有每天约40w动态pv
前段时间连续卡死过几次,当时的状态是
服务器没崩溃,数据库可正常登陆。只是所有的查询都卡在“sending data”状态,长时间无法执行完,这些简单的sql语句,有时候集中在A表上,有时候集中在B表上,同时还有一些卡死在locked状态或update状态看mysql的说明,sending data状态表示两种情况,一种是mysql已经查询了数据,正在发给客户端;另一种情况是,mysql已经知道某些数据需要去什么地方读取,正在从数据文件中读取

mysql官方说,这不是mysql的bug,但是官方也没说怎么处理......那么,看情况,就应该是配置方面的问题了。
首先从sql优化的角度来查了查,那些卡死的sql语句,都是简单查询,消耗非常低,索引做的非常好,所以觉得应该不是sql语句的问题。而且慢查询日志里也没有出现慢查询。

把表都做了优化,就是optimize table ,过几天发现,还是会出现卡死的情况.....

后来考虑增加并发性能,增加了key_buffer thread_cache 等一系列的内存配置,发现没什么作用。情况依旧

再后来,把query_cache减小到默认值 16M,把一些不怎么变动的数据,做了静态化。惊奇的发现,12天过去了,没再出过问题......

后来想想,修改query_cache可能对这个问题有些帮助,毕竟数据更新比较频繁,query_cache的更新也很频繁。不过看mysql的状态,query_cache的命中率还是相当高的,差不多75%。

觉得问题可能出在程序上,只是没查出来。后来静态化的那些内容,是一些产品的说明文字,一般一个产品的说明也就三五十个汉字。

这里出问题的嫌疑比较大,一个页面有七八个产品,加起来可能三五百个汉字,虽然不多,不过查询很频繁,从这个表上查询的数据量应该是很可观的,mysql会频繁的从这个表拿数据。不过,不过有时候卡死的语句并不是在查询这个表......

手头没有好使的工具,郁闷。反正问题貌似好了,先放下备案吧,等以后水平高些,再来查。

MySQL很容易进程满而死的一个重要原因

建站不容易已经远远超过了我的设想和预期,除了经济上还有技术上的,有些问题不是一般技术人员能解决。不过在这段时间里让我也学会了如何思考问题和解决问题,特别是连续解决了几个问题,可以说真不是开发人员或者别的技术人员能解决的,对此自信心也越来越足了!

谈到这,必须说下我们的站布衣生活网www.yes81.net,基本配置,LINUX 9.0系统,JBOSS42 WEB服务,MYSQL,从五一到现在,运行有段时间了,目前的访问量是4000IP左右。

记得以前发生过一个问题也是检查了好久都没解决的,故障一发生CPU就跑到100%左右,系统没响应,MYSQL、JBOSS进程死。当初是通过对一些大数据表建立索引解决的!这次问题现象和这个有点象,死的时候几乎服务没有响应,通过查看后台MYSQL进程,居然已经超过我设置的1000个限制,第1天我把配置改成3000,想想是否跟这个有关,最近的访问量增大了。说实话,我还是不相信并发1000个连接,但事实摆在面前,现在就是1000个进程堵在这!第2天发现3000也不行了,在进程列表中看到基本上很容易就进程满,而且每个进程都在sending data 状态,查找了2天还是无法解决问题,不论是重新配置启动参数还是检查外来攻击都无法解决,按照一些人的说法,把临时缓冲表增大到512M也是没有任何帮助。象这种的每增加个连接都几乎会卡死,而且是sending data 状态!是数据无法发出还是查询不能完成呢?

带着这个问题,跟开发的沟通,是否存在数据死锁或者没有提交的问题,造成的查询锁死!而且有时候是正常,但大部分是不正常的死锁!查了半天,报告说,程序没发现问题,因为根据命令已经能定位到程序的准确代码上了!那么是什么问题呢?

想起以前MS SQLSERVER2000下曾经发生过的数据库损坏的问题,也尝试了修复。根据堵塞命令集中在几个重要的表上,其一是餐馆信息表(4万条记录),用修复命令都无法修复!发现设置的类型是inoubox ,把类型改成MYISAM 后再修复,修复也没报告什么错误,但重新启动系统后一切问题就解决了!

mysql卡死,大部分线程长时间处于sending data状态