Linux Centos MySQL PHP InnoDB下的内存管理

Question

这台服务器是否有足够的内存，如果有或没有，你如何判断？你有什么建议的改变吗？

我希望得到一些关于我应该如何管理虚拟机LAMP堆栈的内存的理解，或者更具体地说，我如何配置才能最大限度地利用可用内存。我并不是在寻找像“你需要更多的内存”或者“停止使用innodb”或者“你需要切换到fastcgi来服务PHP”这样的答案。在不更改任何堆栈的情况下，我正在寻找如何判断服务器是否有足够内存以及如何调优其性能的答案。一个好的经验法则是，你的交换大小应该等于你的系统内存(这只是一个对我有帮助的例子，我不知道这是不是真的)。

关于正在发生的事情的更多背景信息，我有类似的服务器开始崩溃，然后我有运行相同堆栈的服务器和内存增加的web应用程序，解决了这个问题。现在，我知道这是因为它们有更多的内存，可以“处理”负载，但我觉得在不了解底层机制的情况下盲目增加服务器大小可能不是一个好方法。另外，直觉上，我觉得512MB的web服务器应该可以处理任何事情，我知道我以前运行过的服务器要少得多。

130201 21:04:27  mysqld restarted
InnoDB: The log sequence number in ibdata files does not match
InnoDB: the log sequence number in the ib_logfiles!
130201 21:04:27  InnoDB: Database was not shut down normally!
InnoDB: Starting crash recovery.
InnoDB: Reading tablespace information from the .ibd files...
InnoDB: Restoring possible half-written data pages from the doublewrite
InnoDB: buffer...
130201 21:04:28  InnoDB: Started; log sequence number 0 4945108
130201 21:04:28 [Note] /usr/libexec/mysqld: ready for connections.
Version: '5.0.77'  socket: '/var/lib/mysql/mysql.sock'  port: 3306  Source distribution

Number of processes running now: 0
130201 21:08:48  mysqld restarted
InnoDB: Error: pthread_create returned 11
130201 21:08:57  mysqld ended

130201 21:26:19  mysqld started
130201 21:26:35  InnoDB: Error: cannot allocate 8404992 bytes of
InnoDB: memory with malloc! Total allocated memory
InnoDB: by InnoDB 8154720 bytes. Operating system errno: 12
InnoDB: Check if you should increase the swap file or
InnoDB: ulimits of your operating system.
InnoDB: On FreeBSD check you have compiled the OS with
InnoDB: a big enough maximum process size.
InnoDB: Note that in most 32-bit computers the process
InnoDB: memory space is limited to 2 GB or 4 GB.
InnoDB: We keep retrying the allocation for 60 seconds...
130201 21:26:58  mysqld ended

我现在知道上面的问题是由于崩溃，可能是因为MySQL没有足够的内存，或者是因为InnoDB占用了太多的内存，没有足够的内存让操作系统继续运行。下面是我的一个典型服务器在低活跃度下的顶部。我不知道如何解释这一点。例如，100mb是免费的吗？为什么有这么多apache线程使用超过300m的内存，这是如何可持续的？我的InnoDB缓冲池应该是多少？任何帮助或指导都将不胜感激！

top - 01:56:34 up 3 days,  4:05,  1 user,  load average: 0.00, 0.00, 0.00
Tasks:  74 total,   3 running,  71 sleeping,   0 stopped,   0 zombie
Cpu(s):  0.0%us,  0.0%sy,  0.0%ni,100.0%id,  0.0%wa,  0.0%hi,  0.0%si,  0.0%st
Mem:    524288k total,   424172k used,   100116k free,    11680k buffers
Swap:   499992k total,   102684k used,   397308k free,    56552k cached

  PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND                                                   
