12

x64 amazon linux ami に EC2 インスタンスを設定しています。

私は PHP と Wordpress を W3 トータル キャッシュと php-apc を使用して MySQL に支えられて、かなりの数の接続を比較的安価に処理できるブログをテストしています。

ただし、私の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 から NginX などの別の http サーバーに移行することには注意してください。これは抜本的な手順であり、問​​題を解決する可能性があります.....しかし、間違った理由で

私はこれらのほとんどに罪を犯し、apache /var/log/httpd/ACCESS_LOG ファイルを見て、自分のサイトが というファイルを探している同じ IP から 1 秒間に数回アクセスされていることを確認するまで、多くの誤った希望を提起しました。 XMLRPC.PHP は、Wordpress 業界でよく知られている DDOS 攻撃の一種です。

access_log エントリの例 ....

191.96.249.80 - - [21/11/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 の影響が見られない場合は、別の原因である可能性があります。上記のすべてを試してください。;-) しかし、この攻撃に苦しめられているワードプレス/Apache サイトをいくつか見てきました。...同じIPも！残念なことに、Amazon AWS はセキュリティ グループでブラックリストを許可していません。[はぁ]

于 2016-11-23T16:25:25.893 に答える
4

あなたのインスタンスには、あなたがやりたいことをするために必要なメモリが不足していると思います。

MySQLにRDSを使用することを検討しましたか？これはAWSの世界で実際に推奨される方法であり（少なくともDBの場合、高度なカスタム構成は必要ありません）、EBSストレージでMySQLを実行するよりもはるかに優れたパフォーマンスを提供します（他の方法で実行していると思います）。 DBコンテンツを永続化する方法はありません）。

于 2012-09-12T19:58:26.440 に答える
1

apache を調整して修正しました。あまりにも多くの予備サーバーを起動しようとして、すべてのメモリを使い果たしていました。

#MinSpareServers    5
#MaxSpareServers   20
MinSpareServers    2
MaxSpareServers   4

もちろん、サイトを運営するにはある程度の資金が必要ですが、私のサイトはトラフィックが少ないです。

于 2014-06-18T20:30:05.317 に答える
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 に答える
0

t2.small EC2 インスタンスでも同様の問題がありました。ログインして mysql を再起動すると、おなじみのデータベース エラー メッセージが再び表示されるまでの約 5 分間、ウェブサイトは問題ありません。

これは、エラスティック IP を使用して Wordpress Web サイトを実行していました。これらの手順を実行した後、データは失われませんでした。これは、このインスタンスの EBS ストレージが原因であると理解しています。

手順:

  1. AWS コンソールにログイン

  2. EC2に移動してインスタンスを選択

  3. アクション -> インスタンスの状態 -> 停止 (停止に約 3 分かかりました)

  4. Actions -> Instance Settings -> Change Instance Type (私は t2.small から t2.medium に変更しました)

  5. アクション -> インスタンスの状態 -> 開始

インスタンスが開始されてからウェブサイトをリロードすると、すべてが正常に戻りました。

インスタンスのアップスケーリングには明らかに価格に関する考慮事項があります。

詳細: http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-instance-resize.html

于 2016-03-05T08:49:44.603 に答える