MySQL服务器似乎总是在某些类型的查询上锁定并停止响应,最终(在没有响应的几分钟后)放弃一个错误"MySQL服务器已经消失“,然后一次又一次地挂在下一组查询上。服务器被设置为从主服务器复制到dbA的从服务器,主要是INSERT语句,每秒5-10行。基于PHP的应用程序正在服务器上运行,该服务器每5-10秒读取新复制的数据,并对其进行处理并存储(插入重复的密钥更新),从而生成一个单独的数据库dbB。所有表都使用MyISAM引擎。web应用程序为用户显示后处理的数据.从基本意义上讲,所涉及的处理步骤是将每秒分辨率的时间序列数据压缩为每分钟、小时和每天的分辨率。
当MySQL锁定时,我执行SHOW PROCESSLIST命令,并看到以下查询:
N User Time Status SQL query
1 system user XX update INSERT INTO `dbA`.`tableA` (...) VALUES (...)
2 ???? XX Waiting for query cache lock INSERT INTO `dbB`.`tableB` (...) VALUES (...) ON DUPLICATE KEY UPDATE ...
3 ???? XX Writing to net SELECT ... FROM `dbA`.`tableA` WHERE ... ORDER BY ..."Time“列将保持同步滴答,直到达到某种查询等待超时,然后我们得到错误"MySQL服务器已经消失”。在5-10秒内,当再次处理新数据时,同样的锁定将发生。查询#1是复制过程。查询2是对后处理数据的更新。查询3是对新复制的数据进行流(未缓冲)处理。最终产生错误"MySQL服务器已经消失“的是查询#3,大概是因为它是第一个超时的查询。
看上去像是死锁,但我不明白为什么。在一个数据库中同时选择和插入似乎会通过在另一个数据库中对重复的键更新插入查询缓存更新而导致死锁。如果关闭复制或查询缓存,则不会发生锁定。平台: Debian 7,MySQL 5.5.31,PHP5.4.4-所有标准包。值得注意的是,几乎相同的应用程序目前在Debian 6、MySQL 5.1.66、PHP5.3.3上运行良好,只是后处理数据使用单独的INSERT和UPDATE查询存储,而不是在重复键更新时插入。
MySQL配置(在Debian 6和7机器上):
key_buffer_size = 2G
max_allowed_packet = 16M
thread_cache_size = 64
max_connections = 200
query_cache_limit = 2M
query_cache_size = 1G任何有关此锁发生原因的提示都将不胜感激!
发布于 2014-10-18 01:36:27
尝试显着减少查询缓存的大小。1G可能太大了。
从16M或32M开始,并相应地调整query_cache_limit (256 K?)-并且在写入时不达到“等待查询缓存锁”的情况下,随着读取性能的提高而往上移动。
“对于过大查询缓存的大小要小心,这可能会增加维护缓存所需的开销,这可能超出启用缓存的好处。几十兆字节的大小通常是有益的。数百兆字节的大小可能不是。”http://dev.mysql.com/doc/refman/5.6/en/query-cache.html。
https://stackoverflow.com/questions/18184282
复制相似问题