mysql cpu 占用率居高不下,找不到原因

ddouble 发布于 2012/08/28 11:28
阅读 13K+
收藏 4

【华为云1024程序员节·向云而生】预约直播 抽14件华为电子产品礼包!>>>

现场情况概述:
目前我的mysql有三千七百个数据库,仍在增加中,打算让他增长到一万个。

每个数据库不到一百个表,大部分数据库的的容量在300M以下,有众多20M左右的数据库,极少数超过1G。类似于一台服务器多个web站点,每个站点一个数据库,数据库中的表都是自动创建的。

问题是:由于前段时间将mysql5.1升级到5.5,不知道5.5的默认存储引擎是innodb,结果升级后创建的表都变成innodb,原来的表存储引擎是myisam,所以目前大概有一半以上的数据库表都是innodb了。这样却也运行良好了约二十天,直到昨天突然发现 mysql cpu 占用率很高,即使把apache停掉,没有任何请求也一样降不下来,show processlist中也没有死锁的查询。现在已把默认引擎改为myisam,但还没有将大量innodb表转换成myisam。

但是有个现象引起我注意:重启动时 debian-sys-maint 这个用户会运行各种查询很长时间,有的查询会出现 checking permission 状态等待很久,出现 checking permission 时都是在对 information_schema 数据库操作。本以为是这个问题导致cpu占用。可经过漫长的等待后 debian-sys-maint 终于完成任务,cpu占用还是下不来,process list里已经没有耗时查询了。

有人碰到类似问题吗?谢谢大家帮忙分析下,如果需要什么数据,我会贴上来。

还有个问题:mysql从5.1升级到5.5,是否需要做表升级的操作?使用mysqlcheck来做吗?

 

 

以下是问题补充:

@ddouble:解决问题,居然是“闰秒”问题,用 hwclock -s 重置系统时钟后,mysql 占用率立即下降。 (2012/08/30 22:20)
加载中
0
红薯
红薯
debian-sys-maint 这东西是干嘛的呢?
ddouble
ddouble
有没有可能,虽然 process list 为空,但还是有 mysql 内部的什么东西在运行?维护大量的表信息?(因为我这个情形有几十万张表),那个information_schema.tables查询起来很慢,即使 limit 1也几乎无法返回值,但如果限制他的 table_schema='mydb' 为特定数据库,就可以返回了。
红薯
红薯
回复 @ddouble : 那会不会是这个东西引起了,mysql如果没有连接进来,cpu 肯定是会下来的,除非是有后台作业在运行
ddouble
ddouble
比如,如果升级了mysql,重启mysql后,他会一直做 CHECK TABLE `mytable` FOR UPGRADE ,都是自动的。
红薯
红薯
回复 @ddouble : 可它到底在干嘛呢?
ddouble
ddouble
debian-sys-maint 不是我创建的,应该是 debian 发行版创建的用于维护数据库的用户。
0
ddouble
ddouble
贴状态表给大家分析
mysql> show status like 'open%';
+--------------------------+---------+
| Variable_name            | Value   |
+--------------------------+---------+
| Open_files               | 136     |
| Open_streams             | 0       |
| Open_table_definitions   | 400     |
| Open_tables              | 400     |
| Opened_files             | 1241304 |
| Opened_table_definitions | 0       |
| Opened_tables            | 0       |
+--------------------------+---------+


mysql> show status like 'key%';
+------------------------+---------+
| Variable_name          | Value   |
+------------------------+---------+
| Key_blocks_not_flushed | 0       |
| Key_blocks_unused      | 53583   |
| Key_blocks_used        | 9909    |
| Key_read_requests      | 5613490 |
| Key_reads              | 89590   |
| Key_write_requests     | 107111  |
| Key_writes             | 34430   |
+------------------------+---------+

mysql> show status like 'tab%';
+-----------------------+--------+
| Variable_name         | Value  |
+-----------------------+--------+
| Table_locks_immediate | 406255 |
| Table_locks_waited    | 2      |
+-----------------------+--------+

