web-dev-qa-db-ja.com

AWS RDS本当に奇妙なエラー...＃1041メモリ不足、バッファOK、メモリOK

AWS RDS（MySQL 5.6.35）db.m3.mediumを使用していますが、過去2週間にテーブルの構造を変更しようとするとランダムなエラーが発生しました。

#1041 - Out of memory; check if mysqld or some other process uses all available memory; if not, you may have to use 'ulimit' to allow mysqld to use more memory or you can add more swap space

メモリがはるかに少ない非常に小さなインスタンスでさえ、このエラーに遭遇したことはありません。このインスタンスでは暗号化isが有効になっているため、負荷が少し増える可能性があることに注意してください。

コンソールでメモリ統計を確認すると、100％近く使用されているようには見えません。インスタンスがスワップしているようにも見えません。再起動後、テーブルを適切に変更できます。このテーブルは非常に小さいです... 10列未満、オーバーヘッドはほとんどなく、行数は多くありません（<100）。奇妙なことに、RDSのデフォルトのバッファーサイズ（インスタンスのメモリ割り当ての3/4）は変更していません。これだけでなく、バ​​ッファテーブルをチェックした後も、すべてが問題ないように見えました。

ここで何か不足していますか？

更新：それは再び起こりました。 RDSサーバーを再起動すると、発生している問題が軽減されます。これは、インシデント発生時のバッファ統計のスクリーンショットです（これは、問題を修正する再起動前です）...

screenshot

アップデート9/1/2017：RDSインスタンスをm4.large...にアップグレードした後、しばらくの間問題を軽減したと思っていましたが、しばらくの間はそうでした。ただし、今夜の前にいくつかの移行を実行している間...間違いなく、エラー＃1041-メモリ不足です。私はすぐにCloudWatchレポートに異常がないかどうかを確認しました。解放可能なメモリは非常に高く、あまり変動していません。さらに、再起動により問題が修正されました。私はそれが再び起こるのをまだ見ていませんが、いくつかのトランザクションの数週間後には再び起こると確信しています。 データベースが破損している可能性がありますか？データベースの読み取りや書き込みに問題が発生したことはなく、すべてのアプリケーションがこのサーバーでデータベースを問題なく使用しています。 phpMyAdmin内からALTER TABLEの変更を開始できないだけです...

mysqlinnodbmysql-5.6amazon-rdsaws
3
1234567

私はあなたがここに一人でいるとは思わない。 AWSは5.7.11から5.7.17に私をプッシュしましたが、データベースに何らかの種類のメモリプレッシャーがあると、テーブルの変更コマンドを実行できません。

https://forums.aws.Amazon.com/thread.jspa?threadID=251866 をご覧ください

この時点で、MySQL 5.6 <5.6.37および5.7 <5.7.19に問題がある可能性があります。

残念ながら、AWS RDSには5.6.35または5.7> 5.7.17を超える5.6イメージはありません。

5.7.17を使用する前は、5.7.11をしばらくの間問題なく使用していました。データベースをダンプ/復元できる場合は、それが最適なオプションとなる可能性があります。そうでない場合は、より大きなインスタンスを試すことができます。

2
notnightman

これはdb.m3.mediumなので、2つの問題、おそらく3つの問題が発生します。

問題＃1：利用可能なRAM

RDSはRAM for innodb_buffer_pool_size の75％を使用しているため、OSには960Mしかありません。ヘッドルームはあまりありません。

問題＃2：DB接続

複数のDB接続を開いたり閉じたりすると、OSが利用可能なDB接続と競合する可能性がありますRAM（私の以前の投稿を参照してください： DB接続の開閉にはどれくらいのコストがかかりますか？ ）

問題＃3：データベース内のテーブルが多すぎる

テーブルと列が多いとメモリが消費されることをご存知ですか？

自問する質問

  • 最近テーブルを追加しましたか？
  • 1つ以上のテーブルの列数を増やしましたか？
  • 多くのクエリ（SHOW OPEN TABLES;を実行）を実行した後、開いているファイルテーブルがたくさんありますか？

提案

おそらく、FLUSH TABLES;を実行するだけで、ALTER TABLEコマンドを実行する直前に、以前にアクセスしたテーブルへの開いているすべてのファイルハンドルが閉じられます。

2017-08-15 08:21 EDTを更新

あなたが投稿したインシデント発生時のバッファ統計を見ました。

  • InnoDBバッファープールは98.8023％空です（168454/170496）
  • 31.59375 MB（2022 * 16384 /1048576）のデータしかない
  • わからない部分はこちらです
    • フラッシュする23824ページがあります
    • つまり、372.25 MB（23824 * 16384 /1048576）があることを意味します。
    • 実際のデータの11.78倍です

32 MBのデータしかない場合、世界でどのように372 MBをフラッシュする必要があるでしょうか。

問題＃4：圧縮（多分）

innodb_file_format Barracuda を使用していないことを願っています。これには、InnoDBバッファープール内のページを圧縮解除する必要があります。より大きなバッファプールが必要になります。私はこれについて前に書いた：

問題＃5：CPU

db.m3.mediumのみ1 vCPU。つまり、InnoDB、暗号化、OSはすべて1つのvCPUで実行されています。痛い!!!

問題1の再考

バッファー統計によると、InnoDBバッファープール用に2664 MBがあります

  • バッファプールは、インストールされているRAMの75％であると想定されています。
  • db.m3.mediumには、3840 MB（3.75 GB）しかない。残りRAMは960MBです
  • 統計によると、RAMの75％は2664 MBです。つまり、RAMの100％は3552 MBです。
  • したがって、残りのRAM OSの場合、960 MBではなく888 MBになります。

勧告

次のいずれかまたは両方を実行してください。

  • 暗号化の使用をやめる
  • さらに取得RAM（アップグレードサーバークラス）
1
RolandoMySQLDBA