Cómo determinar si el grupo de subprocesos de Tomcat es demasiado pequeño
1. Edite el archivo server.xml en el directorio conf en el directorio de instalación de Tomcat.
En la configuración lt; Connector en el archivo de configuración de Tomcat server.xml. el número de conexiones Los parámetros relevantes son:
maxThreads="150" significa que el número máximo de conexiones simultáneas es 150 y Tomcat usa subprocesos para procesar cada solicitud entrante. Este valor representa la cantidad máxima de subprocesos que Tomcat puede crear. El valor predeterminado es 200.
minSpareThreads="25 "Indica que incluso si nadie lo usa, abrirá tantos hilos vacíos y los esperará
maxSpareThreads="75 "Indica el número máximo de hilos vacíos Los hilos si están disponibles son 75, por ejemplo, si hay 80 visitantes en un momento determinado y nadie visita después de eso, Tomcat no mantendrá 80 hilos vacíos, sino que cerrará 5 hilos vacíos. (Una vez que el número de subprocesos creados supere este valor, Tomcat cerrará los subprocesos de socket que ya no sean necesarios. (El valor predeterminado es 50.
)
acceptCount="100" Cuando La cantidad de conexiones que aún se pueden recibir en la cola cuando la cantidad de conexiones simultáneas alcanza maxThreads. Las conexiones que exceden este valor se devolverán como conexiones rechazadas (especifica la cantidad de solicitudes que se pueden colocar en la cola de procesamiento cuando se usa cualquier cantidad de. subprocesos para procesar solicitudes. El valor predeterminado es 10.
Los parámetros relacionados con el número máximo de conexiones son maxThreads y AcceptCount. Si desea aumentar el número de conexiones simultáneas, debe aumentar estos dos. parámetros
El servidor web permite. El número máximo de conexiones también está limitado por la configuración de los parámetros del kernel del sistema operativo. Windows suele ser alrededor de 2000 y Linux suele ser alrededor de 1000. Ejemplo de configuración de Tomcat5:
lt; puerto del conector="8080"
maxThreads="150" minSpareThreads="25" maxSpareThreads="75"
acceptCount="100"/gt;
Y así sucesivamente para otros puertos configurados para escuchar.
Los grupos de subprocesos generalmente tienen tres parámetros importantes:
1. Número máximo de subprocesos en cualquier momento. se está ejecutando, el número total de subprocesos no excederá este número si el número de solicitudes excede el máximo, el programa esperará a que otros subprocesos completen la solicitud antes de procesarla. *hedge El número máximo de subprocesos, es decir, el número máximo de subprocesos inactivos. Si el número actual de subprocesos inactivos excede este valor, no habrá exceso.
3. El número mínimo de subprocesos disfrutados, es decir, el número mínimo de subprocesos inactivos, se creará a la vez si el número actual de subprocesos inactivos es menor que este valor, por lo que es en sí mismo un paso. al crear subprocesos.
El grupo de subprocesos tiene dos conceptos:
1. Los subprocesos de trabajo ejecutan principalmente código y tienen dos estados: estado inactivo y estado en ejecución. es similar a "dormir" y esperar tareas; procesar el estado de ejecución, es decir, ejecutar tareas (Ejecutable)
2. El subproceso auxiliar es el principal responsable de monitorear el grupo de subprocesos. El número de subprocesos inactivos excede el número máximo de subprocesos inactivos o es menor que el número mínimo de subprocesos inactivos. Si no cumple con los requisitos, realice ajustes
Echemos un vistazo al principio del subproceso. piscina.
De hecho, el principio del grupo de subprocesos es muy simple, similar al concepto de búfer del sistema operativo. El proceso es el siguiente: primero inicie varios subprocesos y colóquelos en un estado inactivo. despertará el grupo de subprocesos. Se utiliza un subproceso inactivo para procesar la solicitud del cliente y, cuando se procesa la solicitud, el subproceso vuelve a estar en estado inactivo. Quizás se pregunte: ¿Por qué tomarse tantas molestias si puedo crear un hilo nuevo cada vez que el cliente realiza una nueva solicitud? Esto puede ser una buena idea porque facilita la escritura de código, pero ¿está pasando por alto un tema importante? ¡actuación! Tomando mi unidad como ejemplo, mi unidad es un centro de red bancaria con un conjunto de datos provinciales. El número máximo de solicitudes simultáneas de clientes por segundo supera las 100. Si se crea un nuevo hilo para cada solicitud de cliente, consumirá una cantidad asombrosa. Tiempo de CPU y memoria: si utiliza un grupo de subprocesos con 200 subprocesos, ahorrará muchos recursos del sistema, lo que permitirá utilizar más tiempo de CPU y memoria para procesar el grupo de subprocesos real. En lugar de crear y destruir subprocesos con frecuencia, el tiempo de la CPU y la memoria se pueden utilizar para manejar aplicaciones comerciales reales.
Después de presentar los grupos de subprocesos de los tres contenedores web de Java, tomcat, jetty y resin, es habitual comparar sus ventajas y desventajas. Pero primero debemos resumir las características del grupo de subprocesos.
Los grupos de subprocesos se utilizan ampliamente como una solución para mejorar la capacidad de un programa para procesar datos. Una gran cantidad de servidores utilizan la tecnología de grupo de subprocesos en un grado u otro. Ya sea que se implementen en Java o C, los grupos de subprocesos tienen las siguientes características:
Los grupos de subprocesos generalmente tienen tres parámetros importantes:
1. En cualquier momento mientras el programa se esté ejecutando, el número total de subprocesos nunca excederá este número. Si el número de solicitudes excede el máximo, el programa esperará a que otros subprocesos completen la solicitud antes de procesarla.
2.****hedge El número máximo de subprocesos, es decir, el número máximo de subprocesos inactivos. Si el número actual de subprocesos inactivos excede este valor, los subprocesos sobrantes se eliminarán.
3. ****-Disfrutado El número mínimo de subprocesos, es decir, el número mínimo de subprocesos inactivos. Si el número actual de subprocesos inactivos es menor que este valor, este número de subprocesos inactivos se creará a la vez, por lo que es en sí mismo un paso en la creación de subprocesos.
El grupo de subprocesos tiene dos conceptos:
1. El hilo de trabajo ejecuta principalmente el código de ejecución y tiene dos estados: estado inactivo y estado en ejecución. En el estado inactivo, es similar a "dormir", esperando tareas para procesar el estado de ejecución, es decir, ejecutar tareas (Ejecutable).
2. Hilo auxiliar. Principalmente responsable de monitorear el estado del grupo de subprocesos: si los subprocesos inactivos exceden el número máximo de subprocesos inactivos o son menores que el número mínimo de subprocesos inactivos. Si no se cumplen los requisitos, haga ajustes.
1. Modifique los parámetros de la memoria de inicio y especifique la zona horaria de JVM (menos de 8 horas en Windows Server 2008):
Cuando se ejecuta el código del proyecto j2ee en Tomcat, la memoria suele aparecer en En el caso de desbordamiento, la solución es agregar parámetros del sistema a los parámetros del sistema:
Ventana. En la parte superior de catalina.bat:
set JAVA_OPTS=-XX:PermSize=64M -XX:MaxPermSize=128m -Xms512m -Xmx1024m -Duser.timezone=GMT 08; Debe estar en catalina.bat agregado en la parte superior.
En Linux, agregue en la parte superior de catalina.sh:
JAVA_OPTS="-XX:PermSize=64M -XX:MaxPermSize=128m -Xms512m -Xmx1024m -Duser.timezone= Asia / Shanghai"
Nota: la diferencia entre los dos antes y después, con o sin conjunto, con o sin comillas dobles.
2. Configuración del grupo de subprocesos (bajo Tomcat6)
Usar un grupo de subprocesos y menos subprocesos para manejar más acceso puede mejorar la capacidad de Tomcat para procesar solicitudes. Cómo utilizar:
Primero. Abra /conf/server.xml y agregue
lt;Executor name="tomcatThreadPool" namePrefix="catalina-exec-"
maxThreads="500" minSpareThreads=" 20" maxIdleTime ="60000" /gt;
MaxThreads="500" (suficiente para servidores generales), minSpareThreads="20", maxIdleTime="60 segundos del hilo.
Luego, modifique el Conector...> nodo y agregue las propiedades del ejecutor, por ejemplo:
Connector executor="tomcatThreadPool"
port="80"
protocol=" HTTP/1.1"
maxThreads=" 600"
minSpareThreads="100"
maxSpareThreads="300"
connectionTimeout=" 60000"
keepAliveTimeout="15000"
maxKeepAliveRequests="1"
redirectPort="443"
..... ./gt;
maxThreads: el número máximo de subprocesos que Tomcat puede crear, una solicitud por subproceso;
minSpareThreads: el número mínimo de subprocesos de repuesto, Tomcat inicia el número de subprocesos inicializado;
maxSpareThreads. Una vez que el número de subprocesos creados supera este valor, Tomcat cerrará los subprocesos de socket que ya no son necesarios;
acceptCount: especifica cuándo se utilizarán todos los subprocesos disponibles. Cuando se utilizan todos los subprocesos para procesar solicitudes, se rechazará la cantidad de solicitudes que se pueden colocar en la cola de procesamiento, es decir, la cantidad de solicitudes en cola.
ConnectionTimeout: tiempo de espera de la conexión de red, en milisegundos. Establecerlo en 0 significa que nunca expirará, pero esta configuración también tiene peligros ocultos
enableLookups: si se permiten búsquedas de DNS
Nota: Sí, permite que se compartan varios conectores. un grupo de subprocesos.
3. Ajuste los parámetros del conector relacionados con la conexión:
lt; Connector Executor="tomcatThreadPool"
port="80" protocol="HTTP / 1.1"
connectionTimeout="60000"
keepAliveTimeout="15000"
maxKeepAliveRequests="1"
redirectPort="443 "
maxHttpHeaderSize="8192" URIEncoding="UTF-8" enableLookups="false" AcceptCount="100" enableUploadTimeout="true"/gt
Descripción del parámetro:
ConnectionTimeout: tiempo de espera de la conexión de red en milisegundos. Establecerlo en 0 significa que nunca se agota el tiempo, lo que puede resultar complicado. Normalmente, esto se puede configurar en 30000 milisegundos.
keepAliveTimeout: tiempo de espera máximo de mantenimiento (en milisegundos) para conexiones largas. Son 15 segundos.
maxKeepAliveRequests: el número máximo de conexiones largas (1 significa deshabilitadas, -1 significa ilimitadas, el valor predeterminado es 100). El número máximo de solicitudes HTTP que pueden permanecer en proceso antes de que el servidor cierre la conexión. Establecer esta propiedad en 1 deshabilita el mantenimiento de actividad HTTP/1.0, el mantenimiento de actividad HTTP/1.1 y las canalizaciones. Establezca esta propiedad en -1 para permitir una cantidad ilimitada de solicitudes HTTP canalizadas o de mantenimiento de actividad. Establezca esta propiedad en -1 para permitir una cantidad ilimitada de solicitudes HTTP canalizadas o de mantenimiento de actividad. Si no se especifica, esta propiedad se establecerá en 100.
maxHttpHeaderSize: utiliza todos los subprocesos de manejo de solicitudes posibles para recibir solicitudes de conexión. Cualquier solicitud recibida cuando la cola esté llena será rechazada. El valor predeterminado es 10.
disableUploadTimeout: si se utiliza el mecanismo de tiempo de espera para la carga
enableLookups: si se habilita la consulta de nombre de dominio, el valor es verdadero o falso, debe establecerse en falso para un mejor efecto de procesamiento
bufferSize: define el tamaño del búfer proporcionado en bytes; de forma predeterminada, se proporciona un búfer de 2048 bytes.
maxSpareThreads (número máximo de subprocesos de repuesto): establece el número de conexiones inactivas. Una vez que el número de subprocesos creados supera este valor, Tomcat permitirá que exista el número máximo de subprocesos de procesamiento de solicitudes no utilizados hasta el grupo de subprocesos. comienza a detenerse. El valor predeterminado es 50.
maxThreads: el número máximo de conexiones simultáneas que Tomcat utilizará para manejar cada solicitud entrante. Este valor representa la cantidad máxima de subprocesos que Tomcat puede crear. El número máximo de subprocesos de manejo de solicitudes creados por este conector, lo que determina el número máximo de solicitudes que se pueden procesar simultáneamente. Si no se especifica, esta propiedad se establecerá en 200.
minSpareThreads: el número mínimo de subprocesos inactivos creados cuando se inicializa Tomcat, es decir, el número de subprocesos de procesamiento de solicitudes creados cuando se inicia el conector por primera vez. El conector también garantizará que esté disponible un número específico de subprocesos de procesamiento inactivos. El valor de configuración de esta propiedad debe ser menor que el valor de configuración de maxThreads. El valor predeterminado es 4.
minProcessors: número mínimo de subprocesos de conexión inactivos. El valor predeterminado es 10.
(Usado en Tomcat4)
maxProcessors - maxProcessors: el número máximo de subprocesos, es decir, el número máximo de solicitudes de procesamiento simultáneas, el valor predeterminado es 75. (Usado en Tomcat4)
Nota:
Tomcat4 puede controlar el número de subprocesos modificando los valores minProcessors y maxProcessors.
En Tomcat5, ajuste principalmente los siguientes parámetros
maxThreads
Tomcat utiliza subprocesos para procesar cada solicitud recibida. Este valor representa la cantidad máxima de subprocesos que Tomcat puede crear.
acceptCount
Especifica el número de solicitudes que se pueden colocar en la cola de procesamiento cuando se han utilizado todos los subprocesos disponibles para procesar solicitudes. Las solicitudes que superen este número no se procesarán.
connectionTimeout
Tiempo de espera de conexión de red, en milisegundos. Establecerlo en 0 significa que nunca expirará, pero esta configuración tiene sus inconvenientes. Normalmente, esto se puede configurar en 30000 milisegundos.
minSpareThreads
El número de subprocesos creados cuando se inicializa Tomcat.
maxSpareThreads
Una vez que el número de subprocesos creados supera este valor, Tomcat cerrará los subprocesos del socket que ya no sean necesarios.