Surveillance des ressources serveur et optimisation des performances

Ce que « performance » veut vraiment dire sur un serveur dédié

Sur un VPS, tu es limité par les restrictions imposées par l'hyperviseur. Les serveurs dédiés tournent directement sur le matériel, donc tes performances sont vraiment plafonnées. Ça veut dire la RAM physique, les cœurs de processeur réels et le débit d'E/S de tes NVMe . C'est un gros avantage, mais ça veut aussi dire que quand tu atteins une limite, tu te heurtes au matériel réel, pas à un régulateur artificiel.

Cette différence est importante pour la stratégie de surveillance. Sur une infrastructure partagée ou virtualisée, un pic d'utilisation du processeur peut signifier qu'un voisin vole des ressources. Sur un serveur dédié, un pic signifie que votre charge de travail est réellement plus importante qu'auparavant. Les deux situations nécessitent une attention particulière, mais pour des raisons différentes.

Indicateurs clés à surveiller

Utilisation du processeur et charge moyenne

Le pourcentage d'utilisation du processeur seul ne donne pas une image complète. Un serveur à 8 cœurs avec un taux d'utilisation du processeur de 90 % peut très bien fonctionner si tous les cœurs sont vraiment occupés. Les signes qui montrent qu'il y a un problème sont les suivants :

• Charge moyenne bien plus élevée que le nombre de cœurs: un serveur AMD EPYC 4545P à 16 cœurs avec une charge moyenne de plus de 40 en une minute, ça veut dire que les processus attendent leur tour pour utiliser le CPU, ils ne l'utilisent pas juste. Vérifie avec uptime ou cat /proc/loadavg.
• Attente CPU (wa) dans la sortie top: un pourcentage iowait élevé veut dire que les processus sont bloqués en attendant des lectures ou des écritures sur le disque. Le CPU est en fait inactif, mais rien d'utile ne se passe.
• Vol de temps sur les invités virtualisés: ça ne s'applique pas aux serveurs physiques ; si tu vois du vol de temps sur un serveur « dédié », c'est que tu es en fait sur une infrastructure virtualisée.

Pression mémoire

C'est quand la RAM est à sec que les serveurs plantent souvent sans prévenir. Les indicateurs à surveiller :

• Mémoire disponible (pas la mémoire libre) : Linux met en cache de manière agressive les données du disque dans la RAM. La commande free -m affiche une mémoire « libre » très faible sur les serveurs en bon état de fonctionnement. C'est la colonne « disponible » qui importe, car elle indique la quantité de RAM que le noyau peut récupérer à la demande.
• Utilisation de l'espace d'échange: ce n'est pas forcément un problème, mais quand l'utilisation de l'espace d'échange augmente sous une charge normale, c'est un signal d'alarme. Dès que les applications commencent à lire/écrire dans l'espace d'échange, la latence grimpe en flèche.
• Événements OOM killer: Vérifie /var/log/kern.log ou dmesg | grep -i oom. Si le noyau tue des processus pour récupérer de la mémoire, c'est qu'il y a un problème de capacité.

Le serveur dédié Extreme d'InMotion est livré avec 192 Go de RAM DDR5 ECC. C'est assez de marge pour que la plupart des charges de travail n'atteignent pas le plafond, même avec une mise en cache agressive. Le composant ECC est aussi important : les erreurs de mémoire qui pourraient corrompre silencieusement les données sur le matériel grand public sont détectées et corrigées automatiquement.

E/S disque

NVMe ont vraiment changé la donne en matière de performances des disques, mais même NVMe devenir un problème quand il y a beaucoup d'écritures. Chiffres clés :

• iowait: Dans iostat -x 1, la colonne %await montre le temps moyen par requête d'E/S en millisecondes. Un temps inférieur à 5 ms, c'est bon pour NVMe. Un temps supérieur à 20 ms sous une charge normale, ça veut dire que le disque est saturé ou qu'il a un problème.
• Profondeur de la file d'attente: iostat -x 1 affiche aussi avgqu-sz. Des valeurs soutenues supérieures à 1-2 sur un NVMe montrent souvent que le disque n'arrive pas à suivre le rythme des E/S.
• Rapport lecture/écriture: les tâches qui demandent beaucoup d'écriture usent plus vite les SSD et peuvent saturer les tampons d'écriture. Comprendre ton mix lecture/écriture aide à choisir la bonne stratégie de mise en cache et la bonne configuration de stockage.

Débit du réseau et perte de paquets

• Utilisation de la bande passante: Utilise iftop ou nethogs pour voir en temps réel l'utilisation de la bande passante par connexion et par processus.
• Retransmissions TCP: netstat -s | grep retransmit, si ça augmente, ça veut dire qu'il y a des paquets qui se perdent entre le serveur et les clients ou l'infrastructure en amont.
• États de connexion: ss -s montre le nombre de connexions par état. Si y a plein de connexions CLOSE_WAIT, ça veut dire que le code de l'appli ne ferme pas les connexions comme il faut.

Options de surveillance de la pile

Netdata

Netdata, c'est le moyen le plus rapide d'avoir des mesures en temps réel, à la seconde près, sur un serveur Linux, avec un minimum de configuration. L'installation par défaut de l'agent récupère tout de suite les mesures du processeur, de la mémoire, du disque et du réseau, et la granularité à la seconde permet de repérer les pics que les systèmes de surveillance basés sur des moyennes par minute ne voient pas du tout. Ça tourne bien sur les serveurs de production avec moins de 1 % de charge CPU dans la plupart des configurations.

Pour les serveurs dédiés gérés par des équipes techniques, l'exportation des métriques Prometheus de Netdata facilite l'intégration des données dans les tableaux de bord Grafana existants.

Prometheus + Grafana

