Cómo solucionar problemas de valores de procesamiento de CTD con picos o en alto rendimiento de POW del plano de datos de depuración >

> debug dataplane pow performance
func                                  max-μs   avg-μs        count     total-μs  ac-max-μs  ac-avg-μs         ac-count      ac-total-μs
sml_vm                                     0      276491782.0  0            0         65        1.1           312208           369019
ctd_token                                  0      36.0           27197221  0        180       20.8            18000           374440
detector_run_p1                            0      0.0            0            0         66        4.9             8509            42053
detector_run_p2                            0      0.0            0            0         27        1.5             8786            13669
regex_lookup                               0      0.0            0            0       1093        7.0            11494            81464

• PAN-os
• CTD (Detección de contenido y amenazas)

• Se introdujo un cierto flujo de tráfico nuevo que es grande o pesado en el motor de inspección del firewall, como: unknown-udp, unknown-tcp, ms-ds-smb, mssql-db, etc.
• Una cantidad o tasa anormalmente alta de un tipo de tráfico más pesado pasa a través del firewall, como: unknown-udp, unknown-tcp, ms-ds-smb, mssql-db, etc.
• Todo o una gran cantidad de tráfico pasa por una regla de permiso de política de seguridad con perfiles de seguridad "estrictos" adjuntos (especialmente cuando la cantidad de tráfico se acerca al rendimiento y la capacidad máximos de ese modelo, en este caso, se esperaría que sml_vm, ctd_token, detector_run_p1 y detector_run_p2 sean altas).
• Todo o la mayoría del tráfico pasa por una única regla de perfil de seguridad amplia que tiene muchos perfiles de seguridad pesados o estrictos configurados, especialmente si hay grandes cantidades de tráfico no clasificado (unknown-udp, unknown-tcp) o tráfico de alta velocidad de datos (ms-ds-smb, mssql-db, etc.) que pasa a través del firewall
• Se configuró una firma/objeto de URL personalizado ineficiente, aplicación personalizada o amenaza personalizada que utiliza demasiados comodines, no usa nada más que un solo comodín, es demasiado amplio, etc. (Esta configuración incorrecta a menudo hará que la función regex_lookup se eleve específicamente). Para resolver esto, quite los comodines o patrones ineficientes que afecten al rendimiento en objetos de filtrado de URL, aplicaciones personalizadas o firmas personalizadas; consulte El carácter comodín anidado(*) en las URL puede afectar gravemente al rendimiento para obtener más detalles.

1. Tome una línea base de estos valores antes de que ocurriera el problema (o verifique los valores históricos).Si los valores actuales para sml_vm, ctd_token, detector_run_p1 y detector_run_p2 son mucho más altos que los valores anteriores vistos, entonces podrían ser los culpables del problema de alta CPU o tráfico. Si los valores actuales son aproximadamente los mismos que los valores antiguos cuando el problema no estaba ocurriendo, entonces podrían no ser el culpable o la causa raíz del problema. Si los valores son anormalmente más altos que los valores de línea base antes de que comenzara a producirse el problema, continúe con el paso 2 a continuación.
2. Identifique qué nuevo flujo de tráfico (por IP de origen, puerto de origen, IP de destino, puerto de destino, aplicación) se introdujo y que comenzó a causar que estos valores aumentaran
   1. Vaya a la ficha ACC > Actividad de red > ver los gráficos Actividad IP de origen, Actividad IP de destino y Uso de aplicaciones
   2. Revise y evalúe cualquier flujo de tráfico en los gráficos anteriores que se destaque como valores atípicos que ocupan una gran cantidad de: bytes, sesiones, velocidad de paquetes, etc. (especialmente los nuevos flujos de tráfico que han aparecido solo desde que comenzó a ocurrir el problema). Busque un flujo de tráfico o aplicación específica que aparezca en los gráficos solo cuando se produzca el problema y no aparezca cuando el problema no se produzca. 
   3. Ejecute el comando CLI: > mostrar estadísticas de aplicaciones en ejecución para comprobar si alguna aplicación tiene un valor anormalmente alto para cualquier columna (especialmente para aplicaciones de mayor velocidad de datos como: navegación web, unknown-udp, unknown-tcp, dns, ms-ds-smb, ms-ds-smbv2, ms-ds-smbv3 y mssql-db, o cualquier aplicación personalizada)
   4. Si algún flujo de tráfico o aplicación se destaca como posibles delincuentes en los pasos anteriores, es decir, cuando sus valores son más altos que en tiempos normales, funcionales y sin problemas cuando no hay un problema de tráfico / CPU alta), detenga temporalmente ese flujo de tráfico a través del firewall y vea si los valores relacionados con CTD en > depuran el rendimiento del plano de datos ( sml_vm, ctd_token, detector_run_p1 o detector_run_p2) vuelven a bajar a niveles normales y si el problema de tráfico ha desaparecido
3. Reduzca cualquier inspección realizada en ese flujo de tráfico específico al:
   1. Crear una aplicación personalizada para ese tráfico (para que no se clasifique como unknown-udp o unknown-tcp)
   2. Envíe ese tráfico en su lugar a través de una regla de política de seguridad que no tenga ningún perfil de seguridad adjunto (o use un perfil menos estricto con menos firmas habilitadas)
   3. Habilite DSRI en la regla de directiva de seguridad que toma ese tráfico
   4. Crear una invalidación de aplicaciones para ese tráfico (úselo solo si su organización confía en el tráfico)