Linux上的MySQL内存不足

操作系统：红帽企业Linux服务器版本5.3（Tikanga）

架构：Intel Xeon 64Bit

MySQL Server 5.5.20 Enterprise Server高级版。

应用程序：Liferay。

我的数据库大小是200MB。 RAM是64GB。 内存消耗逐渐增加，内存不足 。那么只有重启才能释放所有的内存，但是内存消耗的过程又会重新开始，在不到一天的时间就会达到63-64GB。

详细参数 ：

的key_buffer_size = 16M

innodb_buffer_pool_size = 3GB

inndb_buffer_pool_instances = 3

MAX_CONNECTIONS = 1000

innodb_flush_method = O_DIRECT

innodb_change_buffering =刀片

read_buffer_size = 2M

read_rnd_buffer_size = 256K

这是我面临的一个严重的生产服务器问题。这可能是背后的原因，以及如何解决。

这是今天下午2点左右的报告，在昨天晚上10点左右重启Linux之后。

自由-m的输出

             caching总共使用的空闲共享缓冲区
 Mem：64455 22053 42402 0 1544 1164
 -  / + buffers / cache：19343 45112
交换：74998 0 74998

vmstat 2的输出5

    procs -----------内存---------- --- swap-- ----- io -----system-- ----- cpu ------    
    rb swpd free buff cache si so bi bo in cs us sy id wa st
    0 0 0 43423976 1583700 1086616 0 0 1 173 22 27 1 1 98 0 0
    2 0 0 43280200 1583712 1228636 0 0 0 146 1265 491 2 2 96 1 0
    0 0 0 43421940 1583724 1087160 0 0 0 138 1469 738 2 1 97 0 0
    1 0 0 43422604 1583728 1086736 0 0 0 5816 1615 934 1 1 97 0 0
    0 0 0 43422372 1583732 1086752 0 0 0 2784 1323 545 2 1 97 0 0

top -n 3 -b的输出


顶部 -  14:16:22上午16:32，5位用户，平均负载：0.79，0.77，0.93
任务：共345次，1次跑步，344次睡眠，0次停止，0次僵尸
 Cpu：1.0％us，0.9％sy，0.0％ni，98.1％id，0.1％wa，0.0％hi，0.0％si，0.0％st
 Mem：66002772k共计，22656292k使用，43346480k免费，1582152k缓冲
交换：总共76798724k，使用0k，76798724k免费，1163616kcaching

   PID用户PR NI VIRT RES SHR S％CPU％MEM时间+命令                     
  6434 mysql 15 0 4095m 841m 5500 S 113.5 1.3 426：53.69 mysqld                     
     1 root 15 0 10344 680 572 S 0.0 0.0 0：03.09 init                        
     2根RT -5 0 0 0 S 0.0 0.0 0：00.01迁移/ 0                 
     3根34 19 0 0 0 S 0.0 0.0 0：00.00 ksoftirqd / 0                 
     4根RT -5 0 0 0 S 0.0 0.0 0：00.00看门狗/ 0                  
     5根RT -5 0 0 0 S 0.0 0.0 0：00.01迁移/ 1

我有一个类似的问题，基本上我改变了mysqltuner.pl脚本，使其更加详细，知道发生了什么。

基本上，内存的使用情况，如果你使用的是my-innodb-heavy-4G.cnfconfiguration文件的任何变种，使用内存的主要部分将会是这样的：

 memory usage = min(tmp_table_size, max_heap_table_size) + key_buffer_size + query_cache_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 + thread_stack + join_buffer_size ) )

这个总和并不是全部因素，请参阅mysqltuner.pl脚本代码（并运行它）来查看它们全部。

因此，似乎您需要降低很多read_buffer_size ， read_rnd_buffer_size ， thread_stack ， thread_stack和join_buffer_size ，因为它的总和乘以max_connections的1000。

其他的解决办法是降低一点max_connections数量。有了这个线程缓冲区的巨大内存， innodb_buffer_pool_size和所有的InnoDB相关的variables成为一个小问题。

你也可以尝试弄清楚你的应用程序是否真的有大量的sort_buffer_size和join_buffer_size 。如果不是，则将这些值降低。

希望它有帮助。