[SWAP产生原理] 先从swap产生的原理来分析,由于linux内存管理比较复杂,下面以问答的方式列了一些重要的点,方便大家理解: 1.swap是如何产生的 swap指的是一个交换分区或文件,主要是在内存使用存在压力时,触发内存回收,这时可能会将部分内存的数据交换到swap空间. 2.内存回收的机制 <1>Linux内核使用cache对部分文件进行缓存,提升文件读写效率.所以 引入了kswapd进程进行周期性检查,保证剩余内存空间. <2>当内存分配没有足够的空间时,直接内存回收…

[作者] 王栋:携程技术保障中心数据库专家,对数据库疑难问题的排查和数据库自动化智能化运维工具的开发有强烈的兴趣. [问题描述] 我们知道当mysqld进程使用到SWAP时,就会严重影响到MySQL的性能.SWAP的问题比较复杂,本文会从SWAP的原理开始,分享我们碰到的案例和分析思路. [SWAP原理] swap是把一部分磁盘空间或文件,当作内存来使用.它有换出和换入两种方式,换出是进程把不活跃的内存数据存储到磁盘上,并释放数据占用的内存空间,换入是进程再次访问这部分数据的时候,从磁盘读到内存…

[问题] 有一台MySQL5.6.21的服务器发生OOM,分析下来与多种因素有关 [分析过程] 1.服务器物理内存相对热点数据文件偏小,62G物理内存+8G的SWAP,数据文件大小约550G 触发OOM是binlog备份的cp进程 2.mysqld实际使用物理内存远大于innodb_buffer_pool_size设置,与我们之前分析的内存分配管理模块有关,建议更换为jemalloc 可以参考我之前的文章,MySQL5.7.18(ptmalloc VS tcmalloc VS jemalloc)…

Linux有很多很好的内存.IO调度机制,但是并不会适用于所有场景.对于运维人员来说,Linux比较让人头疼的一个地方是:它不会因为MySQL很重要就避免将分配给MySQL的地址空间映射到swap上.对于频繁进行读写操作的系统而言,数据看似在内存而实际上在磁盘是非常糟糕的,响应时间的增长很可能直接拖垮整个系统.所以,作为运维人员,怎样做到尽量避免MySQL惨遭Swap的毒手将显得尤为重要! SWAP是操作系统虚拟出来的一部分内存地址,它的物理存储元件是磁盘.在备份数据或恢复数据时,文件系统会向L…

有次公司突然断电,导致wamp mysql无法重启 二 分析    初步估计是mysql日志损坏问题,从日志内容分析来看,数据库在机器crash 导致日志文件损坏,重启之后无法正常恢复,更无法正常对外提供服务.三 解决   因为日志已经损坏,这里采用非常规手段,首先修改innodb_force_recovery参数,使mysqld跳过恢复步骤,将mysqld 启动,将数据导出来然后重建数据库.   innodb_force_recovery可以设置为1-6,大的数字包含前面所有数字的影响.   …

[问题] 有台MySQL服务器不定时的会出现并发线程的告警,从记录信息来看,有大量insert的慢查询,执行几十秒,等待flushing log,状态query end [初步分析] 从等待资源来看,大部分时间消耗在了innodb_log_file阶段,怀疑可能是磁盘问题导致,经过排查没有发现服务器本身存在硬件问题 后面开启线程上升时pstack的自动采集,定位MySQL线程等待的位置. [分析过程] 部署了pstack的自动抓取后,出现过6次thread concurrency >=50的告警…

改进动态设置query cache导致额外锁开销的问题分析及解决方法 关键字:dynamic switch for query cache,  lock overhead for query cache 背景 Query Cache是MySQL Server层的一个非常好的特性,对于小数据集或访问量非常集中的应用场景,有非常好的性能提升,内部细节可以参考1,在此处不打算展开Query Cache的一些应用特性. Query Cache引入了一新的问题, 即如果你不想要Query Cache的功能…

前言 压力测试过程中,如果因为资源使用瓶颈等问题引发最直接性能问题是业务交易响应时间偏大,TPS逐渐降低等.而问题定位分析通常情况下,最优先排查的是监控服务器资源利用率,例如先用TOP 或者nmon等查看CPU.内存使用情况,然后在排查IO问题,例如网络IO.磁盘IO的问题. 如果是磁盘IO问题,一般问题是SQL语法问题.MYSQL参数配置问题.服务器自身硬件瓶颈导致IOPS吞吐率问题. 本文主要给大家介绍的是关于MySQL服务器 IO 100%的分析与优化方案,下面话不多说了,来一起看看详细的…

今天,有个哥们碰到一个问题,他有一个从库,只要是启动MySQL,CPU使用率就非常高,其中sys占比也比较高,具体可见下图. 注意:他的生产环境是物理机,单个CPU,4个Core. 于是,他抓取了CPU的历史信息,发现CPU飙高大概是从2017年1月1日8点10分开始的. 但是这个从库的负载并不高,通过他反馈的"show processlist"和"show engine innodb status\G"的结果可以看出来 show processlist mysql…

最近我们有台 mysql 服务器一直报负载过高,不停的收到阿里云的报警短信,让我很抓狂,登陆上服务器,看下一下,慢查询日志 发现有60多万的慢查询日志,一看这个就知道是搜索带来的,一直想把搜索的服务给弄出来单独用elasticsearch 来做搜索服务,业务太忙,还没有来得及去架构, 再查了一下nginx 的日志: 果然是恶意搜索引过来的,一开始想的是屏蔽 ip,发现他用的代理,ip有点多,但是我们发现,user-agent 是;Apache-HttpClient/4.3.1 (java 1.5…