万答#3，MGR最佳配置参考，PFS里的监测指标要全开吗，mysqld进程占用内存过高怎么排查
问题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 :)
文章推荐：
扫码添加GreatSQL社区助手微信好友
发送“加群”加入GreatSQL/MGR交流群
想看更多技术好文，点个“在看”吧！