Couchbase -Client scheitert ohne OutofMemoryError bei zu vielen wartenden Fäden ⇐ Java

[Anonymous]

Ich habe eine Java -Stapelanwendung, die mehrere Verarbeitungsschritte auf einem Couchbase -Bucket ausführt, das in einem einzelnen Knotencluster gehostet wird. Die Datenbank ist weder groß noch blitzschnell, nur etwa 500 MB Daten. Sie tun es parallel oder wiederholt, daher führt ein einzelner Batch -Lauf bei vielen Aufrufen von cluster.connect () .

Code: Select all

[16.081s][warning][os,thread] Failed to start thread "Unknown thread" - pthread_create failed (EAGAIN) for attributes: stacksize: 256k, guardsize: 4k, detached.
[16.082s][warning][os,thread] Failed to start the native thread for java.lang.Thread "boundedElastic-evictor-225"
13:11:59.543 [jberet-1] ERROR org.jberet - JBERET000007: Failed to run job createTickets, createTickets, org.jberet.job.model.Step@78739007
java.lang.OutOfMemoryError: unable to create native thread: possibly out of memory or process/resource limits reached
at java.base/java.lang.Thread.start0(Native Method) ~[?:?]
at java.base/java.lang.Thread.start(Unknown Source) [?:?]
at java.base/java.lang.System$2.start(Unknown Source) ~[?:?]
...

Hinzufügen der JVM -Option -xx:+HeapdumponoutofMemoryError löst keine Heap -Dumps aus. Das Erhöhen des Haufens half auch nicht, aber ich entdeckte mehr als 2000 Wartefäden, bevor der Fehler auftritt. Fast alle Threads beziehen sich auf die Couchbase -Verbindungen. Dies begrenzt meine Anwendung bei der Verarbeitung weiterer Daten. Es ist Couchbase). Ich habe die Admin -Schnittstelle überprüft, aber es gibt keinen Hinweis auf ein Problem. < /P>
Was kann die Hauptursache für dieses Verhalten sein? Was soll ich mir ansehen, um mehr herauszufinden? Durch Entfernen von nachverfolgenden Nummern aus Threadnamen finde ich diese Zählungen:

, während sie weiter untersucht. Aus dem Thread -Müllkippe kann ich sehen, dass viele Threads auf Couchbase -Schlösser warten. Hier ist ein Beispiel: < /p>

Code: Select all

"cb-txn-cleanup-230" daemon prio=5 Id=2311 WAITING on java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject@1472208d
"cb-comp-994" daemon prio=5 Id=2004 TIMED_WAITING on java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject@446e7065

Sieht so aus, als würde ich vor einem Kunden-Side-Deadlock stehen.