Saltar al contenido

Cómo aumentar el número máximo de hilos JVM (Linux 64bit)

Ya no busques más por todo internet ya que has llegado al espacio adecuado, poseemos la respuesta que deseas pero sin complicaciones.

Solución:

Puede usar un programa de muestra para averiguar el límite actual de subprocesos.

si te encuentras Exception in thread "main" java.lang.OutOfMemoryError: unable to create new native threadrevisa estos:

  1. En pequeñas máquinas de memoria

    Cada subproceso de Java consume su propia memoria de pila. El tamaño de pila predeterminado es 1024k (= 1M). Puede reducir el tamaño de la pila como java -Xss512k .... JVM no se puede iniciar si el tamaño de la pila es demasiado bajo.

    Y tenga cuidado con las configuraciones de memoria en montón: (inicial) -Xms y (máximo) -Xmx. Cuanta más memoria se asigna al montón, menos memoria disponible para la pila.

  2. Límites del sistema

    algunos valores en ulimit -a puede afectar un límite de subprocesos.

    • max memory size – ilimitado en la mayoría de las máquinas de 64 bits
    • max user processes – Linux trata los hilos como procesos
    • virtual memory – ilimitado en la mayoría de las máquinas de 64 bits. el uso de la memoria virtual aumenta con la configuración -Xss (predeterminada 1024k)

    Puede cambiar estos valores ejecutando (temporalmente) ulimit comando o edición (permanente) /etc/security/limits.conf.

  3. sys.kernel.threads-max

    Este valor es el número máximo de subprocesos global del sistema (incluidos los procesos que no son JVM). Controlar cat /proc/sys/kernel/threads-maxy aumente si es necesario.

    echo 999999 > /proc/sys/kernel/threads-max

    o
    sys.kernel.threads-max = 999999 en /etc/sysctl.conf para cambiar permanentemente.

  4. sys.kernel.pid_max

    Si cat /proc/sys/kernel/pid_max es similar al límite actual, aumente esto. Linux trata los hilos como procesos.

    echo 999999 > /proc/sys/kernel/pid_max

    o
    sys.kernel.pid_max = 999999 en /etc/sysctl.conf para cambiar permanentemente.

    Y es posible que deba aumentar sys.vm.max_map_counttambién.

  5. sys.vm.max_map_count

    cat /proc/sys/vm/max_map_count debe ser al menos (2 x número de hilos).

    Attempt to protect stack guard pages failed. y OpenJDK 64-Bit Server VM warning: Attempt to deallocate stack guard pages failed. JavaThread::create_stack_guard_pages() emite mensajes de error y llama a os::guard_memory(). En Linux, esta función es mprotect().

    echo 1999999 > /proc/sys/vm/max_map_count

    o
    sys.vm.max_map_count = 1999999 en /etc/sysctl.conf para cambiar permanentemente.

Información adicional para sistemas linux modernos (systemd).

Hay muchos recursos sobre estos valores que pueden necesitar ajustes (la otra respuesta es una buena fuente para la mayoría de ellos); sin embargo, se impone un nuevo límite a través del límite systemd “TasksMax” que establece pids.max en cgroup.

Para las sesiones de inicio de sesión, el valor predeterminado de UserTasksMax es el 33% del límite del kernel pids_max (generalmente 12,288) y se puede anular en /etc/systemd/logind.conf.

Para los servicios, el valor predeterminado de DefaultTasksMax es el 15 % del límite del kernel pids_max (normalmente 4915). Puede anularlo para el servicio configurando TasksMax en “systemctl edit” o actualizando DefaultTasksMax en /etc/systemd/system.conf

Me encontré con un problema similar en un programa de Python y lo siguiente funcionó para mí. Esto se basa en la respuesta anterior de maczniak y https://superuser.com/questions/1219960/cannot-edit-proc-sys-kernel-threads-max.

echo kernel.threads-max = 1073741823 >> /etc/sysctl.conf && echo 1073741823 > /proc/sys/kernel/threads-max
echo kernel.pid_max = 999999 >> /etc/sysctl.conf && echo 999999 > /proc/sys/kernel/pid_max
echo vm.max_map_count = 2147483646 >> /etc/sysctl.conf && echo 2147483646 > /proc/sys/vm/max_map_count
echo vm.overcommit_memory = 1 >> /etc/sysctl.conf && echo 1 > /proc/sys/vm/overcommit_memory
echo fs.inotify.max_user_instances = 256 >> /etc/sysctl.conf && echo 256 > /proc/sys/fs/inotify/max_user_instances
sysctl -p

también tuve que poner DefaultTasksMax en /etc/systemd/system.conf (o /etc/systemd/user.conf para servicios administrados por el usuario) a DefaultTasksMax=unlimited.

Systemd también aplica un límite para los programas que se ejecutan desde un shell de inicio de sesión. Estos predeterminados son 4096 por usuario (se incrementarán a 12288) y están configurados como UserTasksMax en el [Login] Sección de
/etc/systemd/logind.conf.

Eso es de esta pregunta de StackExchange. Configurando mi UserTasksMax para UserTasksMax=999999 trabajó para mi.

Te mostramos reseñas y calificaciones

Eres capaz de reafirmar nuestro cometido escribiendo un comentario y dejando una valoración te damos la bienvenida.

¡Haz clic para puntuar esta entrada!
(Votos: 0 Promedio: 0)



Utiliza Nuestro Buscador

Deja una respuesta

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *