Java de la Mémoire d'erreur: impossible de créer un thread natif

J'ai cette erreur sur mon serveur UNIX, lors de l'exécution de mon serveur java:

Exception in thread "Thread-0" java.lang.OutOfMemoryError: unable to create new native thread
at java.lang.Thread.start0(Native Method)
at java.lang.Thread.start(Thread.java:640)
at [... where ever I launch a new Thread ...]

Il arrive à chaque fois que j'ai environ 600 threads en cours d'exécution.

J'ai mis en place cette variable sur le serveur:

$> ulimit -s 128

Ce qui semble étrange pour moi, c'est le résultat de cette commande, j'ai couru quand le bug a eu lieu la dernière fois:

$> free -m
              total       used       free     shared    buffers     cached
Mem:          2048        338       1709          0          0          0
-/+ buffers/cache:        338       1709
Swap:            0          0          0

Je lance mon serveur java comme ceci:

$> /usr/bin/java -server -Xss128k -Xmx500m -jar /path/to/myJar.jar

Ma version de debian:

$> cat /etc/debian_version
5.0.8

Ma version de java:

$> java -version
java version "1.6.0_26"
Java(TM) SE Runtime Environment (build 1.6.0_26-b03)
Java HotSpot(TM) 64-Bit Server VM (build 20.1-b02, mixed mode)

Ma question: j'ai lu sur Internet que mon programme doit gérer quelque chose comme 5000 threads ou plus. Donc ce qui se passe, et comment les corriger s'il vous plaît ?

Edit: c'est la sortie de ulimit -a quand j'ouvre un shell:

core file size          (blocks, -c) unlimited
data seg size           (kbytes, -d) unlimited
scheduling priority             (-e) 0
file size               (blocks, -f) unlimited
pending signals                 (-i) 794624
max locked memory       (kbytes, -l) 32
max memory size         (kbytes, -m) unlimited
open files                      (-n) 100000
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) 794624
virtual memory          (kbytes, -v) unlimited
file locks                      (-x) unlimited

Je lance le script en tant que démon de init.d, et c'est ce que je run:

DAEMON=/usr/bin/java
DAEMON_ARGS="-server -Xss128k -Xmx1024m -jar /path/to/myJar.jar"
ulimit -s 128 && ulimit -n 10240 && start-stop-daemon -b --start --quiet --chuid $USER -m -p $PIDFILE --exec $DAEMON -- $DAEMON_ARGS \
    || return 2

Edit2: je suis venu dans ce débordement de pile question avec un java de test pour les threads: comment plusieurs threads peut-java-vm-support

    public class DieLikeADog { 
        private static Object s = new Object(); 
        private static int count = 0; 
        public static void main(String[] argv){ 
            for(;;){ 
                new Thread(new Runnable(){ 
                        public void run(){ 
                            synchronized(s){ 
                                count += 1; 
                                System.err.println("New thread #"+count); 
                            } 
                            for(;;){ 
                                try { 
                                    Thread.sleep(100); 
                                } catch (Exception e){ 
                                    System.err.println(e); 
                                } 
                            } 
                        } 
                    }).start(); 
            } 
        } 
    }

Sur mon serveur, le programme se bloque après 613 threads. Maintenant, je suis certain que ce n'est pas normal, et uniquement lié à ma configuration de serveur. Quelqu'un peut-il aider s'il vous plaît ?

Edit 3:
Je suis tombé sur cet article, et beaucoup d'autres, expliquant que linux ne peut pas créer de 1000 threads, mais les gars, vous me dites que vous pouvez le faire sur votre système. Je ne comprends pas.

J'ai aussi couru à ce script sur mon serveur: threads_limits.c et la limite est de l'ordre de 620 fils.

Mon site est maintenant en mode hors connexion et c'est la pire chose qui puisse arriver à mon projet.
Je ne sais pas comment recompiler glibc et ce genre de choses. C'est trop de travail de l'omi.

Je suppose que je devrais passer à windows server. Car aucun des paramètres proposés sur cette page ne faire aucun changement: La limite de mon système est entre 600 et 620 fils, peu importe le programme.

