ec2 linux AMI 上的 mysql 偶尔会崩溃

ec2 linux AMI 上的 mysql 偶尔会崩溃

我在具有 1 个 CPU 和 1 GB 内存的 Amazon EC2 Linux AMI 上安装了带有 mysql 的 wordpress。

最近,mysql 每周至少崩溃一两次,而我无法找出问题所在。

当我运行命令时

sudo 服务 mysqld 状态

我明白了

mysqld 已死但子系统已锁定

我已通过编辑 /etc/my.cnf 启用日志记录,如下所示:-

[mysqld] datadir = /var/lib/mysql 套接字 = /var/lib/mysql/mysql.sock

log_error=/var/log/mysqld.log

[mysqld_safe] 日志错误=/var/log/mysqld.log

pid 文件=/var/run/mysqld/mysqld.pid

但是每次崩溃时,我都无法在日志文件中识别错误。最近的崩溃在日志文件 /var/log/mysqld.log 中显示以下内容,但不确定它们是否是我重新启动 mysql 时的日志。

版本:'5.6.37' 套接字:'/var/lib/mysql/mysql.sock' 端口:3306 MySQL 社区服务器(GPL)

2017-12-06 12:29:53 30473 [注意] 插件‘FEDERATED’已被禁用。

2017-12-06 12:29:53 30473 [注意] InnoDB: 使用原子来引用计数缓冲池页面

2017-12-06 12:29:53 30473 [注意] InnoDB: InnoDB内存堆已禁用

2017-12-06 12:29:53 30473 [注意] InnoDB: 互斥锁和 rw_locks 使用 GCC 原子内置函数

2017-12-06 12:29:53 30473 [注意] InnoDB:未使用内存屏障

2017-12-06 12:29:53 30473 [注意] InnoDB:压缩表使用zlib 1.2.8

2017-12-06 12:29:53 30473 [注意] InnoDB:使用Linux原生AIO

2017-12-06 12:29:53 30473 [注意] InnoDB:使用CPU crc32指令

2017-12-06 12:29:53 30473 [注意] InnoDB:初始化缓冲池,大小 = 128.0M

2017-12-06 12:29:53 30473 [注意] InnoDB: 缓冲池初始化完成

2017-12-06 12:29:53 30473 [注意] InnoDB: 支持的最高文件格式是Barracuda。

2017-12-06 12:29:53 30473 [注意] InnoDB: ibdata文件中的日志序列号189532097和189532097与ib_logfiles中的日志序列号189715563不匹配!

2017-12-06 12:29:53 30473 [注意] InnoDB: 数据库未正常关闭!

2017-12-06 12:29:53 30473 [注意] InnoDB:开始崩溃恢复。

2017-12-06 12:29:53 30473 [注意] InnoDB:从.ibd 文件读取表空间信息...

2017-12-06 12:29:53 30473 [注意] InnoDB:恢复可能写入一半的数据页

2017-12-06 12:29:53 30473 [注意] InnoDB:来自双写缓冲区......

2017-12-06 12:29:53 30473 [注意] InnoDB: 128 个回滚段处于活动状态。

2017-12-06 12:29:53 30473 [注意] InnoDB:等待清除开始

2017-12-06 12:29:53 30473 [注意] InnoDB: 5.6.37 已启动;日志序列号 189715563

2017-12-06 12:29:53 30473 [注意] 未找到 RSA 私钥文件:/var/lib/mysql//private_key.pem。某些身份验证插件将无法工作。

2017-12-06 12:29:53 30473 [注意] 未找到 RSA 公钥文件:/var/lib/mysql//public_key.pem。某些身份验证插件将无法工作。

2017-12-06 12:29:53 30473 [注意] 服务器主机名(绑定地址):'*';端口:3306

2017-12-06 12:29:53 30473 [注意] IPv6 可用。

2017-12-06 12:29:53 30473 [注意] - '::' 解析为 '::';

2017-12-06 12:29:53 30473 [注意] 在 IP '::' 上创建服务器套接字。

