unable to create new native Thread or Resource temporarily unavailable after 10K threads

Question

I'm trying to allocate more than 10K threads on both a Fedora 30 (12GB of RAM) and Ubuntu 16 Linux machines (16GB of RAM).

I get these errors around 10k threads:

• Java: unable to create new native Thread
• C: Resource temporarily unavailable

Follows some settings of the Fedora machine:

$ 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

On the Ubuntu machine with 4 GB of memory more than the Fedore machine, I can allocate no more than 13K. This difference could be related to the bigger memory for the Ubuntu machine.

Any hint?

Answer 1

The problem was the systemd cgroup limits...

I checked the "/sys/fs/cgroup/pids/user.slice/user-$UID.slice/pids.max" and it was 10.813. Raised to 15000 and the threads was allocated.

So Systemd uses cgroup to limits resources and threads too...

this post was the path for the truth!

https://askubuntu.com/questions/845380/bash-fork-retry-resource-temporarily-unavailable/883677#883677

Answer 2

While it's helpful to know what the resource limits are on a given system, that alone is not enough to determine the root cause of the error when attempting to create so many native threads. e To make matters more... interesting, the error you get back from pthread_create() only tells you that you've exceeded the resource limits. The valuable piece of information it does not tell you is which resource(s) limits were exceeded:

EAGAIN - Insufficient resources to create another thread, or a system-imposed limit on the number of threads was encountered. The latter case may occur in two ways: the RLIMIT_NPROC soft resource limit (set via setrlimit(2)), which limits the number of process for a real user ID, was reached; or the kernel's system-wide limit on the number of threads, /proc/sys/kernel/threads-max, was reached. source: https://linux.die.net/man/3/pthread_create

Unfortunately, this means you're left with tedious manual debugging to pin-point which resource limits are causing your problem.

Side note: Java Threads are implemented with Operating System native threads, which on Linux is POSIX threads (pthreads). The same with C, hence the similar symptoms.

An alternative

An alternative which may work for you, and may be a better use of your time, is to use light-weight threads (aka. green threads). In contrast to the premptive threading model of native threads (eg. pthreads), in which the Linux kernel is responsible for switching between threads, light-weight threads are cooperative, meaning the light-weight threads have to yield to the main thread at regular intervals to maintain the feeling of multiple threads of execution.

While on the surface this may appear to be an inferior model, a big benefit to light-weight threads is that usually you can have ~100K threads running with minimal impact on your available resources. Obviously, if you, say, open a file in each of those light-weight threads, you'll end up back where you started, but I recommend digging into light-weight threads to see if it's a viable solution for you.