疯狂java


您现在的位置: 疯狂软件 >> 新闻资讯 >> 正文

线上MySQL机器内存爆掉原因分析与解决


 

   阿里金融某业务的MySQL机器的内存每隔几天就会增长,涨上去后,却不下来。累积后内存爆掉。

  分析:

  此业务是间隔的对MySQL有大访问,其它时间几乎无访问。排查发现,内存涨时,一般会有MySQL读非常大,主要是InnoDB_DATA_READS。

  结合此时的特性,业务同学给出此时的主要场景:

  1、14个线程并发;

  2、写入数据流程:先查询再update;

  select pid,value from tableName where id=?;

  查不到“id&pid”的记录,执行如下语句

  insert into tableName values ( id,pid,value,now() ) on duplicate key update value=values(value) ;

  查到“id&pid”的记录,执行如下

  update tableName set value= ? where id=? and pid=?;

  在分析过程,我们走了些弯路。现在回想,我们可能会从如下几个方面去思考:

  1、近期升级过kernel,典型的阿里分库分表集群,其中一台升级未升级。所以,新版本内核相关性不大。

  2、innodb内部统计的内存使用量,没有发现异常。

  3、NUMA开关导致swap。这是MySQL swap中经常会讨论到的,但这几台没有开(线上也全部是关掉的)。

  4、临时表、memory引擎表,可能会消耗大量的服务器端的内存,但业务没有用到或生成临时表。

  5、连接所消耗内存。类似key_buffer_size等每个线程所占有的,是我们格外要注意的,但很明显,这点可以否定,因为并发连接一直很小。

  6、table cache相关的内存。这点实现证明,效果非常明显,是我们排查问题的突破点。

  7、真正的mysqld内存泄漏。结合业务的特性,在buglist中发现这个问题在很久很久之前确实存在并早已fix掉。

  执行FLUSH TABLES发现mysqld的RSZ直接减少10G~

  flush之前:

  PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND

  3018 mysql 20 0 44.2g 41g 4232 S 0.0 86.8 981:52.36 /u01/mysql/libexec/mysqld

  $ free -m

  total used free shared buffers cached

  Mem: 48384 46335 2048 0 344 2896

  -/+ buffers/cache: 43094 5289

  Swap: 8191 8 8183

  flush之后:

  PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND

  3018 mysql 20 0 34.7g 30g 4248 S 0.3 65.5 981:55.64 /u01/mysql/libexec/mysqld

  $ free -m

  total used free shared buffers cached

  Mem: 48384 36010 12373 0 345 2898

  -/+ buffers/cache: 32766 15617

  innodb层状态几乎没有变化:

  ———————-

  BUFFER POOL AND MEMORY

  ———————-

  Total memory allocated 26361200640; in additional pool allocated 0

  Dictionary memory allocated 7723336

  Buffer pool size 1572863

  Free buffers 1

  Database pages 1556426

  Old database pages 574520

  Modified db pages 4

  Pending reads 0

  解决方法:

  定时在业务低峰时flush tables或将相关的参数(table_open_cache 和 table_definition_cache)改小(从2048到512或更小)。