4

RHEL 6.3で実行されているプロセスがいくつかありますが、何らかの理由でそれらがスレッドスタックサイズを超えています。

たとえば、Javaプロセスには起動時の実行時に-Xss256kのスタックサイズが与えられ、C++プロセスには実際のコードでpthread_attr_setstacksize（）を使用して1MBのスレッドスタックサイズが与えられます。

ただし、何らかの理由で、これらのプロセスはこれらの制限に固執しておらず、その理由はわかりません。

たとえば、私が実行すると

pmap -x <pid>

C ++およびJavaプロセスの場合、それぞれに数百の「anon」スレッドが表示されます（これらの各プロセスによって作成された内部ワーカースレッドであることが確認されています）が、これらには、設定された制限ではなく、それぞれ64MBの割り当て値があります。その上：

00007fa4fc000000 168 40 40 rw--- [ anon ] 
00007fa4fc02a000 65368 0 0 ----- [ anon ] 
00007fa500000000 168 40 40 rw--- [ anon ] 
00007fa50002a000 65368 0 0 ----- [ anon ] 
00007fa504000000 168 40 40 rw--- [ anon ] 
00007fa50402a000 65368 0 0 ----- [ anon ] 
00007fa508000000 168 40 40 rw--- [ anon ] 
00007fa50802a000 65368 0 0 ----- [ anon ] 
00007fa50c000000 168 40 40 rw--- [ anon ] 
00007fa50c02a000 65368 0 0 ----- [ anon ] 
00007fa510000000 168 40 40 rw--- [ anon ] 
00007fa51002a000 65368 0 0 ----- [ anon ] 
00007fa514000000 168 40 40 rw--- [ anon ] 
00007fa51402a000 65368 0 0 ----- [ anon ] 
00007fa518000000 168 40 40 rw--- [ anon ] 
...

しかし、すべての64MBの「anon」スレッドを使用して上記のプロセスで以下を実行すると、

cat /proc/<pid>/limits | grep stack 

Max stack size 1048576 1048576 bytes

最大スレッドスタックサイズは1MBであるため、ここで何が起こっているのか少し混乱しています。また、これらのプログラムを呼び出すスクリプトは、「ulimit-s1024」も設定します。

これは、非常にハイエンドのマシン（48GB RAM、24 CPUコアなど）を使用している場合にのみ発生するように見えることに注意してください。この問題は、それほど強力ではないマシン（4GB RAM、2 CPUコアなど）では発生しません。

ここで何が起こっているのかを理解する助けをいただければ幸いです。

4

4 に答える 4

6

RHEL6 2.11は、可能な場合は各スレッドに独自のスレッドプールが割り当てられるようにスレッドモデルを変更したため、大規模なシステムでは最大64MBを取得する場合があります。64ビットでは、許可されるスレッドプールの最大数が多くなります。

これに対する修正は、追加することでした

export LD_PRELOAD=/path/to/libtcmalloc.so

プロセスを開始するスクリプト内（glibc2.11を使用するのではなく）

これに関するいくつかの詳細情報は、以下から入手できます。

Linux glibc> = 2.10（RHEL 6）mallocは、過剰な仮想メモリー使用量を示す場合があります https://www.ibm.com/developerworks/mydeveloperworks/blogs/kevgrig/entry/linux_glibc_2_10_rhel_6_malloc_may_show_excessive_virtual_memory_usage?lang=en

glibcのバグmallocは、マルチスレッドアプリケーションに過剰なメモリを使用します http://sourceware.org/bugzilla/show_bug.cgi?id=11261

Apache hadoopは、MALLOC_ARENA_MAX https://issues.apache.org/jira/browse/HADOOP-7154を設定することで、この問題を修正しました。

于 2012-11-05T13:39:36.910 に答える
0

で報告されるスタックサイズは、 setrlimit（2）/proc/1234/limitsで設定されます（おそらくログイン時にPAMサブシステムによって）。

実際のスタックセグメントがそれぞれ64Mbであるように見える理由については、私にはよくわかりません。おそらく、大きなサーバーは巨大なページを使用します（ただし、デスクトップは使用しません）。

たとえば、プログラムを呼び出すスクリプトでsetrlimit（おそらくulimitbashビルトインまたはlimitzshビルトインを使用して）呼び出すことができます。

于 2012-11-01T16:17:41.383 に答える
0

を使用してulimit -s <size_in_KB>、プロセスの最大スタックサイズを設定できます。を使用して現在の制限を確認することもできますulimit -s。

于 2012-11-01T16:25:28.810 に答える
0

@roryあなたの答えに反して、64mbブロックアドレスはヒープアドレスであるはずですが、今ではアドレスはスタックアドレスである00007fa50c02a000のようになっていますよね？

于 2014-02-27T04:26:09.640 に答える