Aurora MySQL データベースのメモリ不足の問題のトラブルシューティング
Aurora MySQL DB インスタンスのメモリが著しく不足している場合、オペレーティングシステムはデータベースプロセスを終了させ、予期しない再起動を引き起こす可能性があります。こうした再起動を防ぐために、Aurora MySQL には、システムメモリをモニタリングし、メモリが少ないときに自動復旧アクションを実行するメモリ管理機能が含まれています。これらのアクションは、メモリの枯渇によるデータベースの可用性の低下を防ぐのに役立ちます。
次のパラメータはこの動作を制御します。
-
aurora_enable_memory_management– Aurora MySQL 8.4 でのみ使用できます。-
ON(デフォルト) の場合、Aurora は自動的にメモリ復旧アクションを管理し、aurora_oom_responseパラメータは無視されます。 -
復旧アクションを手動で制御するには、
aurora_oom_responseをOFFに設定します。
-
-
aurora_oom_response– カンマ区切りの復旧アクションのリスト。空の文字列を指定すると、すべてのアクションが無効になります。Aurora MySQL バージョン 3 で利用可能です。Aurora MySQL 8.4 でも利用できますが、aurora_enable_memory_managementがOFFに設定されている場合にのみ考慮されます。
OOM レスポンスアクション
以下のアクションを aurora_oom_response に含めることができます。影響の小さいものから大きいものの順に示しています。
| アクション | その内容 | 注意事項 |
|---|---|---|
print |
メモリを大量に消費するクエリと接続をエラーログに記録します。クエリや接続は終了されません。 | Aurora MySQL バージョン 3 および 8.4 で利用可能です。 |
tune |
内部テーブルキャッシュ (table_open_cache、table_definition_cache) を縮小してメモリを解放します。キャッシュサイズは、メモリが通常に戻ると復元されます。以前にキャッシュされたエントリは復元されません。新しいエントリは、後続のクエリがそれらにアクセスするときにのみ追加されます。 |
Aurora MySQL バージョン 3 および 8.4 で利用可能です。プロビジョニングされたインスタンスのみ - Serverless v2 ではサポートされていません。 |
tune_buffer_pool |
InnoDB バッファプールを縮小してメモリを解放します。メモリが通常に戻ると、バッファプールのサイズが復元されます。以前に削除されたキャッシュされたページは自動的に再ロードされません。新しいページは、後続のクエリがそれらにアクセスするときにのみキャッシュされます。 | Aurora MySQL バージョン 3 (3.06 以降) および Aurora MySQL 8.4 のみ。2 つの vCPU を持つプロビジョニングされたインスタンスでのみサポートされます。Serverless v2 ではサポートされていません。 |
decline |
メモリが少ない間は、新しいクエリをエラーで拒否します。 | Aurora MySQL バージョン 3 および 8.4 で利用可能です。 |
kill_query |
メモリ消費が最も多いクエリから順に、メモリが通常に戻るまで、実行中の SELECT クエリを終了させます。DDL、その他の DML、およびトランザクションは影響を受けません。 |
Aurora MySQL バージョン 3 および 8.4 で利用可能です。kill_connect とは相互排他的 – 両方が設定されている場合、kill_connect のみがアクティブ化されます。 |
kill_connect |
ユーザー接続を終了し、アクティブなトランザクションをロールバックして、DDL ステートメントを終了します。 | バージョン固有の動作については、以下を参照してください。 |
重要
tune_buffer_pool を kill_query または aurora_oom_response パラメータ値の kill_connect とペアにする必要があります。これらのいずれかがない場合、tune_buffer_pool が含まれている場合でも、バッファプールのサイズ変更は行われません。
kill_connect バージョン固有の動作
| Aurora MySQL バージョン | 行動 |
|---|---|
| Aurora MySQL 3.04 – Aurora MySQL 3.10 | データベースがメモリ負荷から回復するのに十分なメモリを解放するために、ユーザー接続を終了します。 |
| Aurora MySQL 3.11 以降、Aurora MySQL 8.4 | データベースがメモリ負荷から回復するのに十分なメモリを解放するために、ユーザー接続を終了します。また、メモリ負荷時にメモリの割り当てを試みるユーザー接続も終了します。 |
Serverless v2 では、Aurora はまず ACU をスケールアップして追加のメモリを提供します。スケーリングの進行中にメモリ負荷が継続する場合、Aurora はメモリを回復するために既存の接続を終了することがあります。メモリの割り当てを試みる接続の終了は、インスタンスが設定された最大 ACU 制限に達し、それ以上スケーリングできなくなった場合にのみ発生します。
バージョンごとのデフォルト値
Aurora MySQL は、エンジンのバージョン、インスタンスタイプ、使用可能なメモリに基づいて自動的に aurora_oom_response を設定します。
Aurora MySQL 8.4 では、aurora_enable_memory_management が ON (デフォルト) の場合、Aurora は自動的にメモリ復旧アクションを管理し、aurora_oom_response 値は使用されません。OFF に設定すると、Aurora は aurora_oom_response 値を直接使用します。この値はデフォルトでは空なので、明示的に設定しない限り、復旧アクションは実行されません。次のデフォルトの表は、Aurora MySQL バージョン 3 にのみ適用されます。
スモールインスタンスのしきい値: バージョン 3.04 および 3.05 では ≤2 GiB。バージョン 3.06 以降では ≤4 GiB。
ラージインスタンスのしきい値: バージョン 3.04 および 3.05 では >2 GiB。バージョン 3.06 以降では >4 GiB。
| バージョン | インスタンスサイズ | プロビジョンド | Serverless v2 |
|---|---|---|---|
| Aurora MySQL 3.04–Aurora MySQL 3.05 | Small | print,tune | print |
| 大 | (無効) | (無効) | |
| Aurora MySQL 3.06 | Small | print,tune,decline,kill_connect | print |
| 大 | (無効) | (無効) | |
| Aurora MySQL 3.07 | Small | print,tune,decline,kill_connect | print |
| 大 | print | print | |
| Aurora MySQL 3.08 | Small | print,tune,tune_buffer_pool,decline,kill_connect | print |
| 大 | print | print | |
| Aurora MySQL 3.09–Aurora MySQL 3.10 | Small | print,tune,tune_buffer_pool,decline,kill_connect | print |
| 大 | print,decline,kill_connect | print,decline,kill_connect | |
| Aurora MySQL 3.11 以降 | Small | print,tune,tune_buffer_pool,decline,kill_connect | print,decline,kill_connect |
| 大 | print,decline,kill_connect | print,decline,kill_connect |
Aurora Serverless v2
tune および tune_buffer_pool アクションは、Aurora Serverless v2 ではサポートされていません。他のすべてのアクションは、プロビジョニングされたインスタンスと同じように動作します。
メモリしきい値は、インスタンスが ACU をスケールするにつれて動的に調整されます。上記のデフォルトの表の Serverless v2 列には、各バージョンの有効なデフォルトが表示されています。
モニタリング
OOM 回避アクティビティは、次の方法でモニタリングできます。
エラーログ
メモリ復旧アクションが実行されると、Aurora MySQL はデータベースのエラーログにメッセージを書き込みます。メッセージのプレフィックスはバージョンによって異なり、今後のリリースで変更される可能性があります。
Aurora MySQL バージョン 3: メッセージには
OOM crash avoidance:というプレフィックスが付いています。Aurora MySQL バージョン 8.4: メッセージには
Aurora memory management:というプレフィックスが付いています。
これらのメッセージには以下が含まれます。
合計メモリと使用可能なメモリを含む、メモリ負荷の検出および復旧の通知
メモリ復旧のために終了したクエリまたは接続の詳細
printアクションによって識別される候補クエリ
エラーログを表示するには、「Aurora MySQL エラーログ」を参照してください。
Amazon CloudWatch メトリクス
次の CloudWatch メトリクスは、インスタンスレベルで OOM 回避アクティビティを追跡します。
| メトリクス | 説明 | 利用可能なバージョン | Unit |
|---|---|---|---|
AuroraMemoryHealthState | メモリのヘルス状態を示します。0 は正常 (メモリ負荷なし)、5 は中程度のメモリ負荷、10 は重大なメモリ負荷を意味します。 | Aurora MySQL 3.06.1 以降、Aurora MySQL 8.4 | ゲージ |
AuroraMemoryNumDeclinedSqlTotal | OOM 回避の一環として拒否したクエリの増分数。 | Aurora MySQL 3.06.1 以降、Aurora MySQL 8.4 | カウント |
AuroraMemoryNumKillConnTotal | OOM 回避の一貫として閉じられた接続の増分数。 | Aurora MySQL 3.06.1 以降、Aurora MySQL 8.4 | カウント |
AuroraMemoryNumKillQueryTotal | OOM 回避の一環として終了されたクエリの増分数。 | Aurora MySQL 3.06.1 以降、Aurora MySQL 8.4 | カウント |
AuroraMillisecondsSpentInOomRecovery | メモリのヘルス状態が通常の状態を下回ってからの時間。 | Aurora MySQL 3.08.0 以降、Aurora MySQL 8.4 | ミリ秒 |
AuroraNumOomRecoverySuccessful | メモリのヘルス状態が通常の状態に復元された回数。 | Aurora MySQL 3.08.0 以降、Aurora MySQL 8.4 | カウント |
AuroraNumOomRecoveryTriggered | メモリのヘルス状態が通常の状態を下回った回数。 | Aurora MySQL 3.08.0 以降、Aurora MySQL 8.4 | カウント |
次の一般的な CloudWatch メトリクスも、メモリ負荷のモニタリングにも役立ちます。
| メトリクス | 説明 | Unit |
|---|---|---|
FreeableMemory | 使用可能なメモリの量。/proc/meminfo から MemAvailable の値をレポートします。 | バイト |
SwapUsage | 使用したスワップ領域の量。 | バイト |
Aurora MySQL インスタンスレベルのメトリクスの完全なリストについては、「Amazon Aurora のインスタンスレベルのメトリクス」を参照してください。
グローバルステータス変数
次のステータス変数は、OOM 状態に関する情報を提供します。Aurora MySQL バージョン 3.06.0 以降で利用可能。
| 可変 | 説明 |
|---|---|
Aurora_oom_response | この DB インスタンスの現在アクティブな OOM レスポンスアクション。 |
aurora_oom_avoidance_recovery_state | OOM リカバリが ACTIVE か INACTIVE か。 |
aurora_oom_status | データベースの現在のメモリのヘルス状態: 正常 (メモリ負荷なし)、中程度のメモリ負荷、または重大なメモリ負荷。バージョン 3 でのみ使用可能。 |
クエリを実行するには、SHOW GLOBAL STATUS LIKE 'aurora_oom%'; と入力します。
Aurora MySQL グローバルステータス変数の完全なリストについては、「Aurora MySQL グローバルステータス変数」を参照してください。
Performance Insights
Performance Insights が有効になっている場合は、OS レベルのメモリメトリクスを使用してメモリ負荷をモニタリングし、OOM イベントを検出できます。os.memory および os.swap カウンターでは、次のメトリクスを使用できます。
| メトリクス | 説明 |
|---|---|
os.memory.outOfMemoryKillCount | 前回の収集間隔における OOM キルの数。ゼロ以外の値は、メモリが枯渇したためにオペレーティングシステムがプロセスを終了したことを示しており、通常はデータベースの再起動につながります。 |
os.memory.total | メモリの合計量 (キロバイト単位)。 |
os.memory.free | 未割り当てのメモリの量 (キロバイト単位)。 |
os.memory.active | 割り当てられたメモリの量 (キロバイト単位)。 |
os.memory.cached | ファイルシステム I/O のキャッシュに使用されたメモリの量 (キロバイト単位)。 |
os.memory.dirty | 変更されたものの、まだストレージに書き込まれていないメモリページの量 (キロバイト単位)。 |
os.memory.inactive | 最も使用されていないメモリページの量 (キロバイト単位)。 |
os.memory.db.residentSetSize | データベースプロセスで使用されたメモリの量 (共有メモリを除く)。(バイト単位)。 |
os.memory.db.cache | データベースプロセスがページキャッシュに使用したメモリの量 (バイト単位)。 |
os.memory.db.swap | データベースプロセスが使用したスワップメモリの量 (バイト単位)。 |
os.swap.in | ディスクからスワップインされたメモリの量 (キロバイト単位)。 |
os.swap.out | ディスクにスワップアウトされたメモリの量 (キロバイト単位)。 |
os.memory.outOfMemoryKillCount をモニタリングして、OS がメモリ不足のためにデータベースプロセスをいつ強制終了したかを検出できます。OS カウンターの完全なリストについては、「Performance Insights OS メトリクス」を参照してください。
Performance Schema
performance_schema を有効にすると、メモリ概要テーブルを使用して、メモリを最も多く消費しているコンポーネントと接続を特定できます。詳細については、「Aurora MySQL データベースのメモリ使用量に関する問題のトラブルシューティング」を参照してください。
