1

非常に大きなテキスト ファイルのセットがあります。タスクは、この巨大なコーパス内のすべての用語について (一意に) ドキュメント頻度 (特定の用語を含むドキュメントの数) を計算することでした。単純に最初のファイルから始めて、すべてをシリアル化された方法で計算するのはばかげているように思えました (私はそれがどれほど悲惨なものであるかを確認するためにやっただけだと認めます)。この計算を Map-Reduce 方式で行うと、つまりデータをより小さな断片にクラスタリングし、最終的に結果を集計すると、結果がはるかに速く得られることに気付きました。

私の PC には 4 つのコアがあるため、データを 3 つの異なるサブセットに分割し、各サブセットを個別のスレッドに供給して、すべてのスレッドが作業を終了するのを待ち、その結果を別のメソッドに渡してすべてを集計することにしました。

非常に小さなデータセットでテストしましたが、問題なく動作しました。実際のデータを使用する前に、その動作をよりよく調査できるように、より大きなセットでテストしました。jvisualvm と htop を起動して、CPU とメモリがどのように機能しているかを確認しました。3 つのスレッドが実行されており、CPU コアもビジーであることがわかります。ただし、これらのコアの使用率が 50% を超えることはめったにありません。これは、アプリケーションが実際には PC の能力をフルに活用していないことを意味します。これは私のコードに関連していますか、それとも本来あるべき姿ですか。私の期待は、各スレッドができるだけ多くの CPU コア リソースを使用することでした。

Ubuntuを使用しています。

4

4 に答える 4

3

IO バウンドのアプリケーションがあるように思えます。ディスクからデータを読み取る個々のスレッドでより多くの時間を費やしており、読み取った情報を実際に処理しています。

これをテストするには、プログラムを SSD を搭載した別のシステムに移行して、CPU のパフォーマンスが変化するかどうかを確認します。また、すべてのファイルを読み込んで後で処理し、処理時間中に CPU 曲線が変化するかどうかを確認することもできます。そうなると思います。

于 2013-01-18T14:58:29.253 に答える
2

すでに述べたように、おそらくディスク IO によってボトルネックが発生しています。ディスクから読み取るコードをデータを処理するコードから分離し、それぞれに別のスレッド プールを使用してみてください。その後、リソースに適切に適合するようにスレッド プールを迅速にスケーリングする良い方法は、Executorsスレッド プールの 1 つを使用することです。

于 2013-01-18T15:03:31.447 に答える
1

CPUバウンドではなく、単一のマシンでこのような問題にIOバウンドです。ファイルを積極的に読んでいますか？すべてのファイルがメモリ内にある場合にのみ、CPU が飽和し始めます。これが map-reduce が有効な理由です。CPU よりも合計 IO スループットをスケーリングします。

于 2013-01-18T14:58:41.937 に答える
0

Linuxを使用していて、データをディスクではなくメモリに格納するためにtmpfsを使用している場合は、これをかなり高速化できる可能性があります。

于 2013-01-18T15:12:41.440 に答える