0

私は、大きなログ ファイルを読み取る必要がある場所に書きたい単純なツールの設計段階にあります。いくつかのコンテキストを提供するために、まずそれについて説明します。

読み取る必要があるログ ファイルは、常に次の 3 行の形式で構成されるログ エントリで構成されています。

statistics : <some data which is more of less of the same length about 100 chars>
request :  <some xml string which can be small (10KB) or big (25MB) and anything in between>
response :  <ditto>

ログ ファイルのサイズは約 100 ～ 600 MB になる可能性があり、これは多くのログ エントリを意味します。これで、これらのログ エントリは相互に関係を持つことができます。そのためには、ファイルを最後から最初まで読み始める必要があります。これらの関係は、統計行から推測できます。

統計行の情報を使用して、ユーザーがデータを検索し、フィルタリング操作を行うために使用できるデータグリッドを構築したいと考えています。ユーザーが実際に必要とするまで、要求/応答行をメモリにロードしたくありません。さらに、ロードされるリクエスト/レスポンス エントリの最大数を制限することで、メモリの負荷を小さく保ちたいと考えています。

そのため、ファイルを初めて解析して統計のインデックスを作成するときに、統計行のオフセットを保存する必要があると思います。次に、ユーザーがログエントリの要素である統計をクリックすると、このオフセットを使用してファイルから要求/応答を読み取ります。次に、ロードされた要求/応答エントリがあまりないように注意するメモリプールを保持できます (前述の req を参照)。

問題は、ユーザーが要求/応答データを必要とする頻度がわからないことです。それはたくさんかもしれませんし、数回かもしれません。さらに、ログ ファイルはネットワーク共有からロードできます。

私が持っている質問は次のとおりです。

  1. これは、多くの読み取り操作が発生する可能性があるため、メモリ マップド ファイルを使用する必要がある場合のシナリオですか? それとも、プレーンなファイルストリームを使用する方が良いですか. ところで。この段階ではログ ファイルへの書き込み操作は必要ありませんが、将来的には必要になる可能性があります。

これまでのところ、他のヒントや私の考えに欠陥がある場合は、私にも知らせてください. 私はどんなアプローチにもオープンです。

アップデート：

さらに明確にするために：

  • ユーザーがドライブまたはネットワーク共有からログ ファイルをロードするときに、ツール自体が解析を行う必要があります。

  • ツールは WinForms アプリケーションとして作成されます。

  • ユーザーは、選択したログ エントリをエクスポートできます。現時点では、このエクスポートの形式は不明です (バイナリ、ファイル データベース、テキストファイル)。このエクスポートは、ユーザーが行った選択のみを表示するアプリケーション自体によってインポートできます。

4

3 に答える 3

1

要求/応答チャンクをネットワーク経由で送信する場合、ネットワークのsend（）時間は、seek（）/ read（）とmemmapの使用の違いよりもはるかに長くなる可能性が高いため、問題にはなりません。このスケールを実際に作成するには、ファイルを多数のファイルに分割し、提供するチャンクごとに1つずつ実行するのが簡単な解決策です（「要求」は最大25 MBになる可能性があるため）。次に、HTTPサーバーはそのチャンクを可能な限り効率的に送信します（Webサーバーによってはゼロコピーを使用する場合もあります）。小さな「リクエスト」チャンクが多数あり、巨大なチャンクが少数しかない場合は、特定のしきい値を超えたチャンクのみを分割できます。

于 2012-08-04T00:08:47.357 に答える
0

私はワルサーからの答えに同意しません。私はdbまたはすべてのメモリに行きます。

600 MBはそれほど多くないので、なぜメモリの節約についてそれほど心配しているのですか。2 GB未満のメモリを搭載したマシンで実行しますか？

統計をキーとして、値を2つのプロパティ（要求と応答）を持つクラスを使用してディクショナリにロードします。辞書は速いです。LINQは強力で高速です。

于 2012-08-04T00:10:42.150 に答える