春天来了，花园里开满了花，有梅花，有迎春花，有山茶花，有丁香花，真是太好看了。
有台服务器，访问量挺大，每天近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卡死大部分线程长时间处于sendingdata的状态就介绍到这了。方向对了，剩下的就是坚持。更多相关mysql卡死大部分线程长时间处于sendingdata的状态内容请查看相关栏目，小编编辑不易，再次感谢大家的支持！
