记录一次现网MySQL内存增长超限问题定位过程

问题现象
现网物理机内存近几日内爆涨使用率超过了90%，可用内存从250G，降低到20G以下，报告警。
服务器使用情况来看，并没有什么异常。除了QPS缓慢增长外。

MySQL内存分配结构

定位这个问题，先了解一下MySQL的内存分配知识。

MySQL的内存分配分为两部分，一部分是启动之初就分配的，主要是buffer_pool_size，key_buffer_size(本例256M)等。
还有一部分是每个连接建立并执行查询等操作时分配的。
https://dev.mysql.com/doc/refman/5.6/en/memory-use.html

MySQL的内存分配分为两部分，一部分是启动之初就分配的，主要是buffer_pool_size，key_buffer_size(本例256M)等。
还有一部分是每个连接建立并执行查询等操作时分配的。
https://dev.mysql.com/doc/refman/5.6/en/memory-use.html

每个连接分配的（当有相应的SQL操作时，非活动线程占用的内存很小）
(read_buffer_size+read_rnd_buffer_size+sort_buffer_size+thread_stack+
join_buffer_size+binlog_cache_size)=8M+32M+8M+256K+2M+32K~=51M

但是，需要注意的是，每个连接。有需要的时候会动态的扩展到max_allowed_packet，也即64M。也许这就是文件中很多64M的内存块分配的原因吧？

我猜想是这样，但是实际上确不太正确。因为Threads_connected | 75， Threads_created | 622，状态信息显示所有的连接创建数总共才622个，而且按文档所述连接所用的内存应该主要按照活动的连接进程来计算。 现网即时状态显示，活动连接总计才 Threads_running | 3 个。

max_allowed_packet = 64M
Each thread that the server uses to manage client connections requires some thread-specific space. The following list indicates these and which system variables control their size:
A stack (thread_stack)
A connection buffer (net_buffer_length)
A result buffer (net_buffer_length)
The connection buffer and result buffer each begin with a size equal to net_buffer_length bytes, but are dynamically enlarged up to max_allowed_packet bytes as needed. The result buffer shrinks to net_buffer_length bytes after each SQL statement. While a statement is running, a copy of the current statement string is also allocated.
When a thread is no longer needed, the memory allocated to it is released and returned to the system unless the thread goes back into the thread cache. In that case, the memory remains allocated.

注：还有上面所述的关于read_buffer_size, read_rnd_buffer_size
根据我的经验最大只能配置2M左右。太大了，非但不会提升性能，还会影响性能。

至于原因，记得是在某篇文章里面提到过。不太记得出处在哪了，等我找到了再更新。

但这个参数，我是不打算改了。因为是现网，还有这是客户系统，就算有再充分的原因，没有严重问题也不可能接受你的建议修改的。

用PMAP查看内存具体分配

除了Buffer pool预先分配的内存230G是在已知的情况下。
内存PMAP统计信息显示其中有1659个64M=104G的内存块分配。
问题应该就是出在这里，到底是什么导致很多不同的64M的内存块分配，而且分配后还没有释放？

下一步对策

从前面的分析来看，没有任何一点能解释问题发生的根本原因。
我猜测问题有可能是内存泄露，也许是内存未释放。

那接下来，我们该怎么办呢？目前来看，我几乎没有办法。

内存问题的定位工具，由于现网无法使用。
Valgrind

其实还可以查询一下performance_schema关于内存的统计信息。
但可惜这个是5.7之后的版本才有的功能。现网5.6版本不支持。

最后的办法：
1）在实验室搭建一个和现网一样的环境（数据一样）。但没有流量数据，可能也难以复现问题。
2）升级到5.7，反正早晚都要升级的。升级后，关于内存这一块就可以查看更多的信息了。

注：关于内存不释放我也怀疑过有可能是OS的问题，比如说solaris系统就是如此（属于solaris系统的正常现象）。
https://bugs.mysql.com/bug.php?id=77616

Solaris系统下，当内存被进程主动释放时，OS不会回收内存到OS，只会标记内存为未使用，等下次进程再需要时再指配给进程，这就是所谓内存重用。表向为进程占用内存一直维持高位不会下降。
而Redhat, centos是会把内存回收给OS，表向为进程占用内存下将。现网的机器是centos核的，应该不会有此问题。

MySQL 5.7 performance_schema 内存查询

其它检查项

检查是否有使用内存表，结果是没有(因为只有系统虚内存表)
select * from information_schema.tables where engine='MEMORY‘

检查performance_schema占用内存，结果显示为约为761M
SHOW ENGINE PERFORMANCE_SCHEMA STATUS
Type: performance_schema
Name: performance_schema.memory
Status: 798686336
167 rows in set (0.00 sec）

白高兴

突然有同事告诉我，现网还大量使用了存储过程。这个是我之前忽略的一点。

我一查，是不是有存储过程的Memory leak的BUG？

结果真有。我兴冲冲的用测试机器测试了一下，结果是死活不出现我所期待的现象。

再一查，这个BUG，居然在目前使用的版本之前已经修复了。

https://bugs.mysql.com/bug.php?id=76349

后续

问题定位两天无果。隔了一个周末来看，居然告诉我系统被Monitor重启了，问题没了。

只能等待下次出现问题再说了。

虽然没有定位出问题，但过程也还是很有参考意义的。

问题天天有，世界照样转。不说了，得去别的地方搬砖了。