+ ANスイッチを使用して非同期スレッドプールのサイズを増やすことが理にかなっている場合を理解しようとして、ドキュメントを読んでいます。
私は完全にベンチマークの準備ができていますが、プールサイズを0からN（またはNからN + M）に増やすことが役立つと思われる場合の経験則があるかどうか疑問に思いました。
ありがとう
質問する
3998 次
2 に答える
25
BEAMは、スケジューラーと呼ばれる特別なスレッドでErlangコードを実行します。デフォルトでは、プロセッサのすべてのコアに対してスケジューラが起動します。たとえば、すべてのコアでErlangを実行したくないが、他の目的のために一部を「予約」したい場合は、これを制御して起動時間を設定できます。通常、ファイルI / O操作を実行すると、スケジューラーで実行されます。ファイルI / O操作は比較的遅いため、実行中にそのスケジューラーをブロックします。これは、リアルタイムのプロパティに影響を与える可能性があります。通常、ファイルI / Oはそれほど多くないので、問題はありません。
非同期スレッドプールは、I/O操作に使用されるOSスレッドです。通常、プールは空ですが、+A起動時にを使用すると、BEAMはこのプール用に追加のスレッドを作成します。これらのスレッドは、ファイルI / O操作にのみ使用されます。つまり、スケジューラスレッドは、ファイルI / Oの待機をブロックしなくなり、リアルタイムプロパティが改善されます。もちろん、OSスレッドは無料ではないため、これにはコストがかかります。スレッドは混在しないため、スケジューラスレッドは単なるスケジューラスレッドであり、非同期スレッドは単なる非同期スレッドです。
ポート用のリンクインドライバーを作成している場合、これらは非同期スレッドプールも使用できます。しかし、それらがいつ開始されたかを自分で検出する必要があります。
必要な数は、アプリケーションによって異なります。デフォルトでは、何も開始されません。@demeshchukのように、Riakは多くのファイルを開くため、大きな非同期スレッドプールを使用するのが好きだと聞いています。私の唯一のアドバイスは、それを試して測定することです。すべての最適化と同じように？
于 2012-11-21T16:30:22.977 に答える
4
デフォルトでは、実行中のErlang VMのスレッド数は、プロセッサー論理コアの数と同じです（もちろん、SMPを使用している場合）。
私の経験から、+ Aパラメーターを増やすと、ファイルI/O操作を同時に行う場合にパフォーマンスが向上する可能性があります。また、BEAMのスケジューラーは非常に高速で最適化されているため、+Aを増やすとプロセス全体のパフォーマンスが向上する可能性があるとは思えません。
正確な数について言えば、それは完全にアプリケーションに依存すると思います。たとえば、開かれるファイルの最大数が多かれ少なかれ予測可能であるRiakの場合、+ Aをこの最大値に設定するか、大きすぎる場合は数分の1に設定できます（デフォルトでは64、BTW）。アプリケーションに数百万のファイルが含まれていて、それらをWebクライアントに提供する場合、それは別の話です。ほとんどの場合、独自のコードと独自の環境でいくつかのベンチマークを実行することをお勧めします。
最後に、私は+Aを100以上見たことがないと思います。設定できないという意味ではありませんが、意味がない可能性があります。
于 2012-11-21T08:50:29.263 に答える