linux - mysqld 服务每天在 ec2 服务器上停止一次

Question

环境细节：

Server: Amazon ec2 Linux
Web Server: Apache
Web Framework: Django with mod_wsgi

以下我在 mysql_err.log 文件中找到。

The InnoDB memory heap is disabled
120823  3:21:40 InnoDB: Mutexes and rw_locks use GCC atomic builtins
120823  3:21:40 InnoDB: Compressed tables use zlib 1.2.3
120823  3:21:40 InnoDB: Using Linux native AIO
120823  3:21:41 InnoDB: Initializing buffer pool, size = 128.0M
InnoDB: mmap(137363456 bytes) failed; errno 12
120823  3:21:41 InnoDB: Completed initialization of buffer pool
120823  3:21:41 InnoDB: Fatal error: cannot allocate memory for the buffer pool
120823  3:21:41 [ERROR] Plugin 'InnoDB' init function returned error.
120823  3:21:41 [ERROR] Plugin 'InnoDB' registration as a STORAGE ENGINE failed.
120823  3:21:41 [ERROR] Unknown/unsupported storage engine: InnoDB
120823  3:21:41 [ERROR] Aborting

看起来系统内存不足以将内存分配给缓冲池。我在使用时发生了同样的错误Amazon ec2 micro instance，所以我搬到了small instance. 它可以正常工作几天，但现在又一天中断一次。是否有永久解决方案？我可以移动到中等实例，但问题是它会被修复吗？我应该减小innodb_buffer_pool_size，首选尺寸是多少？

结果cat /proc/meminfo如下（可能会有所帮助）：

MemTotal:        1697824 kB
MemFree:          125744 kB
Buffers:          109704 kB
Cached:           481408 kB
SwapCached:            0 kB
Active:          1212396 kB
Inactive:         266840 kB
Active(anon):     888192 kB
Inactive(anon):       76 kB
Active(file):     324204 kB
Inactive(file):   266764 kB
Unevictable:           0 kB
Mlocked:               0 kB
SwapTotal:             0 kB
SwapFree:              0 kB
Dirty:                 4 kB
Writeback:             0 kB
AnonPages:        888144 kB
Mapped:            15604 kB
Shmem:               144 kB
Slab:              63752 kB
SReclaimable:      53680 kB
SUnreclaim:        10072 kB
KernelStack:         800 kB
PageTables:        16436 kB
NFS_Unstable:          0 kB
Bounce:                0 kB
WritebackTmp:          0 kB
CommitLimit:      848912 kB
Committed_AS:    1417140 kB
VmallocTotal:   34359738367 kB
VmallocUsed:       10988 kB
VmallocChunk:   34359725168 kB
DirectMap4k:     1748992 kB
DirectMap2M:           0 kB

操作系统版本（uname -a）： Linux ip-10-246-134-149 3.2.21-1.32.6.amzn1.x86_64 #1 SMP Sat Jun 23 02:32:15 UTC 2012 x86_64 x86_64 x86_64 GNU/Linux

我检查了ps aux服务器只剩下 15MB 内存的命令，这些是当时httpd正在运行的进程：

的结果free -m

total       used       free     shared    buffers     cached
Mem:          1657       1628         29          0          3         19
-/+ buffers/cache:       1605         51
Swap:          895        875         20

的结果ps aux

