Fedora 30(12GBのRAM)とUbuntu 16 Linuxマシン(16GBのRAM)の両方に10Kを超えるスレッドを割り当てようとしています。
私はこれらのエラーを約10kスレッドで受け取ります:
Fedoraマシンのいくつかの設定に従います:
$ uname -a
Linux lab21.xxxxx.ix 5.1.11-300.fc30.x86_64 #1 SMP Mon Jun 17 19:33:15 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux
$ ulimit -a
core file size (blocks, -c) unlimited
data seg size (kbytes, -d) unlimited
scheduling priority (-e) 0
file size (blocks, -f) unlimited
pending signals (-i) 47765
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) 47765
virtual memory (kbytes, -v) unlimited
file locks (-x) unlimited
$ cat /proc/sys/kernel/pid_max
32768
$ cat /proc/sys/kernel/threads-max
95530
**$ cat /proc/meminfo (before the stress test)**
MemTotal: 12257732 kB
MemFree: 11424808 kB
MemAvailable: 11772784 kB
Buffers: 74556 kB
Cached: 487680 kB
SwapCached: 0 kB
Active: 424696 kB
Inactive: 224036 kB
Active(anon): 87056 kB
Inactive(anon): 592 kB
Active(file): 337640 kB
Inactive(file): 223444 kB
Unevictable: 0 kB
Mlocked: 0 kB
SwapTotal: 6003828 kB
SwapFree: 6003828 kB
Dirty: 1576 kB
Writeback: 0 kB
AnonPages: 86496 kB
Mapped: 112124 kB
Shmem: 1152 kB
KReclaimable: 45044 kB
Slab: 100440 kB
SReclaimable: 45044 kB
SUnreclaim: 55396 kB
KernelStack: 3600 kB
PageTables: 3784 kB
NFS_Unstable: 0 kB
Bounce: 0 kB
WritebackTmp: 0 kB
CommitLimit: 12132692 kB
Committed_AS: 732436 kB
VmallocTotal: 34359738367 kB
VmallocUsed: 0 kB
VmallocChunk: 0 kB
Percpu: 7680 kB
HardwareCorrupted: 0 kB
AnonHugePages: 0 kB
ShmemHugePages: 0 kB
ShmemPmdMapped: 0 kB
CmaTotal: 0 kB
CmaFree: 0 kB
HugePages_Total: 0
HugePages_Free: 0
HugePages_Rsvd: 0
HugePages_Surp: 0
Hugepagesize: 2048 kB
Hugetlb: 0 kB
DirectMap4k: 121280 kB
DirectMap2M: 12427264 kB
**After the stress test**
MemTotal: 12257732 kB
MemFree: 11014248 kB
MemAvailable: 11363328 kB
Buffers: 75096 kB
Cached: 487988 kB
SwapCached: 0 kB
Active: 517840 kB
Inactive: 221644 kB
Active(anon): 176960 kB
Inactive(anon): 600 kB
Active(file): 340880 kB
Inactive(file): 221044 kB
Unevictable: 0 kB
Mlocked: 0 kB
SwapTotal: 6003828 kB
SwapFree: 6003828 kB
Dirty: 0 kB
Writeback: 0 kB
AnonPages: 176428 kB
Mapped: 112408 kB
Shmem: 1160 kB
KReclaimable: 45576 kB
Slab: 208928 kB
SReclaimable: 45576 kB
SUnreclaim: 163352 kB
KernelStack: 171744 kB
PageTables: 46040 kB
NFS_Unstable: 0 kB
Bounce: 0 kB
WritebackTmp: 0 kB
CommitLimit: 12132692 kB
Committed_AS: 86824336 kB
VmallocTotal: 34359738367 kB
VmallocUsed: 0 kB
VmallocChunk: 0 kB
Percpu: 7872 kB
HardwareCorrupted: 0 kB
AnonHugePages: 0 kB
ShmemHugePages: 0 kB
ShmemPmdMapped: 0 kB
CmaTotal: 0 kB
CmaFree: 0 kB
HugePages_Total: 0
HugePages_Free: 0
HugePages_Rsvd: 0
HugePages_Surp: 0
Hugepagesize: 2048 kB
Hugetlb: 0 kB
DirectMap4k: 123328 kB
DirectMap2M: 12425216 kB
Fedoreマシンより4GB多いメモリを搭載したUbuntuマシンでは、13K以下を割り当てることができます。この違いは、Ubuntuマシンのメモリが大きいことに関連している可能性があります。
ヒントはありますか?
問題はsystemd cgroupの制限...
「/sys/fs/cgroup/pids/user.slice/user-$UID.slice/pids.max」を確認したところ、10.813でした。 15000に上げられ、スレッドが割り当てられました。
したがって、Systemdはcgroupを使用してリソースとスレッドも制限します...
この投稿は真実への道でした!
特定のシステムのリソース制限を知ることは役立ちますが、それだけでは、非常に多くのネイティブスレッドを作成しようとしたときに、エラーの根本原因を特定するのに十分ではありません。 eさらに興味深いことに、pthread_create()
から返されるエラーは、リソース制限を超えたことを示しているだけです。それが教えてくれない貴重な情報は、どのリソースの制限を超えたかです。
[〜#〜] eagain [〜#〜]-別のスレッドを作成するためのリソースが不十分であるか、システムによって課せられたスレッド数の制限が発生しました。後者の場合は、次の2つの方法で発生する可能性があります。実際のユーザーIDのプロセス数を制限するRLIMIT_NPROCソフトリソース制限(setrlimit(2)を介して設定)に達した。または、スレッド数に関するカーネルのシステム全体の制限/ proc/sys/kernel/threads-maxに達しました。ソース: https://linux.die.net/man/3/pthread_create
残念ながら、これは、問題の原因となっているリソース制限を特定するための面倒な手動デバッグが必要になることを意味します。
補足:Java Thread
sは、LinuxではPOSIXスレッドであるオペレーティングシステムのネイティブスレッドで実装されます( pthreads)。 Cと同じ、したがって同様の症状。
あなたのために働くかもしれない、そしてあなたの時間をよりよく使うかもしれない別の方法は、軽量のスレッド(別名グリーンスレッド)を使うことです。 Linuxカーネルがスレッド間の切り替えを担当するネイティブスレッド(例:pthreads)のpremptiveスレッドモデルとは対照的に、軽量スレッドはcooperativeは、複数のスレッドの実行感を維持するために、軽量スレッドが一定の間隔でメインスレッドに譲らなければならないことを意味します。
表面的にはこれは劣ったモデルのように見えるかもしれませんが、軽量スレッドの大きな利点は、通常、使用可能なリソースへの影響を最小限に抑えて最大100Kのスレッドを実行できることです。明らかに、たとえば、これらの軽量スレッドのそれぞれでファイルを開くと、最初の場所に戻ることになりますが、軽量スレッドを掘り下げて、それが実行可能な解決策であるかどうかを確認することをお勧めします。