MySQL服务器SWAP使用率高导致db很慢很卡

环境介绍:

CentOS:6.X

MySQL版本:5.5.40

故障原因分析:

物理内存是16G,swap是4G。此时MySQL本身已经占用了14G物理内存,而同时其他应用程序或者系统进程又需要3G内存,这时候操作系统就可能把MySQL所拥有的一部分地址空间映射到swap上去,有可能产生swap的操作事件:

产生的主要原因:

1.mysqldump以及mysql import很大的库或者表;

2.数据库层大批量的并发操作的io writer和io read操作;

3.在OS层copy一个大文件,比如上百GB的数据库备份文件。

通常的解决办法:

1.释放SWAP空间

#swapoff -a

然后开启swapon

#swapon -a

2.添加MySQL的配置参数memlock

这个参数会强迫mysqld进程的地址空间一直被锁定在物理内存上

设置max locked memory

#echo "mysql            hard    memlock        unlimited ">> /etc/security/limits.conf

#echo "mysql            soft    memlock        unlimited ">> /etc/security/limits.conf

3.修改内核参数

#echo "vm.swappiness=0" >>/etc/sysctl.conf

4.修改my.cnf参数:

修改my.cnf里面的innodb_flush_method参数,开启O_DIRECT模式。

5.使用大页内存。

参考链接:http://blog.csdn.net/jacson_bai/article/details/44755109

时间: 2024-11-08 00:03:01

MySQL服务器SWAP使用率高导致db很慢很卡的相关文章

后台服务器CPU使用率高 问题分析方法

一.找出cpu使用率高的进程和线程: a.将 cpu 占用率高的线程找出来: ps H -eo user,pid,ppid,tid,time,%cpu,cmd--sort=%cpu b.对于多线程的服务,通过top命令得到cpu使用率高的进程后,可以使用如下命令查看该进程下各线程cpu使用率 ps -eLo pid,lwp,pcpu | grep PID c.直接使用 ps Hh -eopid,tid,pcpu | sort -nk3 |tail 获取对于的进程号和线程号 二.gdb调试cpu使

性能测试 | 服务器CPU使用率高分析实例

前面我们讨论系统调用的时候结论是耗时200ns-15us不等.不过我今天说的我的这个遭遇可能会让你进一步认识系统调用的真正开销.在本节里你会看到一个耗时2.5ms的connect系统调用,注意是毫秒,相当于2500us! 问题描述 当时是我的一个线上云控接口,是nginx+lua写的.正常情况下,单虚机8核8G可以抗每秒2000左右的QPS,负载还比较健康.但是该服务近期开始出现一些500状态的请求了,监控时不时会出现报警.通过sar -u查看峰值时cpu余量只剩下了20-30%. 图3.jpg

找出导致Mysql机器IO过高的SQL

近期一次mysql机器io过高导致入库缓慢,这里记录下解决和问题查找的过程. 首先通过top看到wa比较高,wa意思是CPU花在等待IO上的时间占比, 进而通过iostat -x 2看到如下图, rrqm/s:   每秒进行 merge 的读操作数目.即 delta(rmerge)/swrqm/s:  每秒进行 merge 的写操作数目.即 delta(wmerge)/sr/s:           每秒完成的读 I/O 设备次数.即 delta(rio)/sw/s:         每秒完成的

Oracle数据库所在服务器swap严重

今天Nagios监控发现一台Oracle数据库服务器swap严重,导致部分Nagios监控项超时报警 查看该服务器,swap空间设置为32G,已使用19G,使用率非常高,并且,vmstat显示si严重 此服务器物理内存32G,SGA设置20G,连接数不高,即使设置不当,也不应该出现如此严重的swap cat /proc/meminfo 发现此服务器设置了HugePage,但状态均为Free 我们知道HugePage设置后,即使不使用它,所占的内存空间也不能被其他进程使用,并且,HugePage是

一个查询交易导致数据库CPU使用率高的问题

这一阵子在做一个查询交易的压力测试,使用的AIX+informix数据库.应用和数据库分别部署在两台机器上.使用loadrunner进行并发测试.相关表的历史数据是20W级别的.使用20个并发进行测试. 测试过程中,应用服务器负载正常,数据库服务器磁盘.网络使用率正常,但是CPU使用率却是98%左右.觉得很奇怪,因为这台机器是测试环境中性能最好的,表现不应该如此.于是先猜测会不会是informix的参数配置不对,于是搜了些informix参数中影响CPU使用率的参数调了一遍,但是现象依旧.对里面

mysql 群集架构mmm高可用群集及服务器上线

MMM即Multi-Master Replication Manager for MySQL:mysql多主复制管理器,基于perl实现,关于mysql主主复制配置的监控.故障转移和管理的一套可伸缩的脚本套件(在任何时候只有一个节点可以被写入),MMM也能对从服务器进行读负载均衡,所以可以用它来在一组用于复制的服务器启动虚拟ip,除此之外,它还有实现数据备份.节点之间重新同步功能的脚本. 优点:高可用性,扩展性好,出现故障自动切换,对于主主同步,在同一时间只提供一台数据库写操作,保证的数据的一致

mysql占用服务器cpu过高的原因以及解决办法

排查方法 : > mysql -uroot -p      #登陆数据库 >********                    #输入数据库密码 mysql> show processlist; show processlist 命令详解: processlist命令的输出结果显示了有哪些线程在运行,可以帮助识别出有问题的查询语句. +-----+-------------+--------------------+-------+---------+-------+--------

MySQL 实例空间使用率过高的原因和解决方法

用户在使用 MySQL 实例时,会遇到空间使用告警甚至超过实例限额被锁定的情况.在 RDS 控制台的实例基本信息中,即会出现如下信息: 本文将介绍造成空间使用率过高的常见原因及其相应的解决方法.对于MySQL 5.6版本的实例,升级实例规格和存储空间后即可解锁实例,关于如何升级实例配置,请参见变更配置. 常见原因 造成 MySQL 实例空间使用率过高,主要有如下四种原因: Binlog 文件占用高. 数据文件占用高. 临时文件占用高. 系统文件占用高. 查看空间使用状况 您可以通过 DMS 中的

(原创)性能测试中,Oracle服务器定位CPU使用率高的瓶颈(SQL)

本篇博客记录一次性能测试过程中,定位对CPU使用率高的瓶颈问题,主要定位SQL为准 一.用SQL命令定位1.首先用TOP命令监控系统资源,如果是AIX系统,就用topas,进入TOP命令的滚动刷新数据时,发现userCPU高达98%!! 保持top的状态下,按shift+p,可以将所有进程按CPU使用率高低排序,这样可以了解消耗CPU最多的进程是哪些 可以看到,当前userCPU使用率高达98%,且此时TPS不再随并发数上升了,可以认为已经达到性能瓶颈了,且是由CPU瓶颈造成的 2.排序完后,将