mysql> show status like 'thr%';
+-------------------+-------+
| Variable_name     | Value |
+-------------------+-------+
| Threads_cached    | 6     |
| Threads_connected | 5     |
| Threads_created   | 13    |
| Threads_running   | 4     |
+-------------------+-------+

mysql> show status like '%conn%';
+--------------------------+-------+
| Variable_name            | Value |
+--------------------------+-------+
| Aborted_connects         | 0     |
| Connections              | 865   |
| Max_used_connections     | 13    |
| Ssl_client_connects      | 0     |
| Ssl_connect_renegotiates | 0     |
| Ssl_finished_connects    | 0     |
| Threads_connected        | 7     |
+--------------------------+-------+

mysql> show status like 'thread%';
+-------------------+-------+
| Variable_name     | Value |
+-------------------+-------+
| Threads_cached    | 5     |
| Threads_connected | 6     |
| Threads_created   | 13    |
| Threads_running   | 5     |
+-------------------+-------+

mysql> show status like 'que%';
+---------------+--------+
| Variable_name | Value  |
+---------------+--------+
| Queries       | 428677 |
| Questions     | 124    |
+---------------+--------+
2 rows in set (0.00 sec)


0
枫爱若雪
枫爱若雪
administrator 监控下
ddouble
ddouble
怎么监控,什么软件,能说下吗?
0
ddouble
ddouble

这东西又来了,一直checking permissions 

debian-sys-maint | localhost | NULL          | Query   |  835 | checking permissions | select count(*) into @discard from `information_schema`.`COLUMNS`                

0
桔子
桔子
监控一下慢搜索
ddouble
ddouble
用3秒慢查询监控,一条都没有。
0
磊神Ray
磊神Ray
三千七百个数据库   MySQL压力很大啊
ddouble
ddouble
他们一直相安无事,也不用作跨库查询,只是最近两天情况变奇怪了。
0
deleted
deleted

table_cache过小或者innodb buffer pool相对数据过小不停内存硬盘交换的话倒是有可能, 不过也不至于这么严重

其实我很怀疑你是不是硬盘出坏道了

奇葩100
奇葩100
这个分析很科学,我也怀疑是这个问题。表引擎由myisam转换为innodb,innodb buffer pool默认是没调整的,这个变量的改变如果不合适,会造成频繁的IO,从而,CPU占用就会上升。
0
ddouble
ddouble

终于解决问题,居然是“闰秒”问题,用 hwclock -s 重置系统时钟后,mysql终于走下神坛。如今 top上你来的我往的,只有偶尔会看到 mysql 的身影。

在此感谢大家热情洋溢的回答,红薯反应尤其迅速,如同即时通讯工具:-) 。

 

ddouble
ddouble
回复 @voov : 没思路,google 出来的,搜出各种 mysql cpu 占用率高的情况,逐一比较,分析,尝试。
voov
voov
求分析思路,lz怎么想到时间这块的?谢谢
奇葩100
奇葩100
从7月1号闰秒,你一个月了才解决?你家数据库苦了一个月。 我遭遇闰秒是hadoop集群整体被毁了。
八宝旗
八宝旗
回复 @ddouble : 学习力,楼主厉害
ddouble
ddouble
是的,最后是死马当作活马医的心态试试重置时钟,立马降下来,天气凉快了,心情愉快了。但此问题打算暂时不求甚解了,身心俱疲,需要海吃海睡。
下一页
0
中山野鬼
中山野鬼
楼主有没有查一下 mysql 5.1 5.5关于RTC依赖的差异性? 如果只是恰好到点了,和你版本升级没关系,那你真是可以去买彩票了。哈。我现在还没理解,你的系统的时钟问题,是mysql 的新版本和OS的一些特性有冲突,还是mysql自身的问题,和版本差异无关。
皮总
皮总
这个问题秒杀那些问 “正则表达式” 与问 “SELECT语句” 的问题
0
0000222
0000222
不会Mysql oracle可以帮你看下
返回顶部
顶部