1

アプリケーションでディスクがいっぱいになるというエラーが発生し、何らかの理由でディスクがいっぱいになった結果、未処理の例外がスローされ、set_terminate()ハンドラーが呼び出されました。

通常、ログ ファイルに何らかのスタック トレースが記録されるので、何が問題なのかを確認できますが、この場合、ディスクがいっぱいだったため、スタック トレースが記録されず、プログラムが原因で終了したことは明らかではありません。ディスク容量の不足。

ディスクに最後に書き込まれたものから私ができることを読むと、ディスクにstd::clog移動するように設定されている（いっぱいになったもの）に書き込まれているようです。

operator<<write toを使用すると例外がスローされる可能性があるかどうか疑問に思ってclogいます。もしそうなら、どの例外がスローされた可能性がありますか?

さらに、将来この状態が再発した場合にアプリケーションを更新して、ディスクがいっぱいであり、ディスクがいっぱいであったことを知ることができるように、アプリケーションを更新して正確に何が問題だったのかをより適切に追跡できるようにする方法についてのアイデアに興味があります。アプリケーションの他の欠点ではありません。

ただし、重要な問題は障害の検出であり、それがなければ、緩和方法のアイデアは役に立ちません。

4

2 に答える 2

2

Linux では、[特別なディレクトリに?] ファイル名を使用して、自分がいた場所の痕跡を作成できます。ファイルは、通常は十分にある「i ノード スペース」のみを使用するためです。

別のオプションは、「緊急ログ ストア」として大きな (っぽい) ファイルを作成することです。ディスクがいっぱいの場合は、緊急ログ ストアを開き、そのファイルに書き込みます。数メガバイトにすると、最新のディスクでは誰も気付かないでしょうが、自分がいた場所のコンテキストをダンプするのに十分なスペースが得られます.

于 2013-01-14T00:52:38.990 に答える
2

コード自体で何が起こるかの詳細はわかりませんが、この種の例外をどのように処理するかという問題に対処したいと思います。

本質的に、より多くのロギングが役立つこの種の問題。ただし、ここでロギング メカニズムが問題であるかどうかを考慮する必要があります。ディスクに依存しない代替のログ/レポート システムが必要です。

冗長性のレイヤーを追加し続けることもできますが、私の意見では、例外的な状況で失敗するプライマリと、さらに多くの例外的な状況で失敗するバックアップを組み合わせれば、ほとんどのアプリで十分です。データの回復力が最重要事項である場合は、もちろん、リソースを監視し、アプリケーションの処理中に軽減 (オペレーターの警告を発行するか、フォールバック メカニズムとして選択したもの - バックアップ スプール スペースなど) を行います。

一般に、all ways up比較のコストはnearly always up、コストと開発時間の 80/20 ルールに従います。

于 2013-01-14T00:53:03.497 に答える