AWS EC2 t2.micro实例非常不稳定。

Question

AWS EC2 t2.micro实例非常不稳定。

amazon-web-servicesamazon-ec2reboot

4

我在AWS EC2 t2.micro实例上运行一个WordPress页面。没有什么花哨的东西，只是一个简单的WordPress网站。

每隔几周，以下情况会相当频繁地发生：

1. 我的页面无法访问，ssh也无法访问 2. 在仪表板上检查时，一切看起来都正常，没有警告或投诉 3. 在AWS管理面板上重新启动它后，其中一个检查将失败：“实例可达性检查在（时间）失败”

系统日志显示出现了内核恐慌（下面复制了所有日志）。这可能是什么原因引起的？AWS方面的硬件有问题吗？这真的让我很困惑，请帮忙解答。谢谢！

[2950123.794183] end_request: I/O error, dev xvda, sector 13514688
[2950123.797618] end_request: I/O error, dev xvda, sector 13514712
[2950123.798170] end_request: I/O error, dev xvda, sector 13514776
[2950123.798170] end_request: I/O error, dev xvda, sector 13514816
[2950123.798170] end_request: I/O error, dev xvda, sector 13514872
[2950123.798170] end_request: I/O error, dev xvda, sector 12894512
[2950123.798170] end_request: I/O error, dev xvda, sector 12875536
[2950123.798170] end_request: I/O error, dev xvda, sector 511456
[2950123.798170] end_request: I/O error, dev xvda, sector 13403944
[2950123.798170] end_request: I/O error, dev xvda, sector 515968
[2950124.114201] Kernel panic - not syncing: Attempted to kill init! exitcode=0x00000007
[2950124.114201] 
[2950124.118093] CPU: 0 PID: 1 Comm: init Not tainted 3.14.35-28.38.amzn1.x86_64 #1
[2950124.118093] Hardware name: Xen HVM domU, BIOS 4.2.amazon 05/06/2015
[2950124.118093]  ffff88003d578ae0 ffff88003da2bc80 ffffffff814867ca ffffffff81788cf0
[2950124.118093]  ffff88003da2bcf8 ffffffff814825ab ffffffff00000010 ffff88003da2bd08
[2950124.118093]  ffff88003da2bca8 ffffffff81c9af20 0000000000000007 ffff88003da30480
[2950124.118093] Call Trace:
[2950124.118093]  [<ffffffff814867ca>] dump_stack+0x45/0x56
[2950124.118093]  [<ffffffff814825ab>] panic+0xc8/0x1cd
[2950124.118093]  [<ffffffff8105ffd1>] do_exit+0xa41/0xa50
[2950124.118093]  [<ffffffff8106005f>] do_group_exit+0x3f/0xa0
[2950124.118093]  [<ffffffff8106f707>] get_signal_to_deliver+0x1c7/0x6e0
[2950124.118093]  [<ffffffff81014458>] do_signal+0x48/0x6f0
[2950124.118093]  [<ffffffff811e7c38>] ? fsnotify+0x228/0x2f0
[2950124.118093]  [<ffffffff81014b68>] do_notify_resume+0x68/0x90
[2950124.118093]  [<ffffffff8148d822>] retint_signal+0x48/0x86

- Kitetaka

如果您转移到其他t2.micro实例，会发生什么？ - tedder42

不确定这是否有所不同 - 我碰巧落在了一台“柠檬”硬件上？ :) - Kitetaka

这将排除掉它，是的。 - tedder42

不必重新启动，如果我停止实例，然后再次启动它，它就可以工作（在另外几周之前会再次出现问题），此外这种方式会更改实例的IP地址，而且去路由53并重定向DNS到新的IP地址/终端点也很麻烦。 - Kitetaka

1个回答

网页内容由stack overflow 提供, 点击上面的

可以查看英文原文，
原文链接

- E.J. Brennan · Accepted Answer

你应该设计一个可以应对失败的解决方案。失败是不可避免的，但AWS提供了所有处理问题所需的服务。

将你的ec2实例设置在自动扩展组中，并创建/设置健康检查，以便AWS可以确定实例是否正常运行。

如果你正确设置了它，当AWS发现你的实例正在失败/已经失败时，它会自动用另一个实例替换它。

这将需要你在架构上进行一些工作，但随后你就不必再担心监视/检查你的实例并在出现问题时启动新实例了。

http://docs.aws.amazon.com/AutoScaling/latest/DeveloperGuide/WhatIsAutoScaling.html

不要把您的EC2实例当作普通的托管服务提供商套餐来对待，即您购买并将解决方案放入其中，并期望它永远按原样运行。如果这是您的计划，那么最好选择常规的托管服务提供商 - 他们会负责通过为您管理底层硬件/软件来确保您的网站永远运行。

如果您要使用AWS，请利用他们的平台。

至于您的具体问题，我倾向于认为是内存泄漏 - 症状听起来正确，您从头开始运行它可以连续运行数天/数周，然后崩溃。