Grid Infrastructure – Alto consumo de CPU por culpa de systemd-udevd
¡Qué sorpresa! Otra vez escribiendo sobre clusterware, grid infrastructure y problemas que van surgiendo relacionados con esta reciente instalación que realicé.
Esta vez se ha detectado un gran consumo de CPU (a veces del 100%) por el proceso systemd-udevd.
No teníamos muy claro qué ocurría, ni a qué era debido. Ha tocado investigar un poco, hasta llegar a una solución final.
Para ponernos en contexto, tenemos un servidor Linux con RedHat 8, Grid Infrastructure 19c con la Release Update 19.23 y una base de datos 19c, pero esta con Release Update 19.12.
La base de datos es un Dataguard que tiene la Primary y una Standby.
El Problema
Como os venía comentando en las líneas anteriores, el problema está en que hay un consumo de CPU demasiado elevado, a veces casi el 100% con una sola base de datos, lo cual parece muy extraño, ya que tiene suficientes cores como para estar mucho más relajada.
Vemos la información del comando ‘top’
Prestemos atención a la parte superior. Concretamente en la tercera línea.
Vemos que hay un consumo del 20% por parte del procesamiento en modo usuario y un 11% por parte del procesamiento en modo sistema.
De este consumo, hay tres procesos ocupando las primeras posiciones de systemd-udevd. Uno de ellos usando el 95,4%.
Comprobaciones previas
Como buen informático, DBA, o cualquier otro cargo tecnológico, ¿Qué es lo primero que haces cuando aparece un error o hay algún problema?Preguntar a ChatGPT Buscar en San Google.
Lo de udevd ya nos da una pista de que tiene algo que ver con almacenamiento. Aquí el almacenamiento con GRID y Base de Datos va controlado por Oracle ASM.
En una primera búsqueda, encontramos relación con los conceptos AFD y ACFS.
Entre los primeros resultados, aparece una nota oficial de Oracle en la que está la matriz de compatibilidad de estas herramientas con las diferentes versiones del sistema operativo y las releases updates de Oracle que tenemos instaladas.
ACFS and AFD Support On OS Platforms (Certification Matrix). (Doc ID 1369107.1)
Buscamos en la parte de Oracle 19c y Red Hat Linux 8 y tenemos la siguiente información:
Comprobamos nuestra versión correcta de Red Hat y el kernel:
[oracle@servidor1 ]$ uname -a
Linux servidor1 4.18.0-553.el8_10.x86_64 #1 SMP Fri May 10 15:19:13 EDT 2024 x86_64 x86_64 x86_64 GNU/Linux
[oracle@servidor1 ]$ cat /etc/*release
NAME="Red Hat Enterprise Linux"
VERSION="8.10 (Ootpa)"
Red Hat Enterprise Linux release 8.10 (Ootpa)
Tenemos Red Hat 8.10 y el kernel 4.18.0-553. Esto quiere decir que tenemos que fijarnos en la primera fila de la tabla. Tanto en ACFS como en AFD, se nos exige como versión mínima de release de Grid Infrastructure la 19.23, justo la que tenemos instalada.
Podemos descartar cualquier problema de compatibilidad.
Causa del problema
Siguiendo con la búsqueda, afinamos un poco más en Google. Añadimos al nombre del proceso «high CPU utilization». Y… ¡BINGO! 🤹🏼 Aparece un resultado de Red Hat que nos podría ayudar.
systemd-udev is causing high CPU utilization on RHEL with Oracle Database server
* Si no tienes cuenta de Red Hat, es posible que no puedas ver la información.
Lo que dice Red Hat, es que en estos casos, Oracle indica a sus clientes que desactiven el Soft Filtering de AFD para solucionar el problema.
Pero esto no es algo que Red Hat se haya inventado, ponen como referencia otra nota de Oracle, que explica un poco la causa del problema y la solución a este.
AFD: High CPU Usage by ‘systemd-udevd’ When Using ASMFD Soft-Filtering (Doc ID 3000507.1)
AFD utiliza un filtrado suave (soft filtering) que se logra configurando el disco en modo read only y el bit se cambia a read write durante las escrituras confiables.
Utiliza la API set_disk_ro() desde dentro del núcleo para lograr esto. Cuando se llama a «set_disk_ro()», genera un evento UDEV en cada alternancia de read only que puede causar una inundación de eventos UDEV que finalmente conducen a que systemd-udevd se ejecute al 100%.
El soft filtering es una nueva funcionalidad introducida por Oracle a partir de la versión 19.11. (recordad que nosotros tenemos GI 19.23 y base de datos 19.12)
Solución
La solución que propone Oracle, y también la que propone Red Hat basandose en las notas de Oracle, es desactivar el Soft Filtering como usuario root.
Consultamos el estado actual:
[root@servidor 1 ]# /app/oracle/product/19.0.0/bin/asmcmd afd_state
ASMCMD-9526: The AFD state is 'LOADED' and filtering is 'ENABLED' on host 'servidor1'
[root@servidor1 ]# /app/oracle/product/19.0.0/bin/asmcmd afd_lsdsk
--------------------------------------------------------------------------------
Label Filtering Path
================================================================================
GRID_DISK1 ENABLED /dev/sdc
GRID_DISK2 ENABLED /dev/sde
GRID_DISK3 ENABLED /dev/sddDesactivamos el Soft Filtering de AFD:
[root@servidor1 ]# /app/oracle/product/19.0.0/bin/asmcmd afd_filter -dConsultamos como ha quedado después de desactivarlo:
[root@servidor1 ]# /app/oracle/oracrs/product/19.0.0/bin/asmcmd afd_state
ASMCMD-9526: The AFD state is 'LOADED' and filtering is 'DISABLED' on host 'servidor1'
[root@servidor1 ]# /app/oracle/product/19.0.0/bin/asmcmd afd_lsdsk
--------------------------------------------------------------------------------
Label Filtering Path
================================================================================
GRID_DISK1 DISABLED /dev/sdc
GRID_DISK2 DISABLED /dev/sde
GRID_DISK3 DISABLED /dev/sdd
[root@ma29vbd041dydah oracrs]# cat /etc/oracleafd.conf|grep afd_filtering
afd_filtering=disableComprobaciones posteriores
Tras desactivarlo, vamos a comprobar de nuevo la CPU y observar qué ocurre.
Fijaos qué diferencia, y como se observa la bajada de consumo al desactivar el Soft Filtering pasadas las 14:30.
Seguimos luchando y peleando con Grid y Red Hat 8. 💪🏼
Cada batalla es un nuevo aprendizaje. 🧑🏼🎓