12

我在 x64 amazon linux ami 上设置了一个 EC2 实例。

我正在使用 PHP 和 Wordpress 以及由 MySQL 支持的 W3 总缓存和 php-apc 来测试一个可以相对便宜地处理相当数量的连接的博客。

但是，我的mysql不断崩溃。

取自 /var/log/mysqld.log

120912  8:44:24 InnoDB: Completed initialization of buffer pool
120912  8:44:24 InnoDB: Fatal error: cannot allocate memory for the buffer pool
120912  8:44:24 [ERROR] Plugin 'InnoDB' init function returned error.
120912  8:44:24 [ERROR] Plugin 'InnoDB' registration as a STORAGE ENGINE failed.
120912  8:44:24 [ERROR] Unknown/unsupported storage engine: InnoDB

有人知道这可能发生的原因吗？

当前内存使用情况（下）

[root@ip-obscure mysql]# free -m
             total       used       free     shared    buffers     cached
Mem:           594        363        230          0          3         67
-/+ buffers/cache:        293        301
Swap:            0          0          0
4

7 回答 7

9

小心断定你没有足够的内存，是的，这是你看到的错误，但这也是一个症状而不是原因。在为更大的实例付费之前等待，问题只会消失一段时间，直到内存再次填满。

小心创建 SWAP 文件，同样，您只是在包扎症状。

也要警惕更改配置设置（并限制 apache 或 mysql 的性能），这已经工作了一段时间，但现在突然服务器根本不会长时间运行。

想想这怎么可能真的是设置？如果在 PHP 中存在优化不佳的设置或内存泄漏，它会在相同的时间段后始终失败。因此，假设您不仅最近安装了新模块并且已经有一段时间的静态环境，那么不太可能是内存泄漏或设置。显然，如果您刚刚安装新模块，禁用它们应该始终是第一步

小心将数据库拆分到另一台服务器，这不会像购买更大的服务器不能解决问题一样解决问题。是的，每个函数最初都会获得更多内存，但随后......

小心从 apache 迁移到另一个 http 服务器，例如 NginX，这是一个激进的步骤，这可能会解决问题......但是出于错误的原因

我对其中的大部分感到内疚，并提出了许多错误的希望，直到我查看了 apache /var/log/httpd/ACCESS_LOG 文件，发现我的网站每秒被同一个 IP 多次访问，寻找一个名为XMLRPC.PHP，一种在 Wordpress 圈子中广为人知的 DDOS 攻击。

示例 access_log 条目 ....

191.96.249.80 - - [21/Nov/2016:20:27:53 +0000] "POST /xmlrpc.php HTTP/1.0" 200 370

每次收到它时，apache 都会尝试实例化一个子进程来服务该请求。不久之后，您的内存耗尽，apache 开始无法派生新进程，mysql 放弃尝试将内存空间分配给缓冲池。您基本上内存不足，所有这些请求都会使您的服务器停止运行。

为了解决这个问题，我更改了 .htaccess 文件以拒绝从该 IP 访问该文件，并且我的服务器立即恢复正常运行。

示例 .htaccess

<Files xmlrpc.php>

order allow,deny

deny from 191.96.249.80

allow from all

</Files>"

希望我来之不易的发现对其他人有所帮助！

显然，如果您的访问日志没有显示 DDOS 效果，则可能是其他原因，请尝试以上所有方法！;-) 但我现在已经看到几个受此攻击影响的 wordpress/apache 站点。......同样的IP！可惜亚马逊 AWS 不允许在其安全组中加入黑名单。[叹]

于 2016-11-23T16:25:25.893 回答
4

我想您的实例缺少执行您想做的事情所需的内存。

您是否考虑过使用 RDS for MySQL？这确实是 AWS 世界中的首选方法（至少对于 DB 而言，不需要高度的自定义配置），并且会比在 EBS 存储上运行 MySQL 提供更好的性能（我假设您正在这样做）无法持久化您的数据库内容）。

于 2012-09-12T19:58:26.440 回答
2

好吧，现在是 2016 年 12 月，显然这仍然存在。

一位客户报告说他的一个网站（不是我公司管理的）出现故障并请求支持。当我们开始寻找问题时，很明显他的网络服务器由于这个漏洞而受到 DDoS 攻击。

其他答案中几乎涵盖了缓解程序，所以我只想添加我的 2 美分：除了.htaccess规则之外，您还可以阻止发起请求的 IP iptables。请参阅此处以获取快速概览。基本上你从中得到的是：

  1. Apache（或您正在使用的任何东西）不会消耗开销资源403来回复攻击来源，甚至不会记录它们（节省大量磁盘空间） - 您的机器将简单地忽略请求；

  2. 如果您意识到请求来自同一个子网，您可以阻止每个子网源的请求，同时攻击许多攻击您的受感染机器。

