mysqld服务每天在ec2服务器上停止一次
环境细节：
Server: Amazon ec2 Linux Web Server: Apache Web Framework: Django with mod_wsgi 以下我已经在mysql_err.log文件中find了。
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 。 有些日子可以正常工作，但是现在又一次破了一次。 有没有永久的解决办法？ 我可以移动到中等实例，但问题是将被修复或不是？ 我应该减lessinnodb_buffer_pool_size ，首选大小是多less？
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过程的想法？
使用50％的可用RAM来testing：
你可以减lessinnodb_buffer_pool_size非常低，看看是否有帮助：
#/etc/my.cnf innodb_buffer_pool_size = 1M
经验法则是将innodb_buffer_pool_size设置为可用RAM的50％，以便进行低内存testing。 这意味着你启动服务器和MySQL InnoDB 以外的所有东西。 看看你有多lessRAM。 然后使用InnoDB的50％。
要一次尝试许多低内存设置：
更可能的罪魁祸首是该服务器上的其他任何东西，如Web服务器。
Apache的？
你使用Apache和/或其他networking服务器？ 如果是这样，请尝试降低其RAM使用率。 例如在Apache conf中，考虑如下的低RAM设置：
StartServers 1 MinSpareServers 1 MaxSpareServers 5 MaxClients 5
并限制这样的要求：
MaxRequestsPerChild 300
然后重新启动Apache。
mod_wsgi的：
如果您使用mod_python使用Apache，请使用mod_wsgi切换到Apache。
Pympler：
如果还在发生，可能你的Django正在稳步增长。 用Pympler尝试Django内存分析：
SAR：
您每天一次的失败报告，然后是每周一次的失败报告可能指向每天或每周运行的某种cron作业。 例如，也许有一个批处理过程需要大量的RAM或数据库转储等。
要追踪RAM的使用情况，并在MySQL死前一个小时内查找RAM峰值，请查看SAR，这是一个很好的工具： http : //www.thegeekstuff.com/2011/03/sar-examples/
你必须减less你的innodb_buffer_pool_size =你的主内存的60-80％
Innodb错误解决scheme：
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/
像其他人一样，这个问题似乎是你的系统在RAM上运行的很低，MySQL因此而炸毁。 以下是如何缩小您的系统内存使用范围，以及如何从数据库中恢复。
看看collectd和它的插件。 一些适用的可能是进程插件和内存插件 。 有了这些，你可以看到你的系统的内存使用情况，以及哪些进程占用了大部分的内存。
根据你如何运行Django，你可以configuration工作进程只处理一定数量的请求，然后终止。 这样，如果在应用程序中存在某种内存泄漏，它将不会持续超过该请求数量。 例如，如果您使用Gunicorn ，则可以使用–max-requests选项。 将其设置为500将在处理完500个请求之后放下工作人员。
上面结合统计收集会告诉你一些有趣的内存使用趋势。
至于数据库closures，你可以设置进程监督，如果MySQL死了，它会自动重新启动。 最新版本的Ubuntu中的MySQL使用Upstart来做到这一点。 如果这个过程死了，Upstart会立即恢复。 如果您正在使用另一个没有内置的发行版，请查看Supervisor 。 虽然这不能解决问题，但至less可以减轻其影响。 这不应该被看作是修复，而是一种保持你的应用程序运行的方式，以防出现问题。
一旦我遇到类似的问题，我真的很沮丧，我的用户看到这个丑陋的消息， build立数据库连接错误 。 我没有解决确切的问题，而是发现这个回购工作像我的（暂时的）魅力。 之后，我得到了我的朋友debugging，他只是调整了一些configuration更改我的服务器。 但是我仍然每隔10分钟就把这个脚本添加到我的crontab中，然后检查服务器是否崩溃（对于我的情况，最终崩溃的时候我每次在服务器上运行VNCServer），然后重新启动
通过添加新的交换空间来增加可用内存也可能有所帮助。 步骤在这里
确保您创build的大小小于可用空间的交换文件
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
所以我创build使用2 G
sudo fallocate -l 2G /swapfile
然后才开始服务
sudo /etc/init.d/mysql restart
希望这可以帮助。 祝一切顺利。
