メモリーリークのトラブルシューティング

この節では、メモリーリークのトラブルシューティング方法について説明します。

メモリーリークの考えられる原因

メモリーリークは、Directory Server 自体またはカスタムプラグインにメモリー割り当ての問題があるために発生します。これらの問題のトラブルシューティングは、特にカスタムプラグインの場合、非常に難しいことがあります。

メモリーリークに関するデータの収集

メモリーリークに関するデータを収集する前に、次の作業を行っておくことが重要です。

• すべてのカスタムプラグインを無効にする

• キャッシュ設定を非常に低い値に下げる

• 監査ログを有効にする

上記の作業を実行したら、メモリーリークについて検証するテストを実行します。テストの実行中に、次のようにして pmonitor ユーティリティーの出力を収集します。

pmonitor ユーティリティーはプロセスモニターです。

「汎用データの収集」の説明に従って、一般的な Directory Server データを収集します。このデータには、実行中の Directory Server のバージョン、テスト実行のログ (特に監査ログ)、および Directory Server 設定ファイルが含まれます。

データを収集したら、Sun サポートセンターに連絡して問題解決の支援を求めることができます。

libumem ライブラリを使用したメモリーリークの分析

Solaris システムでは、libumem ライブラリは、プロセスメモリーフットプリントに割り当てられるすべてのアドレスを追跡するメモリーエージェントライブラリです。これは非常に低速なため、通常、本稼働環境では使用されません。ただし、メモリーリークの原因を分析するのに役立ちます。libumem ライブラリの詳細については、次の場所にある技術記事を参照してください。"http://access1.sun.com/techarticles/libumem.html"

次のコマンドを使用して、Directory Server を再起動します。

# SUN_SUPPORT_SLAPD_NOSH=true LD_PRELOAD=libumem.so \
UMEM_DEBUG=contents,audit=40,guards UMEM_LOGGING=transaction ./start-slapd

これで、Directory Server の起動前に、SmartHeap を使用せずに libumem ライブラリが読み込まれます。

次に、gcore コマンドを複数回実行します。メモリー使用量が増え始める前に 1 回、増え始めたあとで 1 回実行するようにしてください。gcore コマンドにより、アドレスとポインタのリストが出力されます。出力結果を使って、libumem ライブラリを読み取ります。

# cd install-root/bin/slapd/server
gcore -o /tmp/directory-core process-id

最後に、mdb および splitrec ツールを使用して結果を分析します。splitrec ツールは、結果を比較してリークの完全なスタックを確認します。

# cd install-root/bin/slapd/server
echo "::umausers -e" | mdb ./ns-slapd path_gcore1 > res.1
eacho "::umausers -e" | mdb ./ns-slapd path_gcore2 > res.2
splitrec -1 res.1 res.2

splitrec ツールは、Sun サポートから入手できます。このツールは、割り当てスタックのリーク原因として特定されたスタックの概要を示します。Sun サポートでは、これらのスタックの内容を使って、SunSolve データベース内で既知のメモリーリークを特定します。splitrec ツールのデフォルト設定では、リークが 100 回を超えていることが確認されたスタックだけがリークとして報告されるため、出力が生成されないことがあります。splitrec -l オプションを使って、制限値を引き下げてください。