C'est un serveur de jeu. J'ai ouvert 2 threads pour chaque client: 1 pour le protocole TCP-lire, et 1 pour le protocole TCP-écrire. Le serveur se bloque quand j'arrive à 300 clients, mais j'ai des tonnes de mémoire, alors pourquoi ?
Roach: Pourquoi pas? Véritable matériel de serveur peuvent le taux de désabonnement avec d'assez grandes quantités de threads sans trop de problèmes, si les paramètres sont corrects.
Et quelles en seraient les paramètres corrects être, s'il vous plaît ?
Parce que le changement de contexte et les frais généraux de le faire est horrible et pas nécessaire?
Roach: nous sommes en cours d'exécution autour de 2000 à 4000 threads, la plupart d'entre elles sont actives, et la charge de serveur est d'environ 2% à 5% (sur un 4-core Xeon). Bien sûr, cela est spécifique à notre serveur et le logiciel de configuration.
Aucune raison pourquoi vous êtes plafonnement de la -Xmx à une simple 500M pour une haute performance du serveur d'application et que trop sur une version 64 bits de la VM?
La raison en est qu'il ne semble pas changer quoi que ce soit puisque je ne suis pas d'atteindre cette limite.
Droit, mon point est, avez-vous essayé avec différentes valeurs de Xmx comme 4GiB? Le nombre de threads dans ce cas tombe? Aussi, vous pouvez poster à la sortie de ulimit -a?
Je ne peux pas poster la sortie puisqu'il est situé dans un daemon script init.d, mais j'ai soulevé à chaque valeur de la limite, sauf les fils de la pile de la taille abaissée à 128, et c'est toujours de s'écraser à 600 fils.
oui, j'ai essayé de chaque valeur possible pour xmx mais ça ne change quoi que ce soit depuis l'application serveur qui consomme moins de mémoire que 200 mo de même pour 300 clients
Il y avait des tests qui ont montré de meilleures performances avec Java IO comparativement à NIO - et contrairement à la sagesse générale ("nio beaucoup plus rapide que io") que mec effectivement fourni des repères pour ses revendications. Il est donc de loin pas que claire. La page est en bas de l'atm, mais il y a un google docs version:
cont. plutôt long lien
Vous avez raison, cela ne semble pas Java spécifique, mais plus d'un problème de config. Pour essayer quelques petites choses: vous pouvez exécuter le même code sans impliquer init.d? c'est à dire une plaine simple ulimit -s 128; ulimit -n 10240; java -server -Xss128k -Xmx1G -jar /path/to/myJar.jar à la bash shell? Parce qu'il semble que votre ulimit changements ne sont pas pris en charge par votre java processus de...
Ce pourrait être votre coupable: "la taille de la pile (kbytes, -s) 10240" (à Partir de votre ulimit -a output). C'est 10megabytes de la pile par thread. Essayez de modifier votre " /etc/security/limits.conf' et de définir la taille de la pile et d'autres paramètres. Je ne pense pas que ulimit-changements sont ramassés dans la même session (mais pas sûr), mais la modification de /etc/security/limits.conf doit être permanente (nécessite au moins démarrer une nouvelle session, qui charge la modification des limites.conf, ou dans le pire des cas, un redémarrage à chaque fois que le fichier est modifié, ne me souviens plus qui). Faire une sauvegarde de la configuration d'origine avant de le modifier
ulimit changements sont repris dans le même bash session. Le problème est peut-être la manière dont le démon est ramasser ces limites
Ce noyau que vous utilisez? Toute sortie de dmesg ?
J'ai essayé d'exécuter la commande dans un bash session et avait le même problème
J'ai déjà essayé avec cette limite.fichier conf et toujours le même limite exacte de 600 fils
J'utilise Debian 5.0.8 et la commande dmesg sorties de rien.
1) Avez-vous d'exécuter le programme dans edit2 directement à partir de la promt où vous avez tapé ulimit-a ? J'ai copié votre établissement et je n'ai aucun problème. 2) Quelle est la commande uname-a-dire?
Oui j'ai exécuté la edit2 directement à partir de l'invite de commandes. uname -a retourne Linux de801.ispfr.net 2.6.18-028stab085.5 #1 SMP Thu Apr 14 15:06:33 MSD 2011 x86_64 GNU/Linux
Voir mon post, vérifiez que vous avez NTPL et pas le vieux et obsolète "Linux Threads" qui pourrait gérer à 1500 threads ou plus.
laissez-nous continuer cette discussion dans le chat
Merci pour votre aide. Je suis sur le chat.

InformationsquelleAutor Joel | 2011-11-20

12

