Tuning Oracle AHF: Resolviendo picos de CPU causados por "Rediscovery"
En la administración de entornos Oracle, el Oracle Autonomous Health Framework (AHF) es una pieza fundamental para el diagnóstico proactivo. Sin embargo, como cualquier herramienta robusta, sus procesos internos pueden impactar en el rendimiento si no están bien ajustados.
Recientemente, investigamos un caso donde el sistema presentaba picos de CPU cíclicos (cada media hora exacta). En esta entrada, detallo cómo identificamos al responsable y el procedimiento para estabilizar el entorno.
1. El hallazgo: Investigando con OSWatcher (OSW)
Todo comenzó analizando los datos históricos de OSWatcher. Al revisar los archivos de procesos (ps), detectamos un patrón recurrente. Varios procesos de Perl ejecutados como root realizaban modificaciones de inventario con el flag -collectall de forma persistente:
[grid@rac-node-001 oswps]$ grep -i collectall *.dat
rac-node-001.internal_ps_25.11.30.2200.dat:root 13603 9521 19 13.6 S 22:09:28 00:00:00 /bin/perl /opt/oracle.ahf/tfa/bin/tfactl.pl directory modify /u01/app/oracle/agent/... -collectall
rac-node-001.internal_ps_25.11.30.2200.dat:root 16113 9521 19 36.2 S 22:10:00 00:00:00 /bin/perl /opt/oracle.ahf/tfa/bin/tfactl.pl directory modify /u01/app/oracle/product/19.26/... -collectall
rac-node-001.internal_ps_25.11.30.2200.dat:root 138557 134853 19 7.2 S 22:39:27 00:00:00 /bin/perl /opt/oracle.ahf/tfa/bin/tfactl.pl directory modify /u01/app/oracle/agent/... -collectall
rac-node-001.internal_ps_25.11.30.2200.dat:root 140654 134853 19 8.7 S 22:39:58 00:00:00 /bin/perl /opt/oracle.ahf/tfa/bin/tfactl.pl directory modify /u01/app/oracle/product/19.26/... -collectall
rac-node-001.internal_ps_25.12.01.1500.dat:root 69691 65697 19 6.1 S 15:09:29 00:00:00 /bin/perl /opt/oracle.ahf/tfa/bin/tfactl.pl directory modify /u01/app/oracle/agent/... -collectall
rac-node-001.internal_ps_25.12.01.1500.dat:root 72082 65697 19 7.3 S 15:10:00 00:00:00 /bin/perl /opt/oracle.ahf/tfa/bin/tfactl.pl directory modify /u01/app/oracle/product/19.26/... -collectall
2. Anatomía del problema: El árbol de procesos
Para entender el origen, mapeamos la jerarquía del demonio de TFA (Trace File Analyzer). Identificamos que el disparador era una tarea de "redescubrimiento" automática:
Estructura del proceso:
TFA Daemon (Java TFAMain): El proceso padre persistente.
Revelando la Jerarquía: ¿Quién consume mi CPU?
Para entender por qué el servidor presentaba picos de carga, no basta con ver un proceso suelto; es necesario entender la relación padre-hijo. Utilizando los datos de OSWatcher (OSW) y rastreando los PIDs (Process IDs) mediante ps -ef, logramos reconstruir el árbol genealógico del culpable.
La Raíz: El Demonio TFA
Todo nace del TFA Daemon (PID 2616695 en nuestro caso), con el proceso Java (oracle.rat.tfa.TFAMain) que corre como root. Este demonio mantiene varios hilos vivos para monitorizar eventos , pero el "ruido" venía de su rama de descubrimiento.
El Descenso: De Java a Perl
Al investigar el PID padre, vimos cómo el demonio invoca una cadena de comandos para realizar el mantenimiento del inventario:
El Iniciador: El demonio lanza un script shell
tfactl rediscover.La Capa Python: Este a su vez llama a un componente empaquetado (
tfactl.egg) que gestiona la lógica de AHF.El Motor Perl: Finalmente, la ejecución recae en scripts de Perl (
tfactl.pl), que es donde se realiza el trabajo pesado de interacción con el sistema de archivos.
El "Fumigador": El proceso collectall
El punto crítico aparece en los procesos hoja (los últimos de la rama). Identificamos múltiples procesos Perl ejecutando: tfactl.pl directory modify <path> -collectall -private
Estos procesos son los que escanean recursivamente directorios críticos como:
El inventario del Agente de Enterprise Manager (
/u01/app/oracle/agent/...).El inventario del Home de la Base de Datos (
/u01/app/oracle/product/19.26/...).Etc.
Representación del Árbol de Ejecución
Así es como se ve la cascada de ejecución que capturamos durante el pico de consumo:
TFA Daemon (PID 2616695) – TFAMain (Java)
└─ sh tfactl rediscover (PID 9325)
└─ python tfactl.egg rediscover (PID 9370)
└─ sh tfactl.tfa rediscover (PID 9485)
└─ tfactl.pl rediscover -mode lite -auto (PID 9521) <-- El "Scheduler"
├─ tfactl.pl directory modify ... -collectall (PID 13603)
├─ tfactl.pl directory modify ... -collectall (PID 16113)
└─ java CommandLine rac-node-001:listtfausers (PID 9617)
3. Comandos útiles de diagnóstico
Durante la resolución, estos fueron los comandos clave para entender qué estaba pasando "bajo el capó":
Consultar la frecuencia actual:
tfactl get rediscoveryInterval(En nuestro caso, devolvió30m, confirmando ejecuciones cada media hora).[root@rac-node-001 ~]# tfactl get rediscoveryInterval .------------------------------------------------------. | rac-node-001 | +----------------------------------------------+-------+ | Configuration Parameter | Value | +----------------------------------------------+-------+ | Rediscovery Interval ( rediscoveryInterval ) | 30m | '----------------------------------------------+-------'Revisar logs de actividad: Los logs de AHF son vitales. Se encuentran en nuestro caso (separación de roles):
/u01/app/grid/oracle.ahf/data/<hostname>/diag/ahf/tfactl.log.Verificar ayuda y límites: En la documentación oficial vemos que el intervalo acepta minutos (
m), horas (h) o días (d), con un máximo de 1 día. Documentación
Conclusión del análisis: Este árbol nos confirmó que no estábamos ante un error o un proceso "zombie", sino ante una tarea de mantenimiento programada de AHF (rediscover -mode lite) que, por configuración por defecto, era demasiado agresiva para nuestro entorno.
4. El desafío de la programación (Scheduler)
Al no existir un comando para deshabilitar el proceso o para fijar una hora exacta (ej. las 03:00 AM), tuvimos que entender el funcionamiento del timer de TFA. El contador es relativo: comienza a contar desde que el servicio se inicia o desde que se modifica el parámetro.
5. La Solución: Sincronizando el intervalo al máximo
Decidimos reducir la frecuencia al mínimo posible estableciendo el intervalo en 24 horas para todo el cluster:
[root@rac-node-001 ~]# tfactl set rediscoveryInterval=24h -c
Successfully set rediscoveryInterval=24h
[root@rac-node-001 ~]# tfactl get rediscoveryInterval
.------------------------------------------------------.
| rac-node-001 |
+----------------------------------------------+-------+
| Configuration Parameter | Value |
+----------------------------------------------+-------+
| Rediscovery Interval ( rediscoveryInterval ) | 24h |
'----------------------------------------------+-------'
Nota importante: Al aplicar el cambio con el parámetro -c (cluster-wide), TFA lanza inmediatamente un rediscover sincronizado en todos los nodos. Esto es ideal porque nos permite "resetear" el contador de 24 horas en el momento exacto en que ejecutamos el comando.
6. Verificación en los Logs
Confirmamos la ejecución en los logs de ambos nodos justo tras el cambio: [2026-01-21 10:04:40 CET] INFO - Executing command ... rediscover -mode lite -auto [2026-01-21 10:04:48 CET] INFO - Process completed execution with exit code 0
Conclusión
Si sufres picos de CPU causados por AHF, no intentes deshabilitarlo, busca el ajuste para la métrica concreta.
La estrategia ganadora es:
Elegir una ventana de baja carga.
Configurar
rediscoveryInterval=24h -c.Si necesitas una hora fija, reinicia el servicio TFA (
tfactl restart) en ese horario.
Con esto, hemos pasado de 48 picos de CPU diarios a solo 1, manteniendo el sistema monitorizado pero estable.