apache   21123  0.1  1.2 394652 20464 ?        S    19:35   0:06 /usr/sbin/httpd
apache   21146  0.1  1.2 394280 20796 ?        S    19:38   0:06 /usr/sbin/httpd
apache   21152  0.1  1.2 394284 21560 ?        S    19:38   0:05 /usr/sbin/httpd
apache   21155  0.2  1.4 396244 24528 ?        S    19:38   0:06 /usr/sbin/httpd
apache   21156  0.1  1.1 392552 20344 ?        S    19:38   0:06 /usr/sbin/httpd
apache   21157  0.1  1.1 394284 18884 ?        S    19:38   0:05 /usr/sbin/httpd
apache   21159  0.1  1.4 396200 25040 ?        S    19:38   0:06 /usr/sbin/httpd
apache   21161  0.1  1.2 394856 21724 ?        S    19:38   0:06 /usr/sbin/httpd
apache   21162  0.1  1.3 394864 22400 ?        S    19:38   0:06 /usr/sbin/httpd
apache   21163  0.1  1.3 394860 22204 ?        S    19:38   0:06 /usr/sbin/httpd
apache   21164  0.1  1.1 392560 19204 ?        S    19:38   0:06 /usr/sbin/httpd
apache   21165  0.1  1.3 394832 22280 ?        S    19:38   0:06 /usr/sbin/httpd
apache   21166  0.1  1.3 395276 22932 ?        S    19:38   0:06 /usr/sbin/httpd
apache   21172  0.2  1.4 396320 24820 ?        S    19:38   0:06 /usr/sbin/httpd
apache   21174  0.2  1.7 400672 29452 ?        S    19:39   0:06 /usr/sbin/httpd
apache   21178  0.1  1.4 400540 25304 ?        S    19:39   0:06 /usr/sbin/httpd
apache   21179  0.2  1.6 400580 27856 ?        S    19:39   0:06 /usr/sbin/httpd
apache   21184  0.1  1.7 400628 29320 ?        S    19:39   0:06 /usr/sbin/httpd
apache   21185  0.1  1.6 397944 27292 ?        S    19:39   0:05 /usr/sbin/httpd
apache   21186  0.1  1.5 397960 25648 ?        S    19:39   0:05 /usr/sbin/httpd
apache   21187  0.1  1.7 400576 29120 ?        S    19:39   0:06 /usr/sbin/httpd
apache   21191  0.1  1.4 400576 24400 ?        S    19:39   0:06 /usr/sbin/httpd
apache   21193  0.1  1.4 400536 24940 ?        S    19:39   0:05 /usr/sbin/httpd
apache   21194  0.1  1.5 400572 26096 ?        S    19:39   0:06 /usr/sbin/httpd
apache   21203  0.1  1.6 400580 28808 ?        S    19:39   0:05 /usr/sbin/httpd
apache   21206  0.1  1.7 400584 29732 ?        S    19:39   0:06 /usr/sbin/httpd
apache   21207  0.1  1.6 400576 27940 ?        S    19:39   0:06 /usr/sbin/httpd
apache   21224  0.1  1.2 400624 20768 ?        S    19:39   0:06 /usr/sbin/httpd
apache   21225  0.1  1.6 400576 28468 ?        S    19:39   0:05 /usr/sbin/httpd
apache   21226  0.1  1.6 400576 28048 ?        S    19:39   0:06 /usr/sbin/httpd
apache   21228  0.1  1.4 400572 23880 ?        S    19:39   0:06 /usr/sbin/httpd
apache   21237  0.1  1.5 400628 26124 ?        S    19:39   0:06 /usr/sbin/httpd
apache   21265  0.1  1.6 400536 28592 ?        S    19:39   0:06 /usr/sbin/httpd
apache   21276  0.1  1.2 400544 21456 ?        S    19:39   0:05 /usr/sbin/httpd
apache   21277  0.1  1.3 400624 22676 ?        S    19:39   0:05 /usr/sbin/httpd
apache   21278  0.1  1.6 400536 27360 ?        S    19:39   0:06 /usr/sbin/httpd
apache   21282  0.1  1.4 400612 24996 ?        S    19:39   0:06 /usr/sbin/httpd
apache   21292  0.1  1.4 400532 24780 ?        S    19:39   0:05 /usr/sbin/httpd
apache   21302  0.2  1.2 400540 21332 ?        S    19:39   0:06 /usr/sbin/httpd
apache   21303  0.1  1.3 400628 22228 ?        S    19:39   0:06 /usr/sbin/httpd
apache   21305  0.2  1.2 400536 21116 ?        S    19:39   0:06 /usr/sbin/httpd
apache   21306  0.1  1.3 400572 22380 ?        S    19:39   0:06 /usr/sbin/httpd
apache   21307  0.1  1.1 397956 20056 ?        S    19:39   0:05 /usr/sbin/httpd
apache   21308  0.1  1.2 400624 21520 ?        S    19:39   0:06 /usr/sbin/httpd
apache   21319  0.1  1.1 400540 19468 ?        S    19:39   0:05 /usr/sbin/httpd
apache   21320  0.1  1.3 400628 22712 ?        S    19:39   0:05 /usr/sbin/httpd
apache   21335  0.1  1.0 400540 17236 ?        S    19:39   0:05 /usr/sbin/httpd
apache   21336  0.1  1.3 400628 22188 ?        S    19:39   0:06 /usr/sbin/httpd
apache   21352  0.1  1.1 394276 18972 ?        S    19:40   0:04 /usr/sbin/httpd
apache   21356  0.1  1.1 394280 19028 ?        S    19:40   0:05 /usr/sbin/httpd
apache   21358  0.1  1.1 394280 19004 ?        S    19:40   0:05 /usr/sbin/httpd
apache   21361  0.2  0.7 400452 12632 ?        S    19:40   0:06 /usr/sbin/httpd
apache   21610  0.2  1.6 400536 27660 ?        S    19:46   0:06 /usr/sbin/httpd
apache   21643  0.2  1.3 400156 23272 ?        S    19:55   0:04 /usr/sbin/httpd
apache   21647  0.2  1.0 400544 17556 ?        S    19:57   0:05 /usr/sbin/httpd
apache   21654  0.2  1.5 400188 26884 ?        S    19:58   0:05 /usr/sbin/httpd
apache   21719  0.3  1.9 400192 32264 ?        S    20:14   0:03 /usr/sbin/httpd
apache   21725  0.2  2.0 400044 35340 ?        S    20:15   0:03 /usr/sbin/httpd
apache   21738  0.0  0.8 257648 13792 ?        S    20:26   0:00 /usr/sbin/httpd

