“java.lang.OutOfMemoryError: kan geen nieuwe native thread maken”

We krijgen "java.lang.OutOfMemoryError : unable to create new native Thread” op 8 GB RAM VM na 32k threads (ps -eLF| grep -c java)

Echter, "top" and "free -m" shows 50% free memory available. JDk is 64 bit en geprobeerd met zowel HotSpot als JRockit.Server heeft Linux 2.6.18

We hebben ook geprobeerd OS stack size (ulimit -s)aan te passen en max process(ulimit -u) limieten, limit.conf te verhogen, maar alles tevergeefs.

Ook hebben we bijna alle mogelijke combinaties van hoopgrootte geprobeerd, laag, hoog enz. gehouden.

Het script dat we gebruiken om de applicatie uit te voeren is

/opt/jrockit-jdk1.6/bin/java -Xms512m -Xmx512m -Xss128k -jar JavaNatSimulator.jar /opt/tools/jnatclients/natSimulator.properties

Bedankt voor het antwoord.

We hebben geprobeerd /etc/security/limits.conf en ulimit te bewerken, maar nog steeds hetzelfde

[root@jboss02 ~]# 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) 72192
max locked memory       (kbytes, -l) 32
max memory size         (kbytes, -m) unlimited
open files                      (-n) 65535
pipe size            (512 bytes, -p) 8
POSIX message queues     (bytes, -q) 819200
real-time priority              (-r) 0
stack size              (kbytes, -s) 10240
cpu time               (seconds, -t) unlimited
max user processes              (-u) 72192
virtual memory          (kbytes, -v) unlimited
file locks                      (-x) unlimited

Antwoord 1, autoriteit 100%

Dit is geen geheugenprobleem, ook al suggereert de uitzonderingsnaam, maar een probleem met een besturingssysteem. Je hebt bijna geen native threads, d.w.z. hoeveel discussies het besturingssysteem zal je JVM gebruiken om te gebruiken.

Dit is een ongewoon probleem, omdat je die velen zelden nodig hebt. Heb je veel onvoorwaardelijke draadspawning waar de threads mogen, maar niet afmaken?

U kunt overwegen om te herschrijven in het gebruik van callable / runnables onder controle van een uitvoerder indien mogelijk. Er zijn veel standaardleiders met verschillende gedrag die uw code gemakkelijk kan besturen.

(er zijn veel redenen waarom het aantal threads beperkt is, maar ze variëren van besturingssysteem naar besturingssysteem)

Antwoord 2, Autoriteit 16%

Ik heb tijdens de laadtest hetzelfde probleem tegengekomen, de reden is vanwege JVM kan niet verder een nieuwe Java-draad verder maken. Hieronder staat de JVM-broncode

