0

这台服务器是否有足够的内存，如果有或没有，你怎么知道？你会推荐什么改变？

我希望了解我应该如何管理虚拟机 LAMP 堆栈的内存，或者更具体地说，我可以如何配置以最大化可用内存。我不是在寻找诸如“您需要更多内存”或“停止使用 innodb”或“您需要切换到 fastcgi 以提供 PHP 服务”之类的答案。在不更改任何堆栈的情况下，我正在寻找有关如何判断服务器是否有足够内存以及如何调整其性能的答案。一个好的经验法则会很棒，你的交换大小应该等于你的系统内存（这只是一个可以帮助我的例子，我不知道这是不是真的）。

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

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
4

2 回答 2

4

MySQL 数据库调优可能令人生畏，但它是可行的。从 RolandoMySQLDBA查看这个答案。他关于如何测量 InnoDB 缓冲池的建议是完美的，我推荐关于 turing 的建议，innodb_file_per_table因为在你不得不处理一个阻塞系统的巨大 InnoDB 崩溃文件之前，你真的不知道地狱是什么样的。以下查询直接来自RolandoMySQLDBA的回答：

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

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的脚本。确实帮助我解决了 MySQL 的难题。您需要让数据库启动并运行并激活至少 2 天，以便其数据有用，因此我在生产服务器至少有 2 天的实际流量后在生产服务器上运行它。

于 2013-02-05T02:29:41.793 回答
0

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

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

  1. ulimit -a
  2. free -m

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

于 2013-05-18T07:52:35.297 回答