Chinaunix

标题: 关于mysql内存溢出，请高手支招 [打印本页]

作者: real_lufeng 时间: 2009-05-06 17:42
标题: 关于mysql内存溢出，请高手支招
有台服务器，只运行了一个mysql
服务器配置两颗4核E5410 8G内存 146G sas 15k转速的硬盘
系统为centos 5.2 64位
mysql 5.1.32 64位
平均每秒约1w次查询，优化的还不错，性能很好，负载4左右也很稳定
加载了google的 tcmalloc
现在的问题是，不知道什么原因，内存貌似失控了。内存的使用率，跟配置的完全不是一回事，一般48小时内就能把8G内存耗光，估计4天左右又能把4G的swap空间耗光，用到swap的时候，性能并没有下降。然后，就内存溢出了，挺郁闷。
目前的内存使用情况
free -m
         total    used    free    shared buffers    cached
Mem:       7982    6999       983       0       237       955
-/+ buffers/cache:    5806    2175
Swap:       4094       6    4087
预计3天以后就能把物理内存和swap都能耗光，然后溢出
主要的表都用的innodb引擎。不多废话，把配置文件贴出来，请高手们不吝赐教

# Example MySQL config file for very large systems.
#
# This is for a large system with memory of 1G-2G where the system runs mainly
# MySQL.
#
# You can copy this file to
# /etc/my.cnf to set global options,
# mysql-data-dir/my.cnf to set server-specific options (in this
# installation this directory is /usr/local/mysql/data) or
# ~/.my.cnf to set user-specific options.
#
# In this file, you can use all long options that a program supports.
# If you want to know which options a program supports, run the program
# with the "--help" option.

# The following options will be passed to all MySQL clients
[client]
#password    = your_password
port          = 3306
socket       = /tmp/mysql.sock

# Here follows entries for some specific programs

# The MySQL server
[mysqld]
port          = 3306
bind-address=192.168.0.2
socket       = /tmp/mysql.sock
skip-locking
key_buffer = 512M
max_allowed_packet = 1M
table_cache = 1024
sort_buffer_size = 2M
read_buffer_size = 2M
read_rnd_buffer_size = 8M
myisam_sort_buffer_size = 64M
thread_cache_size = 8
query_cache_size = 32M
# Try number of CPU's*2 for thread_concurrency
thread_concurrency = 16
set-variable=max_connections=1000
long_query_time = 1
log_slow_queries    = /backup/logs/mysql/mysql-slow.log
max_heap_table_size = 500M
tmp_table_size = 200M
back_log=400
# Don't listen on a TCP/IP port at all. This can be a security enhancement,
# if all processes that need to connect to mysqld run on the same host.
# All interaction with mysqld must be made via Unix sockets or named pipes.
# Note that using this option without enabling named pipes on Windows
# (via the "enable-named-pipe" option) will render mysqld useless!
#
#skip-networking
skip-name-resolve

# Disable Federated by default
skip-federated

# Replication Master Server (default)
# binary logging is required for replication
#log-bin=mysql-bin

# required unique id between 1 and 2^32 - 1
# defaults to 1 if master-host is not set
# but will not function as a master if omitted
server-id    = 1

# Replication Slave (comment out master section to use this)
#
# To configure this host as a replication slave, you can choose between
# two methods :
#
# 1) Use the CHANGE MASTER TO command (fully described in our manual) -
# the syntax is:
#
# CHANGE MASTER TO MASTER_HOST=<host>, MASTER_PORT=<port>,
# MASTER_USER=<user>, MASTER_PASSWORD=<password> ;
#
# where you replace <host>, <user>, <password> by quoted strings and
# <port> by the master's port number (3306 by default).
#
# Example:
#
# CHANGE MASTER TO MASTER_HOST='125.564.12.1', MASTER_PORT=3306,
# MASTER_USER='joe', MASTER_PASSWORD='secret';
#
# OR
#
# 2) Set the variables below. However, in case you choose this method, then
# start replication for the first time (even unsuccessfully, for example
# if you mistyped the password in master-password and the slave fails to
# connect), the slave will create a master.info file, and any later
# change in this file to the variables' values below will be ignored and
# overridden by the content of the master.info file, unless you shutdown
# the slave server, delete master.info and restart the slaver server.
# For that reason, you may want to leave the lines below untouched
# (commented) and instead use CHANGE MASTER TO (see above)
#
# required unique id between 2 and 2^32 - 1
# (and different from the master)
# defaults to 2 if master-host is set
# but will not function as a slave if omitted
#server-id    = 2
#
# The replication master for this slave - required
#master-host    = <hostname>
#
# The username the slave will use for authentication when connecting
# to the master - required
#master-user    = <username>
#
# The password the slave will authenticate with when connecting to
# the master - required
#master-password = <password>
#
# The port the master is listening on.
# optional - defaults to 3306
#master-port    =  <port>
#
# binary logging - not required for slaves, but recommended
#log-bin=mysql-bin
#
# binary logging format - mixed recommended
#binlog_format=mixed

