Cómo determinar la ruta del archivo estático del que desaparece nginx

nginx es popular entre las SA debido a su bajo consumo de recursos, gran tolerancia a la concurrencia y archivos de configuración simples. Sin embargo, la configuración de nginx que circula en Internet no se ha optimizado demasiado. A continuación, el autor le explicará los aspectos principales de la optimización de nginx desde la perspectiva de la optimización real de la operación y el mantenimiento de nginx, un gran sitio web de medios.

El comando de inicio de nginx es /usr/local/nginx/sbin/nginx -c /usr/local/nginx/conf/nginx.conf
-c se usa para establecer la ruta del archivo de configuración, no Agregar -nginx cargará automáticamente el archivo de configuración en la ruta predeterminada.

Detener

La parada se realiza enviando una señal al proceso nginx (consulte el artículo de Linux para saber qué son las señales)

Paso 1: Encuentre el número de proceso principal de nginx

ps -ef | grep nginx

Busque el proceso principal en la lista de procesos, y su número es el número de proceso principal.

Paso 2: Enviar señal

Detenga Nginx con elegancia:

elimine -QUIT número de proceso maestro

Detenga Nginx rápidamente:

kill -TERM número de proceso maestro

Forzar la detención de Nginx:

pkill -9 nginx

Además, si nginx se ha estado ejecutando durante un mucho tiempo, es posible que desee detener también el proceso principal. p>Además, si la ruta al archivo pid está configurada en nginx.conf, el archivo pid se guardará en el número de proceso principal de nginx. Si no está configurado, se guardará en el directorio de registro de nginx. Con el archivo pid, no necesitamos encontrar primero el número de proceso principal de Nginx, sino enviar una señal directamente a Nginx. El comando es el siguiente:

kill -signal type '/usr/nginx/logs. /nginx.pid'

Reinicio sin problemas

Si desea reiniciar Nginx después de cambiar la configuración, ¿necesita cerrar Nginx y luego abrirlo nuevamente? ¿Cerrar Nginx y luego abrirlo de nuevo? No, puedes enviar una señal a Nginx para que se reinicie correctamente.

Comando de reinicio suave:

kill -HUP ingresa el nombre o la ruta del archivo ID del proceso

o usa

/usr/nginx/ sbin/nginx -s reload

Tenga en cuenta que después de modificar el archivo de configuración, es mejor verificar si el archivo de configuración modificado es correcto para evitar reiniciar. Para evitar errores al reiniciar Nginx que puedan afectar el funcionamiento estable del servidor. El siguiente comando puede determinar si Nginx está configurado correctamente:

nginx -t -c /usr/nginx/conf/nginx.conf

o

/usr /nginx /sbin/nginx -t

Actualización fluida

Si el servidor se está ejecutando y Nginx se está actualizando, o se están agregando o eliminando módulos, debemos detener el servidor y realice cambios para que el servidor se detenga. Después de funcionar durante un período de tiempo, Nginx se puede actualizar sin tiempo de inactividad y sin afectar el funcionamiento del servidor.

Paso 1:

Si desea actualizar el programa Nginx, reemplace el archivo del programa antiguo con el nuevo programa, compile el nuevo programa e instálelo directamente en el directorio de instalación de Nginx.

Paso 2: Ejecute el comando

kill -USR2 el número de proceso principal o el nombre del archivo de proceso de la versión anterior del programa

Luego, la versión anterior de El proceso principal de Nginx cambiará el nombre de su propio archivo de proceso a .oldbin y luego ejecutará la nueva versión de Nginx.

Para detener la versión anterior de Nginx, ingrese el comando:

kill -WINCH número de proceso maestro antiguo

A medida que se completa la tarea, el antiguo proceso de trabajo Saldrá lentamente, el nuevo proceso de trabajo de Nginx reemplazará gradualmente al antiguo proceso de trabajo.

Llegado a este punto podremos decidir si utilizar la nueva versión o volver a la anterior.

Iniciar procesos de trabajo antiguos/nuevos sin recargar la configuración

eliminar -HUP ID del proceso maestro antiguo/nuevo

Cerrar proceso antiguo/nuevo correctamente

kill -QUIT número de proceso principal antiguo/nuevo

Si se produce un error que indica que todavía hay procesos sin terminar, puede usar el siguiente comando para cerrar el proceso de trabajo antiguo/nuevo primero y luego Cierre el proceso principal

kill -TERM número de proceso de trabajo antiguo/nuevo

De esta manera, si desea volver a la versión anterior, solo necesita operar la nueva versión de el número de proceso principal en los pasos anteriores. Si desea utilizar la versión anterior de la nueva versión, manipule el número de proceso maestro en el paso anterior.

Las anteriores son algunas operaciones básicas de Nginx. Espero que Nginx pueda tener una mejor manera de manejar estas operaciones en el futuro. Es mejor usar comandos de Nginx en lugar de enviar señales del sistema al proceso de Nginx.

