mysql突然出现大量慢sql，随后redis访问超时
- - Linux - 操作系统 - ITeye博客在亚马逊云买了多台的虚拟主机，一年多没有由于系统的原因出过故障. 早上接到报警，从业务故障上来看，应该是数据库没有响应了. SSH连数据库服务器，发现连不上. 重启数据库服务器，一直起不来. 最后用上周的数据库服务器的系统备份snapshot（我们的数据盘和系统盘是分开的）新建一个Volume，替换掉故障系统盘，重新启动服务器，才顺利进入系统.
mysql突然出现大量慢sql，随后redis访问超时
标签：
mysql
sql
redis
| 发表时间：2015-07-01 12:19 | 作者：fredlong
出处：http://www.iteye.com
在亚马逊云买了多台的虚拟主机，一年多没有由于系统的原因出过故障。今天碰见了。
早上接到报警，从业务故障上来看，应该是数据库没有响应了。
SSH连数据库服务器，发现连不上。
重启数据库服务器，一直起不来。
最后用上周的数据库服务器的系统备份snapshot（我们的数据盘和系统盘是分开的）新建一个Volume，替换掉故障系统盘，重新启动服务器，才顺利进入系统。在用新的Volume挂靠服务器的时候，一定要记得，设备名称要和原来的系统Volume的名称一致，服务器才能顺利启动：
Root device /dev/sda1
MYSQL服务启动后，所有服务按照顺序重启一遍，业务恢复。
从业务日志上来看，在6月23日22：06分左右出现大量慢sql日志，非常简单的sql语句都会等待10秒以上，随后不久出现大量redis拒绝服务的错误日志。（Redis和数据库服务部署在同一台机器上），最终导致ssh都连接不上，系统处于宕机状态。
分析当时的CPU和磁盘IO都处于健康状态。
分析Linux系统/var/log/message的日志，发现在Jun 23 08:06:33开始就出现JAVA的OOM
Jun 23 08:06:33 App-01 kernel: java invoked oom-killer: gfp_mask=0x280da, order=0, oom_adj=0, oom_score_adj=0
Jun 23 08:06:33 App-01 kernel: java cpuset=/ mems_allowed=0
Jun 23 08:06:33 App-01 kernel: Pid: 30096, comm: java Not tainted 2.6.32-431.17.1.el6.x86_64 #1
然后出现出现各种系统错误日志。
分析/var/log/mysqld.log，发现在23点左右出现以下日志：
InnoDB: Warning: a long semaphore wait:
--Thread 140539730044672 has waited at btr0cur.cc line 257 for 1775.0 seconds the semaphore:
X-lock on RW-latch at 0x7fd1f7f589c0 '&block->lock'
number of readers 0, waiters flag 0, lock_word: 100000
Last time read locked in file btr0cur.cc line 257
Last time write locked in file /home/mysql/storage/innobase/btr/btr0cur.cc line 362
InnoDB: ###### Starts InnoDB Monitor for 30 secs to print diagnostic info:
InnoDB: Pending preads 0, pwrites 0
=====================================
2015-06-23 23:02:52 7fd1eb5fe700 INNODB MONITOR OUTPUT
=====================================
Per second averages calculated from the last 1571 seconds
-----------------
BACKGROUND THREAD
-----------------
srv_master_thread loops: 2215108 srv_active, 0 srv_shutdown, 164283 srv_idle
srv_master_thread log flush and writes: 2379391
----------
SEMAPHORES
----------
OS WAIT ARRAY INFO: reservation count 815307
OS WAIT ARRAY INFO: signal count 905349
Mutex spin waits 13126865, rounds 31704200, OS waits 415905
RW-shared spins 503431, rounds 12970865, OS waits 375385
RW-excl spins 58495, rounds 950616, OS waits 5991
Spin rounds per wait: 2.42 mutex, 25.76 RW-shared, 16.25 RW-excl
------------
TRANSACTIONS
------------
Trx id counter 226393815
Purge done for trx's n:o < 226393810 undo n:o < 0 state: running but idle
History list length 1365
LIST OF TRANSACTIONS FOR EACH SESSION:
---TRANSACTION 226393813, not started
MySQL thread id 18660718, OS thread handle 0x7fd0ec968700, query id 195313941 ip-172-31-7-84.ap-southeast-1.compute.internal 172.31.7.84 admin cleaning up
---TRANSACTION 226393812, not started
MySQL thread id 18660719, OS thread handle 0x7fd1e4e59700, query id 195313940 ip-172-31-7-84.ap-southeast-1.compute.internal 172.31.7.84 admin cleaning up
---TRANSACTION 226393627, not started
MySQL thread id 18660553, OS thread handle 0x7fd1e63ad700, query id 195314129 ip-172-31-7-84.ap-southeast-1.compute.internal 172.31.7.84 admin cleaning up
---TRANSACTION 226393626, not started
MySQL thread id 18660552, OS thread handle 0x7fd1e5cd2700, query id 195314130 ip-172-31-7-84.ap-southeast-1.compute.internal 172.31.7.84 admin cleaning up
---TRANSACTION 226393625, not started
MySQL thread id 18660617, OS thread handle 0x7fd0ec189700, query id 195314208 ip-172-31-7-84.ap-southeast-1.compute.internal 172.31.7.84 admin cleaning up
---TRANSACTION 226393624, not started
MySQL thread id 18660618, OS thread handle 0x7fd0ec148700, query id 195314209 ip-172-31-7-84.ap-southeast-1.compute.internal 172.31.7.84 admin cleaning up
分析结论：
业务高峰期，JAVA/REDIS/MYSQL对服务器内存的需求都到达顶峰（目前JAVA进程的内存没有限制），在所有JAVA进程都没有FULLGC之前，可能会存在一个内存峰值，引发Linux系统开始屠杀进程。
Linux屠杀进程的过程中往往抓个最大的开始搞，mysql，redis就非常容易被搞掉。
因为这些服务还会自动重启，Linux杀着杀着就把自己给杀蒙了，就宕机了。
应对策略：
1.买两台内存更大的服务器作为资源服务器，MYSQL和REDIS从应用应用服务器迁移到资源服务器。
2.对MYSQL和Redis做高可用架构应对单机宕机的情形。
3.调整inux内核信号量默认设置，让MYSQL能撑的时间长一点。
参考文档：
http://www.cnblogs.com/GoodGoodWorkDayDayUp/p/3473348.html
http://blog.csdn.net/wulantian/article/details/37560849
已有 0 人发表留言，猛击->> 这里<<-参与讨论
ITeye推荐
相关 [mysql sql redis] 推荐：
MySql动态SQL
- - SQL - 编程语言 - ITeye博客13.7. 用于预处理语句的SQL语法. MySQL 5.1对服务器一方的预制语句提供支持. 如果您使用合适的客户端编程界面，则这种支持可以发挥在MySQL 4.1中实施的高效客户端/服务器二进制协议的优势. 候选界面包括MySQL C API客户端库（用于C程序）、MySQL Connector/J（用于Java程序）和MySQL Connector/NET.
mysql记录耗时的sql
- - 数据库 - ITeye博客mysql记录耗时的sql. mysql可以把耗时的sql或未使用索引的sql都记录在slow log里，供优化分析使用. 1.mysql慢查询日志启用：. mysql慢查询日志对于跟踪有问题的查询非常有用,可以分析出当前程序里有很耗费资源的sql语句,那如何打开mysql的慢查询日志记录呢. 这说明slow log功能没有启用，要启用需要修改mysql的配置文件，在配置文件"[mysqld]"里添加如下俩参数：.
全国省市县 SQL (mysql)
- - 学习笔记此城市区域内容可以配合ip.taobao.com api 使用.. 有些字段没有添加索引，用的时候根据实际情况做修改. 使用mysql来实现lbs(地理位置服务)功能. 10款对开发者有帮助的Android应用. DeployPHP 系列第 1 部分：优化 PHP 和 Oracle. 在 Oracle 和 PHP 中使用 LOB.
mysql的sql优化(前奏)
- - 数据库 - ITeye博客要优化mysql首先要知道什么地方需要优化，然后才能针对具体问题进行优化. 什么分库分表，建立索引....摆脱不要那么官方好吗. 1.学会和培养使用mysql的查看命令的使用习惯. 什么你忘记如何创建表的语句了. SHOW CREATE TABLE
Name: 'SHOW CREATE TABLE'
Description:
Syntax:
SHOW CREATE TABLE tbl_name
Shows the CREATE TABLE statement that creates the named table.
MySQL SQL Tuning:深入理解Order By
- - CSDN博客数据库推荐文章在MySQL中ORDER BY按先后顺序有2种实现方式，先走索引无排序，如果不行，则用FILESORT. 走索引无排序需要满足2个条件：. ①排序字段和执行计划中所利用INDEX的索引键(或前面几个索引键)完全一致. ②表访问方式为index、ref或range [注释：explain输出中的Type可看出].
Mysql查看sql是否走事务
- - CSDN博客数据库推荐文章可以看到监控日志是否开启的选项（off是关闭）on是开启. 接下来就可以直接进入shell中根据sql特征来查看我们sql会话信息. 126002192 Query select pk fromT_GANTT_CHART where pk =47 for update
//忽略其他的数据了.
利用tcpdump抓取mysql sql语句
- - 学习笔记这个脚本是我之前在网上无意间找个一个利用tcpdump 抓包工具获取mysql流量，并通过过滤把sql 语句输入. 脚本不是很长，但是效果很好. #!/bin/bash
#this script used montor mysql network traffic.echo sql
tcpdump -i eth0 -s 0 -l -w - dst port 3306 | strings | perl -e '
while(<>) { chomp; next if /^[^ ]+[ ]*$/;.
REDIS与MYSQL实现标签的对比
- - CSDN博客推荐文章这里来演示下REDIS和MYSQL之间的数据转换问题，REDIS 是典型的KEY -VALUE型NOSQL数据库，并且提供了额外丰富的数据类型. 这里简单列举了标签类型的应用问题. 比如在MySQL里面，对内容的标签有以下简单的几张表，我这里只列出来拆分过后的表结构. 内容表：
CREATE TABLE `content` (
`id` int(10) unsigned NOT NULL, -- 内容ID，唯一.
SQL监控：mysql及mssql数据库SQL执行过程监控审计
- - Seay's blog 网络安全博客 最近生活有很大的一个变动，所以博客也搁置了很长一段时间没写，好像写博客已经成了习惯，搁置一段时间就有那么点危机感，心里总觉得不自在. 所以从今天起还是要继续拾起墨笔（键盘），继续好好维护这个博客，写出心里最真实的想法，写出平时接触到的一些人和事以及一些新的技术. 当然写博客也不是单纯的为了记录，也想通过博客来结交更多的朋友，今天在公司图书馆看到一句话大致说的是“在今天这个年代，已经很难等到三顾茅庐，诸葛亮也需要博客、微博和影响力”，在一年前就曾想过写一篇关于怎样通过博客来提高个人影响力的文章，我会尽快在这个月抽时间写出来，另外最近也看了几本书，过些时候给大家推荐.