我有来自MySQL的错误日志,知道吗?网站工作了一段时间,然后几个小时后我完全关闭了MySQL。
140919 10:48:27 [Warning] Using unique option prefix myisam-recover instead of myisam-recover-options is deprecated and will be removed in a future release. Please use the full name instead.
140919 10:48:27 [Note] Plugin 'FEDERATED' is disabled.
140919 10:48:27 InnoDB: The InnoDB memory heap is disabled
140919 10:48:27 InnoDB: Mutexes and rw_locks use GCC atomic builtins
140919 10:48:27 InnoDB: Compressed tables use zlib 1.2.3.4
140919 10:48:28 InnoDB: Initializing buffer pool, size = 128.0M
InnoDB: mmap(137363456 bytes) failed; errno 12
140919 10:48:28 InnoDB: Completed initialization of buffer pool
140919 10:48:28 InnoDB: Fatal error: cannot allocate memory for the buffer pool
140919 10:48:28 [ERROR] Plugin 'InnoDB' init function returned error.
140919 10:48:28 [ERROR] Plugin 'InnoDB' registration as a STORAGE ENGINE failed.
140919 10:48:28 [ERROR] Unknown/unsupported storage engine: InnoDB
140919 10:48:28 [ERROR] Aborting
140919 10:48:28 [Note] /usr/sbin/mysqld: Shutdown complete
140919 10:48:28 [Warning] Using unique option prefix myisam-recover instead of myisam-recover-options is deprecated and will be removed in a future release. Please use the full name instead.
140919 10:48:28 [Note] Plugin 'FEDERATED' is disabled.
140919 10:48:28 InnoDB: The InnoDB memory heap is disabled
140919 10:48:28 InnoDB: Mutexes and rw_locks use GCC atomic builtins
140919 10:48:28 InnoDB: Compressed tables use zlib 1.2.3.4
140919 10:48:28 InnoDB: Initializing buffer pool, size = 128.0M
InnoDB: mmap(137363456 bytes) failed; errno 12
140919 10:48:28 InnoDB: Completed initialization of buffer pool
140919 10:48:28 InnoDB: Fatal error: cannot allocate memory for the buffer pool
140919 10:48:28 [ERROR] Plugin 'InnoDB' init function returned error.
140919 10:48:28 [ERROR] Plugin 'InnoDB' registration as a STORAGE ENGINE failed.
140919 10:48:28 [ERROR] Unknown/unsupported storage engine: InnoDB
140919 10:48:28 [ERROR] Aborting
140919 10:48:28 [Note] /usr/sbin/mysqld: Shutdown complete
Mysql由于内存不足而无法重新启动,请检查是否配置了适当的交换文件。
没帮助吗 如果这不是您的问题,那么继续研究的更多合格问题是:
我在EC2上建立的第一个系统上确实遇到了这个问题,该系统的特点是那里托管的wordpress网站有时会因“建立数据库连接错误”而崩溃。
日志显示与OP发布的错误相同的错误。我对错误的了解(已删除时间戳)是:
InnoDB: Fatal error: cannot allocate memory for the buffer pool
[ERROR] Plugin 'InnoDB' init function returned error. [ERROR] Plugin 'InnoDB' registration as a STORAGE ENGINE failed. [ERROR] Unknown/unsupported storage engine: InnoDB [ERROR] Aborting
[Note] /usr/sbin/mysqld: Shutdown complete
检查/var/log/syslog
并搜索 mysql 产量:
Out of memory: Kill process 15452 (mysqld) score 93 or sacrifice child
Killed process 15452 (mysqld) total-vm:888672kB, anon-rss:56252kB, file-rss:0kB
init: mysql main process (15452) killed by KILL signal
init: mysql main process ended, respawning
type=1400 audit(1443812767.391:30): apparmor="STATUS" operation="profile_replace" name="/usr/sbin/mysqld" pid=21984 comm="apparmor_parser"
init: mysql main process (21996) terminated with status 1
init: mysql main process ended, respawning
init: mysql post-start process (21997) terminated with status 1
<repeated>
注意:如果错误是在cron旋转日志之前发生的,则可能需要压缩并搜索存档的日志。
就我而言,根本问题是我忽略了配置交换文件。
您可以通过运行查看是否配置了一个free -m
。
total used free shared buffers cached Mem: 604340 587364 16976 0 29260 72280 -/+ buffers/cache: 485824 118516 Swap: 0 0 0
在上面的示例中,交换:0表示没有交换文件。
有关设置的教程:
注意,更大不一定代表更好! 从Ubuntu指南:
“收益递减”表示, 如果您需要更多的交换空间而不是RAM大小的两倍
,则最好添加更多的RAM,因为硬盘驱动器(HDD)的访问速度比RAM的访问速度慢约10³,因此大约 需要1秒钟,突然花了15分钟以上
!快速固态硬盘(SSD)上还有一分钟多的时间…
The InnoDB memory heap is disabled
这实际上不是错误,只是表明InnoDB正在使用系统的内部内存分配器而不是其自身的内存。默认值为yes / 1,并且可以接受生产。
根据文档,此命令已弃用,并将在5.6以上的MySQL版本中删除(并且我假设为MariaDB):
http://dev.mysql.com/doc/refman/5.6/en/innodb-performance-
use_sys_malloc.html
感谢:Ruben Schade评论
[Note] Plugin 'FEDERATED' is disabled.
关于禁用FEDERATED的消息不是错误。这只是意味着FEDERATED引擎在您的mysql服务器上未开启。默认情况下不使用。如果您不需要它,则无需关心此消息。
参见:https :
//stackoverflow.com/a/16470822/2586761
问题内容: 我偶尔会遇到服务器的内存分配限制,尤其是对于像Wordpress这样a肿的应用程序,但是却从未遇到过“无法为池分配内存”和跟踪任何信息的麻烦。 有人知道这意味着什么吗?我尝试增加失败。我也没有对该应用程序进行任何重大更改。有一天没有问题,第二天我遇到了这个错误。 问题答案: 可能与APC有关。 对于有此问题的人,请指定您的.ini设置。特别是您的apc.mmap_file_mask设置
问题内容: 我刚从python移植了我的应用程序,所以Go有点新。看来我遇到了记忆问题。 它在ubuntu机器上运行。通过主管。 编辑: 设置解决问题 问题答案: 对于遇到此问题的其他人,这是golang问题中的相关近期问题 对于所有受影响的人,在Linux上得到适当修复之前的临时替代方法可以是以下之一: 启用无条件过量使用: 能够无条件过载:添加交换到你的主机,用它几乎永远不会被使用,但在计算参
<---JS StackTrace---> =====JS栈迹=================================================================== 安全上下文:0369632D1:create(This=036856A9)2:_Walk[034841A1:~764][PC=1CCAED1F](This=3A11A619,Visitor=3BCEFD
节点版本为 根据在崩溃期间内存使用率不会超过 再现此错误的代码: 为了检查是否存在递归堆栈大小问题,我使用-stack-size=60000参数运行了下一段代码 并且得到了 然后我运行的代码给出了一个致命的错误:CALL_AND_RETRY_LAST Allocation失败-进程内存不足,具有相同的-stack-size=60000参数,并且没有。 因此我得出结论与递归堆栈大小没有共同之处。 我
我正在尝试为DMA Linux编写驱动程序,但我的驱动程序一直无法执行DMA_CONCENTER_alloc,我已经增加了CMA内存和CONCENTERY_pool。。。 我错过了什么? dmesg在物理CPU 0x0上引导Linux<br>Linux版本4.14.0-xilinx-v2018.2(oe-user@oe-host)(gcc版本7.2.0(gcc))#5 SMP抢占Sun二月17日2
我尝试了这个解决方案:致命错误:CALL_AND_RETRY_LAST分配失败-进程内存不足 但不管用。 还尝试了其他:Devextreme:致命错误:CALL_AND_RETRY_LAST分配失败-JavaScript堆内存不足 产生的错误: <---最后几个GC--> [5344:00000000002C05B0]46772 ms:Mark-sweep 1399.5(1427.9)->1399