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

Solución:

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

Si te encuentras Exception in thread "main" java.lang.OutOfMemoryError: unable to create new native thread, marque estos:

1. En pequeñas máquinas de memoria

   Cada hilo 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 .... No se puede iniciar JVM si el tamaño de la pila es demasiado bajo.

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

2. Límites del sistema

   Algunos valores en ulimit -a puede afectar el límite de un hilo.

   • 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 (por defecto 1024k)

   Puede cambiar estos valores ejecutando (temporal) 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). Cheque 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 de corriente, aumente este. Linux trata los subprocesos 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_count, también.

5. sys.vm.max_map_count

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

   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 por medio del límite systemd “TasksMax” que establece pids.max en el cgroup.

Para las sesiones de inicio de sesión, el valor predeterminado 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 DefaultTasksMax es el 15% del límite del kernel pids_max (generalmente 4,915). 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 de maczniak anterior 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

Yo tambien tuve que poner DefaultTasksMax en /etc/systemd/system.conf (o /etc/systemd/user.conf para los servicios ejecutados por el usuario) para DefaultTasksMax=unlimited.

Systemd también aplica un límite para los programas que se ejecutan desde un shell de inicio de sesión. Estos valores 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.

---

---

Utiliza Nuestro Buscador