# Point the following paths to different dedicated disks
#tmpdir       = /tmp/
#log-update    = /path-to-dedicated-directory/hostname

# Uncomment the following if you are using InnoDB tables
#innodb_data_home_dir = /usr/local/mysql/data/
#innodb_data_file_path = ibdata1:2000M;ibdata2:10M:autoextend
innodb_data_file_path = ibdata1:1500M;ibdata2:1500M;ibdata3:1500M;ibdata4:1500M;ibdata5:1500M:autoextend
#innodb_log_group_home_dir = /usr/local/mysql/data/
#innodb_log_arch_dir = /usr/local/mysql/data/
# You can set .._buffer_pool_size up to 50 - 80 %
# of RAM but beware of setting memory usage too high
innodb_buffer_pool_size = 3072M
innodb_additional_mem_pool_size = 20M
# Set .._log_file_size to 25 % of buffer pool size
innodb_log_file_size = 256M
innodb_log_buffer_size = 20M
innodb_flush_log_at_trx_commit = 2
innodb_thread_concurrency = 1000
innodb_flush_method = O_DIRECT

[mysqldump]
quick
max_allowed_packet = 16M

[mysql]
no-auto-rehash
# Remove the next comment character if you are not familiar with SQL
#safe-updates

[isamchk]
key_buffer = 256M
sort_buffer_size = 256M
read_buffer = 2M
write_buffer = 2M

[myisamchk]
key_buffer = 256M
sort_buffer_size = 256M
read_buffer = 2M
write_buffer = 2M

[mysqlhotcopy]
interactive-timeout

[ 本帖最后由 real_lufeng 于 2009-5-6 17:45 编辑 ]

作者: 枫影谁用了 时间: 2009-05-06 18:45
# Uncomment the following if you are using InnoDB tables
#innodb_data_home_dir = /usr/local/mysql/data/
#innodb_data_file_path = ibdata1:2000M;ibdata2:10M:autoextend
innodb_data_file_path = ibdata1:1500M;ibdata2:1500M;ibdata3:1500M;ibdata4:1500M;ibdata5:1500M:autoextend
#innodb_log_group_home_dir = /usr/local/mysql/data/
#innodb_log_arch_dir = /usr/local/mysql/data/
# You can set .._buffer_pool_size up to 50 - 80 %
# of RAM but beware of setting memory usage too high
innodb_buffer_pool_size = 3072M
innodb_additional_mem_pool_size = 20M
# Set .._log_file_size to 25 % of buffer pool size
innodb_log_file_size = 256M
innodb_log_buffer_size = 20M
innodb_flush_log_at_trx_commit = 2
innodb_thread_concurrency = 1000
innodb_flush_method = O_DIRECT

主要参数都在上面，适当调小观察下看看,连接数也适当调小。
看看慢查询里的有没有啥特费时的sql.

作者: real_lufeng 时间: 2009-05-06 21:08
标题: 回复 #2 枫影谁用了的帖子
没有慢查询，好歹也是每秒近1w次的查询，有一条慢查询的话这机器就给拖死了
连接数不大，两台web，总共512个php-cgi进程，也就是说，最多也就并发512
你说的主要的参数，这里面跟默认相比，改动最大的也就是
innodb_buffer_pool_size
这个改成1G的时候倒是没注意过有没有出现现在的情况，不过1G不够用。之前调到4G，出现了溢出，又改到了3G
我挺纳闷的是，我机器有8G内存 4G swap，我配置的这些参数，到底是哪里的问题，才导致mysql能把这将近12G的内存用光

