Data Loss Prevention (DLP) のFileReaderが過剰に再起動する。
検出サーバーのログに以下のようなメッセージが1つ、または複数表示される。
BoxMonitor log:
Restarted FileReader. FileReader process was restarted because it went down unexpectedly.
Process [FileReader] has not responded for 16 minute(s) 0 ms
Restarted FileReader. FileReader was restarted because it wasn't responding.
FileReader restarts excessively. Process FileReader has restarted x times during last xx minutes.
boxmonitor_operational log:
Process [FileReader] has not responded for 16 minute(s) 0 ms
Process FileReader was restarted
Process [FileReader] has not responded for 16 minute(s) 0
FileReader log:
Message chain #x didn't stop processing the message.
Failed to get data from the client within specified time., Exception thrown from : ServerShmChannelImpl.cpp(242) FileTypeIdentifierImpl.cpp 113
Content extraction for file [xxxxx.xxx] failed.
Recording Message processing failure due to ContentExtractionTimeoutException
Failed to process item: //<path to file xxxxx.xxx>. Content extraction timeout occurred.
FileReaderは通常、タイムアウトが発生すると再起動します。タイムアウトは以下のような問題によって発生します。
FileReaderが時々自動で再起動するのは正常な動作です。 しかし、お客様の環境でFileReaderの再起動が頻繁に発生する場合、原因を特定するためにできることがいくつかあります。
FileReader logを調査し、FileReaderのどのサブシステムが起動しなかったか特定してください。
設定を受信できなかったサブシステムを特定できたら、MonitorControllerログを見て対応するサブシステムが初期化に成功しているか確認します。
よくある失敗の原因の1つに、ディスク上のキーの有効化パスワードと、データベース上の管理者パスワードが同期されていないため、MonitorControllerで暗号キーが有効化できなくなったというものがあります。この場合、パスワードの問題を修復し、その後MonitorController(SymantecDLPDetectionServerController)サービスを再起動する必要があります。
以下の場所にあるMonitor Controllerのプロパティファイル (SymantecDLPDetectionServer.conf) を確認します。
Windows: <Drive>:\Program Files\Symantec\DataLossPrevention\DetectionServer\Services\SymantecDLPDetectionServer.conf
Linux: /opt/Symantec/DataLossPrevention/DetectionServer/Services/SymantecDLPDetectionServer.conf
Java ヒープサイズを確認します。
デフォルトの値 128 と 256 が設定されている場合、サーバー上の利用可能なRAMサイズに合わせて、ヒープのメモリ設定を増やしてください。
例:
# Initial Java Heap Size (in MB)
wrapper.java.initmemory = 1024
# Maximum Java Heap Size (in MB)
wrapper.java.maxmemory = 2048
FileReaderの再起動は、特定のポリシーによって発生します。1つの例として、特定のポリシーのregexが設定された閾値 (例: maximum component timeなど) を越えた場合が挙げられます。
各新しい例外は、短絡的な検出の能力を向上させますが、全体の実行 (検出) マトリックスのサイズ、(FileReaderの起動時にメモリにロードされるサイズ) を増加させます。
例外の設定数に明確な制限はありませんが、経験則から例外の行数を制限し、リスト(送信者/受信者) を活用し、複合規則を避けることが重要です。
ドキュメント「High memory or cpu usage of the DLP agent or services when using compound exceptions in policies」をご覧ください。
MessageChain.CacheSizeとMessageChain.NumChainsがサーバー上のCPUのコア数と一致しているか確認します。
設定の変更方法については、「サーバーの拡張設定」をご覧ください。
注意: コンテンツ抽出は様ざまな種類のファイル処理に問題がある場合がありますが、FileReaderの再起動の原因となることは殆どありません。
停止しかけの (問題のある) スレッドは、FileReaderのハートビートの報告を停止させ、最終的に再起動を引き起こすことがあります。
BoxMonitor.logに例外が記録されていないか確認してください。 ログファイルに記録された各例外は、深刻な問題 (Javaのクラッシュやその他の不具合など) の指標となり、FileReaderの再起動の原因となる場合が多くあります。
上記の解決策でFileReaderが再起動される問題が解決されない場合、追加のトラブルシューティングを行うためにBroadcom Support にお問い合わせください。
※ このドキュメントは、以下のドキュメントを元に作成されています。