1. Optimización de la compilación

1. Primero, analice los parámetros de configuración Según los parámetros de configuración más utilizados en Internet, la mayoría de ellos son:

# ./configure (

--prefix=/usr/local/nginx (

--user=www (

--group=www (

p>

--with-/files/google-perftools-1.7.tar.gz

# tar xzvf google-perftools-1.7.tar. gz

# cd google-perftools-1.7

Luego inicie la configuración:

# ./configure --prefix=/usr --enable-frame- punteros (se pueden usar 32 bits sin -enable-frame-pointers)

# make --j4 && make installnginx

configurar con --with-google-perftools recompilar nginx

# ./ configurar \

--prefix=/usr/local/nginx \

--user=www \

--group=www \

--with-.ipv4.tcp_max_tw_buckets = 6000

Tiempo de espera, el valor predeterminado es 180000.

net.ipv4.ip_local_port_range = 1024 65000

Permitido El rango de puertos que abre el sistema

net.ipv4.tcp_tw_recycle = 1

Permite un ciclo rápido de los tiempos de espera

.

net.ipv4.tcp_tw_reuse = 1

Habilita la reutilización. Permite reutilizar los sockets TIME-WAIT para nuevas conexiones TCP

net.ipv4.tcp_syncookies = 1

Habilita la cookie SYN Procesada cuando la cola de espera SYN se desborda.

net.core.somaxconn = 262144

Para net.core.somaxconn en nuestros parámetros del kernel, el límite predeterminado de la acumulación de la función de escucha en la aplicación de red es 128, y el NGX_LISTEN_BACKLOG definido por nginx El valor predeterminado es 511, por lo que es necesario ajustar este valor.

net.core.netdev_max_backlog=262144

El número máximo de paquetes que se permite enviar a la cola cuando cada interfaz de red recibe paquetes más rápido de lo que el kernel puede procesarlos.

net.ipv4.tcp_max_orphans = 262144

El número máximo de sockets TCP en el sistema que no están asociados con ningún identificador de archivo de usuario. Si se excede este número, las conexiones huérfanas se restablecerán inmediatamente y se imprimirá un mensaje de advertencia. Este límite solo está destinado a prevenir ataques DoS simples y no se debe confiar en que se reduzca excesiva o artificialmente, sino que se aumente (si se agrega memoria).

net.ipv4.tcp_max_syn_backlog = 262144

Registra el valor máximo de solicitudes de conexión que aún no han recibido confirmación del cliente. Para sistemas con 128 M de memoria, el valor predeterminado es 1024 y para sistemas con menos memoria, el valor predeterminado es 128.

net.ipv4.tcp_timestamps = 0

Las marcas de tiempo impiden el ajuste del número de secuencia. Un enlace de 1 Gbps definitivamente encontrará números de secuencia que se han utilizado antes. Las marcas de tiempo permiten que el núcleo acepte dichos paquetes "anormales". Esto hay que cerrarlo.

net.ipv4.tcp_synack_retries=1

Para abrir una conexión con el otro extremo, el kernel necesita enviar un SYN y un ACK como respuesta al SYN anterior, es decir, en el segundo apretón de manos de tres vías. Esta configuración determinará cuántos paquetes SYN+ACK envía el kernel antes de abandonar la conexión.

net.ipv4.tcp_syn_retries = 1

El número de paquetes SYN enviados antes de que el núcleo deje de establecer la conexión.

net.ipv4.tcp_fin_timeout = 1

Este parámetro determina cuánto tiempo permanecerá el socket en el estado FIN-WAIT-2 si este extremo solicita cerrar el socket. Algo podría salir mal en el otro extremo, no poder cerrar nunca la conexión o incluso fallar inesperadamente. El valor predeterminado es 60 segundos. El valor típico para núcleos 2.2 es 180 segundos. Puede configurarlo así, pero debe tener en cuenta que incluso si su máquina es un servidor WEB con carga ligera, es posible provocar un desbordamiento de memoria debido a una gran cantidad de sockets inactivos. FIN-WAIT-2 es menos peligroso que FIN-WAIT-1 porque requiere hasta 1,5 K de memoria, pero dura más.

net.ipv4.tcp_keepalive_time=30

Con qué frecuencia TCP envía mensajes keepalive cuando los keepalive están activos. El valor predeterminado es 2 horas.

msgmax = 65536

kernel.shmmax = 68719476736

kernel.shmall = 4294967296

net.ipv4.tcp_max_tw_buckets = 6000

net. ipv4.tcp_window_scaling = 1

net.ipv4.tcp_rmem = 4096 87380 4194304

net.ipv4.tcp_wmem = 4096 16384 4194304

net.core.wmem_default = 8388608

net.core.wmem_default = 8388608tcp_fin_timeout = 1

net.ipv4.tcp_keepalive_time = 30

net.ipv4.ip_local_port_range = 1024 65000

Optimización simple de los archivos de configuración de nginx