任何人都可以知道为什么有这么多的httpd进程吗？

score 45 · Accepted Answer

使用 50% 的可用 RAM 进行测试：

您可以将 innodb_buffer_pool_size 降低到非常低，看看它是否有帮助：

#/etc/my.cnf 
innodb_buffer_pool_size = 1M

经验法则是将 innodb_buffer_pool_size 设置为可用 RAM 的 50% 以进行低内存测试。这意味着您启动服务器和除MySQL InnoDB 之外的所有内容。看看你有多少内存。然后将其中的 50% 用于 InnoDB。

一次尝试多个低内存设置：

http://paragasu.wordpress.com/2008/12/02/very-low-memory-mysql-5-mycnf-configuration/

更可能的罪魁祸首是该服务器上的其他任何东西，例如网络服务器。

阿帕奇？

您使用的是 Apache 和/或其他网络服务器吗？如果是这样，请尝试减少其 RAM 使用量。例如，在 Apache conf 中，考虑像这样的低 RAM 设置：

StartServers 1
MinSpareServers 1
MaxSpareServers 5
MaxClients 5

并限制这样的请求：

MaxRequestsPerChild 300

然后重新启动 Apache。

mod_wsgi：

如果您使用带有 mod_python 的 Apache，请切换到带有 mod_wsgi 的 Apache。

皮普勒：

如果它仍在发生，可能你的 Django 正在稳步增长。尝试使用 Pymler 进行 Django 内存分析：

http://www.rkblog.rk.edu.pl/w/p/profiling-django-object-size-and-memory-usage-pympler/

特区：

您对每天一次故障和每周一次故障的报告可能指向某种每天或每周运行的 cron 作业。例如，可能存在占用大量 RAM 的批处理或数据库转储等。

要在 MySQL 死亡前一小时跟踪 RAM 使用并查找 RAM 峰值，请查看 SAR，这是一个很棒的工具：http ://www.thegeekstuff.com/2011/03/sar-examples/

score 9 · Accepted Answer

您必须减少 innodb_buffer_pool_size = <60-80% 的主内存）

Innodb 错误的解决方案：

