美文网首页
万答#3,MGR最佳配置参考,PFS里的监测指标要全开吗,mys

万答#3,MGR最佳配置参考,PFS里的监测指标要全开吗,mys

作者: GreatSQL | 来源:发表于2021-12-30 14:43 被阅读0次
    • GreatSQL社区原创内容未经授权不得随意使用,转载请联系小编并注明来源。

    问题1,有推荐的MGR运行最佳配置参考吗

    在「3306π」社区广州站5月22日的分享会上,万里数据库CTO娄帅给出了他建议的配置参考,我们一起来看下:

    group_replication_single_primary_mode=ON
    log_error_verbosity=3
    group_replication_bootstrap_group=OFF 
    group_replication_transaction_size_limit=<默认值150MB,但建议调低在20MB以内,不要使用大事务>
    group_replication_communication_max_message_size=10M
    group_replication_flow_control_mode=OFF #官方版本的流控机制不太合理,其实可以考虑关闭
    group_replication_exit_state_action=READ_ONLY
    group_replication_member_expel_timeout=5 #如果网络环境不好,可以适当调高
    

    另外,使用MGR的其他建议有:

    • 只是用InnoDB表。

    • 每个表都必须要有主键。

    • 节点数采用奇数。

    • 保证网络可靠性,低延迟环境,不要跨城部署(一般建议网络延迟低于1ms)。

    • 使用单主模式。

    • BINLOG_FORMAT=ROW。

    更多关于MGR的最佳使用实践,可以关注「3306π」社区公众号(pai3306),获取娄帅老师本次分享内容。

    问题2,MySQL Performance Schema都建议开启哪些监控采集指标(除了默认自动开启的指标)

    先说我的看法:一般建议只开启锁(Lock)监控相关的监测指标。

    # 开启MDL监测指标
    mysql> CALL sys.ps_setup_enable_instrument('wait/lock/metadata/sql/mdl');
    
    # 开启全部Lock相关监测指标
    mysql> CALL sys.ps_setup_enable_instrument('%lock%');
    

    其余的监测指标,例如Memory、Statement、Transaction等,有必要再临时开启。因为从MySQL 5.7开始,PFS支持在线动态开启和关闭,因此非必要的话,不建议一口气全开。

    一般而言,PFS里的监测指标全开的话,对性能影响一般5%左右,内存消耗1G左右,整体还是可控的。

    已知的问题是在Percona分支版本中,如果同时开启PFS和线程池后,很容易发生OOM。

    小结:

    • 需要的话,可以全开。

    • 对性能影响有限。

    • 但还是建议只开锁监控相关的。

    问题3,mysqld进程占用内存过高怎么排查

    遇到一个比较极端的案例,innodb_buffer_pool_size 值仅设置为2GB,但是mysqld进程却占用了25GB的内存。

    PID USER      PR  NI    VIRT    RES    SHR S  %CPU %MEM     TIME+ COMMAND
    45305 mysql     20   0   28.4g    25g   8400 S  48.5 81.4  64:46.82 mysqld
    

    后面会有专门的文章介绍详细分析排查过程,这里先直接说可能的原因以及解决方案。

    可能的原因

    1、session(会话)级内存buffer参数设置过高,并且连接数也设置过高,例如

    read_buffer_size = 64M
    read_rnd_buffer_size = 32M
    sort_buffer_size = 64M
    join_buffer_size = 64M
    tmp_table_size = 1G
    max_heap_table_size = 1G
    max_connections=2000
    

    当连接数较少时,需要消耗的内存并不多。

    但是当遇到突发流量时,可能并发连接数会接近打满,再加上可能有产生临时表、额外排序的低效率的SQL频繁出现,这就很容易导致内存占用快速增长。

    因此建议调低session级buffer参数值,并有效控制并发连接数,下面是一个比较通用的设置值参考:

    read_buffer_size = 4M
    read_rnd_buffer_size = 4M
    sort_buffer_size = 4M
    join_buffer_size = 4M
    tmp_table_size = 32M
    max_heap_table_size = 32M
    max_connections = 512
    

    2、PFS中开启过多检测指标,造成内存消耗过大。

    在上面也提到过,全部开启PFS后,可能需要大约1GB内存。不过在高并发并伴随频繁低效SQL的情况下,可能需要消耗更多内存。

    3、可能还用到MyISAM引擎,并且 key_buffer_size 设置过大。

    不过现在MyISAM引擎大家一般用得也比较少了。

    4、程序内存泄漏风险。

    可以用valgrind工具检验是否存在这个问题,如果确定的话,可以考虑升级MySQL版本,或者定期在维护时间重启mysqld实例,或者通过高可用切换方式将有风险的实例重启。

    5、glibc的内存管理器自身缺陷导致。

    简言之,就是调用glibc申请的内存使用完毕后,归还给OS时没有被正常回收,而变成了碎片,随着碎片的不断增长,就能看到mysqld进程占用的内存不断上升。这时候,我们可以调用函数主动回收释放这些碎片。

    PID USER      PR  NI    VIRT    RES    SHR S  %CPU %MEM     TIME+ COMMAND
    45305 mysql     20   0   28.4g    25g   8400 S  48.5 81.4  64:46.82 mysqld
    
    [root@mysql#] gdb --batch --pid `pidof mysqld` --ex 'call malloc_trim(0)'
    
      PID USER      PR  NI    VIRT    RES    SHR  S  %CPU %MEM     TIME+ COMMAND
    45305 mysql     20   0   28.4g    5.2g   8288 S  2.7  17.0  64:56.82 mysqld
    

    这就像是在InnoDB表中产生太多碎片后,我们主动执行 OPTIMIZE TABLE 重建表的做法。

    Enjoy MySQL :)

    本文由博客一文多发平台 OpenWrite 发布!

    相关文章

      网友评论

          本文标题:万答#3,MGR最佳配置参考,PFS里的监测指标要全开吗,mys

          本文链接:https://www.haomeiwen.com/subject/gybiqrtx.html