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 

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