Viens de recevoir les informations suivantes: C'est une limitation imposée par mon hébergeur. Cela n'a rien à voir avec de la programmation, ou linux.
- Il sera intéressant de savoir comment il a imposé cette limite !
- Voici la réponse: Nuxit.com hébergeur vend des virtuals serveur sous la dénomination de "serveur Dédié". Ils virtualiser les faux serveurs à l'aide d'un logiciel appelé "Parallels® Virtuozzo Containers". Ils peuvent contrôler la façon dont le processus d'exécution et d'imposer des limites sur les threads, de la mémoire, et ainsi de suite. Il m'a fallu une semaine pour savoir mais j'ai changé d'hôte, et maintenant mon programme fonctionne finalement très bien.
- Merci pour le retour. L'apprécier !
- Je ne suis pas en mesure de créer plus de 375 threads par processus sur Amazon EC2 de la machine. Est-ce la limite imposée par Amazon? forums.aws.amazon.com/thread.jspa?threadID=86751
- Je suis sûr que cette limite est imposée par Amazon. Si vous avez besoin de plus de threads, location d'un vrai serveur dédié et non pas un serveur privé virtuel ou d'un nuage. Vous pouvez également essayer de contacter leur support et leur demander pour plus de threads machines à sous. Bonne chance.
- Merci Joel pour vous réponse, je suis d'accord que parfois le service d'hébergement peut désactiver le nombre maximum de threads par processus, mais c'est faux de dire que Linux n'est pas à mettre en œuvre par le processus de limite de thread. Vérifier ma réponse pour plus de détails.
- Merci pour cette astuce, c'était dans mon cas! Je checken avec cat /proc/user_beancounters la numprocess valeur qui a été 768 - trop faible pour moi..
InformationsquelleAutor Joel
7

Le système d'exploitation (Debian Linux dans ce cas) ne permet pas la création de plus de threads. Voir ici comment faire pour augmenter le montant maximum: Nombre Maximum de threads par processus dans Linux?

J'ai lu sur Internet que mon programme doit gérer quelque chose comme
5000 threads ou plus.

Cela dépend des limites fixées à l'OS, le montant des processus en cours d'exécution, etc. Avec des paramètres appropriés, vous pouvez atteindre aisément que le nombre de threads. Je suis sur Ubuntu sur mon ordinateur, et je peux créer autour de 32000 threads avant de frapper à la limite sur un seul programme Java avec tous mes "normal trucs" en cours d'exécution sur le fond (ce qui a été fait avec un programme de test qui venez de créer fils qui est allé dormir immédiatement dans une boucle infinie). Naturellement, cette quantité de fils en train de faire quelque chose aurait probablement brûler la consommation de matériel à un arrêt assez rapide.
- c'est le nombre de threads-max sur mon système: 1589248 ; et c'est le nombre maximum de processus disponibles pour un seul utilisateur: 794624 ; donc je ne vois pas de correspondance limitation ici
- Peut-être vous êtes vraiment à court de mémoire. Je n'ai vu que le "java.lang.OutOfMemoryError: impossible de créer un thread natif" -exception lorsque nous avons atteint la limite sur un système de production à environ 20000 threads.
- oui c'est possible, mais avez-vous vu la sortie de free -m ? N'est-ce pas dire que j'ai 75% de mémoire libre ?
- Vous pouvez commencer avec ces: le tas de la taille de la JVM comme par @Sid Malani post (Essayez -Xmx1024M par exemple et aller à partir de là). La quantité de mémoire libre dans le système peut être rien, mais la JVM ne obtenez ce que vous donnez à elle. Vérifiez également que vous ulimits (ulimit-a), n'oubliez pas que à peu près tout dans Linux/Unix est un fichier, donc également vérifier le nombre de fichiers ouverts sont autorisés par l'utilisateur. ulimit-changements ne deviennent pas "actif" d'emblée, la session doit être redémarré (démarrage d'une nouvelle console de session devrait être suffisant, l'utilisation de ulimit -a pour vérifier que les modifications ont réellement pris).
- J'ai vérifié ulimit-a et la seule limite restante (les descripteurs de fichier) pour 100 000, et j'ai la même exception quand j'arrive à 600 fils. tout autre réglage possible ?
- Rien de ce que je peux penser en ce moment. @Adam Zalcmans point sur la suppression de la pile de la taille et de tas de taille pour laisser plus de mémoire pour les piles sonnait un bon candidat, mais si la limite semble être la même 600 threads indépendamment de ces paramètres, il doit être quelque chose de non-liés à la mémoire.
- Quel est votre système d'exploitation et version s'il vous plaît ? Je veux dire celui où vous pouvez exécuter 2000 threads.
- - Je exécuter Ubuntu 10.10 sur mon homebox, j'ai le "OOM: impossible de créer un thread natif"-exception à environ 32000 threads. Au travail, nous avons une Lame serveur Gentoo Linux, en fait exécuter des milliers de threads simultanés servir les clients. Avec celui-là, les limites actuelles de la configuration ont été touchés autour de 20000 threads.
InformationsquelleAutor esaj
3

Pouvez-vous essayer la même commande avec une plus petite taille de la pile "-Xss64k" et de passer sur les résultats ?
- Bon point, j'ai lu le paramètre "-Xms128k" en premier.
- le programme ne peut pas courir avec ce paramètre (débordement de pile). la pile minimale nécessaire est de 128 KO.
InformationsquelleAutor souser

Je commence à soupçonner que "Native Posix Thread Library" est manquant.

>getconf GNU_LIBPTHREAD_VERSION

