Comment interpréter la sortie de « debug dataplane pow performance » lors du dépannage élevé DP CPU
60725
Created On 12/31/18 06:45 AM - Last Modified 06/09/23 09:24 AM
Objective
SSOL’unité (Calendrier/ Synchronisation/Commande) est le composant du Dataplane qui gère la planification et la commande des paquets. Il est également connu sous le POW nom (Paquet / Ordre / Travail). Il est responsable de l’établissement des horaires des travaux aux cœurs basés sur QOS les groupes de priorité et de travail. Il maintient également l’ordre d’entrée de paquet.
A groupe de travail est un ensemble d’applications et chaque noyau peut être affecté à plus d’un groupe de travail. Les groupes de travail sont utilisés pour équilibrer la charge de traitement entre les différents noyaux. La valeur de groupe de travail d’un paquet est définie automatiquement sur l’entrée, et peut être modifiée par logiciel.
Les fonctions sont un sous-ensemble de tâches exécutées par un noyau au sein d’un groupe de travail.
Cet article couvre quelques conseils sur la façon d’interpréter les données de performance pow.
Environment
Cette sortie est commune à tous les PAN-OS pare-feu, que ce hardware soit virtuel.
Procedure
La sortie de la « performance de pow de dataplane de débogage » donne une brève idée de l’utilisation de chaque groupe de travail et fonction dans le dernier cycle DP d’échantillonnage :
- Combien de fois un groupe de travail et une fonction ont été programmés.
- Quel était le temps de traitement moyen en microsecondes (nous) pour chaque groupe de travail et fonction.
- Quel a été le temps de traitement maximum en microsecondes (nous) pour chaque groupe de travail et fonction.
Sortie de l’échantillon :
Colonne 1 : Groupe de travail [ou fonction] Colonne de nom 2 : Temps de traitement maximum pour ce groupe de travail dans le dernier cycle d’échantillonnage Colonne 3 : Temps de traitement moyen pour ce groupe de travail dans la dernière DP
colonne du cycle
d’échantillonnage 4 : Nombre de fois où ce groupe de travail [ou DP fonction] a été planifié
Explication des groupes de travail :
flow_np : Network Processor. Very first program to decide if it is slow path or fast path. flow_lookup : Responsible for existing session/flow lookup. flow_mgmt : Installation and clearing of session table. flow_fastpath : Fastpath processing of packet (Includes post slowpath processing and content inspection). flow_slowpath : Slow path processing of packet (route and policy lookup and session setup). flow_forwarding : Handles forwarding stage of packets. dfa_result : Appid signature matching module_internal : Control messages between internal components . aho_result : Threat signature matching. zip_result : Used for ZIP processing. pktlog_forwarding : Responsible for forwarding logs to MP. flow_host : Process handling packets destined to Firewall flow_ctrl : Aging sessions and handling net-messages nac_result : Analyzing result of appid signature match output
La sortie ci-dessus nous donne un aperçu très nécessaire de l’utilisation sur DP .
- Les valeurs relatives du nombre nous donnent une idée du groupe de travail ou de la fonction qui est appelé pour plus de fois.
- En général, le flow_slowpath aurait un nombre plus faible par rapport à flow_fastpath.Si nous comparons ces données historiquement à partir du fichier journal dp-monitor, nous pouvons voir si le nombre pour un groupe de travail particulier a augmenté dans une fenêtre de temps spécifique.
- module_internal est utilisé pour contrôler les messages entre les composants internes comme les URL recherches, etc. A le nombre élevé de module_internal peut indiquer beaucoup de messagerie interne.
- En général, comptez pour flow_fastpath, flow_forwarding, flow_np devraient être invoqués pour chaque trafic de transit. Ainsi, leur nombre sera comparable élevé.
- aho_result, dfa_result, nac_result nous donnerait une idée de la quantité de couche 7 en cours sur le firewall .
- A haute valeur de Max Proc nous est très bien, mais une valeur élevée de ave. proc nous n’est pas bon.
NOTE: Nous pouvons multiplier le nombre avec ave proc nous pour chaque groupe de travail pour avoir une idée du groupe de travail qui utilise le plus de CPU temps. - Lorsque les choses semblent normales à partir de groupes de travail stand point DP CPU et est toujours sous charge, nous devrions passer à inspecter les fonctions pour comprendre quelle fonction utilise combien CPU .
Additional Information
Étude de cas :
Par exemple, est CPU 100% et les groupes de travail regardent comme ci-dessous:
:group max. proc us ave. proc us count :flow_lookup 0 0 0 :flow_fastpath 122087 55 33971601 :flow_slowpath 199 72 345516 :flow_forwarding 75 2 8910565 :flow_mgmt 57 29 69 :flow_ctrl 100 6 302011 :nac_result 50 1 2015416 :flow_np 66 4 33255061 :dfa_result 21794 242 2059391 :module_internal 525 18 173530 :aho_result 119981 154 2014275 :zip_result 16771 234 197454 :pktlog_forwarding 84 7 287854 :lwm 0 0 0 :flow_host 52 11 5494
Nous savons d’en haut que fastpath est le plus élevé, mais pour trouver la raison de quel composant utilise CPU plus permet de regarder les fonctions pour la même chose:
:func max. proc us ave. proc us count :dfa_match 0 0 0 :policy_lookup 125 10 2239062 :user_group_policy 87 1 477903 :get_gid 41 0 1061755 :regex_lookup 6217 102 2233481 :regex_postfpga 910 16 1039761 :reg_expr_match 0 0 0 :sml_vm 208 6 31643903 :detector_run_p1 2342 34 906163 :detector_run_p2 31327 79 889286 :ssl_proxy_proc 63072 600 2500540 :ssl_encode 202 36 805522 :rsa_operation_pub_enc 766 309 6688 :rsa_operation_pub_dec 648 263 116 :rsa_operation_priv_enc 8216 8168 14362 :rsa_operation_priv_dec 8260 8178 6427 :rsa_key_gen 40126 23467 43 :rsa_RSA_sign 13840 13236 33704 :rsa_RSA_verify 963 430 71904 :ecdhe_key_gen 22925 7559 18 :ecdhe_key_gen_mul 0 0 0 :ecdhe_key_compute_mul 22121 6640 82229 :ecdhe_key_compute 22565 6856 82224 :ecdhe_generate_xchg_key 23514 7948 18 :ecdhe_gen_key_exchange_msg 22630 6949 43919 :ecdhe_get_key_exchange_msg 22656 6932 38261 :ecdhe_parse_server_key_exchange_msg 320 244 45817 :ecdhe_gen_server_key_exchange_msg 78 29 43561 :dhe_gen_para 0 0 0 :dhe_gen_key 0 0 0 :dhe_key_compute 0 0 0 :bn_mod_exp 8226 6196 27618 :cipher_enc 142 9 1956671 :zip_deflate 50 2 197543 :pktlog_log 0 0 0 :pktlog_send 0 0 0 :tunnel_encap 0 0 0 :tunnel_decap 0 0 0 :tunnel_esp 0 0 0 :tunnel_esp_decap 0 0 0 :tunnel_ah_decap 0 0 0 :tunnel_ah 0 0 0 :tunnel_fwd 0 0 0 :tunnel_prepare 0 0 0 :tunnel_post 0 0 0 :appid_result 0 0 0 :ctd_token 21789 239 2060687 :dos_update 17 0 212713 :urlcache_update 20065 178 2555 :urlcache_lookup 107402 125 540508 :urlcache_insert 0 0 0 :urlcache_delete 0 0 0 :urlcache_lru 0 0 0 :session_install 59 8 217532 :session_age 36 0 875144 :session_delete 165 11 212717 :session_purge 0 0 0 :inline_switch 0 0 0 :age_arp 20 2 595 :age_pbf_ret_mac 1 0 595 :stack_trace 0 0 0 :ctd_pw_check 0 0 0 :ctd_pw_md4 0 0 0 :ctd_pw_extract 0 0 0 :prl_rewrite 0 0 0 :pkt_rewrite 0 0 0 :vpn_send_to_client 0 0 0 :vpn_cookie_response 0 0 0 :raven_match 46 2 131751 :raven_match_header 52 2 187227 :raven_match_body 51 14 6 :raven_sig_get_action 0 0 0 :age_mfib 1 0 595
Ci-dessus, si vous multipliez le nombre par temps moyen, vous pouvez avoir une idée claire de ce qui utilise le plus CPU . Voir ci-dessous par exemple (sortie tronquée uniquement pour les fonctions les plus utilisées)
:func max. proc us ave. proc us count count*avg :ssl_proxy_proc 63072 600 2500540 1500324000 :ecdhe_key_compute 22565 6856 82224 563727744 :ecdhe_key_compute_mul 22121 6640 82229 546000560 :ctd_token 21789 239 2060687 492504193 :rsa_RSA_sign 13840 13236 33704 446106144 :ecdhe_gen_key_exchange_msg 22630 6949 43919 305193131 :ecdhe_get_key_exchange_msg 22656 6932 38261 265225252 :regex_lookup 6217 102 2233481 227815062 :sml_vm 208 6 31643903 189863418 :bn_mod_exp 8226 6196 27618 171121128 :rsa_operation_priv_enc 8216 8168 14362 117308816 :detector_run_p2 31327 79 889286 70253594 :urlcache_lookup 107402 125 540508 67563500 :rsa_operation_priv_dec 8260 8178 6427 52560006 :rsa_RSA_verify 963 430 71904 30918720 :detector_run_p1 2342 34 906163 30809542 :ssl_encode 202 36 805522 28998792 :policy_lookup 125 10 2239062 22390620 :cipher_enc 142 9 1956671 17610039 :regex_postfpga 910 16 1039761 16636176 :ecdhe_parse_server_key_exchange_msg 320 244 45817 11179348
Vous pouvez voir que la plupart des fonctions les plus utilisées sont liées au SSL décryptage. Cela nous donne donc une bonne idée des mesures supplémentaires à prendre pour atténuer cette question.