转载 根据status信息对MySQL服务器进行优化
一次启动故障的解决，关于开机强制检测硬盘
2009/05/08 23:23 | by
前几天为mysql配置了tcmalloc
服务器配置两颗4核E5410 8G内存 146G sas 15k转速的硬盘
系统为centos 5.2 64位 mysql 5.1.32 64位
平均每秒约1w次查询，优化的还不错，性能很好，负载4左右也很稳定
不知道什么原因，内存貌似失控了。内存的使用率，跟配置的完全不是一回事，一般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都能耗光，然后溢出
把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编译进去，是否还会出现这个问题
有机会再测试上面三个问题
服务器配置两颗4核E5410 8G内存 146G sas 15k转速的硬盘
系统为centos 5.2 64位 mysql 5.1.32 64位
平均每秒约1w次查询，优化的还不错，性能很好，负载4左右也很稳定
不知道什么原因，内存貌似失控了。内存的使用率，跟配置的完全不是一回事，一般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都能耗光，然后溢出
把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编译进去，是否还会出现这个问题
有机会再测试上面三个问题