作者: stormcc 时间: 2009-05-06 23:24
将set-variable=max_connections=1000 调低些，例如改为500；然后打开慢查询日志。

另外检查看应用是否有未释放的链接。

[ 本帖最后由 stormcc 于 2009-5-6 23:26 编辑 ]

作者: ziggler 时间: 2009-05-06 23:26
SQL优化了吗？

作者: Coolriver 时间: 2009-05-07 00:23
那个MySQL是你自已编译的吧。
贴一下：
/path/mysql/bin/mysqlbug 的相关信息。

另外给你一个建义，先禁掉那个swap.让MySQL自已在内存中交换，不使用Swap.

作者: real_lufeng 时间: 2009-05-07 07:29
标题: 回复 #4 stormcc 的帖子
回4楼的兄弟
两台web总共开了512个php-cgi进程，所以，mysql的并发，最多也就512个，我觉得跟set-variable=max_connections=1000应该没多大关系的
满查询日志是打开的。偶尔会有一两个慢查询，一天下来不超过10个，都是偶尔卡住的简单的sql语句
sleep状态的进程基本没有，用过的链接应该是都释放了。

作者: real_lufeng 时间: 2009-05-07 07:31
标题: 回复 #5 ziggler 的帖子
回5楼的兄弟
优化过了，相当的优化

作者: real_lufeng 时间: 2009-05-07 07:33
标题: 回复 #6 Coolriver 的帖子
回6楼的兄弟。
是直接下载的二进制发行版
不过我加载了google的tcmalloc，据说在内存分配方面比glibc更有优势
窃以为关掉swap只会死的更快些

作者: real_lufeng 时间: 2009-05-07 07:44
目前的内存使用情况
Mem: 8174224k total,  8129184k used, 45040k free, 202740k buffers
Swap:  4192956k total, 297388k used,  3895568k free, 733040k cached

  PID USER PR  NI  VIRT  RES  SHR S %CPU %MEM TIME+ COMMAND
15684 mysql 15 0 7849m 6.8g 4808 S 26 86.6 1488:30 mysqld

作者: ruochen 时间: 2009-05-07 08:27
google的 tcmalloc这个和mysql的版本之间存在兼容性的问题不？

在测试机器上用别的mysql版本测试下

作者: ruochen 时间: 2009-05-07 08:32
google在4月17升级了google-perftools

你用的是什么版本的？

作者: ruochen 时间: 2009-05-07 08:36
http://shiningray.cn/tcmalloc-thread-caching-malloc.html

上面这篇文章中注意的问题：
对于某些系统，TCMalloc可能无法与没有链接libpthread.so（或者你的系统上同等的东西）的应用程序正常工作。它应该能正常工作于使用glibc 2.3的Linux上，但是其他OS/libc的组合方式尚未经过任何测试。

TCMalloc可能要比其他malloc版本在某种程度上更吃内存，（但是倾向于不会有其他malloc版本中可能出现的爆发性增长。）尤其是在启动时TCMalloc会分配大约240KB的内部内存。

不要试图将TCMalloc载入到一个运行中的二进制程序中（例如，在Java中使用JNI）。二进制程序已经使用系统malloc分配了一些对象，并会尝试将它们传递到TCMalloc进行解除分配。TCMalloc是无法处理这种对象的。

作者: bs 时间: 2009-05-07 09:31
你确定已经装上TCMalloc?

作者: 小木虫子 时间: 2009-05-07 09:51
重装MYSQL吧。别用GOOGLE的那个插件。

作者: real_lufeng 时间: 2009-05-07 10:07
标题: 回复 #12 ruochen 的帖子
回12楼的兄弟
用的就是你说的4月17号升级的那个版本
google-perftools-1.2.tar.gz

顺便回14楼的兄弟
确认装上去了

