MySQL 内存监控

上一篇blog介绍了因为sql查询information_schema表而导致内存暴涨的case。

今天顺便做了一个thd内存的监控：

先来介绍下MySQL的内存：

　　1. 线程内内存：thd->mem_root， 线程在执行sql的过程中，申请的内存从thd->mem_root进行分配，在sql结束的时候释放。

　　2. 线程外内存：对象专有的mem_root; 比如，table， table_share，st_transactions等都有专有的mem_root。

所以： 对于sql引起的内存暴涨，可以监控thd->mem_root的变化情况。 但对于其它，比如创建的临时表等，需要另外监控。

在sql/sql_show.cc show processlist调用的函数中添加一个thd_size字段。

最终的结果如下：

　　

变量加锁的问题：

　　1. thd_size的累计在线程内进行累计，所以thd_size的增加和减少不需要使用mutex来进行保护。

　　2. show processlist读的问题：

　　　　因为show processlist命令的线程和thd线程非同一个线程，所以，如果要保证绝对一致，需要使用mutex，这样的话，thd_size 的变化也要加mutex。

而对于内存分配这种，mutex太重，所以加mutex并不合适，性能开销比较大。

所以这里选择了不加锁的模式：

1. 不需要保证thd_size的实时一致。

　　2. 但需要保证thd_size内部一致。

什么是内部一致性？

　　比如：thd_size是long long型变量，在x86-64位的机器上，一共占用64位， 如果出现更改了前4个字节，在更改后4个字节的情况下，读出了数据，那这就是内部不一致。

背景：

　　在x86-64位的机器上，相比较32位多出了8个64bit的通用寄存器，而基本的mov指令也可以支持64bit的操作，所以从机器的指令上保证了c 基本数据类型的内部一致性。但这里读是单指令操作，对于写，仍然是多指令操作：mov+add+mov。

结论：

　　 对于c 的基本数据类型，在不严格的情况下，比如上面的这种情况，读一致性要求不高，而写又不存在并发的情况下，可以不使用mutex进行保护。