Évaluation - OutOfMemoryError: impossible de créer un nouveau thread natif

Question

Bien qu'il s'agisse de messages d'erreur typiques signalés par divers utilisateurs de Stackoverflow, ma question concerne la façon d'évaluer si les solutions proposées résolvent le problème.

J'ai lu diverses discussions & articles liés à cette erreur et la plupart des solutions descendent vers ulimits Linux et je suppose que cela semble être le cas pour moi aussi.

Mes valeurs ulimit sont:

STACK 10240k, CORE 0k, NPROC 1024, NOFILE 4096; 

Je suppose que la question pourrait être avec NOPROC/NOFILE étant trop faible (avec seulement les valeurs par défaut). Cependant, je voulais savoir s'il y avait un moyen exact d'identifier la cause première, à savoir que le NOPROC a été dépassé, etc., et s'il existe un moyen d'évaluer exactement le nombre de processus/gestionnaires de fichiers actuellement utilisés; Ou y a-t-il d'autres questions sur lesquelles je devrais me concentrer et qui peuvent être évaluées statistiquement? FYI, lorsque ce problème s'est produit, heapdump n'a pas été activé et il n'y a pas de données de thread au point d'erreur

Appréciez vos contributions pour l'évaluation et la résolution de ce problème.

Voici le bref stacktrace:

Caused by: java.lang.OutOfMemoryError: unable to create new native thread 
    at java.lang.Thread.start0(Native Method) 
    at java.lang.Thread.start(Thread.java:714) 

Voici les valeurs du système:

OS:Red Hat Enterprise Linux Server release 6.3 (Santiago) 
uname:Linux 2.6.32-279.el6.x86_64 #1 SMP Wed Jun 13 18:24:36 EDT 2012 x86_64 
libc:glibc 2.12 NPTL 2.12 
rlimit: STACK 10240k, CORE 0k, NPROC 1024, NOFILE 4096, AS infinity 
load average:0.11 0.10 0.03 
CPU:total 32 (8 cores per cpu, 2 threads per core) family 6 model 45 stepping 7, cmov, cx8, fxsr, mmx, sse, sse2, sse3, ssse3, sse4.1, sse4.2, popcnt, avx, aes, ht, tsc, tscinvbit, tscinv 

/proc/meminfo: 
MemTotal:  74206252 kB 
MemFree:   2788244 kB 
Buffers:   1042212 kB 
Cached:   58454988 kB 
SwapCached:   2860 kB 
Active:   38242540 kB 
Inactive:  29129604 kB 

Voici les informations du rapport JVM Crash - hs_err_pidxxxxx.log:

# There is insufficient memory for the Java Runtime Environment to continue. 
# Cannot create GC thread. Out of system resources. 
... 
# Out of Memory Error (gcTaskThread.cpp:46), pid=20396, tid=140365307795200 

# JRE version: (7.0_80-b15) (build) 
# Java VM: Java HotSpot(TM) 64-Bit Server VM (24.80-b11 mixed mode linux-amd64 compressed oops) 
# Failed to write core dump. Core dumps have been disabled. To enable core dumping, try "ulimit -c unlimited" before starting Java again 

Current thread (0x00007fa95400a800): JavaThread "Unknown thread" [_thread_in_vm, id=20458, stack(0x00007fa9583f5000,0x00007fa9584f6000)] 
Stack: [0x00007fa9583f5000,0x00007fa9584f6000], sp=0x00007fa9584f4540, free space=1021k 

Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code) 
V [libjvm.so+0x9a320a] VMError::report_and_die()+0x2ea 
V [libjvm.so+0x498d3b] report_vm_out_of_memory(char const*, int, unsigned long, char const*)+0x9b 
V [libjvm.so+0x55943a] GCTaskThread::GCTaskThread(GCTaskManager*, unsigned int, unsigned int)+0x11a 
V [libjvm.so+0x5589b8] GCTaskManager::initialize()+0x2b8 
V [libjvm.so+0x843438] ParallelScavengeHeap::initialize()+0x6f8 
V [libjvm.so+0x97509a] Universe::initialize_heap()+0xca 
V [libjvm.so+0x976269] universe_init()+0x79 
V [libjvm.so+0x5b2f25] init_globals()+0x65 
V [libjvm.so+0x95db4d] Threads::create_vm(JavaVMInitArgs*, bool*)+0x1ed 
V [libjvm.so+0x63b2e4] JNI_CreateJavaVM+0x74 
C [libjli.so+0x2f8e] JavaMain+0x9e 
Java Threads: (=> current thread) 
Other Threads: 
=>0x00007fa95400a800 (exited) JavaThread "Unknown thread" [_thread_in_vm, id=20458, stack(0x00007fa9583f5000,0x00007fa9584f6000)] 
VM state:not at safepoint (not fully initialized) 
VM Mutex/Monitor currently owned by a thread: None 
GC Heap History (0 events): 
No events 
Deoptimization events (0 events): 
No events 
Internal exceptions (0 events): 
No events 
Events (0 events): 
No events 

Answer 1

I wanted to know if there is an exact way to identify the root cause say the NOPROC has been exceeded etc

La JVM, comme n'importe quel autre logiciel, doit finalement parler au noyau par l'intermédiaire de syscalls. Pour engendrer de nouveaux threads, il doit utiliser le syscall clone qui peut renvoyer divers codes d'erreur (documentés dans les pages man). Vous pouvez utiliser strace pour consigner les appels système et voir leurs codes d'erreur, ce qui peut fournir des informations plus fines que l'OOME.