一次mysql瘫痪解救

最近手机app项目访问流量逐步的增长，对服务端webapi考验极大，是在一次新的业务消息推送后，极光推送给手机接受到的客户端达到19万个，此时app立马开始访问速度变慢了，用户体验至关差

客服接到的问题电话开始一个接一个，我一看心想完了，确定是流量起来了，要么是数据库要么是nginx，要么是带宽不够了，这三种可能比较大

因而赶忙解决问题

打开数据库服务监控：进程链接数达到1200个，每一个进程都有sql在处理中。。以下图：

很明显问题出来了，mysql数据库顶不住了，  我这里用的是mysql的分支 percona，抗高并发能力强于官方版本https://www.percona.com/docs/wiki/benchmark:mysql:554-tpcc:start

因而调整参数，而后重启，中间重启出现了一次错误，把我给吓坏了，而后赶忙还原my。cnf，还好每次改的时候会备份一下，否则只有哭了

还原了配置，mysql能够启动了，可是已启动就立刻1200个链接所有被塞满了，app操做依旧慢，个人天，不带这么玩个人，

因而调整参数，而后不重启 用 service mysqld reload 命令来操做

 这里调整好几个参数，都是一点一点的加，结果发现起明显做用的仍是

innodb_buffer_pool_size，innodb_write_io_threads，innodb_read_io_threads，innodb_log_file_size，table_cache

这里要经过监控 看 进程是查询的多仍是 更新写的多，分别来调整innodb_write_io_threads，innodb_read_io_threads
我最高把这两个设置到12，设置完reload，排队的sql进程 很快就由query变成sleep

综合了linux服务器资源使用状况 ，我最后调整成以下配置.

[mysqld]

basedir=/usr/local/mysql
user=mysql
socket=/var/run/mysqld/mysqld.sock

server_id=1

local_infile=1
tmpdir=/mnt/fio

datadir=/mnt/fio320
skip-grant-table

innodb_buffer_pool_size=4G[实际内存8G]

innodb_data_file_path=ibdata1:10M:autoextend
innodb_file_per_table=1
innodb_flush_log_at_trx_commit=1
innodb_log_buffer_size=16M
innodb_log_files_in_group=2
innodb_log_file_size=900M
innodb_thread_concurrency=0
innodb_flush_method             = O_DIRECT

innodb_write_io_threads=9
innodb_read_io_threads=9
innodb_io_capacity=500
innodb_max_dirty_pages_pct=90
max_connections=12000
query_cache_size=0
skip-name-resolve
table_cache=400

调整后reload，瞬间 排队的sql慢慢在减小，进程也开始逐步减小，到130稳定下
再次打开app，速度跟日常速度同样了
用mysqlworkbench 监控，命中率 和buffer使用率达到100%

这里数据库环节优化完了，接下来的思路是要优化sql语句还有java服务程序的性能，用redis来承担频繁的读取，最后同步到mysql