Directorio de artículos
- I. Introducción
- 2. Problemas comunes en línea de los servicios Java
- 3. Ubicación del problema
- 4. Análisis de registros
- 5. Análisis de casos
I. Introducción
El lenguaje Java es actualmente el lenguaje más utilizado en Internet. Como programador de Java, cuando el negocio es relativamente estable, excepto la codificación, la mayor parte del tiempo (70% ~ 80%) se utilizará para solucionar problemas de ráfagas o ciclos. Problemas sexuales en línea.
Debido a errores de la aplicación empresarial (ya sea en sí misma o la introducción de bibliotecas de terceros ), razones ambientales, problemas de hardware, etc., las fallas/problemas en los servicios en línea de Java son casi inevitables. Por ejemplo, los fenómenos comunes incluyen el tiempo de espera de algunas solicitudes, los usuarios obviamente sienten que el sistema está bloqueado, etc.
Tan pronto como el problema en línea es muy obvio por la apariencia del sistema, aún es difícil investigar la causa de la ocurrencia, por lo que ha causado muchos problemas a los estudiantes de pruebas de desarrollo o de operación y mantenimiento.
La resolución y localización de problemas en línea requiere ciertas habilidades o reglas de experiencia. Si el solucionador de problemas tiene una comprensión más profunda del sistema empresarial, será relativamente más fácil de localizar.
En cualquier caso, dominar las ideas de solución de problemas en línea de los servicios Java y solucionar de manera competente herramientas/comandos/plataformas comunes son habilidades prácticas que todo programador Java avanzado debe dominar.
2. Problemas comunes en línea de los servicios Java
Desde la perspectiva de la apariencia del sistema, los problemas en línea de todos los servicios Java se pueden resumir en cuatro aspectos: CPU, memoria, disco y red. Por ejemplo, el pico de uso de la CPU se dispara repentinamente, desbordamiento (pérdida) de memoria, disco lleno, tráfico de red anormal, FullGC y otros problemas.
Con base en estos fenómenos, podemos dividir los problemas en línea en dos categorías: excepciones del sistema y excepciones de servicios comerciales.
1. Excepción del sistema
Las anomalías comunes del sistema incluyen: uso elevado de la CPU, alta frecuencia de cambio de contexto de la CPU, disco lleno, E/S de disco frecuentes, tráfico de red anormal (demasiadas conexiones) y valor bajo a largo plazo de la memoria disponible del sistema (lo que resulta en un problema de destrucción del espacio). etcétera.
Estos problemas se pueden obtener a través de herramientas como top (cpu), free (memoria), df (disco), dstat (tráfico de red), pstack, vmstat, strace (llamada inferior al sistema) y otras herramientas para obtener datos sobre anomalías del sistema.
Además, si no hay ninguna razón más estúpida para el fenómeno anormal después de verificar el sistema y la aplicación, también puede ser causado por la infraestructura externa, como la propia plataforma IAAS.
Por ejemplo, ocasionalmente pueden ocurrir algunas fallas en la red del operador o en el proveedor de servicios en la nube. Si su referencia solo ocurre cuando el servicio no está disponible cuando los usuarios de un área determinada, como Guangdong, acceden al sistema, es muy probable que se deba a estos motivos. .
Hoy, el sistema comercial de Alibaba Cloud implementado por nuestra empresa en la región del este de China de repente no pudo brindar servicios normales a los usuarios en la región de Guangdong al mediodía. Después de varias investigaciones en el sistema, no se encontraron problemas.
Finalmente, al preguntar sobre el anuncio de Alibaba Cloud, se descubrió que el motivo era "una situación anormal de pérdida de paquetes de red o un mayor retraso en el acceso a los recursos de Internet en el este de China (incluida la región Alibaba Cloud East China 1) desde las líneas de telecomunicaciones en Guangdong. "
https://help.aliyun.com/noticelist/articleid/20724342.html?spm=5176.789004748.n2.6.LeTsMp
2. Servicio comercial anormal
Las anomalías comunes de los servicios comerciales incluyen: alto volumen de PV, llamadas de servicio anormales que consumen mucho tiempo, punto muerto de subprocesos, problemas de concurrencia de subprocesos múltiples, GC completo frecuente, escaneo de ataques de seguridad anormales, etc.
3. Ubicación del problema
Generalmente utilizamos el método de eliminación para localizar problemas del servicio en línea desde una investigación externa hasta una investigación interna.
En primer lugar, debemos descartar las fallas que puedan ser causadas por otros procesos (excepto el proceso principal);
Luego solucionar posibles fallos causados por las aplicaciones empresariales;
Puede considerar si la falla es causada por el operador o el proveedor de servicios en la nube.
1. Proceso de posicionamiento
1.1 Proceso de solución de problemas de excepciones del sistema
1.2, proceso de solución de problemas de aplicaciones comerciales
2. Herramientas de análisis de rendimiento de uso común en Linux
Las herramientas de análisis de rendimiento comúnmente utilizadas en Linux incluyen: superior (cpu), libre (memoria), df (disco), dstat (tráfico de red), pstack, vmstat, strace (llamada inferior al sistema), etc.
2.1 CPU
La CPU es un indicador de monitoreo importante del sistema, que puede analizar el estado operativo general del sistema. Los indicadores de monitoreo generalmente incluyen colas de ejecución, uso de CPU y cambio de contexto.
El comando superior es una herramienta de análisis del rendimiento de la CPU de uso común en Linux, que puede mostrar el uso de recursos de cada proceso en el sistema en tiempo real y, a menudo, se usa para el análisis del rendimiento del lado del servidor.
El comando superior muestra el uso de CPU de cada proceso y el uso general de CPU se ordena de mayor a menor para mostrar el resultado. Entre ellos, Load Average muestra la carga promedio del sistema en los últimos 1 minuto, 5 minutos y 15 minutos, y los valores en la figura anterior son 2,46, 1,96 y 1,99.
Generalmente nos centramos en el proceso con mayor uso de CPU, que normalmente es el proceso principal de nuestra aplicación. Debajo de la séptima línea: seguimiento del estado de cada proceso.
PID: ID del proceso
USUARIO: propietario del proceso
PR: prioridad del proceso
NI: buen valor. Un valor negativo indica alta prioridad y un valor positivo indica baja prioridad
VIRT: la cantidad total de memoria virtual utilizada por el proceso, en kb. VIRT=SWAP+RES
RES: El tamaño de la memoria física utilizada por el proceso y no intercambiada, en kb. RES=CODE+DATA
SHR: tamaño de memoria compartida, unidad kb
S: estado del proceso. D=suspensión ininterrumpida R=en ejecución S=suspensión T=rastreo/detención Z=proceso zombie
%CPU: % de tiempo de CPU desde la última actualización %
MEM: % de memoria física utilizada por el proceso
TIME+: CPU utilizada por el proceso Tiempo total, unidad 1/100 segundo
COMANDO: nombre del proceso
2.2 Memoria
La memoria es una referencia importante para solucionar problemas en línea. Los problemas de memoria suelen ser la causa del uso elevado de la CPU.
Memoria del sistema: libre es para mostrar el uso de memoria actual, -m significa M bytes para mostrar el contenido.
libre -m
Algunas descripciones de parámetros:
total Memoria total: 3790 M
usados Memoria usada: 1880 M
libres Memoria libre: 118 M
compartidas Actualmente obsoleto, siempre 0
buffers Memoria caché de buffer: 1792 M
2.3 Disco
df-h
du -m /ruta
2.4 Red
El comando dstat puede integrar tareas que pueden realizar herramientas como vmstat, iostat y netstat.
dstat -c estado de la CPU -d lectura y escritura del disco -n estado de la red -l mostrar la carga del sistema -m mostrar el estado de la memoria similar -p mostrar la información del proceso del sistema -r mostrar el estado de E/S del sistema
2.5 Otros
vmstat:
vmstat 2 10-t
vmstat es la abreviatura de Virtual Meomory Statistics (estadísticas de memoria virtual), es una herramienta de monitoreo del sistema en tiempo real. Este comando accede a estos datos utilizando la subrutina knlist y el controlador de pseudodispositivo /dev/kmen, y la información de salida se imprime directamente en la pantalla.
Utilice el comando vmstat 2 10 -t para ver la situación de io (el primer parámetro es el intervalo de tiempo de muestreo en segundos y el segundo parámetro es el número de tiempos de muestreo).
r representa la cola en ejecución (es decir, cuántos procesos están realmente asignados a la CPU) y b representa el proceso bloqueado.
El tamaño utilizado de la memoria virtual swpd. Si es mayor que 0, significa que la memoria física de su máquina es insuficiente. Si no es la causa de la pérdida de memoria del programa, entonces debe actualizar la memoria o migrarla. consumir tareas a otras máquinas.
Libre El tamaño de la memoria física libre, la memoria total de mi máquina es 8G y el resto 3415M.
buff El sistema Linux/Unix se utiliza para almacenar lo que hay en el directorio, permisos, etc. caché, mi máquina local probablemente ocupa más de 300 M de caché de archivos
si
la columna indica que el disco se transfiere a la memoria, es decir, el número de memoria que ingresa al área de intercambio de memoria;
La columna so indica la cantidad transferida de la memoria al disco, es decir, la cantidad del área de intercambio de memoria que ingresa a la memoria.
Generalmente, los valores de si y so son ambos 0. Si los valores de si y so no son 0 durante mucho tiempo, significa que la memoria del sistema es insuficiente y es necesario considerar si se debe aumentar la memoria del sistema.
bi La cantidad total de datos leídos desde el dispositivo de bloque (disco de lectura) (kb por segundo)
bo La cantidad total de datos escritos en el dispositivo de bloque (disco de escritura) (kb por segundo)
Cuando se lee y escribe el disco aleatorio, el Cuanto mayores sean los dos valores ((más allá de 1024k), se puede ver que el valor de la CPU esperando IO será mayor. El valor de referencia de bi+bo establecido aquí es 1000. Si excede 1000 y el valor de wa es relativamente grande , Significa que el cuello de botella en el rendimiento de IO del disco del sistema
en cada El número de interrupciones de la CPU por segundo, incluida la interrupción de tiempo
cs (Context Switch Context Switch)
strace: strace se utiliza a menudo para rastrear llamadas al sistema y señales recibidas durante la ejecución del proceso.
strace -cp tid strace -T -p tid -T muestra el tiempo empleado en cada llamada. -p pid rastrea el proceso pid especificado. -v genera todas las llamadas al sistema. Algunas llamadas están relacionadas con variables de entorno, estado, entrada y salida, etc. Debido al uso frecuente, no se genera de forma predeterminada -V Muestra información de la versión strace.
3. Herramienta de problemas de posicionamiento JVM
Muchas herramientas valiosas de línea de comandos se proporcionan de forma predeterminada en el directorio bin del directorio de instalación de JDK. El tamaño de cada herramienta pequeña es básicamente relativamente pequeño, porque estas herramientas son solo un paquete simple de jdk\lib\tools.jar.
Entre ellos, los comandos más utilizados al localizar y solucionar problemas incluyen: jps (proceso), jmap (memoria), jstack (hilo), jinfo (parámetro), etc.
jps: consulta toda la información del proceso JAVA de la máquina actual;
jmap: genera el estado de la memoria de un proceso java (como: esos objetos y su cantidad, etc.);
jstack: imprime la información de la pila de subprocesos de un subproceso Java;
jinfo: se utiliza para ver los parámetros de configuración de jvm.
3.1, comando jps
jps se utiliza para generar todos los ID de proceso iniciados por el usuario actual. Cuando se encuentra una falla o problema en línea, jps se puede usar para localizar rápidamente el ID de proceso Java correspondiente.
El parámetro jps -l -m -m -l -l se utiliza para generar la ruta completa de la clase de inicio principal
Por supuesto, también podemos utilizar el comando de consulta del estado del proceso proporcionado por Linux, por ejemplo:
ps -ef | grep gato
También podemos obtener rápidamente la identificación del proceso del servicio Tomcat.
3.2, comando jmap
jmap -heap pid Muestra el proceso actual JVM montón de generación joven, generación anterior, generación permanente y otra información, algoritmo utilizado por GC y otra información jmap -histo :live {pid} | head -n 10 Muestra el tamaño de todos los objetos contenidos en memoria del proceso actual jmap -dump:format=b,file=/usr/local/logs/gc/dump.hprof {pid} genera el estado del montón de la memoria actual en formato binario y luego lo importa a herramientas como MAT para
jmap (Java Memory Map) es una herramienta que puede generar todos los objetos en la memoria e incluso puede generar el montón en la VM como texto en binario.
jmap -montón pid：
jmap -heap pid Genera información como la nueva generación, la generación anterior y la generación persistente del montón JVM del proceso actual y el algoritmo utilizado por GC.
jmap puede ver la asignación de memoria y el uso del proceso JVM, el algoritmo GC utilizado y otra información.
jmap -histo:live {pid} | cabeza -n 10:
jmap -histo:live {pid} | head -n 10 Genera el tamaño de todos los objetos contenidos en la memoria del proceso actual
Genere el número (instancias) y el tamaño (bytes) de todas las instancias de objetos en la memoria del proceso actual. Si hay una anomalía en el número y el tamaño de una instancia de objeto comercial, puede haber una pérdida de memoria o un diseño comercial irrazonable.
jmap-volcado:
jmap -dump:format=b,file=/usr/local/logs/gc/dump.hprof {pid}
-dump:format=b,file= Envíe el estado del montón de la memoria actual al archivo correspondiente en formato binario y luego analice en profundidad el estado de la memoria actual con herramientas de análisis de memoria como MAT.
Generalmente, necesitamos agregar parámetros a la JVM -XX:+Heap Dump On Out Of Memory Error OOM para garantizar que la JVM pueda guardar y volcar la imagen de memoria actual cuando ocurre OOM en la aplicación.
Por supuesto, si decide volcar la memoria manualmente, la operación de volcado ocupará un cierto intervalo de tiempo de CPU, recursos de memoria, recursos de disco, etc., por lo que traerá ciertos efectos negativos.
Además, el archivo de volcado puede ser relativamente grande. Generalmente, podemos considerar usar el comando zip para comprimir el archivo, a fin de reducir la sobrecarga de ancho de banda al descargar el archivo.
Después de descargar el archivo de volcado, debido al gran tamaño del archivo de volcado, puede hacer una copia de seguridad del archivo de volcado en una ubicación específica o eliminarlo directamente para liberar el espacio ocupado por el disco.
3.3 comando jstack
printf '%x\n' tid --> ID de hilo de decimal a hexadecimal (hilo de navegación) %d decimal jstack pid | grep tid -C 30 --color ps -mp 8278 -o THREAD,tid, time | head -n 40
Un proceso Java tiene un alto uso de CPU y queremos ubicar el subproceso con el mayor uso de CPU.
(1) Utilice el comando superior para averiguar el pid del subproceso que representa la CPU más alta
arriba -Hp {pid}
(2) El ID de subproceso con la tasa de ocupación más alta es 6900, que se convierte a formato hexadecimal (porque los subprocesos nativos de Java se generan en formato hexadecimal)
imprimirf '%x\n' 6900
(3) Utilice jstack para imprimir la información de la pila de llamadas del hilo de Java
jstack 6418 | grep '0x1af4' -A 50 --color
3.4, comando jinfo
Ver el valor de un parámetro JVM jinfo -flag ReservedCodeCacheSize 28461 jinfo -flag MaxPermSize 28461
3.5, comando jstat
jstat -gc pid jstat -gcutil `pgrep -u admin java`
4. Herramienta de análisis de memoria MAT
4.1 ¿Qué es MAT?
MAT (Memory Analyzer Tool), una herramienta de análisis de memoria basada en Eclipse, es una herramienta de análisis de montón JAVA rápida y rica en funciones que puede ayudarnos a encontrar pérdidas de memoria y reducir el consumo de memoria.
Utilice la herramienta de análisis de memoria para analizar muchos objetos, calcular rápidamente el tamaño de los objetos en la memoria, ver quién impide que el recolector de basura recicle y puede ver visualmente los posibles resultados a través del informe Objeto.
El gráfico circular de la derecha muestra los objetos más grandes en la instantánea actual. Haga clic en el histograma en la barra de herramientas para ver la información de clase del montón actual, incluido el número de objetos de la clase, montón poco profundo (montón poco profundo) y montón profundo (montón retenido).
El montón poco profundo representa el tamaño de la memoria ocupada por una estructura de objeto. El montón profundo representa el tamaño de memoria que realmente se puede liberar después de reciclar un objeto.
1) El árbol dominador
Enumera los objetos más grandes del montón. Los nodos de segundo nivel representan objetos a los que hacen referencia los nodos de primer nivel. Cuando los objetos de primer nivel se reciclan, estos objetos también se reciclarán.
Esta herramienta puede ayudarnos a localizar referencias entre objetos y dependencias de referencia durante la recolección de basura.
2）Camino a las raíces de GC
Los objetos retenidos por la JVM, como el objeto de subproceso que se está ejecutando actualmente, y los objetos cargados por el cargador de clases del sistema se denominan GC Roots, y la cadena de referencia de un objeto a GC Roots se denomina Ruta a GC Roots.
Al analizar la ruta a GC Roots, puede descubrir el problema de pérdida de memoria de JAVA: cuando el programa no accede al objeto, todavía hay una ruta de referencia al objeto.
4. Análisis de registros
1. Análisis de registros de GC
1.1, análisis detallado del registro de GC
Los registros de GC de la máquina virtual Java son información de registro importante para localizar problemas. La GC frecuente provocará una disminución del rendimiento de la aplicación, un mayor tiempo de respuesta e incluso la indisponibilidad del servicio.
-XX:+PrintGCDetails -XX:+PrintGCDateStamps -Xloggc:/usr/local/gc/gc.log -XX:+UseConcMarkSweepGC
Podemos agregar -XX:+PrintGCDetails a los parámetros de inicio de la aplicación Java para generar registros de GC detallados, y también se pueden agregar otros parámetros auxiliares, como -Xloggc para especificar la dirección del archivo de registro de GC. Si su aplicación no ha habilitado este parámetro, agréguelo la próxima vez que reinicie.
La imagen de arriba es una captura de pantalla del registro de GC de una aplicación en línea en un estado de ejecución estable.
2017 - 12 - 29 T18: 25 : 22.753 + 0800 : 73143.256 : [GC2017- 12 - 29 T18: 25 : 22.753 + 0800 : 73143.257 : [ParNuevo: 559782 K -> 1000 K ( 629120 K ), 0,0135760 segundos] 825452 K -> 266673 K ( 2027264 K ), 0,0140300 segundos] [ Veces : usuario = 0,02sys= 0.00 , real= 0.02 segs]
[ 2017 - 12 - 29 T18: 25 : 22.753 + 0800 : 73143.256 ]: Este GC ocurrió a los 73143.256 segundos desde que se inició JVM.
[ParNew: 559782 K -> 1000 K ( 629120 K ) , 0,0135760 segundos]: GC para la nueva generación, utilizando el recolector ParNew, 559782 K es el tamaño de la nueva generación antes del reciclaje, 1000 K es el tamaño de la nueva generación después del reciclaje, 629120 K es el tamaño total de la memoria asignada por Nueva generación actual, 0,0135760 segundos Indica que esta recuperación de nueva generación tarda 0,0135760Segundos
[ 825452 K -> 266673 K ( 2027264 K ), 0,0140300 segundos]: 825452 K es el tamaño de la memoria del montón recuperada, 266673 K es el tamaño de la memoria después del montón recuperado, 2027264 K es el tamaño total de la actual memoria de montón, 0,0140300 segundos significa que el tiempo total consume 0,0140300 segundos
[ Tiempos : usuario= 0,02 sys= 0,00 , real= 0,02 segundos]: el estado del usuario tarda 0,02 segundos, el estado del sistema tarda 0,00 , el tiempo real tarda 0,02 segundos
Ya sea un GC menor o un GC completo, nos centramos principalmente en el consumo de tiempo real de la recuperación de GC, como real = 0,02 segundos, que es el tiempo de parada mundial. Si el tiempo es demasiado largo, afectará gravemente la rendimiento de la aplicación.
1.2, análisis de registros de GC de CMS
Concurrent Mark Sweep (CMS) es un recolector de basura de antigua generación. Como puede verse por el nombre (Mark Sweep), el recolector CMS se implementa mediante el algoritmo "mark-clear", que se divide en seis pasos:
Marca inicial (marca inicial STW);
marcado concurrente;
Prelimpieza simultánea;
observación (observación STW);
barrido simultáneo;
Reinicio simultáneo.
Entre ellos, se requiere "Stop the World" para la marca inicial (marca inicial STW) y el comentario (observación STW).
Marca inicial : En esta etapa, la máquina virtual necesita detener la tarea que se está ejecutando, el nombre oficial es STW (Stop The Word). Este proceso comienza desde el "objeto raíz" de la recolección de basura y solo escanea y marca los objetos que pueden asociarse directamente con el "objeto raíz".
Entonces, aunque este proceso detuvo toda la JVM, se completó rápidamente.
Marcado concurrente : esta fase sigue a la fase de marcado inicial y continúa rastreando el marcado hacia abajo sobre la base del marcado inicial. En la fase de marcado concurrente, el hilo de la aplicación y el hilo de marcado concurrente se ejecutan al mismo tiempo, por lo que el usuario no experimentará una pausa.
Limpieza previa concurrente : la fase de limpieza previa concurrente sigue siendo concurrente. En esta etapa, la máquina virtual busca objetos que hayan ingresado recientemente a la generación anterior durante la fase de marcado concurrente (algunos objetos pueden promoverse de la nueva generación a la generación anterior, o algunos objetos se pueden asignar a la generación anterior).
Al volver a escanear, se reduce el trabajo de "volver a marcar" en la siguiente etapa, porque la siguiente etapa será Stop The World.
Observación : esta fase pausa la máquina virtual y el subproceso recopilador escanea los objetos restantes en el montón de CMS. El escaneo funciona desde el "objeto siguiente" y funciona en asociaciones de objetos.
Limpieza concurrente : Limpiar objetos basura. En esta etapa, el subproceso del recopilador y el subproceso de la aplicación se ejecutan al mismo tiempo.
Restablecimiento concurrente : en esta fase, restablezca la estructura de datos del recolector de CMS y espere la siguiente recolección de basura.
cms solo hace una breve pausa en la ejecución de la aplicación durante todo el proceso de recopilación. Este recopilador se puede usar configurando en el parámetro JVM -XX:UseConcMarkSweepGC
CMS reduce el número de paradas del mundo, lo que inevitablemente alarga el tiempo total de GC.
El número de GC completo se refiere al número de paradas del mundo, por lo que un CMS al menos aumentará el número de GC completo en +2, porque tanto la marca inicial como la observación del CMS detendrán el mundo, que se registra como 2 veces. Y es posible que CMS no pueda volver a activar un GC completo.
La imagen de arriba es una captura de pantalla del registro de GC de una aplicación en línea en el estado de CMS GC.
Si domina el proceso de recolección de basura de CMS, entonces debería poder comprender fácilmente el registro de GC anterior, por lo que no lo explicaré en detalle aquí.
Además, es posible que el CMS tampoco realice la recolección de basura.
Las excepciones son:
1) Si la promoción falla, entonces GC completo:
[La promoción falló: memoria insuficiente en el área de supervivencia, el objeto ingresa a la generación anterior y, en este momento, la generación anterior todavía no tiene memoria para acomodar el objeto, lo que provocará un GC completo]
2) Si falla el modo concurrente, entonces GC completo:
[Error en el modo concurrente: la velocidad de recuperación del CMS es lenta. Antes de que se complete el CMS, la vejez ya está llena, lo que provocará un GC completo]
3) CMS GC frecuente:
[La memoria es escasa, la vieja generación está llena durante mucho tiempo]
2. Registro comercial
Además de prestar atención a las excepciones del sistema y las excepciones comerciales, los registros comerciales también deben prestar atención a la ejecución del servicio que requiere mucho tiempo. Si no existe un mecanismo como la fusión para llamadas de servicio que demoran demasiado, fácilmente afectará el rendimiento de la aplicación. degradación o indisponibilidad del servicio. La indisponibilidad del servicio es muy fácil. conduce a una avalancha.
Lo anterior es la situación de llamada de una determinada interfaz, aunque la mayoría de las llamadas no tienen excepciones, el tiempo de ejecución es relativamente largo.
grep '[0-9]{3,}ms' *.log
Encuentre el método dao que requiere más de 3 dígitos para llamar, cambie de 3 a 4, tiene más de 4 dígitos
Actualmente, las aplicaciones de Internet casi adoptan una arquitectura distribuida, pero no se limitan a marcos de servicios, middleware de mensajes, cachés distribuidos, almacenamiento distribuido, etc.
¿Cómo se pueden agregar estos registros de aplicaciones para su análisis?
En primer lugar, necesita un sistema de seguimiento de llamadas de enlace distribuido, que agregue todos los registros transmitiendo de forma transparente traceId y rpcId entre subprocesos del sistema y archivos en línea, como Eagle Eye de Taobao, Spring Cloud Zipkin, etc.
5. Análisis de casos
Ubicación del problema de uso elevado de CPU
Según el proceso de posicionamiento, en primer lugar se descartan los problemas a nivel del sistema.
Utilice top -Hp 6814 para generar el uso de CPU de todos los subprocesos cuyo ID de proceso es 6814 y descubra que el uso de un determinado subproceso es relativamente alto y que existen algunas excepciones.
printf '%x\n' 2304 # Genera el pid jstack hexadecimal del ID del hilo | grep '0x900' -C 30 --color
El registro de salida muestra que el hilo ha estado en el estado de E/S con mysql:
Utilice jmap -dump:format=b,file=/usr/local/logs/gc/dump.hprof {pid} para generar el estado del montón de la memoria actual en formato binario y luego importarlo a herramientas como MAT para su análisis. .
Como se muestra en la figura siguiente, haga clic en el árbol dominador de MAT para descubrir que hay una gran matriz de objetos y que la cantidad de objetos de instancia es más de 300,000.
Después del análisis, se descubre que cada objeto en la matriz es un objeto comercial central. Nuestro sistema comercial tiene un hilo de tareas programado que accederá a todos los registros en una determinada tabla comercial en la base de datos.
Luego se carga en la memoria y luego se procesa, por lo que la memoria está escasa y la CPU se dispara repentinamente. El escenario ha sido rediseñado desde que se descubrió este problema.