mysqld 服务每天在 ec2 服务器上停止一次
Posted
技术标签:
【中文标题】mysqld 服务每天在 ec2 服务器上停止一次【英文标题】：mysqld service stops once a day on ec2 server 【发布时间】：2012-08-20 08:00:12 【问题描述】：环境详情：
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进程吗？
【问题讨论】：
看这里***.com/questions/10284532/… 我检查了我已经关闭了 895MB 的交换空间，我把它打开了，让我们看看它是否有效？？ 这个崩溃现在每周发生一次，而不是交换 895Mb 是 ON。 答案对我来说不走运，我尝试了一切，最后我已经转移到 Amazon Ec2 Ubuntu 12.04 (Medium Instance)，并且该网站现在可以正常运行两周了。 嗨，我在 AWS 上哪里可以找到这个文件。我每天不止一次注意到这一点。 【参考方案1】：使用 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 的批处理，或者数据库转储等。
要跟踪 RAM 使用情况并在 MySQL 死亡前一小时查找 RAM 峰值，请查看 SAR，这是一个很棒的工具：http://www.thegeekstuff.com/2011/03/sar-examples/
【讨论】：
感谢您的回答，我会将其标记为已接受，一旦我对其进行测试，我仍然会奖励您额外的赏金。innodb_buffer_pool_size 提示对我有用。我在 EC2 t2.micro 实例上运行了一个非常不稳定的 wordpress 实例。 Mysqlq 每隔几个小时就会崩溃一次并给出Error connecting to database 错误。我在 my.cnf 中添加了：innodb_buffer_pool_size = 200K，现在它更稳定了。【参考方案2】：
您必须减少 innodb_buffer_pool_size =
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/
【讨论】：
面临同样的问题。它可以正常工作一段时间，然后再次出现同样的问题。建立数据库连接时出错。我必须手动 SSH 进入服务器并启动 mysql 服务【参考方案3】：就像其他人提到的那样，问题似乎是您的系统在 RAM 上运行不足，因此 MySQL 正在崩溃。以下是如何缩小系统内存的使用范围以及如何从数据库故障中恢复。
看看collectd 及其插件。一些适用的可能是processes plugin 和memory plugin。通过这些，您可以查看系统的内存使用情况以及哪些进程占用了大部分内存。
根据您运行 Django 的方式，您可以将工作进程配置为仅处理一定数量的请求然后终止。这样，如果您的应用程序中存在某种内存泄漏，它将不会持续超过该数量的请求。例如，如果您使用Gunicorn，则可以使用--max-requests 选项。将其设置为 500 将在处理 500 个请求后删除工作人员。
以上结合统计数据收集将向您展示一些有趣的内存使用趋势。
至于数据库宕机，你可以设置进程监控，这样如果 MySQL 死了，它会自动重新启动。最新版本的 Ubuntu 中的 MySQL 使用 Upstart 来做到这一点。如果进程终止，Upstart 将立即将其恢复。如果您使用的另一个发行版没有内置此功能，请查看Supervisor。虽然这并不能解决问题，但至少会减轻其影响。这不应被视为解决方法，而是一种让您的应用程序在出现问题时保持运行的方法。
【讨论】：
【参考方案4】：当我遇到类似的问题时，我真的很沮丧，因为我的用户看到这条丑陋的消息建立数据库连接时出错。我发现this repo 没有解决确切的问题，对我来说就像一个魅力（暂时）。之后，我的朋友对其进行了调试，他通过一些配置更改对我的服务器进行了微调。但是我仍然每 10 分钟将此脚本添加到我的 crontab 中，然后检查服务器是否崩溃（对于我的情况，每当我在服务器上运行 VNCServer 时最终崩溃），然后重新启动它
【讨论】：
【参考方案5】：我在此讨论中找到答案并为我工作：https://www.digitalocean.com/community/questions/mysql-server-keeps-stopping-unexpectedly?answer=26016
您必须同时将innodb_buffer_pool_size 与my.conf 中的my.conf 上的32M 相结合/etc/mysql/my.cnf，您还可能需要修改/etc/apache2/mods-enabled/mpm_prefork.conf 以减少由阿帕奇;
<IfModule mpm_prefork_module>
StartServers 3
MinSpareServers 3
MaxSpareServers 5
MaxRequestWorkers 25
MaxConnectionsPerChild 0
</IfModule>
【讨论】：
【参考方案6】：通过添加新的交换空间来增加可用 RAM 也可能有所帮助。步骤是here
确保您创建的 /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
希望这会有所帮助。一切顺利。
【讨论】：
请注意，使用 fallocate 就足够了——在挂载交换文件之前，您会丢失 3-4 个命令。更多信息在这里：digitalocean.com/community/tutorials/…以上是关于mysqld 服务每天在 ec2 服务器上停止一次的主要内容，如果未能解决你的问题，请参考以下文章
启动停止mysql时报：服务正在启动或停止中，请稍候片刻后再试一次。
在停止和启动 ubuntu EC2 服务器时，没有名为“cv2”的模块错误。 （导入cv2错误）