La pile d'observabilité open source standard. Prometheus récupère les métriques des exportateurs (node_exporter pour les métriques du système Linux, mysqld_exporter pour MySQL, etc.) à un intervalle que tu peux configurer, généralement 15 ou 30 secondes. Grafana s'occupe du tableau de bord et des alertes.

Cette combinaison demande plus de configuration initiale que Netdata, mais elle offre beaucoup plus de flexibilité pour les métriques personnalisées, la conservation à long terme et la visibilité multi-serveurs. La plupart des équipes d'ingénierie de production qui utilisent plus de 3 ou 4 serveurs dédiés standardisent cette pile.

Moniteur de ressources cPanel

Si ton serveur dédié utilise cPanel, le moniteur de ressources intégré te montre l'utilisation du processeur et de la mémoire au niveau du compte, sans avoir besoin de bidouiller quoi que ce soit. C'est moins précis que Prometheus, mais ça marche tout de suite et c'est super utile pour voir quels cPanel utilisent trop de ressources sur les configurations revendeur ou multi-locataires.

Le pack Premier Care d'InMotion comprend une surveillance proactive par l'équipe APS, ce qui est super utile pendant les heures de bureau quand des schémas inhabituels dans l'utilisation des ressources peuvent nécessiter une coordination entre les diagnostics au niveau du serveur et les investigations au niveau des applications.

Optimisation des performances en fonction de ce que tu trouves

Charges de travail liées au processeur

Si le CPU est vraiment le problème, voici les options par ordre d'impact :

1. Profile the application: Tools like perf top or strace -c -p <pid> identify which system calls or functions consume the most CPU. Optimization at the application level almost always outperforms hardware changes.
2. Vérifie s'il y a des tâches cron qui ne sont pas efficaces: crontab -l et en regardant souvent dans /etc/cron.d/, tu peux trouver des scripts qui tournent en boucle et qui n'ont jamais été optimisés parce qu'ils « ne s'exécutent que de temps en temps ». Sur les serveurs modernes, « de temps en temps » peut vouloir dire 10 secondes à 100 % de CPU toutes les 15 minutes.
3. Dimensionnement du pool de workers PHP-FPM: des pools PHP-FPM mal configurés sur les serveurs web génèrent souvent plus de workers que le nombre de processeurs disponibles, ce qui entraîne une surcharge liée au changement de contexte. Adaptez pm.max_children au nombre de cœurs de votre processeur, multiplié par un facteur de concurrence raisonnable (généralement 2 à 4 fois pour les applications PHP liées à l'E/S).

Charges de travail liées à la mémoire

4. Redis ou Memcached pour la mise en cache d'objets: si ton application interroge souvent la base de données pour les mêmes infos, un cache en mémoire réduit vraiment la pression sur la mémoire de la base de données et la charge du processeur. Les options de persistance de Redis te permettent de mettre en cache de manière intensive sans perdre de données au redémarrage.
5. Réglez la taille du tampon innodb_buffer_pool_size de MySQL: par défaut, le tampon InnoDB de MySQL est réglé sur 128 Mo, ce qui n'est pas pratique sur un serveur avec plus de 64 Go de RAM. Réglez-le sur 70 à 80 % de la RAM disponible pour les charges de travail qui sollicitent beaucoup la base de données. La documentation MySQL fournit la formule et les options de configuration.
6. Pages transparentes géantes: pour certaines charges de travail, désactiver THP (echo never > /sys/kernel/mm/transparent_hugepage/enabled) réduit la latence de gestion de la mémoire. Pour d'autres, l'activer améliore le débit. Fais des tests avec ta charge de travail spécifique.

Charges de travail liées aux E/S

7. Passez à NVMe ce n'est pas déjà fait: passer d'SSD SATA SSD NVMe , ça donne NVMe un débit séquentiel 3 à 5 fois plus rapide et une latence bien plus faible. La gamme actuelle de serveurs dédiés d'InMotion est équipée de NVMe .
8. Configuration RAID: RAID-1 (mise en miroir) offre une redondance sans perte de performances en écriture, mais sans amélioration en lecture sur les E/S aléatoires. RAID-10 double à la fois les performances en lecture et le coût de la redondance. Choisis le niveau RAID en fonction de tes besoins : accélération en lecture, protection en écriture, ou les deux.
9. Choix du système de fichiers: XFS gère mieux les gros fichiers et les charges de travail à haut débit qu'ext4. Pour les serveurs de bases de données, ext4 avec les options de montage noatime et data=writeback comble en grande partie l'écart.

Définir des seuils d'alerte qui comptent

Le but, c'est pas d'avoir une alerte à chaque fois que le CPU passe à plus de 80 %. Le but, c'est d'avoir une alerte avant que les utilisateurs remarquent un problème.

Seuils pratiques pour les alertes sur les serveurs dédiés :

• La charge moyenne du processeur dépasse le double du nombre de cœurs pendant plus de 5 minutes.
• Mémoire disponible en dessous de 10 % du total pendant plus de 10 minutes
• L'attente d'E/S disque dépasse 20 ms pendant plus de 5 minutes.
• Augmentation de l'utilisation de l'espace d'échange pendant plus de 15 minutes (de façon continue, pas juste un petit pic)
• Tout disque affichant des avertissements SMART de défaillance imminente

InMotion HostingPremier CareInMotion Hosting inclut la surveillance des serveurs dans son offre de services gérés. Pour les équipes qui gèrent leur propre pile de surveillance, les seuils ci-dessus permettent de détecter les vrais problèmes tout en limitant le nombre d'alertes inutiles.Lecture connexe: Optimisation de la latence réseau pour les serveurs dédiés | Meilleures pratiques en matière de renforcement de la sécurité des serveurs