Pruebas de rendimiento: ¿Cuáles son los parámetros comunes relacionados con los módulos MPM?
Esta directiva establece el número máximo de procesos secundarios inactivos. El llamado proceso hijo inactivo se refiere a un proceso hijo que no procesa solicitudes. Si la cantidad de procesos secundarios actualmente inactivos excede MaxSpareServers, el proceso principal eliminará los procesos secundarios sobrantes. Este parámetro sólo debe ajustarse en máquinas muy ocupadas y no debe establecerse demasiado alto hasta que el número de subprocesos libres caiga por debajo de este valor. Si establece esta directiva en un valor menor que MinSpareServers, Apache la cambiará automáticamente a "MinSpareServers 1".
Para trabajadores y eventos, la recomendación predeterminada es MaxSpareThreads 250.
Para mpm_netware, el valor predeterminado es MaxSpareThreads 100.
mpmt_os2 funciona igual que mpm_netware.
▲ Nota:
El valor de MaxSpareThreads tiene un rango limitado y el valor de Apache ware debe ser mayor que MinSpareThreads.
● Para trabajadores y eventos, el valor debe ser mayor o igual a MinSpareThreads y ThreadsPerChild.
Representa el número mínimo de subprocesos inactivos para manejar el número máximo de solicitudes. Diferentes MPM manejan esta instrucción de manera diferente.
El valor predeterminado para los módulos de trabajo y eventos es MinSpareThreads 75. Si la cantidad de subprocesos inactivos en el servidor es menor que el valor establecido, se crearán subprocesos secundarios hasta que la cantidad de subprocesos inactivos sea mayor que la cantidad mínima de subprocesos inactivos que configuramos.
Si no hay suficientes subprocesos inactivos en el servidor, se crearán procesos secundarios hasta que el número de subprocesos inactivos sea mayor que el número de subprocesos inactivos. El MinSpareThreads predeterminado del módulo mpm_netware es 10 y el MinSpareThreads predeterminado del módulo mpmt_os2 es 5.
Para preforkMPM, esto se puede hacer a través de MaxRequestWorkers configurados, porque preforkMPM es un proceso hijo que solo genera un subproceso. Para trabajadorMPM y eventoMPM, el valor máximo se configura a través de los parámetros ThreadLimit y MaxRequestWorkers.
Al usar esta directiva, se debe tener en cuenta que el valor de ServerLimit no debe establecerse demasiado alto en comparación con el valor real utilizado, si se establece demasiado alto, no ocuparemos una gran cantidad de memoria; Se asignará la necesidad de uso. Si los valores de ServerLimit y MaxRequestWorkers se establecen por encima de las capacidades de procesamiento del sistema, el módulo Apache solo generará un proceso hijo, por lo que el valor de esta directiva debe ser mayor que la carga máxima manejada por el servidor si lo está utilizando; uno que pueda generar múltiples procesos secundarios en el módulo Worker, entonces el número total de subprocesos debe ser mayor que la carga del servidor.
mpm_winnt El valor predeterminado de esta directiva es 25.
El valor predeterminado de ThreadsPerChild para otros MPM es 64.
El valor de configuración de ThreadsPerChild no puede exceder el valor de ThreadLimit. Si se configura un valor más alto, se reducirá automáticamente al inicio y se registrará un mensaje de registro de advertencia.
MaxConnectionsPerChild Esta directiva se utiliza principalmente para establecer el número máximo de conexiones que un único proceso hijo puede manejar. Si el número de conexiones manejadas por un proceso hijo alcanza este máximo, el proceso hijo será eliminado. Si MaxConnectionsPerChild se establece en 0, el proceso hijo puede manejar un número ilimitado de conexiones. Establecer MaxConnectionsPerChild en un valor distinto de cero limita el problema de que los procesos consuman demasiada memoria debido a pérdidas de memoria.
La directiva MaxRequestWorkers se utiliza para establecer el número máximo de conexiones que el servidor puede manejar simultáneamente. Si se excede este valor, se produce la cola. El valor máximo de la cola lo establece la directiva ListenBacklog. Solo cuando la solicitud se complete en el proceso de la cola se liberará el proceso secundario para dar servicio a otras conexiones.
En este caso, el valor máximo de la cola lo establece la directiva ListenBacklog.
Para los módulos MPM que no son servicios de subprocesos (como prefork), la directiva MaxRequestWorkers se convertirá en el número máximo de subservidores que puede tener el servidor, es decir, el valor de ServerLimit. El valor predeterminado de la directiva MaxRequestWorkers es 256.
Para los módulos MPM que generan clases multiproceso (como eventos o trabajadores), se utilizará la directiva MaxRequestWorkers para limitar el número de conexiones de clientes al servidor. En el caso de MPM mixto, el valor predeterminado de ServerLimit es 16 y el valor predeterminado de ThreadsPerChild es 25, en cuyo caso el valor de la directiva MaxRequestWorkers debe establecerse en un valor mayor que 16 veces 25.
Antes de la versión 2.3.13, la versión anterior de la directiva MaxRequestWorkers se llamaba MaxClients.
El comando ListenBackLog se utiliza para establecer la longitud de la cola de recuento de conexiones. Su valor predeterminado es 511. Generalmente, no necesitamos configurar ni ajustar este comando, pero si algunos sistemas son atacados por TCP SYN. , se puede aumentar el valor adecuadamente.
Esta opción tiene dos elementos principales que deben calcularse: uno es el número de núcleos de CPU en línea y el otro es el depósito de escucha.
Primero, introduzcamos el núcleo de la CPU en línea. El kernel utiliza cuatro mapas de bits para almacenar el núcleo de la CPU en cuatro estados: posible, actual, activo y en línea. Hay un archivo en línea en el directorio /sys/devices/system/cpu, que registra la cantidad de núcleos de CPU actualmente en línea.
El sistema operativo Linux llamará para abrir smp multinúcleo durante el proceso de inicialización. cpuhotplug puede abrir automáticamente el núcleo según la carga de la CPU, equilibrando el rendimiento y el consumo de energía. Finalmente, la CPU inactiva entrará en el estado de CPU inactiva. El principio de cpuhotplug se muestra en la Figura 10-6.
Para estudiar el depósito de escucha, primero debe comprender el proceso de las conexiones TCP y la relación entre las conexiones TCP y los sockets.
El proceso de conexión TCP se muestra en la Figura 10-7.
La función de escucha se utiliza para escuchar el socket vinculado al puerto addr a través de la función bind().
Después de escuchar, el socket cambiará del estado CLOSE al estado LISTEN y el socket puede proporcionar una ventana para conexiones TCP. La función Connect () se utiliza para iniciar una solicitud de conexión al socket monitoreado, es decir, iniciar un proceso de protocolo de enlace TCP de tres vías.
Entonces, ¿cuál es la relación entre las conexiones TCP y los sockets? Cada conexión TCP (ya sea cliente o servidor) está asociada con un socket y un descriptor de archivo al que apunta el socket. Cuando el servidor acepta el mensaje ACK, significa que se ha completado el protocolo de enlace de tres vías y se ha establecido la conexión TCP entre el cliente y el servidor. Una vez establecida la conexión TCP, la conexión TCP se colocará en la cola de escucha () abierta en la cola establecida esperando para aceptar mensajes. En este momento, el socket asociado con la conexión TCP es el socket de escucha y el descriptor que apunta a él. archivo. El socket asociado con una conexión TCP es un socket de escucha y un descriptor que apunta a un archivo.
Cuando aceptar () acepta un TCP en la cola establecida, asociará el socket especificado por aceptar () con un nuevo descriptor de archivo, lo que significa que después de aceptar (), ya no hay ningún relación entre la conexión y la toma de escucha.
En términos generales, un puerto de dirección solo se puede vincular a un socket, lo que significa que el puerto de dirección no se puede reutilizar y diferentes sockets solo se pueden vincular a diferentes puertos de dirección.
Los subprocesos que escuchan el socket son todos oyentes preventivos. Solo un subproceso de escucha puede monitorear o usar el socket de escucha al mismo tiempo. Cuando el subproceso de escucha recibe una solicitud, le permitirá obtener calificaciones de escucha. Y luego otros subprocesos de escucha tomarán los derechos de escucha, pero solo un subproceso puede apoderarse de los derechos de escucha al mismo tiempo. El proceso se muestra en la Figura 10-8.
En circunstancias normales, el puerto addr solo puede estar vinculado por un socket. Si la dirección y el puerto se reutilizan, entonces la combinación es la reutilización de sockets. En el kernel de Linux actual, los sockets que admiten la reutilización de direcciones son La palabra. La opción es SO_REUSEADDR y la opción de socket que admite la reutilización de puertos es SO_REUSEPORT. Después de configurar la opción de reutilización del puerto, puede vincular el puerto. Después de configurar la opción de reutilización de puertos y luego vincular el socket, es equivalente a vincular dos o más puertos addr a una instancia. Para el proceso/hilo de escucha, cada socket reutilizado se denomina depósito de escucha, es decir, cada socket de escucha es un depósito de escucha. Tome el proceso de trabajo o el modelo de eventos de httpd como ejemplo y suponga que hay N subprocesos y que cada subproceso contiene un subproceso de escucha y N subprocesos de trabajo. El proceso de trabajo se muestra en la Figura 10-9.
Utilizar la tecnología de reutilización de direcciones y puertos equivale a vincular varios sockets a la misma dirección y puerto. Como se muestra en la Figura 10-9, un depósito de escucha está vinculado a tres sockets y tres subprocesos escuchan estos tres sockets al mismo tiempo. Sin embargo, cada socket todavía toma la dirección de la misma manera porque la dirección no se reutiliza. Se adelanta la lógica del puerto que no se reutiliza y se obtiene el derecho de monitoreo.
La ventaja de la reutilización de direcciones y puertos es que puede reducir la contención por bloqueos mutex durante el monitoreo, evitar el "problema de inanición", mejorar la eficiencia del monitoreo y equilibrar mejor la carga, pero esto también se ve afectado por Debido a las limitaciones del kernel de la CPU, si se trata de una CPU de un solo núcleo, no habrá ninguna ventaja en la reutilización de direcciones y puertos. Qué ventaja, porque la cantidad de hilos no es suficiente.
Ahora puede comprender el significado de la opción ListenCoresBucketsRatio, que se utiliza para establecer la proporción de núcleos de CPU en línea y depósitos de escucha.
En los subprocesos MPM, cada subproceso tiene su propio asignador. Este parámetro indica la cantidad máxima de memoria disponible que cada asignador puede contener cuando no se llama a la función free() para liberar la memoria.
p>. Establecer en 0 significa que el umbral es ilimitado.
Se utiliza para establecer el tamaño del búfer cuando TCP recibe datos.
Si se establece en cero, prevalecerá el valor proporcionado por el sistema operativo.
Las anteriores son las configuraciones de comando comunes involucradas en el módulo MPM.