MySQL RDSインスタンスがメモリを消費してスワッピングする
Db.m2.4xlargeクラスのRDSインスタンスのメモリに問題があります。
以下はRDSインスタンスの仕様です
インスタンスクラス：db.m2.4xlarge（68.4 GBのRAM）
エンジン：mysql（5.5.37）
IOPS：8000
ストレージ：805GB（128 GBのデータ）
マルチAZ：はい
自動バックアップ：有効（5日）
Mysqlインスタンスは、InnoDBバッファー値を変更せずに調整されます。
合計バッファ：23.9Gグローバル+ 3.0M /スレッド（最大1000スレッド）
可能な最大メモリ使用量：26.8G（インストールされているRAMの42％）
InnoDBテーブルのデータ：98G
以前は、より最適化されたより高いバッファー値を使用していましたが、再起動の頻度により、RDSによって設定されたデフォルトのバッファーサイズに戻す必要がありました。
私たちのアプリケーションは4つのColdFusionサーバーと4つのasp.netサーバーで動作し、それらはすべて関連するMySQL RDSインスタンスと通信します。アプリケーションには接続プーリングを使用しています。すべてのDMLステートメントはストアドプロシージャを使用して実行され、非常に頻繁に実行されます。
私の問題は、RDSインスタンスをそのままにしておくと、メモリをゆっくりと消費してスワップを開始することです。スワップすると、アプリケーションが1つずつ失敗し始めます。したがって、インスタンスを再起動する唯一のオプションが残ります。現在、メモリが5 GB未満になると、サーバーを再起動します。
もう1つのアプローチは、常温核融合サーバーを再起動し、IISを再起動してから、「flush tables」クエリを発行することです。ただし、これにより結果が得られる場合があります、しかし時々、変化はありません。理論的には、flush tablesクエリがなくても、メモリは解放されるはずですが、発生しません。ここでも、解放されたメモリは通常は1〜7 GBの範囲です。
MySQLに設定されたインタラクティブタイムアウトは300秒で、ColdFusion接続のライフタイムは300秒で、asp.netに設定されたタイムアウトは270秒です。
メモリを使用しているものを追跡し、それ自体を維持することはできません。メモリは、MySQLが必要とするときに理想的に解放される必要があります。しかし、それは起こっていません。
RDSインスタンスが再起動せずに機能し続けるように、メモリの消費を追跡する方法についてのガイダンスが必要です。
すでにMONyogがRDSを監視しています。また、RDSでグローバルステータス履歴（GoSH）を有効にしましたが、これは私にはあまり役に立ちませんでした。
すでにここで言及されている同様の問題を目にしました@ メモリ使用量に基づいてRDS MySQLインスタンスをアップグレードすることをいつ検討する必要がありますか？ DBチューニングの一部として推奨されるすべてのことをすでに行っています。
以下はグラフです
このグラフは過去3週間を示しています
グラフは、メモリが0になり、スワッピングを開始した後に発生したリブートから始まります。その後、2回の再起動が行われました。
今週
2014年8月19日に発生したメモリの解放は2つあります。6GBを解放したのは、以下で説明するように、サービスの再起動とテーブルのフラッシュによって行われました。
これは過去24時間の経過です。
[〜＃〜]編集[〜＃〜]
必要に応じて詳細を追加します。
プロセスリストは以下のとおりです
mysql> SHOW PROCESSLIST;
+ -------- + ----------------- + ---------------------- ------------------------------ + ------------ + ------ --- + ------- + ----------------------------- + -------- ---------- + | Id |ユーザー|ホスト
| db |コマンド|時間|州|情報
| + -------- + ----------------- + ---------------------- ------------------------------ + ------------ + ------ --- + ------- + ----------------------------- + -------- ---------- + | 1 | event_scheduler |ローカルホスト
| NULL |デーモン| 30 |次のアクティベーションを待機しています|ヌル
| | 332 |ユーザー| ip3：32355 | NULL |睡眠| 1 | |ヌル
| | 836 | rdsadmin | localhost：40463
| mysql |睡眠| 6 | |ヌル
| | 345919 |ユーザー| server2：49173 | NULL |睡眠| 0 | | NULL | | 354132 |ユーザー| server2：49641 | NULL |睡眠| 82 | | NULL | | 386366 |ユーザー| ip1.us-west-2.compute.internal：64097 | db |睡眠| 1 | | NULL | | 389625 |ユーザー| ip2.us-west-2.compute.internal：59819 | db |睡眠| 0 | | NULL | | 390109 |ユーザー
| ip1.us-west-2.compute.internal：64879 | db |睡眠| 1 |
| NULL | | 391366 |ユーザー| ip2.us-west-2.compute.internal：60319 | db |睡眠| 1 |
| NULL | | 392045 |ユーザー| ip3：39593
| NULL |睡眠| 20193 | |ヌル
| | 393625 |ユーザー| ip3：26708 | db |睡眠| 3902 | | NULL | | 393626 |ユーザー| ip3：37544 |ヌル
|睡眠| 5677 | | NULL | | 393933 |ユーザー| ip2.us-west-2.compute.internal：60912 | db |睡眠| 0 | | NULL | | 394462 |ユーザー| ip1.us-west-2.compute.internal：49971 | db |睡眠|
3 | | NULL | | 394802 |ユーザー
| ip7：1142 | db |睡眠| 88 |
| NULL | | 395410 |ユーザー| ip2.us-west-2.compute.internal：64725 | db |睡眠| 4 |
| NULL | | 396217 |ユーザー| ip2.us-west-2.compute.internal：64891 | db |睡眠| 12 |
| NULL | | 396581 |ユーザー| ip7：1423
| db |睡眠| 22 | |ヌル
| | 396731 |ユーザー| ip7：1429 | db |睡眠| 21 | | NULL | | 396954 |ユーザー| ip1.us-west-2.compute.internal：50472 | db |睡眠| 7 | | NULL | | 398509 |ユーザー| ip1.us-west-2.compute.internal：50595 | db |睡眠|
179 | | NULL | | 399337 |ユーザー| ip3.us-west-2.compute.internal：49539 | db |睡眠| 219 |
| NULL | | 399338 |ユーザー| ip3.us-west-2.compute.internal：49540 | db |睡眠| 219 |
| NULL | | 399360 |ユーザー| ip4.us-west-2.compute.internal：62560 | db |睡眠| 0 |
| NULL | | 399363 |ユーザー| ip4.us-west-2.compute.internal：62568 | db |睡眠| 0 |
| NULL | | 399580 |ユーザー| ip5.us-west-2.compute.internal：50055 | db |睡眠| 1 |
| NULL | | 399581 |ユーザー| ip6.us-west-2.compute.internal：58023 | db |睡眠| 1 |
| NULL | | 399607 |ユーザー| ip6.us-west-2.compute.internal：58034 | db |睡眠| 1 |
| NULL | | 399608 |ユーザー| ip6.us-west-2.compute.internal：58036 | db |睡眠| 1 |
| NULL | | 399609 |ユーザー| ip6.us-west-2.compute.internal：58037 | db |睡眠| 1 |
| NULL | | 399669 |ユーザー| ip4.us-west-2.compute.internal：62615 | db |睡眠| 0 |
| NULL | | 399682 |ユーザー| ip3：9507
| NULL |クエリ| 0 | NULL |プロセスリストを表示する| | 399696 |ユーザー| server1：53241 | db |睡眠| 1 | |ヌル
| | 399704 |ユーザー| server1：53242 | db |睡眠
| 0 | | NULL | | 399705 |ユーザー| ip4.us-west-2.compute.internal：62618 | db |睡眠|
0 | | NULL | | 399706 |ユーザー
| ip4.us-west-2.compute.internal：62619 | db |睡眠| 0 |
| NULL | | 399707 |ユーザー| ip4.us-west-2.compute.internal：62620 | db |睡眠| 0 |
| NULL | + -------- + ----------------- + ---------------------- ------------------------------ + ------------ + ------ --- + ------- + ----------------------------- + -------- ---------- +
SHOW ENGINE INNODB STATUS
データを正しくフォーマットできなかったため、Pastebinに上書きします http://Pastebin.com/JETQ6KG
ありがとうございました。
サーバーは午前中に再び再起動され、メモリが解放されました。
バージョン5.7 （現在開発中）になるまで、メモリはMySQLでインストルメント化されないため、これはあなたの質問を推測ゲームのようにします。
InnoDBのステータスを見ると、InnoDBがメモリを消費しているようには見えないことがわかります（問題が発生したときに収集したものと想定）。
Total memory allocated 26217103360; in additional pool allocated 0
Dictionary memory allocated 1212141
Buffer pool size 1563519
合計メモリ：24.41 GiB（InnoDBは、内部構造用のバッファープールよりも約5〜10％多く必要）バッファープールメモリ：〜23.85 GiB
メモリがMySQLレイヤー（InnoDBではない）で消費されることを推測する必要があります。2つの一般的な原因は、組み込みの一時テーブルと非常に大きなソート/結合バッファーです。