顺便回15楼的兄弟
不准备重装，倒是准备试试看不使用tcmalloc看看情况怎么样
我一直怀疑在某个地方存在内存的泄露，不过手头没有测试机无法模拟生产服务器上的环境，所以也暂时没办法用检测内存的软件去求证是不是内存泄露

作者: real_lufeng 时间: 2009-05-07 10:09
期待传说中的高人出场一语道破天机

作者: ruochen 时间: 2009-05-07 10:17

原帖由 real_lufeng 于 2009-5-7 10:07 发表
回12楼的兄弟
用的就是你说的4月17号升级的那个版本
google-perftools-1.2.tar.gz

顺便回14楼的兄弟
确认装上去了

顺便回15楼的兄弟
不准备重装，倒是准备试试看不使用tcmalloc看看情况怎么样
我一 ...

从你描述的现象看，感觉是内存泄露

作者: Coolriver 时间: 2009-05-07 10:21
你所说的内存溢出是不是报：
application is out of memory
这个错误？
如果这个，请禁掉Ｓｗａｐ。

作者: real_lufeng 时间: 2009-05-07 11:04
标题: 回复 #19 Coolriver 的帖子
早上又仔细的分析了一下，发现了一些新情况
可能我描述的不对，不是mysql内存溢出，而是kernel的内存溢出
摘出一段系统日志，如下

May  3 14:30:07 DST-12 kernel: Node 0 HighMem per-cpu: empty
May  3 14:30:07 DST-12 kernel: Free pages:    41692kB (0kB HighMem)
May  3 14:30:07 DST-12 kernel: Active:934890 inactive:1079143 dirty:0 writeback:0 unstable:0 free:10423 slab:3572 mapped-file:973 ma
pped-anon:2014509 pagetables:6499
May  3 14:30:07 DST-12 kernel: Node 0 DMA free:11116kB min:12kB low:12kB high:16kB active:0kB inactive:0kB present:10760kB pages_sca
nned:0 all_unreclaimable? yes
May  3 14:30:07 DST-12 kernel: lowmem_reserve[]: 0 3251 8049 8049
May  3 14:30:07 DST-12 kernel: Node 0 DMA32 free:23780kB min:4632kB low:5788kB high:6948kB active:1672208kB inactive:1590880kB prese
nt:3329568kB pages_scanned:7393923 all_unreclaimable? yes
May  3 14:30:07 DST-12 kernel: lowmem_reserve[]: 0 0 4797 4797
May  3 14:30:07 DST-12 kernel: Node 0 Normal free:6796kB min:6836kB low:8544kB high:10252kB active:2067656kB inactive:2724708kB pres
ent:4912640kB pages_scanned:16569186 all_unreclaimable? yes
May  3 14:30:07 DST-12 kernel: lowmem_reserve[]: 0 0 0 0
May  3 14:30:07 DST-12 kernel: Node 0 HighMem free:0kB min:128kB low:128kB high:128kB active:0kB inactive:0kB present:0kB pages_scan
ned:0 all_unreclaimable? no
May  3 14:30:07 DST-12 kernel: lowmem_reserve[]: 0 0 0 0
May  3 14:30:07 DST-12 kernel: Node 0 DMA: 3*4kB 6*8kB 3*16kB 6*32kB 3*64kB 3*128kB 0*256kB 0*512kB 2*1024kB 0*2048kB 2*4096kB = 111
16kB
May  3 14:30:07 DST-12 kernel: Node 0 DMA32: 1*4kB 24*8kB 8*16kB 7*32kB 5*64kB 1*128kB 1*256kB 0*512kB 0*1024kB 1*2048kB 5*4096kB =
23780kB
May  3 14:30:07 DST-12 kernel: Node 0 Normal: 129*4kB 1*8kB 8*16kB 6*32kB 1*64kB 0*128kB 1*256kB 1*512kB 1*1024kB 0*2048kB 1*4096kB
= 6796kB
May  3 14:30:07 DST-12 kernel: Node 0 HighMem: empty
May  3 14:30:07 DST-12 kernel: 1330 pagecache pages
May  3 14:30:07 DST-12 kernel: Swap cache: add 1296188, delete 1295948, find 40974/74910, race 0+1077
May  3 14:30:07 DST-12 kernel: Free swap  = 0kB
May  3 14:30:07 DST-12 kernel: Total swap = 4192956kB
May  3 14:30:07 DST-12 kernel: Free swap:          0kB
May  3 14:30:07 DST-12 kernel: 2293760 pages of RAM
May  3 14:30:07 DST-12 kernel: 250204 reserved pages
May  3 14:30:07 DST-12 kernel: 4057 pages shared
May  3 14:30:07 DST-12 kernel: 248 pages swap cached
May  3 14:30:07 DST-12 kernel: Out of memory: Killed process 3408 (mysqld).

