战场原黑仪是我的!

活在2.5次元~\(≧▽≦)/~的,已弃疗_(:з」∠)_的,懒癌晚期╮(╯_╰)╭患者

  • 博客访问: 1105143
  • 博文数量: 95
  • 用 户 组: 普通用户
  • 注册时间: 2014-02-28 10:18
个人简介

活在2.5次元~\(≧▽≦)/~

ITPUB论坛APP

ITPUB论坛APP



APP发帖 享双倍积分

文章分类

全部博文(95)

文章存档

2017年(5)

2016年(25)

2015年(49)

2014年(16)

微信关注

IT168企业级官微



微信号:IT168qiye



系统架构师大会



微信号:SACC2013

订阅
热词专题

分类: MySQL

-------------------------------------------------------------------------------------------------正文---------------------------------------------------------------------------------------------------------------
接前文: http://blog.itpub.net/29510932/viewspace-2129312/

场景 :
MySQL-5.7, 所有的小版本(<=17), percona-mysql-5.7所有版本;
开启多源复制的只读实例的内存无限增长, 直到触发系统的OOM Kill;

结论 :
mysql bug, 附上bug单链接: https://bugs.mysql.com/bug.php?id=85371

现象描述 :
内存监控如图


问题原因:
目前只能基于现象来分析;

开启binlog_rows_query_log_events之后, 启用多源复制的slave会出现内存泄漏; 
表现为内存使用率不断增长: 占用内存的为slave_sql线程, 数据库事件为memory/sql/Log_event;


相关数据(来源于截图中的实例): 
重启只读slave之后, 相关事件的内存使用: 
申请了内存,但是没有释放过: COUNT_FREE, SUM_NUMBER_OF_BYTES_FREE为0


点击(此处)折叠或打开

  1. *************************** 2. row ***************************
  2.                    THREAD_ID: 18189
  3.                   EVENT_NAME: memory/sql/Log_event
  4.                  COUNT_ALLOC: 521692
  5.                   COUNT_FREE: 0
  6.    SUM_NUMBER_OF_BYTES_ALLOC: 117988604
  7.     SUM_NUMBER_OF_BYTES_FREE: 0
  8. ...
  9.     LOW_NUMBER_OF_BYTES_USED: 25286276
  10. CURRENT_NUMBER_OF_BYTES_USED: 117988604
  11.    HIGH_NUMBER_OF_BYTES_USED: 117988604
  12. *************************** 3. row ***************************
  13.                    THREAD_ID: 18183
  14.                   EVENT_NAME: memory/sql/Log_event
  15.                  COUNT_ALLOC: 521426
  16.                   COUNT_FREE: 0
  17.    SUM_NUMBER_OF_BYTES_ALLOC: 117732632
  18.     SUM_NUMBER_OF_BYTES_FREE: 0
  19. ...
  20.     LOW_NUMBER_OF_BYTES_USED: 25154914
  21. CURRENT_NUMBER_OF_BYTES_USED: 117732632
  22.    HIGH_NUMBER_OF_BYTES_USED: 117732632

两小时以后:


点击(此处)折叠或打开

  1. *************************** 1. row ***************************
  2.                    THREAD_ID: 18189
  3.                   EVENT_NAME: memory/sql/Log_event
  4.                  COUNT_ALLOC: 2297022
  5.                   COUNT_FREE: 0
  6.    SUM_NUMBER_OF_BYTES_ALLOC: 525744164
  7.     SUM_NUMBER_OF_BYTES_FREE: 0
  8. ...
  9.     LOW_NUMBER_OF_BYTES_USED: 25286276
  10. CURRENT_NUMBER_OF_BYTES_USED: 525744164
  11.    HIGH_NUMBER_OF_BYTES_USED: 525744164
  12. *************************** 2. row ***************************
  13.                    THREAD_ID: 18183
  14.                   EVENT_NAME: memory/sql/Log_event
  15.                  COUNT_ALLOC: 2296412
  16.                   COUNT_FREE: 0
  17.    SUM_NUMBER_OF_BYTES_ALLOC: 524600639
  18.     SUM_NUMBER_OF_BYTES_FREE: 0
  19. ...
  20.     LOW_NUMBER_OF_BYTES_USED: 25154914
  21. CURRENT_NUMBER_OF_BYTES_USED: 524600639
  22.    HIGH_NUMBER_OF_BYTES_USED: 524600639

event对应的线程:


点击(此处)折叠或打开

  1. *************************** 1. row ***************************
  2.         thd_id: 18183
  3.        conn_id: 18158
  4.           user: sql/slave_sql
  5.        command: Sleep
  6.          state: Slave has read all relay log; waiting for more updates
  7. current_memory: 532.28 MiB
  8. *************************** 2. row ***************************
  9.         thd_id: 18189
  10.        conn_id: 18164
  11.           user: sql/slave_sql
  12.        command: Sleep
  13.          state: Slave has read all relay log; waiting for more updates
  14. current_memory: 533.50 MiB
  15. 2 rows in set (0.10 sec)

解决方案 :
关闭binlog_rows_query_log_events(默认就是关闭的),
实际上这个参数主要是控制binlog中是否记录原始SQL语句的, 主要是Debug用;
而平时用-vv来解析binlog以后, 本身也会注明row模式中的SQL语句, 可读性也还可以接受;


这个bug目前是S2(Serious)

关闭这个配置以后, 内存变化如上图的后半部分, 基本可以看到不再有明显的上升趋势;
需要注意的是, 并不一定就不再有内存泄漏的问题了, 希望官方早日修复~

PS: Null的测试继续拖, 写不动写不动写不动_(:з」∠)_
阅读(1820) | 评论(0) | 转发(0) |
给主人留下些什么吧!~~

杨奇龙2017-04-23 22:12:18

PS: Null的测试继续拖, 写不动写不动写不动_(:з」∠)_

评论热议
请登录后评论。

登录 注册