if (native_thread->osthread() == NULL) {    
// No one should hold a reference to the 'native_thread'.    
    delete native_thread;   
if (JvmtiExport::should_post_resource_exhausted()) {      
    JvmtiExport::post_resource_exhausted(        
        JVMTI_RESOURCE_EXHAUSTED_OOM_ERROR | 
        JVMTI_RESOURCE_EXHAUSTED_THREADS, 
        "unable to create new native thread");    
    } THROW_MSG(vmSymbols::java_lang_OutOfMemoryError(), "unable to create new native thread");  
} Thread::start(native_thread);`

Worteloorzaak: JVM gooit deze uitzondering wanneer
JVMTI_RESOURCE_EXHAUSTED_OOM_Error (Bronnen uitgeput (betekent geheugen
uitgeput) of jvmti_resource_exhausted_threads (threads uitgeput).

In mijn zaak creëert JBoss te veel discussies, om het verzoek te dienen, maar alle threads zijn geblokkeerd. Hierdoor is JVM uitgeput met draden, maar ook met het geheugen (elke draad bevat het geheugen, dat niet wordt vrijgegeven, omdat elke draad is geblokkeerd).

Geanalyseerd De JAVA-draaddumps waargenomen dat bijna 61K-schroefdraad wordt geblokkeerd door een van onze methode, die dit probleem veroorzaakt. Hieronder staat het gedeelte van de draaddump

"SimpleAsyncTaskExecutor-16562" #38070 prio=5 os_prio=0 tid=0x00007f9985440000 nid=0x2ca6 waiting for monitor entry [0x00007f9d58c2d000]
   java.lang.Thread.State: BLOCKED (on object monitor)

Antwoord 3, Autoriteit 12%

Als JVM wordt gestart via SYSTEMD, kunnen er mogelijk een maxtasks per proceslimiet zijn (taken bedekken eigenlijk threads) in sommige Linux OS.

U kunt dit controleren door “Service Status” uit te voeren en te controleren of er een MAXTASSS-limiet is. Als er is, kunt u het verwijderen door /etc/systemD/system.conf, het toevoegen van een config: DefaultTaskSmax = Infinity

Antwoord 4, Autoriteit 9%

Het is waarschijnlijk dat uw besturingssysteem niet toestaat dat het aantal threads dat u probeert te creëren, of u raakt wat limiet in de JVM. Vooral als het zo’n ronde nummer is als 32k, is een limiet van een soort of een ander een zeer waarschijnlijke boosdoener.

Weet je zeker dat je echt 32K-discussies nodig hebt? De meeste moderne talen hebben een soort van ondersteuning voor pools van herbruikbare draden – ik weet zeker dat Java ook iets op zijn plaats heeft (zoals ExecutorService, als gebruiker Jesper genoemd). Misschien kunt u draden van een dergelijk zwembad aanvragen, in plaats van het handmatig nieuwe te maken.

Antwoord 5, Autoriteit 8%

Ik zou aanraden om ook naar de draadstapelgrootte te kijken en te zien of u meer threads krijgt die is gemaakt. De standaarddraadstapelgrootte voor JOOckit 1.5 / 1.6 is 1 MB voor 64-bit VM op Linux OS. 32K-threads vereisen een aanzienlijke hoeveelheid fysiek en virtueel geheugen om deze eis te eren.

Probeer de stapelgrootte naar 512 KB als startpunt te verkleinen en kijk of het helpt bij het maken van meer discussies voor uw aanvraag. Ik raad ook aan om horizontale schaal te verkennen, b.v. het splitsen van uw aanvraagverwerking over meer fysieke of virtuele machines.

Bij gebruik van een 64-bit VM is de werklimiet afhankelijk van de OS-fysieke en virtuele geheugenbeschikbaarheid en OS-afstemparameters zoals Ulimitc. Ik raad ook het volgende artikel aan als referentie:

Voor mij is het opgelost bij het vermelden van alle Java-processen met JPS (voer gewoon jpsin uw schaal uit) en vermoord ze afzonderlijk met behulp van de kill -9 pidBash-opdracht voor elk spookproces.

Dit kan in sommige scenario’s helpen.

Antwoord 7, Autoriteit 2%

Je hebt een kans om de java.lang.OutOfMemoryError: Unable to create new native threadwanneer de JVM om een nieuwe thread van het besturingssysteem vraagt. Wanneer het onderliggende besturingssysteem geen nieuwe native thread kan toewijzen, wordt deze OutOfMemoryError gegenereerd. De exacte limiet voor native threads is erg platformafhankelijk, dus het is aan te raden om die limieten te achterhalen door een test uit te voeren die lijkt op het onderstaande linkvoorbeeld. Maar over het algemeen doorloopt de situatie die java.lang.OutOfMemoryError: Unable to create new native threadveroorzaakt de volgende fasen:

1. Een nieuwe Java-thread wordt aangevraagd door een toepassing die wordt uitgevoerd in de
   JVM
2. JVM native code proxeert het verzoek om een nieuwe native te maken
   thread naar het besturingssysteem Het besturingssysteem probeert een nieuwe native thread te maken die
   vereist dat geheugen aan de thread wordt toegewezen
3. Het besturingssysteem zal weigeren
   native geheugentoewijzing ofwel omdat de 32-bits Java-procesgrootte
   zijn geheugenadresruimte heeft uitgeput – b.v. (2-4) GB procesgrootte
   limiet is bereikt – of het virtuele geheugen van het besturingssysteem is volledig
   uitgeput
4. De java.lang.OutOfMemoryError: Kan geen nieuwe native maken
   threadfout wordt gegenereerd.

Referentie: https://plumbr.eu/outofmemoryerror/unable- to-create-new-native-thread

Antwoord 8, autoriteit 2%

Om erachter te komen welke processen threads maken, probeer:

ps huH

Normaal gesproken stuur ik de uitvoer om naar een bestand en analyseer ik het bestand offline (het aantal threads voor elk proces is zoals verwacht of niet)

Antwoord 9, autoriteit 2%

Deze fout kan om de volgende twee redenen aan het licht komen:

• Er is geen ruimte in het geheugen voor nieuwe threads.

• Het aantal threads overschrijdt de limiet van het besturingssysteem.

Ik betwijfel of het aantal threads de limiet voor het Java-proces heeft overschreden

Dus de kans is groot dat het probleem te wijten is aan het geheugen
Een punt om te overwegen is

threads worden niet gemaakt binnen de JVM-heap. Ze worden buiten gemaakt
de JVM-hoop. Dus als er minder ruimte over is in het RAM, na de JVM
heap-toewijzing, de toepassing loopt tegen
“java.lang.OutOfMemoryError: kan geen nieuwe native thread maken”.

Mogelijke oplossing is om het heapgeheugen te verkleinen of de totale ramgrootte te vergroten

Antwoord 10

Als uw taak faalt vanwege OutOfMemmory op knooppunten, kunt u uw aantal max. kaarten en verloopstukken tweeken en de JVM kiest voor elk. mapred.child.java.opts (de standaard is 200Xmx) moet meestal worden verhoogd op basis van de specifieke hardware van uw dataknooppunten.

Deze link kan nuttig zijn… pls check

Antwoord 11

uw JBoss-configuratie heeft enkele problemen,
/opt/jrockit-jdk1.6/bin/java -Xms512m -Xmx512m
Xms en Xmx beperken je JBoss-geheugengebruik tot de geconfigureerde waarde, dus vanaf de 8 GB die je hebt, gebruikt de server slechts 512 M + wat extra voor zijn eigen doel, verhoog dat aantal, vergeet niet om wat vrij te laten voor het besturingssysteem en andere dingen daar draait en misschien krijg je het aan de gang ondanks de onsmakelijke code.
Het zou ook leuk zijn om de code te corrigeren, als je kunt.

Antwoord 12

Ik had hetzelfde probleem en het bleek een oneigenlijk gebruik van een Java API te zijn. Ik was een builder aan het initialiseren in een batchverwerkingsmethode die niet meer dan één keer mocht worden geïnitialiseerd.

Eigenlijk deed ik zoiets als:

for (batch in batches) {
    process_batch(batch)
}
def process_batch(batch) {
    var client = TransportClient.builder().build()
    client.processList(batch)
}

wanneer ik dit had moeten doen:

for (batch in batches) {
    var client = TransportClient.builder().build()
    process_batch(batch, client)
}
def process_batch(batch, client) {
    client.processList(batch)
}

Antwoord 13

Ik had hetzelfde probleem met een centOS/Red Hat-machine. U bereikt de limiet voor threads, voor de gebruiker, het proces of een algemene limiet

In mijn geval was er een limiet op het aantal threads dat een gebruiker kan hebben. Wat kan worden gecontroleerd met, de regel met de tekst max. gebruikersprocessen

ulimit -a

Je kunt zien hoeveel threads er actief zijn met dit commando

$ ps -elfT | wc -l

Om te zien hoeveel threads uw proces draait (u kunt uw proces-pid krijgen met top of ps aux):

$ ps -p <PROCESS_PID> -lfT | wc -l

Het bestand /proc/sys/kernel/threads-max biedt een systeembrede limiet voor het aantal threads. De rootgebruiker kan die waarde wijzigen

Om de limieten te wijzigen (in dit geval naar 4096 threads):

$ ulimit -u 4096

Je kunt hier meer informatie vinden over Red Hat/centOs http://www.mastertheboss.com/jboss-server/jboss-monitoring/how-to-solve-javalangoutofmemoryerror-unable-to-create-new-native- draad

Antwoord 14

Bent u uw java-app gestart met system.d? Dit is voor jou!

Ik struikelde onlangs over DefaultTasksMax[1] die om de een of andere reden beperkt was tot 60 op mijn machine – niet genoeg voor mijn nieuwe keycloak-installatie.

Keycloak crasht met java.lang.OutOfMemoryError : unable to create new native Threadzodra deze de limiet van ’60’ bereikt (ps -elfT | grep keycloak|wc -l).

Oplossing

1. Zoek uw system.d-instellingen op

systemctl show --property DefaultTasksMax

In mijn geval. Deze gedrukte 60

2. Geef een hogere waarde op

editor /etc/systemd/system.conf

Bewerken:

DefaultTasksMax=128

Je kunt ook een vergelijkbare waarde TaskMaxinstellen in je Unit-File. Zie [2].

3. Herladen, controleren, opnieuw opstarten

systemctl daemon-reload
systemctl show --property DefaultTasksMax
systemctl start keycloak

[1] https://www.freedesktop. org/software/systemd/man/systemd-system.conf.html

[2] https://www.freedesktop. org/software/systemd/man/systemd.resource-control.html

Antwoord 15

Allereerst zou ik niet zozeer het besturingssysteem/VM de schuld geven.. eerder de ontwikkelaar die de code heeft geschreven die zooo veel threadsmaakt.
Eigenlijk ergens in uw code (of van derden) worden veel threads gemaakt zonder controle.

Bekijk de stacktraces/code zorgvuldig en controleer het aantal threads dat wordt gemaakt. Normaal gesproken zou je app niet veel threads nodig hebben, als dat wel het geval is, is het een ander probleem.