作者: ruochen 时间: 2009-05-07 12:41
你使用的kernel是多少？

是的话你在kernel的maillist上问问

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

作者: ruochen 时间: 2009-05-07 12:43
我目前也在使用centos 5.2 默认的内核只打了udev的补丁
目前运行半年，没发现内存泄露的问题

作者: 小木虫子 时间: 2009-05-07 14:28
不太可能是LINUX系统问题。

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

作者: hironics 时间: 2009-05-08 14:41

原帖由 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 时间: 2009-05-08 23:08
标题: 该问题解决，但还没有定性，引出几个新问题
该问题解决，引出一个新问题，有兴趣的兄弟可以琢磨一下
这个问题确实是由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编译进去，是否还会出现这个问题

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

作者: 枫影谁用了 时间: 2009-05-09 07:32
很好，加精推荐。

作者: Hellex 时间: 2009-05-11 14:59
用key_buffer_size + (read_buffer_size + sort_buffer_size)*max_connections　这个公式算一下就知道会不会溢出了。

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

作者: leoxqing 时间: 2009-05-11 16:10
很好，很受用！

作者: bbjmmj 时间: 2009-05-12 00:41

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

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

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

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

作者: 枫影谁用了 时间: 2009-05-12 07:59

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

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

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

作者: 枫影谁用了 时间: 2009-05-12 07:59

原帖由 bbjmmj 于 2009-5-12 00:41 发表

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

这个问题，从一开始就应该猜到，是某些进程或者线程在结束的时候没有彻底释放内存，显然MYSQL那些进程不会随便结束，肯定是进程里面的线 ...

大师来了。。

欢迎骚扰。。。

作者: bs 时间: 2009-05-12 09:53
大师要给予颠覆性言论啊，不然光解释现象不够震撼啊

作者: bbjmmj 时间: 2009-05-12 10:10

原帖由 bs 于 2009-5-12 09:53 发表
大师要给予颠覆性言论啊，不然光解释现象不够震撼啊

作者: rock0018 时间: 2009-06-03 11:39
建议楼主改自己的帖子主题，（看着主题感觉就是MYSQL的问题，其实不然）。
同时在测试机上多花工夫去测试，而不是在生产机器上叫

作者: zmcjs 时间: 2009-06-15 16:16
建议楼主省升级一下mysq说不定可以解决问题,mysql5.1版本的问题很多，当时官方都建议用户谨慎升级，而且5.1 的现在已经升级多很多次版本了，看升级说明，是修正了不少bug

作者: billfcu 时间: 2009-07-13 14:44
见识了
都很强啊

作者: freesoftsomuch 时间: 2009-11-23 13:55
有个办法不知行不行，那就是在这台服务器溢出之前关一下机dump一下就不会了，等mysql有好的版本出来之后，测试之后再用！！！这样比较安全

作者: justin033 时间: 2009-12-15 16:47

原帖由 real_lufeng 于 2009-5-8 23:08 发表
该问题解决，引出一个新问题，有兴趣的兄弟可以琢磨一下
这个问题确实是由google的tcmalloc引起的，我把这个插件去掉，重启了mysql。观察了约30小时，确认问题已解决
目前的内存使用情况
Mem: 8174224k to ...

厉害！！！学习

作者: ws00377531 时间: 2011-03-25 16:30
学习学习

作者: key1077 时间: 2011-04-27 11:12
很强大，学习了。让我找到了我问题的解决方法。

欢迎光临 Chinaunix (http://bbs.chinaunix.net/)