2

より多くのスレッドを許可するようにメモリ設定を最適に調整する方法について、いくつかの入力が必要です。

Java VM はいくつのスレッドをサポートできますか?のポーズを読みました。そこにあるJavaの例（dieLikeaDog）に従いましたが、動作し、死ぬ前に800未満のスレッドを生成しました。

上記の (dieLikeaDog の例) リンクのように、次のエラーが発生するまで、コードは可能なすべてのスレッドを作成します: java.lang.OutOfMemoryError: Cannot create new native thread

コマンド ラインで Xss を指定しても (例: java -Xss104k dieLikeADog)、作成されるスレッドの数は変わりません。

-Xms と -Xmx も変更してみましたが、生成できるスレッドの数はどちらも変更しませんでした。

スレッドの数を変更したことの 1 つは、私の -u ulimit (最大ユーザー プロセスの場合) です。これを大きくすると、スレッドの数が増えました。

私の制限は次のとおりです。

$ ulimit -a
core file size          (blocks, -c) 0
data seg size           (kbytes, -d) unlimited
scheduling priority             (-e) 0
file size               (blocks, -f) unlimited
pending signals                 (-i) 46588
max locked memory       (kbytes, -l) 64
max memory size         (kbytes, -m) unlimited
open files                      (-n) 1024
pipe size            (512 bytes, -p) 8
POSIX message queues     (bytes, -q) 819200
real-time priority              (-r) 0
stack size              (kbytes, -s) 8192
cpu time               (seconds, -t) unlimited
max user processes              (-u) 1024
virtual memory          (kbytes, -v) unlimited
file locks                      (-x) unlimited

他の例を読んで、 -Xss を小さく指定するとスレッド数が増えるはずだと思ったので、少し混乱しています。

Xss の動作を妨げているものは他にありますか?

念のため、私は 64 ビットの fedora 15 システム (6 ギガの RAM を搭載) で実行しています。

  OS:
    Linux
    2.6.42.12-1.fc15.x86_64
    amd64

  JVM:
    Sun Microsystems Inc.
    Java(TM) SE Runtime Environment
    Java HotSpot(TM) 64-Bit Server VM
    1.6.0_27
4

2 に答える 2

3

パラメータは、-Xss各スレッドのスタックに割り当てられるメモリ量を制御します。値の選択は、使用可能なメモリに対するスタックの深さのバランスを取る場合です。の値を設定する-Xss104kと、使用可能なメモリが 104KB になることを意味します( で設定-Xmx)開始された各スレッドのスタックに対して消費されます。1M のメモリにはヒープとクラス (permgen)、およびスレッド スタックが含まれるため、最初から開始すると-Xmx1024k、10 スレッドに到達する前にメモリが使い果たされます。

私のアプローチは、最初にスレッドで実行するコードを調べることです。再帰的な重いコードには、より多くのスタックが必要です。大量のデータセットを反復処理するだけのコードは、スタックがほとんど必要ない可能性があります。

関連する力のバランスを取るための経験的な方法は、 が-Xss得られるまで減少させることですStackOverflowError。これは、スレッドがスタックを使い果たしていることを意味します。機能した最後の値にパディングを追加します。a を引き起こさなかった最後の値StackOverflowErrorが「-Xss1k , the try-Xss2k or-Xss3k . If the stack is wiping out at something like10k 15k」だったI'd try just bumping to場合。

これで、スレッド スタックのサイズが決まりました。合計メモリ ( -Xmx) から permgen を差し引き、必要なヒープの量を差し引いたものが、スレッド用に残っているものになります。ヒープに 1000K、permgen に 50K が必要で、スタック サイズが 2K であると計算した場合、10 個のスレッドを実行する-Xmx1070Kと、最小メモリと見なされます。

そうは言っても、あなたが達成しようとしていることを見てください。なぜもっと多くのスレッドが必要なのですか? おそらく答えはスレッドを増やすことではなく、より少ないスレッドを使用しながらデータをより高速に処理できる別のアルゴリズムです。

アップデート

元の回答のうち、間違っているとわかった部分を取り消しました。

スタック領域はヒープ領域から取得されず、個別に割り当てられます。スレッド スタックとヒープの両方が、プロセスの仮想メモリに対してカウントされます。ヒープを減らすとより多くのスレッドが可能になり、増やすとより少ないスレッドが可能になります。

32 ビット JVM では、スタック サイズを 1K に減らすことができました。64 ビット JVM では、104K が最小です。

4G RAM と 2 コアを搭載した 64 ビット Windows 7 ボックスでいくつかのテストを行いました。

32 ビットの JVM を使用する-Xss8kと-Xmx128m、プログラムによって最大 5000 のスレッドが得られます。それが最良のケースのようです。その時点を超えてスレッド数を増やすオプションの組み合わせは見つかりませんでした。ヒープ サイズを大きくすると、最大スレッド数が減少しました。8k 未満のスタックを選択すると最大スレッド数が実際に悪化するため、スレッド スタック サイズはシステム ページ サイズに関連しているように見えます。

Ubuntu Quantal の 32 ビット JVM にも、最大 5000 のスレッド制限が適用されるようです。

64 ビット JVM では、話はまったく異なります。で-Xss104k、-Xmx128mプログラムは 50000 スレッドを超えました。その時点で、Windows は本当に不幸になりました。数分間応答を停止し、その後、他のプロセスを強制終了し始めました。より多くのメモリを解放しようとしていると推測しています。

アップデート：

Ubuntu での追加テスト: 仮想メモリに ulimit が設定されていることを発見しました。ulimit -v unlimitedプログラムが最大36000スレッドを超えた後。

于 2012-11-28T05:34:03.220 に答える