关于mysql内存溢出，请高手支招

ruochen

你使用的kernel是多少？

是的话你在kernel的maillist上问问


确认是kernel的问题后升级下看看

ruochen

我目前也在使用centos 5.2 默认的内核只打了udev的补丁
目前运行半年，没发现内存泄露的问题

小木虫子

不太可能是LINUX系统问题。

你赶紧把GOOGLE的那个插件卸载。

hironics

原帖由 real_lufeng 于 2009-5-7 11:04 发表
早上又仔细的分析了一下，发现了一些新情况
可能我描述的不对，不是mysql内存溢出，而是kernel的内存溢出
摘出一段系统日志，如下

May  3 14:30:07 DST-12 kernel: Node 0 HighMem per-cpu: empty
May  3 ...

你的描述应该没有错，内存溢出是由mysqld引起。

我写了一个简单的测试脚本，你放到mysql里面执行看看，你的my.cnf配置是否超标。

SET @k_bytes = 1024;
SET @m_bytes = @k_bytes * 1024;
SET @g_bytes = @m_bytes * 1024;
SET @innodb_buffer_pool_size = 3 * @g_bytes;
SET @innodb_additional_mem_pool_size = 20 * @m_bytes;
SET @innodb_log_buffer_size = 20 * @m_bytes;
SET @thread_stack = 192 * @k_bytes;

SELECT
      ( @@key_buffer_size + @@query_cache_size + @@tmp_table_size
      + @innodb_buffer_pool_size + @innodb_additional_mem_pool_size
      + @innodb_log_buffer_size
      + @@max_connections * (
              @@read_buffer_size + @@read_rnd_buffer_size + @@sort_buffer_size
            + @@join_buffer_size + @@binlog_cache_size + @thread_stack
        ) ) / @g_bytes AS MAX_MEMORY_USED_GB;

你测试看看。

也许你的Vitural Memory不够。


至于你说的内存泄漏侦测，我给你一个很不负责任的工具Leaktracer，非常好用。
http://www.andreasen.org/LeakTracer/
另外很多人应该用过IBM的purify，也可以。

如果你用的是solaris，或者我可以给你写一个dtrace脚本。

[ 本帖最后由 hironics 于 2009-5-8 14:57 编辑 ]

real_lufeng

该问题解决，引出一个新问题，有兴趣的兄弟可以琢磨一下
这个问题确实是由google的tcmalloc引起的，我把这个插件去掉，重启了mysql。观察了约30小时，确认问题已解决
目前的内存使用情况
Mem:   8174224k total,  6755448k used,  1418776k free,   340204k buffers
Swap:  4192956k total,     7008k used,  4185948k free,  1285500k cached

  PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND                                                               
15213 mysql     15   0 5873m 4.8g 5652 S  212 61.3   1668:10 mysqld  
回楼上的兄弟，你说的那个测试脚本中的那个公式，之前我已测试过，配置文件中配置的内存肯定是不超标的。
内存检测的工具，确实不敢在生产系统上测试。

这个问题可以描述为这样，这是我目前的推测
tcmalloc在为线程分配内存的时候，会比glibc之类的malloc分配的稍微多些，它倾向于稳定，避免大起大落。因为这台服务器非常繁忙(平均每秒约1w次)，而我之前配置的thread_cache_size 偏小，查看status之后发现，threads_created 值非常高，也就是说，mysql线程的重用程度非常低。而每创建一个线程，tcmalloc都会多分配一些内存。线程销毁的时候，可能这稍稍多出来的一部分内存没有收回，也就是泄露了。时间长了，在我这台服务器上，大约4天，就能把8G物理内存加4G swap耗光，造成kernel没有新内存可以用，进而kernel溢出，杀掉占用内存最多的mysqld

现在引伸出来三个新问题，有兴趣的朋友可以琢磨一下
1. 如果thread_cache_size 配置非常大，mysql线程重用程度非常高，应该是可以把内存溢出的过程拖的非常长，比如之前是4天，可能现在400天也不会溢出
2.之前看过有人编译nginx的时候也用tcmalloc ，nginx的线程创建和销毁更为频繁，我怀疑会不会它造成溢出的可能性更高？ 不过话说回来，一般情况下，一个nginx进程占用的内存很小的，只有4~20M，一般服务器也就开几个这样的进程。所以，貌似它能出问题的机会很小
3.我这次在mysql中用tcmalloc，是用preload的方式。不知道用源码，编译的时候把tcmalloc编译进去，是否还会出现这个问题

上面三个问题还没机会测试，希望有兴趣的朋友一起讨论下

枫影谁用了

很好，加精推荐。

Hellex

用key_buffer_size + (read_buffer_size + sort_buffer_size)*max_connections　这个公式算一下就知道会不会溢出了。

要避免溢出，可以设整上述几个参数。

leoxqing

很好，很受用！

bbjmmj

原帖由 枫影谁用了 于 2009-5-9 07:32 发表
很好，加精推荐。

遇到熟人了，跑你这里来骚扰骚扰

这个问题，从一开始就应该猜到，是某些进程或者线程在结束的时候没有彻底释放内存，显然MYSQL那些进程不会随便结束，肯定是进程里面的线程出了问题，没有彻底释放内存，造成吃内存的现象。显然是编译的过程中出了错，加进了跟MYSQL并不相容的东西。

那个内存插件的源码没有看过，估计其实现原理大致是把内存“虚拟化”成什么东西，而MYSQL线程却不能正确识别这个虚拟化了的东西，它以为那是个实体的东西，线程结束了那东西就会自动释放掉，而那东西却并没有自动释放掉，而是等着被释放，于是就线程结束一次吃一点内存，很快吃光所有内存。LINUX的进程机制可以完全保证管理它所使用的内存，但线程机制却不能，线程销毁，线程申请的资源却不会自动销毁。如果这个申请的资源不能被MYSQL内核代码正确识别的话，就成了无法销毁的资源。
但愿上面一段话能有人看懂帮翻译一下~~~

枫影谁用了

原帖由 Hellex 于 2009-5-11 14:59 发表
用key_buffer_size + (read_buffer_size + sort_buffer_size)*max_connections　这个公式算一下就知道会不会溢出了。

要避免溢出，可以设整上述几个参数。

仔细看看前面的回复，跟这个没有直接的关系啦。