北在南方

每天进步一点点

  • 博客访问: 6443532
  • 博文数量: 1008
  • 用 户 组: 普通用户
  • 注册时间: 2009-10-07 13:14
个人简介

MySQL DBA NoSQL DEVOPS

ITPUB论坛APP

ITPUB论坛APP



APP发帖 享双倍积分

文章分类

全部博文(1008)

微信关注

IT168企业级官微



微信号:IT168qiye



系统架构师大会



微信号:SACC2013

订阅
热词专题

分类: MySQL

一  前言
   DBA 运维就是填坑的过程,其他人挖坑,自己填;自己挖坑,自己填,说多了都是泪。好吧言归正传,今天凌晨忙碌了一个通宵做IDC 交互机维护改造以及升级数据库服务器的事情,需要重启服务器。重启完成OS和重新部署数据库周边配套设施之后,系统没有问题,早上8点多开始数据库的error log 一直出现,别问为啥现在才处理(我补觉到11点多 ,13点才到公司。)
  1. 2017-01-10 20:47:45 21194 [Warning] Too many connections
二 排查
  上面的报警信息虽然不严重,但是error log一直有warnning信息写入,总是要解决的。遇到“Too many connections”报错通常的情况是当前的数据库连接数超过了系统 max_connections,max_user_connections 设置的大小。从这方面入手,具体的排查思路。通常会检查
  1 数据库能否登陆,登陆是否会报错,但是登陆db 无异常。
  2 检查 max_connections,max_user_connections的大小配置
  
  3 检查数据库系统的连接分布,如下图 显然都正常的 ,系统配置 4000个连接,单个用户300多个连接 ,远远小于系统设置的值。
  1. SELECT substring_index(host, ':',1) AS host_name,state,count(*) FROM information_schema.processlist GROUP BY state,host_name;

     分析到这里似乎陷入了僵局。在当前连接数 < max_connections 且当前连接数< max_user_connections 的时候,竟然出现了 "[Warning] Too many connections ",于是乎问了其他DBA同行,拓展一下思路,他们也表示差异,也无其他思路。
     和凌晨一起做变更的同事反馈目前遇到的问题,他的提示一语惊醒梦中人---我们启用sql-killer(类似pt-killer实时监测系统,有执行时间超过1.02s左右的sql 就会kill掉)是通过管理端口连接数据库。
     什么是管理端口---在MySQL启动时使用该参数extra_port指定一个端口号(不要和正常的数据库服务端口冲突),Percona Server会监听来自该端口的请求。启用该参数可以解决使用thread_pool特性时,由于所有的连接池worker忙于处理慢querey或者被锁定导致DBA无法通过正常的端口连接DB, 以便DBA可以正常维护数据库。显然使用管理端口的初衷是好的 ,也是避免慢查询堵住数据库,sql-killer可以从管理端口连接到db,然后kill 产生慢查询的会话。
    于是我们把sql-killer 停止,果然 error信息也随之停止。从管理端口方面检查发现 extra_max_connections 重启之后 变为1 ,导致sql-killer请求无法连接,报"Too many connections " 。知道原因之后 就是动态修改实例中的参数,修改配置文件中的参数,然后重启sql-killer ,至此问题解决。
三 小结
     解决这个异常大概花费了大约1.5h,究其原因还是对自己的系统掌握不够,数据库配置文件方面没有进行标准化,导致一系列的后续问题,假如没有同事提醒还有工具通过管理端口进行数据库连接,估计我需要花费更久的时间来排查问题。以后自己要梳理数据库标准化的配置,统一到所有数据库。
     常规的思维解决常规的问题。 
 
阅读(467) | 评论(5) | 转发(0) |
给主人留下些什么吧!~~

jiangnan_ora2017-04-11 17:45:59

杨奇龙:你的 配置 私我一份  qilong.yangql@gmail.com  我看看你的配置 ,你测试sysbench  并发度 32 或者 48  就好了。 生产环境下 并发256 的情况下比较少 。

已发

回复 | 举报

杨奇龙2017-04-10 19:12:08

jiangnan_ora:最近对percona进行了压测,5.7.17和官方的5.7.14对比的,256线程官方6000tps多,percona才4000多,ssd  bf25g,双1,dbsize100g,innodb_io_capacity -2500,不知道为什么percona会差,看percona说明是对官方做了优化的

你的 配置 私我一份  qilong.yangql@gmail.com  我看看你的配置 ,你测试sysbench  并发度 32 或者 48  就好了。 生产环境下 并发256 的情况下比较少 。

回复 | 举报

jiangnan_ora2017-04-10 19:03:36

杨奇龙:不知道你们的环境是怎么样的 ,通常来说都是数据库层都是兼容的,你需要注意你们自己的数据库工具是否有定制 ,是否兼容Percona Server
建议 
1  采用和当前版本一致的 Percona Server
2  先上开发,qa 环境,跑一段时间 再上生产环境

最近对percona进行了压测,5.7.17和官方的5.7.14对比的,256线程官方6000tps多,percona才4000多,ssd  bf25g,双1,dbsize100g,innodb_io_capacity -2500,不知道为什么percona会差,看percona说明是对官方做了优化的

回复 | 举报

杨奇龙2017-01-12 07:39:41

jiangnan_ora:请问percocan上的话要注意什么,最近想换掉官网的,但一直没有用过,还是 有点担心。

不知道你们的环境是怎么样的 ,通常来说都是数据库层都是兼容的,你需要注意你们自己的数据库工具是否有定制 ,是否兼容Percona Server
建议 
1  采用和当前版本一致的 Percona Server
2  先上开发,qa 环境,跑一段时间 再上生产环境

回复 | 举报

jiangnan_ora2017-01-11 22:22:44

请问percocan上的话要注意什么,最近想换掉官网的,但一直没有用过,还是 有点担心。

评论热议
请登录后评论。

登录 注册