26702 apache    15   0  321m  46m 6068 S  0.0  9.1   0:59.08 httpd                                                      
26701 apache    15   0  316m  41m 6312 S  0.0  8.1   0:32.04 httpd                                                      
26705 apache    15   0  313m  30m 6292 S  0.0  5.9   0:31.81 httpd                                                      
26707 apache    15   0  311m  37m 6372 S  0.0  7.3   0:27.49 httpd                                                      
26704 apache    15   0  311m  23m 5820 S  0.0  4.6   0:28.30 httpd                                                      
20799 apache    15   0  310m  35m 6488 S  0.0  7.0   0:27.43 httpd                                                      
26703 apache    15   0  307m  32m 6240 S  0.0  6.4   0:27.78 httpd                                                      
11123 apache    15   0  307m  30m 5984 S  0.0  5.9   0:10.26 httpd                                                      
26410 apache    15   0  297m  21m 5704 S  0.0  4.3   0:17.26 httpd                                                      
 7871 apache    15   0  296m  23m 5616 S  0.0  4.6   0:09.18 httpd                                                      
26708 apache    15   0  296m  20m 5616 S  0.0  4.1   0:25.38 httpd                                                      
26706 apache    15   0  295m  22m 5636 S  0.0  4.4   0:25.78 httpd                                                      
 1332 root      18   0  279m 5452 3632 R  0.0  1.0   0:00.23 httpd                                                      
 1305 mysql     15   0  195m  10m 3836 S  0.0  2.0   0:26.57 mysqld                                                     
10551 root      17   0 99.7m 1196  900 S  0.0  0.2   0:00.00 crond                                                      
10595 root      17   0 99.7m 1196  900 S  0.0  0.2   0:00.00 crond                                                      
10651 root      17   0 99.7m 1196  900 S  0.0  0.2   0:00.00 crond                                                      
10695 root      17   0 99.7m 1196  900 S  0.0  0.2   0:00.00 crond                                                      
10481 root      16   0 91068 3284 2564 S  0.0  0.6   0:00.00 sshd                                                       
10485 assistrx  15   0 91068 1744  976 S  0.0  0.3   0:00.00 sshd                                                       
 5739 root      15   0 90144 3268 2556 S  0.0  0.6   0:00.00 sshd                                                       
 5741 assistrx  15   0 90144 1720  980 S  0.0  0.3   0:00.00 sshd                                                       
 9687 root      15   0 90144 3388 2652 R  0.0  0.6   0:00.01 sshd                                                       
 1340 root      15   0 74848  700  592 S  0.0  0.1   0:00.04 crond                                                      
 9690 root      15   0 66104 1600 1180 S  0.0  0.3   0:00.00 bash                                                       
 1132 root      18   0 65968 1176 1032 S  0.0  0.2   0:01.48 xe-daemon                                                                                       

Answer 1

MySQL DB调优可能令人望而生畏，但它是可行的。查看this answer from RolandoMySQLDBA。他关于如何测量InnoDB缓冲池的建议非常完美&我推荐关于innodb_file_per_table上的图灵的建议，因为在处理阻塞系统的大型InnoDB崩溃文件之前，您永远不会知道地狱是什么样子。以下问题直接来自RolandoMySQLDBA的回答：

要了解使innodb缓冲池以KB为单位的大小，请运行以下查询：

SELECT SUM(data_length+index_length)/power(1024,1) IBPSize_KB
FROM information_schema.tables WHERE engine='InnoDB';

这里是MB

SELECT SUM(data_length+index_length)/power(1024,2) IBPSize_MB
FROM information_schema.tables WHERE engine='InnoDB';

这是GB

SELECT SUM(data_length+index_length)/power(1024,3) IBPSize_GB
FROM information_schema.tables WHERE engine='InnoDB';

我还使用了tuning-primer脚本discussed here。确实帮助我解决了MySQL的头痛问题。你需要让数据库启动、运行和活跃至少2天，这样它的数据才会有用，所以我在生产服务器上运行它，在它们至少有2天的实际流量之后。

Answer 2

在开始mysql调优之前，您首先需要检查内存分配是否由于ulimits或其他操作系统设置而失败。

您是否可以粘贴以下命令的输出-

1. ulimit -a
2. free -m

这些命令将打印有关在操作系统上设置的内存限制和物理内存规格的信息。