优化mysql的内存
Mysql占用CPU过高的时候,该从哪些方面下手进行优化?
占用CPU过高,可以做如下考虑:
1)一般来讲,排除高并发的因素,还是要找到导致你CPU过高的哪几条在执行的SQL,show processlist语句,查找负荷最重的SQL语句,优化该SQL,比如适当建立某字段的索引;
2)打开慢查询日志,将那些执行时间过长且占用资源过多的SQL拿来进行explain分析,导致CPU过高,多数是GroupBy、OrderBy排序问题所导致,然后慢慢进行优化改进。比如优化insert语句、优化group by语句、优化order by语句、优化join语句等等;
3)考虑定时优化文件及索引;
4)定期分析表,使用optimize table;
5)优化数据库对象;
6)考虑是否是锁问题;
7)调整一些MySQL Server参数,比如key_buffer_size、table_cache、innodb_buffer_pool_size、innodb_log_file_size等等;
8)如果数据量过大,可以考虑使用MySQL集群或者搭建高可用环境。
9)可能由于内存latch(泄露)导致数据库CPU高
10)在多用户高并发的情况下,任何系统都会hold不住的,所以,使用缓存是必须的,使用memcached或者redis缓存都可以;
11)看看tmp_table_size大小是否偏小,如果允许,适当的增大一点;
12)如果max_heap_table_size配置的过小,增大一点;
13)mysql的sql语句睡眠连接超时时间设置问题(wait_timeout)
14)使用show processlist查看mysql连接数,看看是否超过了mysql设置的连接数(http://www.cnblogs.com/kevingrace/p/6226324.html)
下面分享一例遇到过的案例:
网站在高峰时段访问,点击页面有点卡。登陆服务器,发现机器负载有点高,并且mysql占用了很高的CPU资源,如下:
MySQL负载居高不下,如果打开了慢查询日志功能,最好的办法就是针对慢查询日志里执行慢的sql语句进行优化,如果sql语句用了大量的group by等语句,union联合查询等肯定会将mysql的占用率提高。所以就需要优化sql语句
除了优化sql语句外,也可以做一些配置上的优化。在mysql中运行show proceslist;出现下面回显结果:
1.查询有大量的Copying to tmp table on disk状态
明显是由于临时表过大导致mysql将临时表写入硬盘影响了整体性能。
Mysql中tmp_table_size的默认值仅为16MB,在当前的情况下显然是不够用的。
mysql> show variables like "%tmp%";
+-------------------+----------+
| Variable_name | Value |
+-------------------+----------+
| max_tmp_tables | 32 |
| slave_load_tmpdir | /tmp |
| tmp_table_size | 16777216 |
| tmpdir | /tmp |
+-------------------+----------+
4 rows in set (0.00 sec)
解决办法:调整临时表大小
1)进mysql终端命令修改,加上global,下次进mysql就会生效
mysql> set global tmp_table_size=33554432;
Query OK, 0 rows affected (0.00 sec)
再次登陆mysql
mysql> show variables like "%tmp%";
+-------------------+----------+
| Variable_name | Value |
+-------------------+----------+
| max_tmp_tables | 32 |
| slave_load_tmpdir | /tmp |
| tmp_table_size | 33554432 |
| tmpdir | /tmp |
+-------------------+----------+
4 rows in set (0.01 sec)
2)my.cnf配置文件修改
[root@www ~]# vim my.cnf
.....
tmp_table_size = 32M
重启mysql
[root@www ~]# /etc/init.d/mysqld restart
2.show processlist;命令的输出结果显示了有哪些线程在运行,可以帮助识别出有问题的查询语句。比如下面结果:
Id User Host db Command Time State Info
207 root 192.168.1.25:51718 mytest Sleep 5 NULL
先简单说一下各列的含义和用途,
第一列,id,一个标识,你要kill一个语句的时候很有用。
user列,显示单前用户,如果不是root,这个命令就只显示你权限范围内的sql语句。
host列,显示这个语句是从哪个ip的哪个端口上发出的。呵呵,可以用来追踪出问题语句的用户。
db列,显示这个进程目前连接的是哪个数据库 。
command列,显示当前连接的执行的命令,一般就是休眠(sleep),查询(query),连接(connect)。time列,此这个状态持续的时间,单位是秒。
state列,显示使用当前连接的sql语句的状态,很重要的列,后续会有所有的状态的描述,请注意,state只是语句执行中的某一个状态,一个sql语句,已查询为例,可能需要经过copying to tmp table,Sorting result,Sending data等状态才可以完成,
info列,显示这个sql语句,因为长度有限,所以长的sql语句就显示不全,但是一个判断问题语句的重要依据。
常见问题:
一般是睡眠连接过多,严重消耗mysql服务器资源(主要是cpu, 内存),并可能导致mysql崩溃。
解决办法 :
在mysql的配置my.cnf文件中,有一项wait_timeout参数设置.即可设置睡眠连接超时秒数,如果某个连接超时,会被mysql自然终止。
wait_timeout过大有弊端,其体现就是MySQL里大量的SLEEP进程无法及时释放,拖累系统性能,不过也不能把这个指设置的过小,否则你可能会遭遇到“MySQL has gone away”之类的问题。
通常来说,把wait_timeout设置为10小时是个不错的选择,但某些情况下可能也会出问题,比如说有一个CRON脚本,其中两次SQL查询的间隔时间大于10秒的话,那么这个设置就有问题了(当然,这也不是不能解决的问题,你可以在程序里时不时mysql_ping一下,以便服务器知道你还活着,重新计算wait_timeout时间):
MySQL服务器默认的“wait_timeout”是28800秒即8小时,意味着如果一个连接的空闲时间超过8个小时,MySQL将自动断开该连接。
然而连接池却认为该连接还是有效的(因为并未校验连接的有效性),当应用申请使用该连接时,就会导致下面的报错:
The last packet successfully received from the server was 596,688 milliseconds ago.
mysql> show variables like 'wait_timeout';
+---------------+-------+
| Variable_name | Value |
+---------------+-------+
| wait_timeout | 28800 |
+---------------+-------+
1 row in set (0.00 sec)
28800seconds,也就是8小时。
如果在wait_timeout秒期间内,数据库连接(java.sql.Connection)一直处于等待状态,mysql就将该连接关闭。这时,你的Java应用的连接池仍然合法地持有该连接的引用。当用该连接来进行数据库操作时,就碰到上述错误。
可以将mysql全局变量wait_timeout的缺省值改大。
查看mysql手册,发现对wait_timeout的最大值分别是24天/365天(windows/linux)。
比如将其改成30天
mysql> set global wait_timeout=124800;
Query OK, 0 rows affected (0.00 sec)
优化mysql的内存的更多相关文章
- 优化MySQL占用内存过高
打开mysql 的配置文件 my.cnf 查找方式:https://www.cnblogs.com/pxblog/p/13701211.html 在[mysqld]后面修改或添加 # The max ...
- TCMalloc优化MySQL、Nginx内存管理
TCMalloc的全称为Thread-Caching Malloc,是谷歌开发的开源工具google-perftools中的一个成员. 与标准的glibc库的Malloc相比,TCMalloc库在内存 ...
- mysql大内存高性能优化方案
mysql优化是一个相对来说比较重要的事情了,特别像对mysql读写比较多的网站就显得非常重要了,下面我们来介绍mysql大内存高性能优化方案 8G内存下MySQL的优化 按照下面的设置试试看:key ...
- jemalloc优化MySQL、Nginx内存管理
上一篇文章<TCMalloc优化MySQL.Nginx.Redis内存管理>,下面来看下jemalloc jemalloc源于Jason Evans 2006年在BSDcan confer ...
- TCMalloc优化MySQL、Nginx、Redis内存管理
TCMalloc(Thread-Caching Malloc)与标准glibc库的malloc实现一样的功能,但是TCMalloc在效率和速度效率都比标准malloc高很多.TCMalloc是 goo ...
- Mysql占用内存过高的优化过程
一.环境说明: 操作系统:CentOS 6.5 x86_64 数据库:Mysql 5.6.22 服务器:阿里云VPS,32G Mem,0 swap 二.问题情况: 1.某日发现公司线上系统的Mysql ...
- 记一次Mysql占用内存过高的优化过程
一.环境说明: 操作系统:CentOS 6.5 x86_64 数据库:Mysql 5.6.22 服务器:阿里云VPS,32G Mem,0 swap 二.问题情况: 1.某日发现公司线上系统的Mysql ...
- 简单的方式优化mysql
参考博客 自己笔记本上向mysql导入txt数据,有一个table导入了将近4个小时,而且多个table之间都是相互之间存在关系的,所以做联合查询的时候你会发现问题会十分的多,我之前联合查询两个表就死 ...
- MYSQL之性能优化 ----MySQL性能优化必备25条
今天,数据库的操作越来越成为整个应用的性能瓶颈了,这点对于Web应用尤其明显.关于数据库的性能,这并不只是DBA才需要担心的事,而这更是我 们程序员需要去关注的事情.当我们去设计数据库表结构,对操作数 ...
随机推荐
- 第一篇:百问网ubuntu安装注意事项和部分配置
目录 一.开启虚拟化技术 二.ubuntu部分设置 一.开启虚拟化技术 64位机,需要使用cpu-z.SecurAble软件来检查:CPU是否支持VT虚拟化技术 cpu-z使用(软件) 第一步:以 ...
- python新手学习之文件读写之修改
文件除r.w.a方式打开外,还可以有多种组合方式如r+ w+ a+等多种方式 1.r+ 读写模式介绍,开始读是从一行开始读,写永远从最后开始写(类似于追加) # f = open("test ...
- C++中引用的本质分析
引用的意义 引用作为变量别名而存在,因此在一些场合可以代替指针 引用相对于指针来说具有更好的可读性和实用性 swap函数的实现对比: void swap(int* a, int* b) { int t ...
- BZOJ1452_Count_KEY
题目传送门 二维树状数组,对于每个颜色开一个树状数组,用容斥求解. code: #include <cstdio> using namespace std; int read() { ') ...
- OpenCV代码提取:dft函数的实现
The Fourier Transform will decompose an image into its sinus and cosines components. In other words, ...
- Mac下node.js安装与卸载
安装: 访问 http://nodejs.org/ 进入官网,下载 Mac 版本的 node.js,双击打开安装即可. 通过终端输入命令 node -v 验证 node 是否安装正确:npm -v 验 ...
- springboot与activemq的使用
1.springboot和activemq的使用相对来说比较方便了,我在网上看了很多其他的资料,但是自己写出来总是有点问题所以,这里重点描述一下遇到的一些问题. 2.至于activemq的搭建和spr ...
- 强制删除无用old windows文件夹命令
磁盘上有旧系统留下的目录比如old.windows.program files.users(中文目录是用户,删除命令里还是要用user才有效),因为目录的特殊设置,导致无法直接删除,需要修改属性和权限 ...
- dva框架之redux相关
dva封装了redux,减少很多重复代码比如action reducers 常量等,本文简单介绍dva redux操作流程. 利用官网的一个加减操作小实例来操作: dva所有的redux操作是放在mo ...
- 【paging_Class 分页类】使用说明
类名:paging_Class 说明:分页类 注意: 1) 支持百万级数据分页 2) 支持多种类型的SQL语法,比如 Left Join 等. 3) 自动保存查询中的错误情况,记录保存在:/Cache ...