十分なメモリがあるのに Amazon RDS DB インスタンスがスワップメモリを使用するのはなぜですか?
Amazon Relational Database Service (Amazon RDS) DB インスタンスを実行しています。十分な空きメモリが割り当てられているにもかかわらず、大量のスワップメモリを使用されています。十分なメモリがあるのに、スワップメモリが使用される理由は何ですか?
簡単な説明
Linux を実行する Amazon Elastic Compute Cloud (Amazon EC2) インスタンスは、システムが割り当てられた以上のメモリを必要とするときにスワップメモリを使用します。詳細については、インスタンスストアのスワップボリュームをご参照ください。ほとんどの RDS DB インスタンスでは Linux が使用されるため (SQL Server を除く)、データベースでスワップメモリを使用できる場合があります。
RDS DB インスタンスは、クエリの実行時など、ページが現在アクセスされている場合にのみ RAM でそれらのページを必要とします。以前に実行されたクエリによって RAM に取り込まれた他のページは、最近使用されていない場合、領域をスワップするためにフラッシュされます。オペレーティングシステム (OS) がページをメモリに保持するのではなく、古いページをスワップすることがベストプラクティスです。これにより、今後のクエリに使用できる十分な空き RAM があることを確認できます。
スワップ使用量をクリアすると、スワップが必要になったときやページを再ロードするときに、スワップを再割り当てするための余分なオーバーヘッドが必要になるため、Linux のスワップ使用量は頻繁にはクリアされません。その結果、スワップ領域が RDS DB インスタンスで 1 回でも使用されると、SwapUsage メトリクスはゼロに戻りません。Amazon RDS for Oracle でサポートされている HugePages および Amazon RDS for PostgreSQL の HugePages を使用する場合も、スワップメモリを使用できます。HugePages は、Linux のデフォルトサイズである 2 メガバイトよりも大きいです。
解決方法
RDS DB インスタンスのスワップ使用に関する動作を理解するには、まずアプリケーションのワークロードに基づいて DB パフォーマンスのメトリクスを確認してください。FreeableMemory と SwapUsage の両方の Amazon CloudWatch メトリクスを調べて、RDS DB インスタンスの全体的なメモリ使用パターンを把握します。SwapUsage メトリクスの増加と同時に発生する FreeableMemory メトリクスの減少については、これらのメトリクスを確認してください。これは、RDS DB インスタンスのメモリに負荷がかかっていることを示す可能性があります。詳細については、「Amazon RDS for MySQL データベースの空きメモリが少ない問題を解決するにはどうすればよいですか?」を参照してください。 十分な空きメモリがある場合は、スワップを使用しても RDS DB インスタンスのパフォーマンスには影響しないはずです。空きメモリが常に少ないままの場合は、より多くのメモリを搭載した、さらに大きなインスタンスサイズに、RDS DB インスタンスサイズを変更できます。
スワップメモリをモニタリングするには、拡張モニタリングをオンにして、1 秒のわずかな間隔でメトリクスを確認します。拡張モニタリングではホストレベルで統計情報が収集され、CloudWatch が 60 秒ごとにハイパーバイザーレベルからデータを収集します。拡張モニタリングを使用して、1 秒間だけ発生した増減を特定し、個々のプロセスで使用されている CPU とメモリを確認します。詳細については、「CloudWatch Logs を使用した OS メトリクスの表示」を参照してください。
また、Performance Insights を有効化して、RDS DB インスタンスで過剰なスワップ処理やメモリ消費の原因となる SQL や待機イベントを特定することもできます。Performance Insights がデータベースレベルでデータを収集し、そのデータは Performance Insights ダッシュボードに表示されます。Performance Insights は、データベースのパフォーマンスに関する問題のトラブルシューティングに役立ちます。詳細については、「Amazon RDS での Performance Insights を使用した DB 負荷のモニタリング」を参照してください。
Amazon RDS for MySQL
空きメモリが少ない場合は、SHOW FULL PROCESSLIST を実行して、データベースで実行されているすべてのスレッドを確認します。SHOW FULL PROCESSLIST 出力のプロセス ID は、拡張モニタリングで表示されるプロセス ID と一致しません。正しいプロセス ID を表示するには、データベースに関連付けられている DB パラメータグループを Performance_Schema パラメータに変更してください。これは静的パラメータなので、RDS DB インスタンスを再起動する必要があります。ダウンタイムを回避するには、パラメータを変更して、ピークトラフィック時間外にデータベースを再起動します。メモリが目的の使用量に達した後に、次のステップを実行してください。
1. [拡張モニタリング] ページでプロセス ID を並べ替えて、CPU を最大消費しているプロセスの ID を確認できるようにします。
2. マスターユーザーとして、次のクエリを実行します。
select * from performance_schema.threads where THREAD_OS_ID in (ID shown in the Enhanced Monitoring window)\G
例えば、最大メモリが Thread_OS_Id 10374 および 1432 によって消費されている場合は、次のクエリを実行します。
select * from performance_schema.threads where THREAD_OS_ID in (10374, 1432)\G
詳細については、MySQL ウェブサイトの「スレッドテーブル」を参照してください。
3. このクエリの出力から PROCESSLIST_ID 列を取得します。これにより、SHOW FULL PROCESSLIST のプロセス ID の値と一致するプロセス ID を取得できます。
正しいプロセス ID を取得したら、そのプロセス ID をクエリにマッピングできます。この ID を使用して、メモリと CPU の使用率が高い根本的な原因を特定できます。また、拡張モニタリングを使用して OS プロセスを表示することもできます。詳細については、「RDS コンソールでの OS メトリクスの表示」を参照してください。
Amazon RDS for PostgreSQL
大量のメモリを消費しているプロセスを特定するには、拡張モニタリングプロセスリストにあるプロセス ID を正確なクエリにマッピングしてください。プロセスを特定するには、次の pg_stat_activity ビューを実行します。
select * from pg_stat_activity where pid=(the PID of your process);
次に、クエリを調整して、コンピューティングリソースの消費量を減らします。
Amazon RDS for SQL Server
拡張モニタリングでは、大量のメモリを消費している特定のスレッド ID が特定される場合があります。スレッド ID は、SQL Server がカーネルプロセス ID (KPID) として参照するものです。
Amazon RDS for SQL Server から、次のクエリを実行して KPID に対応するサーバープロセス ID (SPID) を取得します。
select * from sys.sysprocesses where kpid = '<Value of Thread ID from Enhanced Monitoring>' ;
サーバープロセス ID (69 など) を取得したら、次のコマンドを実行して SPID 69 によって行われている動作を確認します。
dbcc inputbuffer(69)
Amazon RDS for Oracle
拡張モニタリングの OS プロセス ID を使用すると、どのプロセスが最もメモリを消費しているかを確認できます。その後、次のクエリを実行してセッションのプロセスアドレスを取得します。
select ADDR from v$process where SPID=OS_PID;
次のクエリを実行すると、プロセスアドレスを使用してデータベース内のセッションを特定できます。
select sid,serial#,username, status from v$session where PADDR='<ADDR from above query>';
関連情報
関連するコンテンツ
- 質問済み 7年前lg...
- 質問済み 10ヶ月前lg...
- AWS公式更新しました 2年前
- AWS公式更新しました 2年前