Product-apim: [3.2.0] CPU élevé lorsqu'une seule requête atteint la passerelle sur Kubernetes

Créé le 6 janv. 2021 · 8Commentaires · Source: wso2/product-apim

La description:

CPU élevée lorsqu'une seule demande atteint la passerelle.

La documentation de dépannage suivie et les résultats sont comme ceci :

résultat d'utilisation :
%CPU CPU NI S TIME PID TID
...
78,1 - 0 R 00:17:27 167 356
77,9 - 0 R 00:17:25 167 357
...
résultat du vidage en fonction des identifiants de thread :

"HTTPS-Listener I/O dispatcher-1" #190 prio=5 os_prio=0 cpu=1043696.51ms elapsed=1336.89s tid=0x00007fdc54094000 nid=0x164 runnable  [0x00007fdc1b606000]
   java.lang.Thread.State: RUNNABLE
        at sun.nio.ch.EPoll.wait([email protected]/Native Method)
        at sun.nio.ch.EPollSelectorImpl.doSelect([email protected]/EPollSelectorImpl.java:120)
        at sun.nio.ch.SelectorImpl.lockAndDoSelect([email protected]/SelectorImpl.java:124)
        - locked <0x00000000eafef8d8> (a sun.nio.ch.Util$2)
        - locked <0x00000000eafef778> (a sun.nio.ch.EPollSelectorImpl)
        at sun.nio.ch.SelectorImpl.select([email protected]/SelectorImpl.java:136)
        at org.apache.http.impl.nio.reactor.AbstractIOReactor.execute(AbstractIOReactor.java:256)
        at org.apache.http.impl.nio.reactor.BaseIOReactor.execute(BaseIOReactor.java:105)
        at org.apache.http.impl.nio.reactor.AbstractMultiworkerIOReactor$Worker.run(AbstractMultiworkerIOReactor.java:586)
        at java.lang.Thread.run([email protected]/Thread.java:834)

"HTTPS-Listener I/O dispatcher-2" #191 prio=5 os_prio=0 cpu=1041420.55ms elapsed=1336.89s tid=0x00007fdc5409d000 nid=0x165 runnable  [0x00007fdc1b505000]
   java.lang.Thread.State: RUNNABLE
        at sun.nio.ch.EPoll.wait([email protected]/Native Method)
        at sun.nio.ch.EPollSelectorImpl.doSelect([email protected]/EPollSelectorImpl.java:120)
        at sun.nio.ch.SelectorImpl.lockAndDoSelect([email protected]/SelectorImpl.java:124)
        - locked <0x00000000eaff0950> (a sun.nio.ch.Util$2)
        - locked <0x00000000eaff08f8> (a sun.nio.ch.EPollSelectorImpl)
        at sun.nio.ch.SelectorImpl.select([email protected]/SelectorImpl.java:136)
        at org.apache.http.impl.nio.reactor.AbstractIOReactor.execute(AbstractIOReactor.java:256)
        at org.apache.http.impl.nio.reactor.BaseIOReactor.execute(BaseIOReactor.java:105)
        at org.apache.http.impl.nio.reactor.AbstractMultiworkerIOReactor$Worker.run(AbstractMultiworkerIOReactor.java:586)
        at java.lang.Thread.run([email protected]/Thread.java:834)

Ces deux fils consomment beaucoup de ressources et je n'ai pas pu trouver de raison spécifique.

Étapes à reproduire :

Déployez le graphique helm sur les nœuds de travail AWS m5a.large.

Version du produit concerné :

API-M version 3.2.0

Détails de l'environnement (avec versions) :

Système d'exploitation : AWS Linux
Env (Docker/K8s): K8s 1.18

Champs facultatifs

Problèmes liés:

Étiquettes suggérées :

Cessionnaires suggérés :

PrioritNormal TypBug

Source

okhuz

Tous les 8 commentaires

Salut @okhuz , pouvez-vous s'il vous plaît me faire savoir si vous avez fait des changements de ressources dans les graphiques heml. Je crois que vous utilisez les cartes de barre WSO2. De plus, pouvez-vous me dire le modèle de déploiement que vous utilisez et combien de nœuds y a-t-il dans le cluster (m5a.large). Selon les graphiques de barre WSO2, un pod nécessite au moins 2000 m de processeurs (2 processeurs). Étant donné que le nœud m5a.large a 2 vCPU, je suppose que cela peut être cela (juste une possibilité). Pouvez-vous également me dire un scénario spécifique que vous essayez lorsque vous observez cette utilisation élevée du processeur ? Comme dans un débit plus élevé, les logiques de médiation incluses, etc.

dinusha92 le 6 janv. 2021

Salut @dinusha92 , nous avons des nœuds de mise à l'échelle automatique sur AWS EKS, entre 3 et 6 et dans le graphique, la limite est de 2000 m, j'ai supposé que cela fonctionnerait tel quel. J'ai augmenté le CPU de la requête mais cela n'a eu aucun impact. Avons-nous besoin d'une instance plus grande ?

okhuz le 6 janv. 2021

Pouvez-vous vérifier l'utilisation des ressources du nœud et du pod en utilisant kubectl top node <node name> et kubectl top pod <pod name> . (La commande liée au pod doit être exécutée avec l'espace de noms)

dinusha92 le 7 janv. 2021

Devons-nous appliquer ceci https://github.com/wso2/product-apim/issues/8908 ?

pubudu538 le 7 janv. 2021

👍1

Passerelle consommant toutes les ressources dans un seul nœud. Nous mettons actuellement à niveau la taille de nos instances pour tester ce problème.

okhuz le 7 janv. 2021

NAME     CPU(cores)   CPU%   MEMORY(bytes)   MEMORY%   
xxxxxxx    65m             1%        742Mi                  10%       
xxxxxxx    240m           6%        3065Mi                44%       
xxxxxxx    259m           6%        3145Mi                45%       
xxxxxxx    2198m         56%      3660Mi                53%       
xxxxxxx    190m           4%        2762Mi                40%

NAME                                                              CPU(cores)   MEMORY(bytes) 
wso2am-pattern-2-am-gateway-deployment-7c5dc7dc67-d68tr           1956m           958Mi           
wso2am-pattern-2-am-gateway-deployment-7c5dc7dc67-jczjb            1959m           958Mi

Toujours pas de succès. Cela devrait être une très petite consommation de processeur au ralenti, n'est-ce pas ?

okhuz le 7 janv. 2021

Pouvez-vous également me dire un scénario spécifique que vous essayez lorsque vous observez cette utilisation élevée du processeur ?

Nous avons quelques API dans le gestionnaire d'API, mais cela se produit directement après que Gateway ait reçu une demande. Comme si j'entrais gateway.xxx.com ou gateway.xxx.com/services/Version, juste après que le processeur tourne pour limiter.

okhuz le 7 janv. 2021

Comme @ pubudu538 l'a mentionné, nous avons corrigé un problème de performances. Si vous avez un abonnement WSO2, vous pouvez utiliser WUM afin d'obtenir la correction du bogue. Sinon, vous devrez inclure le correctif manuellement et le corriger.

dinusha92 le 8 janv. 2021

👍1

Cette page vous a été utile?

0 / 5 - 0 notes