Avant de commencer
Utilisez votre VPS Linux et une console de secours si SSH ne répond plus. Les commandes de consultation ci-dessous ne changent pas le système ; certaines nécessitent des droits administrateur ou des outils installés. Masquez les informations sensibles avant de partager les résultats.
Fixer le contexte avant de redémarrer
Notez heure, fuseau, application touchée et dernier changement. Un redémarrage peut effacer une partie des preuves et ne pas corriger la cause. Comparez la durée de la panne avec les journaux de l’application et les mesures de l’espace client.
Horodatage et charge observée
date -Is
uptimeLa charge moyenne ne représente pas un pourcentage CPU : des tâches en attente, notamment d’entrées/sorties, peuvent l’augmenter. Conservez le nombre de processus actifs et le contexte de travail ; ne concluez pas sur ce chiffre seul.
Lire la mémoire disponible plutôt que le seul cache
Linux utilise la mémoire libre pour des caches récupérables. Dans free, available estime la mémoire disponible pour de nouvelles applications ; free et available ne sont pas interchangeables. Comparez plusieurs mesures pendant la difficulté plutôt qu’un instant après le démarrage.
Vue mémoire et swap
free -hExaminez available et les totaux RAM/swap. La présence de swap utilisée ne prouve pas une activité d’échange intense. Si l’application tourne dans un conteneur, sa propre limite mémoire peut être atteinte même lorsque le VPS dispose encore de mémoire.
Comparer swap, attente disque et pression
Des échanges persistants et des périodes d’attente peuvent expliquer des latences, mais une swap simplement occupée n’est pas un verdict. La pression PSI mesure le temps de blocage lié aux ressources, pas la quantité de RAM consommée.
Échantillons courts de l’activité système
vmstat 1 5La première ligne agrège depuis le démarrage ; les suivantes décrivent les intervalles. Comparez si/so, wa et les processus en attente au moment du problème. Une valeur isolée ne mesure ni le débit réseau ni une attaque.
Pression mémoire si le noyau expose PSI
cat /proc/pressure/memorysome et full décrivent du temps passé bloqué ; avg10, avg60 et avg300 portent sur des fenêtres différentes. Si le fichier n’existe pas, PSI peut ne pas être disponible : ne transformez pas cette absence en pression nulle.
Chercher une preuve d’OOM dans les journaux
Un processus disparu peut avoir été arrêté pour d’autres raisons : erreur applicative, limite de conteneur ou action de maintenance. Identifiez le service, l’heure et l’événement exact. Sans journal correspondant, écrivez « OOM non confirmé », pas « le noyau a tué le serveur ».
Lire les événements kernel de la dernière heure
journalctl -k --since '-1 hour' --no-pager | grep -Ei 'out of memory|oom-kill|killed process'La lecture peut nécessiter des droits supplémentaires. Aucune correspondance ne prouve pas l’absence d’OOM : fenêtre trop courte, rétention ou journaux incomplets restent possibles. Le nom et le PID affichés doivent correspondre à l’incident.
Séparer écoute SSH, CPU et panne réseau
Si la console répond mais SSH expire, contrôlez l’écoute locale avant d’attribuer le problème à la RAM. Une écoute présente ne garantit pas la route extérieure ni l’authentification. Si SSH se connecte puis reste lent, comparez charge et activité de l’application sur le même intervalle.
Écoute TCP sur le port SSH configuré
ss -lnt 'sport = :22'Le port par défaut est 22 ; adaptez-le seulement si votre service a été configuré autrement. Cette commande consulte les sockets. Elle n’ouvre aucun port et ne modifie ni le pare-feu ni la configuration SSH.
Choisir une correction justifiée et mesurable
Transmettez au support les observations horodatées, journaux utiles, contexte de charge et tests extérieurs autorisés. Une pression mémoire répétée peut justifier de limiter une application, de revoir ses paramètres ou d’étudier davantage de RAM ; une erreur de route demande un autre traitement.
Évitez la purge de cache comme remède universel, la suppression de données et les redémarrages répétés. Sauvegardez avant une modification identifiée, changez un élément à la fois et mesurez ensuite le même travail. Une offre plus grande ne corrige pas un défaut de configuration ou de logiciel.
Selon votre situation
| Situation | Prochaine vérification |
|---|---|
| Cache élevé mais mémoire disponible et pas de blocage | Ne pas conclure à une saturation sur le seul cache ; observer le comportement pendant la charge réelle. |
| Échanges et pression corrélés aux lenteurs | Identifier les processus et limites concernés avant de choisir une correction ou une capacité supérieure. |
| SSH expire mais la console répond | Comparer écoute locale, adresse, port et trajet extérieur ; ne pas attribuer automatiquement le timeout à la RAM. |
Sources officielles
Ces documents décrivent les protocoles et logiciels concernés. Les conditions de votre service et sa configuration restent à vérifier.