Este artículo presentará un caso real que ocurrió en nuestro entorno en línea. El problema ocurrió durante una promoción importante y causó un impacto relativamente grande en nuestro clúster en línea. Este artículo revisará brevemente este problema. Se lo pedí a todos para que lo entendieran. Es posible que el proceso real de investigación y resolución no sea exactamente el mismo que el descrito en este artículo, pero la idea es la misma.
Proceso de problemas
Durante una promoción importante, se produjo repentinamente una gran cantidad de alarmas en una determinada aplicación en línea, lo que provocó que la tasa de ocupación del disco era demasiado alta, alcanzando más del 80% a la vez.
En este caso, iniciamos sesión en la máquina en línea lo antes posible para verificar el uso del disco de la máquina en línea. Utilice el comando: df para ver el uso del disco.
$df
Filesystem 1K-blocks Used Available Use% Mounted on
/ 62914560 58911440 4003120 93% /
/dev/sda2 62914560 58911440 4003120 93% /home/adminSe encontró que el consumo de disco de la máquina era bastante serio, porque había muchas solicitudes durante la gran promoción, por lo que primero comenzamos a preguntarnos si había demasiados registros, lo que provocó que el disco se agotara.
Aquí hay un fondo: nuestra máquina en línea está configurada con compresión y limpieza automática de registros. Después de que un solo archivo alcanza un cierto tamaño, o el contenido de la máquina alcanza un cierto umbral, se activará automáticamente.
Pero la gran promoción no provocó la limpieza del registro ese día, lo que provocó que el disco de la máquina se agotara por un tiempo.
Después de la investigación, descubrimos que ciertos archivos de registro de la aplicación ocupan mucho espacio en el disco y siguen aumentando.
du -sm * | sort -nr
512 service.log.20201105193331
256 service.log
428 service.log.20201106151311
286 service.log.20201107195011
356 service.log.20201108155838du -sm * | sort -nr: Cuente el tamaño de los archivos en el directorio actual y ordénelos según el tamaño
Entonces, después de comunicarnos con los estudiantes de operación y mantenimiento, decidimos abordarlo con urgencia.
El primer método es limpiar manualmente los archivos de registro. Después de que los estudiantes de operación y mantenimiento inician sesión en el servidor, limpian manualmente algunos archivos de registro menos importantes.
rm service.log.20201105193331Sin embargo, después de ejecutar el comando de limpieza, se descubrió que el uso del disco en la máquina no disminuyó y seguía aumentando.
$df
Filesystem 1K-blocks Used Available Use% Mounted on
/ 62914560 58911440 4003120 93% /
/dev/sda2 62914560 58911440 4003120 93% /home/adminEntonces comenzamos a investigar por qué no se liberó el espacio en el disco después de que se eliminó el registro.A través del comando, encontramos que hay un proceso que aún lee el archivo.
lsof |grep deleted
SLS 11526 root 3r REG 253,0 2665433605 104181296 /home/admin/****/service.log.20201205193331 (deleted)La función de lsof | grep deleted es ver todos los archivos abiertos y filtrar los archivos que se han eliminado
Después de la investigación, este proceso es un proceso SLS, que lee continuamente el contenido del registro de la máquina.
SLS es un servicio de registro de Ali que proporciona funciones integrales de recopilación, limpieza, análisis, visualización y alarma de datos. En pocas palabras, los registros del servidor se recopilarán, conservarán y luego se utilizarán para consultas y análisis.
Todos nuestros logs online son recolectados a través de SLS, por lo que a través del análisis encontramos que no se libera espacio en disco, lo cual está relacionado con la lectura de logs de SLS.
En este punto, básicamente se ha localizado el problema, así que interrumpamos el principio e introduzcamos el conocimiento de fondo detrás de él.
conocimiento de fondo
En el sistema Linux, la eliminación de archivos se controla mediante el número de enlaces. Solo cuando un archivo no tiene ningún enlace, se eliminará.
En términos generales, cada archivo tiene dos contadores de enlaces: i_count e i_nlink, es decir: en el sistema Linux, solo cuando i_nlink e i_count son ambos 0, el archivo se eliminará.
- i_count representa el número de usuarios (o llamados) del archivo actual
- i_nlink representa el número de conexiones de medios (el número de enlaces físicos);
- Se puede entender que i_count es un contador de referencia de memoria e i_nlink es un contador de referencia de disco.
Cuando un archivo es referenciado por un determinado proceso, el número de i_count correspondiente aumentará; cuando se crea el enlace físico del archivo, aumentará el número de i_nlink correspondiente.
En sistemas Linux o Unix, eliminar un archivo a través de rm o un administrador de archivos solo lo desvincula de la estructura de directorios del sistema de archivos. De hecho, reduce el recuento de referencias de disco i_nlink, pero no reduce el número de i_count.
Si un determinado proceso está llamando a un archivo, el usuario usa el comando rm para "eliminar" el archivo. En este momento, el archivo no se puede encontrar a través de comandos de administración de archivos como ls, pero eso no significa que el archivo se haya eliminado del disco. .
Porque todavía hay un proceso ejecutándose con normalidad, leyendo o escribiendo en el archivo, es decir, el archivo no está realmente "eliminado", por lo que el espacio en disco siempre estará ocupado.
Nuestro problema en línea es este principio, porque un proceso está operando en el archivo de registro, por lo que la operación rm no elimina realmente el archivo, por lo que no se libera espacio en el disco.
problema resuelto
Después de comprender el fenómeno del problema en línea y los conocimientos previos relacionados anteriormente, podemos pensar en formas de resolver este problema.
Eso es para encontrar una manera de deshacerse de la referencia de este archivo de registro mediante el proceso SLS, el archivo realmente se puede eliminar y el espacio en disco realmente se puede liberar.
kill -9 11526
$df
Filesystem 1K-blocks Used Available Use% Mounted on
/ 62914560 50331648 12582912 80% /
/dev/sda2 62914560 50331648 12582912 80% /home/adminRecordatorio especial, antes de ejecutar kill -9, debe considerar las consecuencias de la ejecución. Se puede hacer referencia al principio detrás de esto: después de ejecutar kill -9 en el servidor, ¡se me notificará que no vaya al día siguiente!
Posteriormente, después de revisar el juego, encontramos que había dos razones principales para este problema:
- 1. Se imprimen demasiados registros en línea con demasiada frecuencia.
- 2. La velocidad de extracción del tronco SLS es demasiado lenta
Después de un análisis en profundidad, descubrimos que esta aplicación imprimía muchos registros de procesos. Inicialmente, la impresión de registros se utilizaba para facilitar la resolución de problemas en línea o para el análisis de datos. Sin embargo, la cantidad de registros aumentó considerablemente durante el período de promoción, lo que resultó en un rápido aumento en el uso de espacio en disco.
Además, debido a que esta aplicación comparte un proyecto SLS con varias otras aplicaciones grandes, la velocidad de extracción de SLS se ralentiza y el proceso no se puede finalizar.
Posteriormente, también resumimos algunos elementos de mejora Para la segunda pregunta, dividimos la configuración SLS de la aplicación y la administramos de forma independiente.
En cuanto al primer problema, es la política de introducir la degradación del registro durante la gran promoción, una vez que el disco está lleno, el registro se degradará.
Con respecto a la degradación del registro, he desarrollado una herramienta general que empuja dinámicamente el nivel del registro y cambia dinámicamente el nivel de salida del registro en línea a través de la configuración. Y configure la modificación de esta configuración a nuestra plataforma de planes, y realice el procesamiento del plan regular o de emergencia durante el período de gran promoción para evitar este problema.
Las ideas de desarrollo y los códigos relacionados de la herramienta de degradación de registros se compartirán con usted en el próximo artículo.
Pensando
Después de cada gran promoción, encontraremos que la mayoría de los problemas son causados por la acumulación de algunos pequeños problemas poco visibles.
En el proceso de análisis de problemas, a menudo es necesario aplicar muchos conocimientos no relacionados con habilidades de desarrollo, como sistemas operativos, redes de computadoras, bases de datos e incluso conocimientos relacionados con el hardware.
¡Así que siempre pienso que juzgar si un programador es bueno o no depende de su capacidad para resolver problemas!