identifier une conso CPU sur HANA

Publié le par

Voici un exemple pour identifier le traitement consommateur de CPU sur une DB HANA.

avant tout, plusieurs commentaires pour comprendre ce que l’on cherche à identifier :

  • la consommation CPU > 60% au delà de 30 secondes va générer un impact sur le niveau de réactivité GLOBAL, en gros, on ralenti tout le monde
  • la consommation CPU > 85% au délà de 30 secondes va générer un blocage de toutes les nouvelles requêtes (à partir de HANA 2.0 SP02 avec l’arrivée de l’admission control), en gros, c’est rideau pendant quelques secondes
  • une consommation CPU élevée mais courte (< 30 secondes) est normale. en gros, faut quand même pas avoir peur de voir s’envoler l’utilisation CPU, mais faut que ça redescende aussi vite que c’est monté.

pré requis :

  • HANA Studio
  • Importer les scripts de la note oss 1969700

en général, on commence par activé de l’alerting 

une fois que l’on reçoit une alerte par email, on jette un oeil : — santé Mémoire et CPU sur la dernière heure

select TIME, MEMORY_USED, CPU, ACTIVE_THREAD_COUNT, WAITING_THREAD_COUNT, MVCC_VERSION_COUNT, CS_UNLOAD_COUNT from « SYS ». »M_LOAD_HISTORY_SERVICE » where TIME between ADD_SECONDS(current_timestamp, -3600) and current_timestamp order by TIME desc;

un exemple où il y a rien

un exemple où il y a un problème :

lancer le script « HANA_Workload_AdmissionControlEvents_2.00.010+ » (note oss 1969700)

1ere conclusion : l’admission control s’est mis en marche, il va ralentir les nouvelles requêtes tant que le traitement consommateur sera en cours.

Quel est le traitement responsable ?
lancer le script « HANA_Threads_ThreadSamples_AggregationPerTimeSlice_1.00.80+_ESS » en modifiant ainsi :

on exécute :

Hash : 3d3ad594df220be6721c01f4455a06d2
lancer le script « HANA_SQL_StatementHash_SQLText » en modifiant ainsi :

2nde conclusion : on connait la requête et la ou les tables qui sont utilisées.
lancer le script « HANA_Threads_ThreadSamples_FilterAndAggregation_1.00.120+ » en modifiant ainsi :

dernière conclusion : on connait l’utilisateur, le programme, l’adresse ip. avec ça, on doit pouvoir communiquer suffisamment d’élément pour faire corriger le programme.


n.b : l’activation du programme /SDF/MON en permanence sur l’instance ABAP permet de confirmer cette analyse.

Laisser un commentaire