Comment troubleshooter un cluster elasticsearch en utilisant l'api _cat.

Ce post a été écrit il y a 5 ans mais la méthode et les commandes sont toujours d'actualité.

Les jobs CI peuvent être très consomateurs en IOPS, notamment lors des phases de téléchargement des artifacts (maven :) ou docker par exemple...) ou lors du build. Une CI déployée sur des instances EC2 avec des volumes EBS standards (gp2) peut connaitre des temps de réponse particulièrement dégradés lorsqu'elle à dépassé sa capacité de burst et qu'elle est limité en IOPS.

Il est interessant dans ce contexte de monitorer l'EBS Burst Balance sur ces volumes.

En cas de performance limitée par les IOPS EBS, il y a 3 solutions:

• augmenter la taille des EBS pour bénéficier de d'un nombre d'IOPS plus important (nb IOPS = 3 x nb GB)
• passer sur des EBS de type io1 pour bénéficier d'un nombre d'IOPS garanti (souvent moins intéressant en terme de coûts)
• utiliser des instances disposant de SSD internes à la place des EBS (ex: c5d ou m5d instances)

Quelques commandes utiles pour diagnostiquer un problème sur un pod kubernetes.

Pour sauvegarder un dump du kernel dans /var/crash sous debian en cas de kernel panic:

apt install kdump-tools crash kexec-tools makedumpfile `uname -r`-dbg
sed -i 's/USE_KDUMP=0/USE_KDUMP=1/' /etc/default/kdump-tools
sed -i 's/GRUB_CMDLINE_LINUX_DEFAULT="quiet"/GRUB_CMDLINE_LINUX_DEFAULT="quiet" crashkernel=128M"/' /etc/default/grub
update grub
reboot

A partir de Java8, la Metaspace qui remplace la PermGen n'est plus dans la Heap Java mais dans la mémoire native de l'OS.

Par défaut le HeapDump ne fournit donc plus d'infos sur la Metaspace.

Solution:

jmap -clstats PID to dump class loader statistics;
jcmd PID GC.class_stats to print the detailed information about memory usage of each loaded class. The latter requires -XX:+UnlockDiagnosticVMOptions.

Comment diagnostiquer un tomcat KO en analysant les thread dumps:

1. prendre 3 thread dumps à 10s d'intervalle (kill -3 <pid> ou jstack -l <pid>)
2. vérifier la présence de deadlocks
3. comparer ensuite les 3 thread dumps avec un diff, meld ou autre et chercher les threads applicatif (type: http-nio-8080-exec-*) restés dans le même état sur les 3 thread dumps
4. identifier la root cause du thread bloqué en regardant le code si nécessaire

Pour analyser le contenu d'un thread dump

Pour générer un thread dump:

jstack -l <JVM_PID>

Ce guide explique le fonctionnement interne de la JVM et des différents Garbage Collectors et donne des piste de troubleshooting et de profiling avec VisualVM et autres outils d'analyse de dump.