这显然存在不验证所发出请求的有效性的缺陷，但这也是其他解决方案中的一个因素，并且xmlrpc.php仍然无法访问。此外，从这些来源请求的任何文件都将被拒绝。

基本上，我grep对xmlrpc.php被 Apache 记录的请求进行了计数，并计算了哪些是最有问题的：

cat  /var/log/apache2/access.log | grep xmlrpc.php | awk '{print $1;}' | sort -n | uniq -c | sort -nr | head -20

这将打印出排名前 20 的最违规 IP 的排序列表。我注意到在我最讨厌的前 5 个中，有 4 个来自同一个子网。

然后，在您确定要阻止的那些之后，假设它们的 IP 如下123.123.123.123：

sudo iptables -A INPUT -s 123.123.123.123 -j DROP

或者，如果您想定位某个子网：

sudo iptables -A INPUT -s 123.123.123.123/24 -j DROP

/24表示您的目标是123.123.123.XXXXXX 可以是任何组合。尽可能多地重复此过程。我只用了几条规则就阻止了 90% 以上的请求，但是 YMMV。

另外，请注意，除非您删除iptables上面设置的规则，否则这将停止记录那些有问题的请求。

希望这可以帮助！

于 2016-12-30T11:47:10.133 回答
1

错误说明了一切 - 没有足够的内存来容纳池。

如果这是一个负载较小的测试实例，那么您可以尝试安装小样本cnf

http://fts.ifac.cnr.it/cgi-bin/dwww/usr/share/doc/mysql-server-5.0/examples/my-small.cnf

（官方的在 MySQL 网站上的某个地方，我似乎找不到它）。

否则，出于生产目的，我会认真考虑 Mike Brant 的解决方案；否则，您需要一个更大的 Amazon 实例。

于 2012-09-12T20:16:14.233 回答
1

我通过调整 apache 来修复它 - 它通过尝试启动太多备用服务器来耗尽所有内存：

#MinSpareServers    5
#MaxSpareServers   20
MinSpareServers    2
MaxSpareServers   4

当然，您需要一定的流量来运行您的网站，但我的流量很低。

于 2014-06-18T20:30:05.317 回答
0

我的 t2.small EC2 实例也有类似的问题。我会登录并重新启动 mysql，网站会正常运行大约 5 分钟，然后熟悉的数据库错误消息会再次出现。

这是运行一个具有弹性 IP 的 Wordpress 网站。遵循这些步骤后，我没有丢失任何数据。我知道这是由于此实例上的 EBS 存储造成的。

脚步：

  1. 登录 AWS 控制台

  2. 转到 EC2 并选择实例

  3. 操作 -> 实例状态 -> 停止（大约需要 3 分钟才能停止）

  4. 操作 -> 实例设置 -> 更改实例类型（我从 t2.small 变为 t2.medium）

  5. 动作 -> 实例状态 -> 开始

整个过程几乎没有花费任何时间，一旦实例启动，我重新加载了网站，一切都恢复了正常。

升级您的实例显然需要考虑价格。

更多信息：http ://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-instance-resize.html

于 2016-03-05T08:49:44.603 回答
0

根据上面 Binthere 的回答，我的 EC2 实例上的 MySQL 服务器崩溃也是由于 DDOS 攻击，而不是与内存不足的微型实例有关（这也很有可能）。根据我在网上找到的一些很棒的链接，以下是我为快速检查问题而采取的步骤。

1 - SSH 进入实例

2 - 须藤尾 -200 /var/log/httpd/access_log

然后我在 Wordpress XMLRPC 文件上看到了来自 1 个 IP 地址的大量 POST 请求。这是被攻击了。

3 - 如果他们与我联系，请保留此屏幕截图以向亚马逊滥用团队报告（他们首先采取行动，我在打电话给亚马逊后发现）

4 - sudo cp /var/lock/subsys/mysqld /root/mysqld

5 - sudo rm /var/lock/subsys/mysqld

6 - sudo 服务 httpd 停止

7 - sudo 服务 mysqld 重启

8 - 现在在重新启动网络服务器之前，我在 /var/www/html 的网络根目录中对 .htaccess 文件进行了一些更改（这些是针对我的攻击问题的） sudo nano /var/www/html.htaccess

命令允许，拒绝拒绝 允许所有人

9 - sudo 服务 httpd 启动

10 - 呼吸一个解脱的迹象（无论如何，在我的情况下！）

希望这对任何人都有帮助:)

于 2016-12-16T21:48:42.227 回答