java - instalar - install jdk 1.8 centos 7
Límite de subprocesos de proceso único Java bajo en Red Hat Linux (5)
Estoy experimentando un problema en una máquina de prueba que ejecuta Red Hat Linux (la versión del kernel es 2.4.21-37.ELsmp) usando Java 1.6 (1.6.0_02 o 1.6.0_04). El problema es que, una vez que se crea un cierto número de subprocesos en un solo grupo de subprocesos, el sistema operativo no quiere o no puede crear más.
Esto parece ser específico de los subprocesos de creación de Java, ya que el programa C thread-limit fue capaz de crear aproximadamente 1.5k hilos. Además, esto no ocurre con Java 1.4 JVM ... puede crear más de 1.4k hilos, aunque obviamente se manejan de forma diferente con respecto al sistema operativo.
En este caso, la cantidad de hilos a los que corta es de solo 29 hilos. Esto se puede probar con un programa Java simple que solo crea subprocesos hasta que obtiene un error y luego imprime la cantidad de subprocesos que creó. El error es un
java.lang.OutOfMemoryError: unable to create new native thread
Esto no se ve afectado por factores tales como el número de subprocesos en uso por otros procesos o usuarios o la cantidad total de memoria que el sistema está utilizando en ese momento. Las configuraciones de JVM como Xms, Xmx y Xss tampoco parecen cambiar nada (lo cual se espera, ya que el problema parece ser la creación de subprocesos del sistema operativo nativo).
La salida de "ulimit -a" es la siguiente:
core file size (blocks, -c) 0 data seg size (kbytes, -d) unlimited file size (blocks, -f) unlimited max locked memory (kbytes, -l) 4 max memory size (kbytes, -m) unlimited open files (-n) 1024 pipe size (512 bytes, -p) 8 stack size (kbytes, -s) 10240 cpu time (seconds, -t) unlimited max user processes (-u) 7168 virtual memory (kbytes, -v) unlimited
El límite del proceso de usuario no parece ser el problema. La búsqueda de información sobre lo que podría estar mal no ha aparecido demasiado, pero esta publicación parece indicar que al menos algunos kernels de Red Hat limitan un proceso a 300 MB de memoria asignados para la pila, y a 10 MB por hilo para la pila, parece al igual que el problema podría estar allí (aunque parece extraño y poco probable también).
Intenté cambiar el tamaño de la pila con "ulimit -s" para probar esto, pero cualquier valor que no sea 10240 y la JVM no comienza con un error de:
Error occurred during initialization of VM Cannot create VM thread. Out of system resources.
En general, puedo manejar Linux, pero realmente no sé mucho sobre la configuración del sistema, y no he podido encontrar nada que aborde específicamente este tipo de situación. Cualquier idea sobre qué sistema o configuración de JVM podría estar causando esto sería apreciada.
Ediciones : al ejecutar el programa de límite de hilos mencionado por zócalo , no hubo fallas hasta que intentó crear el subproceso 1529th.
El problema tampoco ocurrió con una JVM 1.4 (sí ocurre con las JVM 1.6.0_02 y 1.6.0_04, no se puede probar con una JVM 1.5 en este momento).
El código para la prueba de hilo que estoy usando es el siguiente:
public class ThreadTest {
public static void main(String[] pArgs) throws Exception {
try {
// keep spawning new threads forever
while (true) {
new TestThread().start();
}
}
// when out of memory error is reached, print out the number of
// successful threads spawned and exit
catch ( OutOfMemoryError e ) {
System.out.println(TestThread.CREATE_COUNT);
System.exit(-1);
}
}
static class TestThread extends Thread {
private static int CREATE_COUNT = 0;
public TestThread() {
CREATE_COUNT++;
}
// make the thread wait for eternity after being spawned
public void run() {
try {
sleep(Integer.MAX_VALUE);
}
// even if there is an interruption, dont do anything
catch (InterruptedException e) {
}
}
}
}
Si ejecuta esto con una JVM 1.4 se bloqueará cuando no pueda crear más hilos y requiera un kill -9 (al menos lo hizo por mí).
Más Editar:
Resulta que el sistema que está teniendo el problema está utilizando el modelo de subprocesamiento LinuxThreads, mientras que otro sistema que funciona bien está utilizando el modelo NPTL.
¿Has mirado este recurso ? Establece que debe poder ejecutar thread-limit para encontrar la cantidad máxima de hilos y puede modificarlo compilando glibc.
Esto es con Ubuntu Linux (1GB RAM)
dsm@localhost:~$ javac ThreadTest.java
dsm@localhost:~$ java ThreadTest
8113
dsm@localhost:~$ java -version
java version "1.6.0_07"
Java(TM) SE Runtime Environment (build 1.6.0_07-b06)
Java HotSpot(TM) Client VM (build 10.0-b23, mixed mode, sharing)
dsm@localhost:~$
¿Puedes probarlo con JRockit JVM? IIRC, tenía un modelo de subprocesamiento diferente al stock Sun JVM.
La actualización del kernel a una versión más nueva (2.6.asistencia) con enrutamiento NPTL corrigió esto.
La configuración en /etc/security/limits.d/90-nproc.conf puede estar anulando las configuraciones de /etc/security/limits.conf . Eso puede hacer que el sistema actúe de una manera diferente que se muestra en ulimit -u .