2017-12-06 12:29:53 30473 [注意] 事件调度程序:已加载 0 个事件

2017-12-06 12:29:53 30473 [注意] /usr/libexec/mysql56/mysqld:已准备好连接。版本:'5.6.37' 套接字:'/var/lib/mysql/mysql.sock' 端口:3306 MySQL 社区服务器 (GPL)

我读到过有人坚持认为 1GB 内存对于 wordpress 来说不够。但我也读到过有人说 1GB 就足够了,而事实上他们只使用了不到 800MB 的内存,有些人甚至只使用了不到 600MB 的内存,而他们的网站运行良好。所以我不太确定我需要超过 1GB 的内存。

我已经为内存创建了交换文件,当我这样做时

免费-m

,显示以下内容:

         total       used       free     shared    buffers     cached 

内存:993 856 137 0 8 51

-/+ 缓冲区/缓存:796 196

交换:1023 338 685

仅供参考,我的网站流量非常低,平均每天点击量不到 10 次,实际上,每天最多不超过 20 次点击,每天最少 0 次点击。没有交易,只是纯粹浏览网站和一个简单的(5 个字段)查询表格。

有人能帮忙查明为什么日志文件中没有特定的错误吗?

有没有什么办法可以找出 mysql 的问题所在?

任何帮助我都会非常感激。谢谢。


/var/log/message 中有新发现,我在文件中看到了这一点。我可以确认这是否意味着我的 ec2 实例需要更多内存吗?但为什么呢?如前所述,这是一个流量非常低的 wordpress 网站。有人能解释一下吗?

12 月 6 日 12:26:31 ip-172-31-29-103 内核:[939492.654915] 内存不足:终止进程 25961 (mysqld) 得分 222 或牺牲子进程

12 月 6 日 12:26:31 ip-172-31-29-103 内核:[939492.658743] 已终止进程 25961 (mysqld) total-vm:1336104kB,anon-rss:4676kB,file-rss:0kB,shmem-rss:0kB

12 月 6 日 12:26:31 ip-172-31-29-103 内核:[939493.023492] oom_reaper:已收获进程 25961 (mysqld),现在 anon-rss:0kB、file-rss:0kB、shmem-rss:0kB

12 月 6 日 12:26:38 ip-172-31-29-103 内核:[939499.813569] mysqld 调用 oom-killer:gfp_mask=0x24280ca(GFP_HIGHUSER_MOVABLE|__GFP_ZERO),nodemask=0,order=0,oom_score_adj=0

12月6日 12:26:38 ip-172-31-29-103 内核:[939499.820065] mysqld cpuset=/mems_allowed=0

12 月 6 日 12:26:38 ip-172-31-29-103 内核:[939499.822758] CPU:0 PID:30069 通信:mysqld 污染:GE 4.9.38-16.33.amzn1.x86_64 #1

12 月 6 日 12:26:38 ip-172-31-29-103 内核:[939499.825371] 硬件名称:Xen HVM domU,BIOS 4.2.amazon 08/24/2006

12月6日 12:26:38 ip-172-31-29-103 内核:[939499.825371] ffffc90001dd7b58 ffffffff812fa84f ffffc90001dd7cf8 ffff88000d998000 12月6日 12:26:38 ip-172-31-29-103 内核:[939499.825371] ffffc90001dd7be8 ffffffff811f4d5b ffffc90000000000 00000000000000000

答案1

MySQL 停止工作,因为您的系统内存不足并终止了进程。MySQL 终止时,它占用了 1,336,104 KB。这比 T2.micro 占用的内存还多。

您的问题显然是内存使用情况:

  • 您的日志文件显示您的服务器内存不足
  • 您正在使用 338 MB 的交换空间,这也意味着内存不足。
  • 对于使用率如此低的系统,您根本不应该使用交换空间。

您的解决方案是通过切换到更大的实例大小来为服务器添加更多内存。我是那些认为 T2.micro 对于 WordPress 和数据库来说太小的人之一。

相关内容