110603  7:34:15 [ERROR] Plugin ‘InnoDB’ init function returned error.
110603  7:34:15 [ERROR] Plugin ‘InnoDB’ registration as a STORAGE ENGINE failed.
110603  7:34:15 [ERROR] Unknown/unsupported storage engine: InnoDB
110603  7:34:15 [ERROR] Aborting

10603  7:34:15 [Note] /usr/sbin/mysqld: Shutdown complete

I moved the ib_logfile0 and ib_logfile01 to bak and start Mysql again. Now this time, it is working fine

[root@xxx mysql]# mv ib_logfile0 ib_logfile0-bak
[root@xxx mysql]# mv ib_logfile1 ib_logfile1-bak

来源：http ://www.onaxer.com/tag/error-plugin-innodb-init-function-returned-error/

score 2 · Accepted Answer

就像其他人提到的那样，问题似乎是您的系统在 RAM 上运行不足，因此 MySQL 正在崩溃。以下是如何缩小系统内存的使用范围以及如何从数据库故障中恢复。

看看collectd及其插件。一些适用的可能是processes plugin和memory plugin。通过这些，您可以查看系统的内存使用情况以及哪些进程占用了大部分内存。

根据您运行 Django 的方式，您可以将工作进程配置为仅处理一定数量的请求然后终止。这样，如果您的应用程序中存在某种内存泄漏，它将不会持续超过该数量的请求。例如，如果您使用Gunicorn，则可以使用--max-requests选项。将其设置为 500 将在处理 500 个请求后删除工作人员。

以上结合统计数据收集将向您展示一些有趣的内存使用趋势。

至于数据库宕机，您可以设置进程监督，这样如果 MySQL 确实死了，它将自动重新启动。最新版本的 Ubuntu 中的 MySQL 使用 Upstart 来做到这一点。如果进程终止，Upstart 将立即将其恢复。如果您使用的另一个发行版没有内置此功能，请查看Supervisor。虽然这并不能解决问题，但至少会减轻其影响。这不应该被视为解决方法，而是一种让您的应用程序保持运行以防出现问题的方法。

score 2 · Accepted Answer

一旦我陷入类似的问题，我真的很沮丧，因为我的用户看到这条丑陋的消息Error Establishing DB Connection。我发现这个 repo对我来说就像一个魅力（暂时），而不是解决确切的问题。之后，我的朋友对其进行了调试，他通过一些配置更改对我的服务器进行了微调。但是我仍然每 10 分钟将此脚本添加到我的 crontab 中，然后检查服务器是否崩溃（对于我的情况，每当我在服务器上运行 VNCServer 时最终崩溃），然后重新启动它

score 1 · Accepted Answer

I found answer adds on this discussion and worked for me: https://www.digitalocean.com/community/questions/mysql-server-keeps-stopping-unexpectedly?answer=26016

you have to do both innodb_buffer_pool_size to something reasonable like 32M on my.conf in /etc/mysql/my.cnf, and you also may need to modify /etc/apache2/mods-enabled/mpm_prefork.conf to reduce the number of connections started by apache;

<IfModule mpm_prefork_module>
    StartServers     3
    MinSpareServers  3
    MaxSpareServers  5
    MaxRequestWorkers 25
    MaxConnectionsPerChild  0
</IfModule>

score 0 · Accepted Answer

通过添加新的交换空间来增加可用 RAM 也可能有所帮助。步骤在这里

确保创建的 /swapfile 的大小小于显示的可用空间

df -h

例如对我来说 df- h 的输出是：

Filesystem      Size  Used Avail Use% Mounted on
/dev/xvda1      7.8G  1.2G  6.3G  16% /
none            4.0K     0  4.0K   0% /sys/fs/cgroup
udev            492M   12K  492M   1% /dev
tmpfs           100M  336K   99M   1% /run

所以我用 2 G 创建

sudo fallocate -l 2G /swapfile

然后只需启动服务

sudo /etc/init.d/mysql restart

希望这可以帮助。一切顺利。

linux - mysqld 服务每天在 ec2 服务器上停止一次

6 回答 6

使用 50% 的可用 RAM 进行测试：

阿帕奇？

mod_wsgi：

皮普勒：

特区：

Related

Reference