概要
本ドキュメントでは、ASAのメモリ高負荷問題が発生時の、トラブルシューティング方法を紹介します。
ASAバージョン 9.x向けに作成しておりますが、多くの情報はASAバージョン 8.x以前でも活用いただけます。
本ドキュメントは ASAバージョン 9.4(2)を元に、確認・作成しております。
メモリ高負荷問題のトラブルシューティング
ASAシステムの メモリ空き容量は、show memory コマンドの Free memoryから確認できます。
ASA# show memory
Free memory: 7312995569 bytes (85%) <--- THIS
Used memory: 1289799599 bytes (15%)
------------- ------------------
Total memory: 8589934592 bytes (100%)
当Free memoryが減り、メモリの使用負荷が高い場合は、その主な原因は以下２つの可能性があります。
1. 特定機能や設定、通信環境に起因したメモリ消費
2. ソフトウェア不具合によるメモリ消費
各トラブルシューティング方法が異なりますので、詳しくは以下を参照ください。
1. 特定機能や設定、通信環境に起因したメモリ消費
多くの場合、システムとして正常なメモリ使用です。 主な原因は以下です。
- 特定機能を利用時 (Threat Detectionや WebVPN)
- ACLの推奨を越えた設定量過多
- その他 設定量過多 (NAT, Vlan, Multiple Context, etc..)
- 通信や その処理量の多い環境で、膨大なコネクションや Xlateエントリ
対応策は以下となります。 なお、メモリFree量が大きく枯渇しているような状態(例：Freeが20～30%以下)でなければ、通常は対処不要です。
- 不要な機能や設定は、削除やチューニングを検討
- 長期運用により溜まった 膨大なACLやNAT設定が原因の場合、不要設定行の削除
- 利用環境や設定量、長期運用に合ったサイジングか (通常 ハイエンドモデルほどメモリ搭載量も多くなります)
ACLの推奨の設定量の目安や 不要ACLの確認・削除方法について詳しくは、ASA: インターフェイスACLの最大設定数と 推奨設定数について を参照してください。
膨大なACL設定やコネクション量などでメモリ高負荷が発生時は、同時にパフォーマンス低下問題が併発する事が多いです。 利用モデルのパフォーマンス不足が疑われるため、現在の設定量や通信量、利用環境に適した利用モデルかの再確認と、必要に応じて メモリ搭載量やパフォーマンスのより良い ASA上位モデルへのアップグレードを検討ください。
2. ソフトウェア不具合によるメモリ消費
メモリリークのソフトウェア不具合の場合、特定プロセスの特定処理のメモリ利用の問題により、その処理のため確保したメモリの一部、もしくは全てを解放できず、メモリ枯渇が進みます。 数週間や数か月単位で、show memory の Free memory状況を確認し、明らかなメモリ使用率の上昇が常にあるか確認をしてください。
なお、ASAは内部でキャッシュとしてメモリを保持する機能、かつ メモリ使用量が多い場合の最適化機能を持ちます。 そのため、Free memoryの使用率に十分な空きがある場合(例：20～30%以上)は、Free memoryの減少が続いていても、正常な動作の範囲内である事が多く、様子をみてください。
継続使用でFree memoryが 残り20～30%を越えて 更に枯渇が進む場合は、メモリリークの可能性があがります。 古いASAバージョンをご利用の場合は、既知不具合の影響を受けている可能性があがるため、ご利用中トレイン内の最新バージョンなどへのバージョンアップを推奨します。 ご利用バージョンのメモリ関連の不具合情報一覧は、リリースノートや Interimリリースノートから確認できます。
バージョンアップ後もメモリ枯渇が続く場合は、以下の TAC調査用の各コマンドを、定期的に複数回取得の上、販売店様やCisco TACにお問合せください。 目安として、メモリ使用率 80%を越えたら取得を検討し、使用率が90%付近まで達した場合は、ログ取得をやめ、再起動によるメモリ開放を検討してください。 複数回の取得は メモリ滞留状況の差分比較のためです。 そのため、メモリ枯渇速度に合わせ、取得間隔は十分あけて取得をお願いいたします。 また、「特定機能や設定を利用開始してから メモリ枯渇が大きく進むようになった」や、「日中の通信量が多い時にメモリ枯渇が早い。夜間は殆どメモリ使用は変わらない」などの情報も合わせ事前調査・ご教示頂けると、分析と解析が早くなります。
【TAC調査用: メモリ問題解析用コマンド: 複数回取得】 (ASA9.1.3以降用)
- メモリ枯渇速度に合わせ、1日に1回、や 1週間に1回、など、3回以上ログ取得
- 出力量が多いため、高速なSSHやTelnetでの取得を推奨
show clock
show memory
show memory detail
show memory top
show memory region !! ASA version 9.5 or later only
show chunk | grep total=
show chunk
show memory app-cache
show block
show block old
show tech
show log
show log asdm
ご利用バージョンが ASA9.1.3未満、もしくは 8.4.6未満の場合は、追加で以下URLを参考に show memory binsize <size> コマンドの出力も取得してください。
https://supportforums.cisco.com/t5/-/-/ta-p/3159693
メモリリークによりFree Memory枯渇が大きく進み、Free Memoryが 0% もしくは それに近づくと、システム不安定化やクラッシュの原因につながります。
ソフトウェア問題によりメモリが枯渇した時の暫定の復旧方法は、ASAの再起動です。 Free memoryが完全に枯渇する前に、メンテナンス時間などにASA再起動を検討してください。
なお、Failover構成でActive機でメモリリーク問題が発生時は、対象機をStandbyにFailoverさせてから 対象機を再起動してください。 通信影響を抑え メモリの回復が可能です。 Failover構成での再起動方法について詳しくは、ASA: 冗長構成(Act/Stby)で Active機とStandby機の再起動方法 (CLI) を参照してください。
よくある質問
メモリ使用率が80%以下でログ取得しても、メモリリークか解析可能ですか
メモリ使用率が 80%以下の場合、正常なアプリケーションのメモリ使用である場合 (例：コネクションが多い・利用機能や設定量が多い、など) や、キャッシュとしてメモリが一時的に保持されている影響の可能性があり、メモリリークにより枯渇が発生してるかの判別が難しいです。 また、各アプリケーションが利用するメモリ量は 1つ1つは非常に小さいため、メモリ使用率が 100%に近い場合を除き、十分 空きメモリがある状態では、システム動作には影響を与えません。一旦は ご様子見をお願いします。
参考情報
ASA 8.4以降: SNMP ポーリングを用いたメモリ監視について
https://supportforums.cisco.com/ja/document/12536561
ASA Firewall メモリーリーク時に必要な情報
- ASA 8.4(6)未満 or 9.1(3)未満向けのメモリ問題の調査方法
https://supportforums.cisco.com/ja/document/12485951
ファイアウォール トラブルシューティング
https://supportforums.cisco.com/ja/document/12725841
Firepower System and FTDトラブルシューティング
https://community.cisco.com/t5/-/-/ta-p/3161733
