Notes 2

diagnostics incidents d'exploitation

OOM Killer

appli qui s arrête sans raison on le trouve dans les logs du system ou dmesg

    dmesg

les erreurs apparaissent en rouge ces infos sont copiées dans /var/log/kern.log pour trouver un kill de process

    dmesg | egrep -i 'killed process'
    grep -i 'killed process' /var/log/kern.log

pb d'I/O

input / output 2 métriques : bande passante (vitesse d'écriture) nombre d'I/O pouvant être lus à la seconde (important pour les bases de données) le plus important c'est de vérifier les accès disques pour savoir ce qui consomme le plus d'IO

    iotop

processeur

pour obtenir les infos sur les processeurs

    nano /proc/cpuinfo
    procinfo

pour connaître le nombre de processeur : regarder ligne processor - 1 pour monitorer le context switching

    vmstat 1

la colonne important c'est wa correspondant au temps d'attente avant un calcul st permet de savoir si une vm est ralentit à cause d'autres VM sur l'infra du client

    ps -auxf

le statut est très important S = sleep R = running D = defunct -> en attente d'un autre processus -> conséquence du problème de perf Z = zombie -> état ultime -> on ne peut plus l'arrêter -> une seule solution il faut redémarrer

Statut du processus. Les valeurs possibles sont : S (sleeping), D (uninterruptible sleep), R (running), Z (zombie), ouT (stopped or traced), peut être précédé par < (negative nice value), N (positive nice value), ou W (swapped out).

    sync ; reboot -f

lance un hard reboot

analyse complet d'un processus

    strace PID

mémoire

    free -m

pb de perf si on utilise dans le swap trouver ce qui consomme le plus de mémoire

    top -o RES

buffer

pour compenser la limitation de vitesse des disques, le kernel met les infos redondantes dans le buffer

mesurer les performances avec top

    top
    #load average

load average 1 min 15 mins 60 mins donne le nombre de coeurs nécessaire pour faire tourner correctement la machine

modele OSI

partir de la couche la plus basse pour commencer à diagnostiquer

analyse de trame réseau

    tcpdump
    tcpdump -li eth0 port 80 -As0
    # pour éviter de résoudre le nom des machines
    tcpdump port postgres

regarder le flag pour savoir le statut voir la liste des ports

    nano /etc/services

dimensionnement

• prévoir toujours le double de RAM pour le buffer
• pour apache c'est le temps de latence entre le client et le serveur qui a un impact important sur les performances -> réseau apache consomme peu, se sont les process qu'il va générer derrière l'ajax augmente le nombre de slots occupés dans Apache
• une requête sql sollicite un cpu
• pour notre cas il faut beaucoup de coeurs avec des fréquences pas trop basses -> renseigner les prérequis dans la doc.maarch.org avec la fréquence des procs

astuces pour les perfs

• mettre en queueing les services consommateurs de CPU pour éviter les lancements en parallèles : ex : conversions de fichiers ou génération d'imagettes

http

le virtual Host est chargé à l'aide du HOST présent dans la requête http entrante

serveur dns xip.io

résoud les nom à la volée sans déclaration
toto.127.0.0.1.xip.io

pour utiliser le param vhost avant même que la déclaration dns soit effective

ssl

les éléments permettant de faire fonctionner un certificat ssl dans votre navigateur

• il faut une date de validité
• que le nom de domaine demandé corresponde bien au certificat
• l'autorité qui a délivré le certificat

chiffrement symétrique -> on partage le mdp -> une psk presharedkey chiffrement asymétrique -> clé publique / clé privée on signe avec la clé publique -> on déchiffre avec la clé privée

let's encrypt autorité de certification émettant des certificats gratuits et permettant d'avoir des certicats qui se regénèrent automatiquement

timeout 10 devant la commande unoconv