Devrait afficher quelque chose comme:

NPTL 2.13

Si non, l'installation de Debian est foiré. Je ne suis pas sûr de la façon de corriger cela, mais l'installation d'Ubuntu Server semble comme un bon coup...

pour ulimit -n 100000; (ouvrir fd:s) le programme suivant doit être capable de gérer 32.000 threads ou plus.

Essayer:

package test;
import java.io.InputStream;
import java.net.ServerSocket;
import java.net.Socket;
import java.util.ArrayList;
import java.util.concurrent.Semaphore;
public class Test {
final static Semaphore ss = new Semaphore(0);
static class TT implements Runnable {
@Override
public void run() {
try {
Socket t = new Socket("localhost", 47111);
InputStream is = t.getInputStream();
for (;;) {
is.read();
}
} catch (Throwable t) {
System.err.println(Thread.currentThread().getName() + " : abort");
t.printStackTrace();
System.exit(2);
}
}
}
/**
* @param args
*/
public static void main(String[] args) {
try {
Thread t = new Thread() {
public void run() {
try {
ArrayList<Socket> sockets = new ArrayList<Socket>(50000);
ServerSocket s = new ServerSocket(47111,1500);
ss.release();
for (;;) {
Socket t = s.accept();
sockets.add(t);
}
} catch (Exception e) {
e.printStackTrace();
System.exit(1);
}
}
};
t.start();
ss.acquire();
for (int i = 0; i < 30000; i++) {
Thread tt = new Thread(new TT(), "T" + i);
tt.setDaemon(true);
tt.start();
System.out.println(tt.getName());
try {
Thread.sleep(1);
} catch (InterruptedException e) {
return;
}
}
for (;;) {
System.out.println();
try {
Thread.sleep(1000);
} catch (InterruptedException e) {
return;
}
}
} catch (Throwable t) {
t.printStackTrace();
}
}
}

très intéressant programme de connaître vos résultats en cours d'exécution. sur mon serveur, j'obtiens une erreur à " T255 : abort | java.net.Exception socketexception: Aucun espace tampon disponible | à java.net.Socket.createImpl(Socket.java:397) | ... Est-il possible que c'est une debian/bug de java ?
Quel est votre système d'exploitation et version s'il vous plaît ?
Ajout d'infos ci-dessus. J'ai testé aussi avec openJDk 1.6 et j'ai obtenu les mêmes résultats.
La sortie de getconf GNU_LIBPTHREAD_VERSION est NPTL 2.7.

InformationsquelleAutor KarlP

1

Votre JVM ne parvient pas à allouer de la pile ou de quelques autres par-fil de la mémoire. L'abaissement de la taille de la pile avec -Xss permettra d'augmenter le nombre de threads que vous pouvez créer avant OOM se produit (mais JVM ne vous permettra pas de définir arbitrairement petite taille de la pile).

Vous pouvez confirmer que c'est le problème en voyant comment le nombre de threads créés modifier comme vous tordre -Xss ou en exécutant strace sur votre JVM (vous aurez presque certainement voir un mmap() retour ENOMEM juste avant une exception est levée).

Vérifier votre ulimit sur la taille virtuelle, c'est à dire ulimit -v. L'augmentation de cette limite devrait vous permettre de créer plus de threads avec la même taille de la pile. Notez que résidente de limite de taille (ulimit -m) est inefficace dans le noyau Linux actuel.

Aussi, en abaissant -Xmx pouvez nous aider en laissant plus de mémoire pour les piles de threads.
- quelle que soit la valeur que j'ai utiliser pour le xss, il y a la même limite de 600 threads. ai-je raté quelque chose ?
- Quel est votre ulimit-v et -Xss? En est-il exactement de 600 à chaque fois?
- il est illimité, et c'est toujours la même valeur.
InformationsquelleAutor Adam Zalcman
-3

Sa va de mémoire.

Aussi besoin de changer ulimit. Si votre système d'exploitation ne donnez pas à votre application assez de mémoire -Xmx, je suppose, ne fera aucune différence.

Je suppose que l'-Xmx500m est ne pas avoir d'effet.

Essayer

ulimit-m 512m
avec -Xmx512m
- Tous les manuels que j'ai lu a dit qu'il n'y avait pas de lien entre cette erreur et Xmx option. Et j'ai essayé avec 1.5 GO de ram pour Xmx et obtenu la même erreur, donc je suppose qu'il n'est pas lié
- J'ai reproduit une situation similaire et du croissant -Xmx fait qu'aggraver le problème, c'est à dire l'augmentation de la taille maximum de l'allocation de la mémoire de la piscine laisse moins de mémoire pour les piles.
InformationsquelleAutor Sid Malani

Vous devez vous connecter pour publier un commentaire.