Comprendre l'utilisation des ressources CloudLinux dans cPanel

Si un site Web répond lentement de temps en temps, si des processus s'interrompent ou si des erreurs ne se produisent que sous charge, tu devrais vérifier les ressources d'hébergement disponibles en plus des erreurs PHP et de l'espace de stockage.

CURIAWEB utilise CloudLinux pour isoler les comptes d'hébergement les uns des autres et attribuer les ressources de manière contrôlée. Dans cPanel, vous pouvez, sous Valeurs mesurées → Utilisation des ressources comprendre si ton compte a atteint ses limites de ressources et quelles ressources ont été particulièrement sollicitées à un moment donné.

Dans ce guide, nous vous montrons comment ouvrir l'utilisation des ressources CloudLinux, interpréter correctement les principales métriques et faire la distinction entre un pic de charge de courte durée et un réel problème de ressources.

Important : Une valeur mesurée élevée ou un pic de charge unique ne signifie pas automatiquement que quelque chose ne va pas avec votre site web. Ce qui est déterminant, c'est de savoir si une limite est effectivement atteinte, à quelle fréquence cela se produit et si le moment coïncide avec un problème visible du site web.

Que fait CloudLinux ? #

Sur un système d'hébergement mutualisé, plusieurs comptes d'hébergement utilisent la même infrastructure de serveur physique.

CloudLinux veille notamment à ce que les ressources des différents comptes soient isolées les unes des autres. Ainsi, par exemple, un site web fortement sollicité ne peut pas monopoliser indéfiniment les ressources de l'ensemble du serveur.

Pour un seul compte d'hébergement, différentes ressources peuvent ainsi être examinées et limitées séparément.

Cela comprend, selon la configuration du serveur, notamment :

• Performance du processeur
• mémoire physique
• Performance des entrées/sorties
• processus entrants simultanés
• Nombre total de processus

L'affichage CloudLinux vous aide à identifier, quelle ressource a été sollicitée à quel moment.

Les ressources CloudLinux ne sont pas votre espace de stockage #

L'une des distinctions les plus importantes est celle entre l'espace de stockage d'hébergement et les ressources système en cours d'exécution.

Domaine	Sens
Espace de stockage	Espace pour les fichiers, les e-mails, les bases de données et autres données enregistrées
bande passante	données transférées
Mémoire physique	mémoire utilisée par les processus en cours
Processeur	Puissance de calcul pour les processus en cours
E/S	débit d'opérations d'entrée/sortie
Processus d'entrée	processus entrants traités simultanément dans le contexte de CloudLinux LVE
Processus	Nombre de processus en cours d'exécution du compte

Si vous souhaitez savoir quels fichiers ou e-mails occupent l'espace de stockage de votre hébergement, utilisez plutôt Vérifier l'espace disque et la bande passante dans cPanel.

1. Ouvrir l'utilisation des ressources dans cPanel #

Connecte-toi à ton cPanel CURIAWEB et ouvre :

Valeurs mesurées → Utilisation des ressources

L'interface CloudLinux qui y est fournie vous affiche des informations sur l'utilisation des ressources de votre compte d'hébergement.

Selon la version actuelle de CloudLinux et la configuration du serveur, l'affichage et la désignation de certaines valeurs peuvent légèrement varier.

2. D'abord vérifier le résumé #

Avant d'analyser les différents graphiques, tu devrais examiner le résumé ou l'état actuel.

CloudLinux peut y indiquer si votre compte a atteint ses limites de ressources au cours d'une période examinée.

C'est beaucoup plus significatif pour le diagnostic que de simple constat qu'un graphique montre une valeur élevée à un moment donné.

Règle de base : Ne cherche pas d'abord le pic le plus haut dans le graphique. Vérifie d'abord si une limite a été atteinte et à quel moment cela s'est produit.

3. Sélectionner la période d'analyse #

En cas de problèmes sporadiques, la période considérée est particulièrement importante.

Si, par exemple, ton site Web a été lent ou inaccessible hier vers 14 h 30, tu devrais analyser l'utilisation des ressources, si possible, précisément pour cette période.

Un processus de diagnostic pertinent est le suivant :

Identifier le problème du site web
↓
Noter la date et l'heure
↓
Ouvrir l'utilisation des ressources
↓
Sélectionner la période appropriée
↓
Comparer les limites et les mesures

Un événement lié aux ressources à un moment totalement différent n'explique généralement pas le problème actuel de votre site web.

Comprendre l'utilisation du processeur #

Le processeur fournit la puissance de calcul. Les scripts PHP, les opérations de base de données et d'autres processus nécessitent du temps de processeur pour exécuter leurs tâches.

Une utilisation accrue du CPU peut par exemple résulter de :

• nombreuses visites simultanées du site Web
• processus PHP gourmands en calcul
• opérations de base de données étendues
• Importations et exportations
• Processus de sauvegarde ou de maintenance
• Tâches cron
• plugins ou applications inefficaces
• Accès des robots

Une utilisation élevée du CPU n'est au départ qu'une valeur mesurée. Ce qui est déterminant, c'est de savoir si la limite de CPU applicable au compte est effectivement atteinte.

Que se passe-t-il lorsqu'une limite de CPU est atteinte ? #

Lorsqu'un compte utilise entièrement la puissance CPU qui lui est attribuée, CloudLinux peut limiter son utilisation supplémentaire du CPU.

En termes simplifiés :

Application nécessite plus de puissance CPU
        ↓
La limite CPU du compte est atteinte
        ↓
Le traitement supplémentaire est limité
        ↓
Les processus peuvent prendre plus de temps

Pour les visiteurs, cela peut se traduire par exemple par un site web plus lent.

Une limite de processeur ne signifie donc pas nécessairement qu'un processus est immédiatement arrêté avec un message d'erreur visible.

Pic de processeur momentané ou problème persistant ? #

Un pic de CPU bref peut être tout à fait normal pour certaines tâches.

Par exemple, une importation peut nécessiter temporairement nettement plus de puissance de calcul que le fonctionnement normal du site Web.

Plus critique est un modèle tel que :

Limite de processeur régulièrement atteinte
→ Site web lent en même temps
→ La même situation se répète
→ Cause reproductible

Ensuite, tu devrais examiner quel processus ou quelle application cause la charge.

Comprendre la mémoire physique #

Mémoire physique désigne la mémoire physique utilisée par les processus de votre compte d'hébergement au sein de l'environnement CloudLinux.

Cette valeur n'est pas la même que :

• votre espace d'hébergement
• la taille de ton site web
• le PHPlimite_mémoire

C'est une distinction particulièrement importante.

Différence entre la mémoire physique et memory_limit de PHP #

Le PHPlimite_mémoire limite la mémoire qu'un processus PHP individuel est autorisé à utiliser conformément à sa configuration PHP.

La limite de mémoire physique de CloudLinux examine quant à elle la consommation de mémoire des processus du compte d'hébergement à un autre niveau.

Simplifié :

Limite de mémoire PHP

Une version PHP supérieurelimite_mémoire n'augmente donc pas automatiquement la limite de mémoire CloudLinux.

Nous expliquons comment gérer les limites PHP sur Définir la limite de mémoire PHP, la taille de téléchargement et le temps d'exécution.

Important : Si CloudLinux signale une limite de mémoire, vous ne devez pas simplement augmenter la limite de mémoire PHP. Cela peut même accentuer un problème de ressources, car les processus PHP individuels sont autorisés à consommer plus de mémoire.

Qu'est-ce qui peut consommer beaucoup de mémoire vive ? #

Une consommation de mémoire accrue peut par exemple être causée par plusieurs processus PHP s'exécutant simultanément, par des applications volumineuses ou par des tâches particulièrement gourmandes en mémoire.

Les situations typiques sont :

• importations importantes
• Traitement d'images
• processus WordPress ou WooCommerce étendus
• plusieurs requêtes PHP parallèles
• Tâches cron
• Processus de sauvegarde ou de maintenance
• code d'application défectueux ou inefficace

Comprendre les E/S #

E/S signifie Input/Output et décrit, de manière simplifiée, le débit de données auquel les processus peuvent lire ou écrire des données.

Cela concerne par exemple l'accès aux fichiers.

Une activité d'E/S élevée peut notamment se produire lors des tâches suivantes :

• opérations sur les fichiers volumineux
• Sauvegardes
• Décompression de grandes archives
• importations massives
• Génération de cache
• certaines applications gourmandes en données

Que se passe-t-il en cas de limite d'I/O ? #

Si un processus nécessite plus de performances d'E/S que ce qui est disponible pour le compte, le traitement des données peut être limité en conséquence.

Cela peut entraîner que les opérations sur les fichiers ou les processus qui en dépendent prennent plus de temps.

Une limite d'E/S n'est donc pas la même chose qu'un espace de stockage plein.

Espace de stockage plein
→ manque d'espace pour d'autres données

Limite d'E/S atteinte
→ le débit d'entrée/sortie est limité

Les IOPS peuvent être affichées séparément #

Selon la configuration de CloudLinux, une valeur pour peut également IOPS être affiché.

Les IOPS décrivent le nombre d'opérations d'entrée/sortie par seconde et ne sont donc pas identiques au volume de données transférées par seconde.

Simplifié :

E/S
→ la quantité de données transférées par unité de temps

IOPS
→ le nombre d'opérations d'entrée/sortie individuelles par unité de temps

De nombreuses petites opérations sur les fichiers peuvent donc générer un profil de ressources différent de celui de quelques grandes opérations sur les fichiers.

Comprendre les processus d'entrée #

Processus d'entrée – souvent comme EP — font partie des valeurs de CloudLinux qui sont le plus souvent mal comprises.

Cela décrit de manière simplifiée le nombre de processus entrants entrant simultanément dans l'environnement CloudLinux-LVE ou y étant traités simultanément.

Cela peut notamment inclure des requêtes web dynamiques.

Important : Les processus d'entrée ne correspondent pas au nombre de visiteurs de votre site web. Un visiteur n'est pas automatiquement un processus d'entrée.

Pourquoi les visiteurs et les processus d'entrée ne sont pas la même chose #

Un visiteur peut déclencher plusieurs requêtes successivement. Parallèlement, différentes requêtes peuvent nécessiter des temps de traitement très variables.

C'est pourquoi, pour la limite de PE, le Simultanéité de processus pertinents déterminant et pas seulement le nombre de visiteurs par jour.

Un site web comportant de nombreux appels rapides et bien mis en cache peut donc se comporter différemment d'un site web comportant peu de requêtes dynamiques, mais très lentes.

Que se passe-t-il lorsque la limite du processus d'entrée est atteinte ? #

Si trop de processus correspondants doivent être traités en même temps et que la limite EP est atteinte, les requêtes supplémentaires ne peuvent pas être traitées normalement.

Dans ce contexte, les visiteurs peuvent par exemple rencontrer des erreurs telles que :

508 Limite de ressources atteinte

voir.

Nous aborderons le diagnostic concret et la résolution dans le prochain article sous Limite de ressources atteinte : identifier et corriger les limites CloudLinux.

Comprendre le nombre de processus #

CloudLinux peut également limiter le nombre total de processus d'un compte. Cette valeur est souvent appelée Nombre de processus ou / respectivement NPROC qualifié.

Il ne s'agit pas seulement de requêtes Web entrantes simultanées.

Selon l'environnement, différents processus du compte peuvent contribuer au processus global.

C'est pourquoi Les processus d'entrée et le nombre de processus ne sont pas la même chose.

Comparer les processus d'entrée (Entry Processes) et le nombre de processus (Number of Processes) #

Valeur	En termes simplifiés
Processus d'entrée	processus entrants simultanément survenant ou traités
Nombre de processus (NPROC)	Nombre total de processus en cours du compte

Un compte peut donc avoir un problème de processus sans que EP et NPROC ne présentent nécessairement le même comportement en même temps.

Les pannes sont particulièrement importantes pour le diagnostic. #

Dans l'évaluation CloudLinux, en plus des valeurs actuelles ou moyennes, de soi-disant Défauts ou des événements de limite être pertinents.

Un incident montre, de manière simplifiée, qu'une limite de ressources a été atteinte.

C'est souvent plus révélateur pour le diagnostic qu'un diagramme dont la ligne est simplement proche de la limite.

Conseil pratique : Si tu veux savoir si une limite de ressources a vraiment été pertinente, fais particulièrement attention aux événements de limite documentés et à leur moment.

100 % ne signifie pas la même chose pour toutes les valeurs #

Les pourcentages doivent toujours être lus dans le contexte de la limite de ressources respective.

Par exemple, une valeur CPU de 100 % affichée dans une vue des ressources d'hébergement ne signifie pas automatiquement que l'ensemble du serveur physique est utilisé à 100 %.

Elle peut faire référence à la ressource attribuée à votre compte.

N'utilisez donc pas les pourcentages comme une indication de la charge globale du serveur.

Différencier la limite de compte et la charge du serveur #

Si votre compte d'hébergement atteint une limite CloudLinux, cela ne signifie pas automatiquement que l'ensemble du serveur d'hébergement est surchargé.

CloudLinux sert précisément à isoler les ressources des différents comptes les unes des autres.

Simplifié :

Le compte atteint sa propre limite de ressources
≠
l'ensemble du serveur est surchargé

Cette distinction est cruciale pour l'interprétation des valeurs.

Les valeurs moyennes peuvent masquer des pics de courte durée #

Une valeur moyenne sur une période prolongée peut sembler normale, bien qu'une brève pointe de charge importante soit intervenue au cours de cette période.

Si votre site Web n'a eu des problèmes que pendant quelques minutes, vous devez par conséquent examiner une période aussi appropriée que possible et tenir compte des événements de dépassement de limite.

Un seul pic ne fait pas un diagnostic #

En supposant que l'utilisation du processeur atteigne brièvement un pic élevé pendant que :

• le site Web fonctionne normalement
• aucune limite ne soit documentée
• ne se produisent pas d'erreurs
• la valeur diminue ensuite à nouveau

Il n'y a donc pas nécessairement urgence à agir.

Une pointe de charge peut tout simplement avoir été provoquée par une tâche qui vient d'être exécutée.

Les limites récurrentes sont plus pertinentes #

Un motif nettement plus intéressant est tel que :

chaque jour vers 02h00
→ Le processeur augmente fortement
→ Les E/S augmentent
→ Les limites sont atteintes
→ Le site Web réagit lentement en même temps

Un tel schéma récurrent plaide en faveur d'une analyse plus approfondie des processus en cours à ce moment-là.

Comparer les tâches cron avec les événements de ressources #

Si des problèmes de ressources surviennent régulièrement à la même heure, vérifiez également les tâches cron planifiées.

Un processus d'importation, d'exportation, de sauvegarde ou de synchronisation peut entraîner un profil de charge récurrent.

Nous expliquons comment enquêter sur les problèmes de tâches cron sur La tâche cron ne fonctionne pas : causes et solutions.

Plusieurs tâches cron en même temps #

Si plusieurs tâches cron gourmandes en ressources démarrent exactement en même temps, leurs besoins peuvent s'additionner.

Par exemple :

02:00 → Importation
02:00 → Exportation
02:00 → Synchronisation
02:00 → Processus de maintenance

Si les applications respectives sont flexibles dans le temps, il peut être judicieux de répartir les heures de démarrage.

Ne modifiez toutefois pas les programmes prédéfinis par une application sans les avoir vérifiés.

Les sauvegardes peuvent nécessiter des ressources #

Les processus de sauvegarde et d'archivage peuvent consommer du processeur, des E/S et d'autres ressources en fonction de leur ampleur.

Si un pic de charge se produit pendant une sauvegarde, le contexte temporel est donc pertinent.

Cependant, cela ne signifie pas automatiquement que la sauvegarde est défectueuse.

Les importations et les exportations peuvent provoquer des pics de charge #

Les grands volumes d'importation et d'exportation de données sont des exemples typiques d'opérations temporairement gourmandes en ressources.

Un import de produits WooCommerce, une opération de base de données importante ou le traitement de nombreux fichiers peuvent temporairement nécessiter nettement plus de ressources que le fonctionnement normal du site web.

Les plugins WordPress comme cause potentielle #

Sur WordPress, les plugins peuvent exécuter des tâches en arrière-plan, des requêtes de base de données ou des connexions externes.

Si un problème de ressources survient immédiatement après l'installation ou la mise à jour d'un plugin, cette corrélation temporelle doit être étudiée.

Le plugin n'est donc pas encore prouvé automatiquement comme étant la cause.

Vous trouverez un diagnostic systématique des conflits sur Détecter et résoudre les conflits de plugins et thèmes WordPress.

WooCommerce nécessite souvent un traitement plus dynamique #

Les boutiques en ligne contiennent de nombreuses sections qui ne peuvent pas être traitées simplement comme des pages statiques.

Le panier, le tunnel de commande, le compte client, les commandes, les tâches d'arrière-plan et divers modules complémentaires peuvent générer un traitement dynamique supplémentaire.

Par conséquent, une boutique WooCommerce ne devrait pas être comparée à un simple site web d'information uniquement sur la base du nombre de visiteurs.

Les bots peuvent consommer des ressources #

Il n'y a pas que les visiteurs humains qui génèrent de la charge.

Les robots, les crawlers et les scanners automatisés peuvent envoyer de nombreuses requêtes à un site Web.

Par conséquent, si une charge de ressources inhabituelle coïncide avec un trafic important, les statistiques d'accès ou les journaux d'accès peuvent également s'avérer pertinents.

De nombreux visiteurs ne signifient pas automatiquement des problèmes de ressources #

Un nombre élevé de visiteurs en soi ne dit pas grand-chose sur les ressources serveur nécessaires.

Sont déterminants, entre autres :

• combien de requêtes simultanées sont effectuées
• à quelle vitesse PHP les traite
• l'efficacité des requêtes de base de données
• Quels contenus peuvent être mis en cache
• Quels plugins ou applications sont impliqués

Un site web bien optimisé peut par conséquent traiter nettement plus de demandes qu'un site techniquement inefficace doté d'une application comparable.

La mise en cache peut réduire la charge dynamique #

Lorsque le contenu n'a pas besoin d'être entièrement généré à nouveau par PHP et la base de données à chaque requête, la mise en cache peut réduire considérablement la charge dynamique du serveur.

CURIAWEB fournit un tel outil dans cPanel avec AccelerateWP.

Tu trouveras plus d'informations sur AccelerateWP dans cPanel expliqué.

La mise en cache ne résout pas tous les problèmes de ressources #

Un cache est particulièrement utile pour les requêtes qui peuvent être utilement mises en cache.

Il ne résout pas automatiquement, par exemple :

• tâches cron défectueuses
• processus backend extrêmement complexes
• opérations de base de données mal programmées
• certaines tâches de fond WooCommerce
• fuites de mémoire ou de code défectueux

N'activez donc pas de systèmes de cache supplémentaires de manière aléatoire si la cause réelle est inconnue.

Plusieurs plugins de cache peuvent poser problème #

Plus de mise en cache ne signifie pas automatiquement plus de vitesse.

Plusieurs solutions de mise en cache et d'optimisation fonctionnant simultanément peuvent s'influencer mutuellement ou créer une complexité inutile.

Utilisez par conséquent une configuration contrôlée et adaptée à l'environnement d'hébergement.

La version de PHP peut influencer l'utilisation des ressources #

Les versions de PHP se distinguent notamment en termes de performances et de compatibilité logicielle.

Une version de PHP obsolète ou inadaptée à l'application peut par conséquent être également pertinente, de manière indirecte, pour l'analyse des ressources.

Vous gérez fondamentalement la version PHP d'un domaine sur CURIAWEB via le MultiPHP-Manager.

Ne changez pas de version de PHP uniquement parce qu'une valeur de ressource est élevée. Vérifiez d'abord la compatibilité de votre application.

La limite de mémoire PHP n'est pas un paramètre de performance #

Une erreur fréquente consiste à simplement modifier la version de PHP pour un site web lentlimite_mémoire d'augmenter fortement.

La limite de mémoire fournit simplement à un processus PHP une plage de mémoire maximale autorisée.

Cela ne rend pas PHP automatiquement plus rapide et ne met pas de puissance CPU supplémentaire à la disposition du compte d'hébergement.

Vérifier le journal des erreurs en parallèle #

Si un site web affiche des erreurs en même temps, vous devez également examiner le journal des erreurs en plus des valeurs CloudLinux.

Sous Lire le journal des erreurs cPanel et trouver les erreurs du site Web expliquons comment tu classes les messages typiques de PHP et du serveur web.

Problème de ressources ou erreur PHP ? #

Les deux problèmes peuvent provoquer des symptômes similaires.

Observation	Point de contrôle important
Erreur fatale PHP	Journal des erreurs
Taille de mémoire autorisée épuisée	Limite de mémoire PHP et application
Limitation CloudLinux documentée	Utilisation des ressources
Limite de ressources atteinte	Limites CloudLinux
Site web sporadiquement lent	Comparer le moment avec les ressources et les journaux
Espace de stockage plein	Utilisation de l'espace de stockage

Ne pas assimiler limite de CPU et base de données lente #

Lorsqu'une application consomme beaucoup de CPU, une requête de base de données inefficace peut être en cause. Cependant, la seule valeur du CPU ne le prouve pas.

Inversement, une application lente peut être ralentie par des API externes, des accès aux fichiers ou d'autres facteurs, sans que le processeur ne soit constamment à sa limite.

Le graphique des ressources vous montre était est débité – il ne montre pas automatiquement quel code de programme concret c'est la cause.

L'affichage CloudLinux n'est pas un débogueur de processus #

CloudLinux vous aide à circonscrire les goulots d'étranglement des ressources dans le temps et par type de ressource.

L'annonce indique par exemple :

La limite du processeur a été atteinte à 14h32

Cela ne signifie pas automatiquement :

Le plugin XYZ est coupable

Pour l'analyse des causes profondes proprement dite, vous devez combiner le moment des faits avec les activités du site web, les tâches cron, les journaux, les mises à jour ou d'autres informations techniques.

Ce qui s'est produit immédiatement avant le problème de ressources #

Si l'utilisation des ressources n'est anormale que depuis peu, vérifiez les modifications telles que :

• nouveau plugin installé
• Extension ou thème mis à jour
• nouveau site web importé
• Tâche cron configurée
• Solution de sauvegarde modifiée
• nouvelle campagne marketing lancée
• Trafic en forte hausse
• Extension WooCommerce activée
• Version PHP modifiée

Le lien temporel est un indice important, mais ce n'est pas encore une preuve.

Reproduire de manière ciblée la pointe de charge après modification #

Si une action spécifique est potentiellement responsable de la charge élevée, vous pouvez – à condition que l'action soit répétable sans danger – observer le déroulement de manière ciblée.

Par exemple :

Vérifier l'utilisation des ressources
        ↓
Noter l'heure
        ↓
Exécuter l'action concernée
        ↓
Vérifier à nouveau l'utilisation des ressources

N'exécutez plus plusieurs fois de processus de paiement, d'expédition, d'importation ou d'autres processus de modification si vous ne connaissez pas leur comportement en cas de répétition.

Héberger plusieurs sites web sur le même compte cPanel #

Lorsque plusieurs domaines ou applications sont hébergés sur le même compte d'hébergement, ils peuvent partager les ressources du compte.

Une utilisation élevée des ressources ne provient donc pas nécessairement du site Web sur lequel vous remarquez le problème en premier.

Prenez en compte toutes les applications et tous les processus d'arrière-plan du compte concerné.

Les installations anciennes ou oubliées peuvent générer des ressources #

Une installation de test WordPress qui n'est plus active peut toujours :

• être appelé par des bots
• Exécuter WP-Cron
• Les plugins se chargent
• traiter des tâches automatiques

Si plusieurs installations sont présentes dans le compte d'hébergement, tu dois par conséquent également prendre en compte les anciens systèmes de test.

Comparer les valeurs des ressources après l'optimisation #

Une fois que vous avez trouvé et résolu une cause spécifique, comparez ensuite l'utilisation des ressources dans des conditions aussi similaires que possible.

Exemple :

Avant :
Limite de CPU atteinte plusieurs fois par jour

Modification :
correction d'un processus d'arrière-plan défectueux

Après :
plus d'incidents CPU sur une période comparable

Cela vous permet de mieux juger si la mesure a réellement aidé.

Ne pas effectuer plusieurs optimisations en même temps #

Si vous en même temps :

tu changes de version de PHP
tu modifies le cache
tu désactives les plugins
tu déplaces les tâches cron
tu optimises la base de données

et que la charge diminue ensuite, tu ne sais pas quelle mesure en a été responsable.

Procédez donc de manière méthodique et étape par étape lors du diagnostic.

Quand une limite de ressources est-elle réellement pertinente ? #

Une limite est particulièrement pertinente lorsque plusieurs points se rejoignent :

• la limite est effectivement atteinte
• L'événement se produit de manière répétée.
• Le moment coïncide avec un problème de site web.
• le comportement peut être reproduit ou attribué à un processus

En revanche, une seule courte pointe de charge sans effets visibles ne doit pas être surestimée.

Ressources typiques et leur importance #

Ressource	Sens	Examiner d'abord à la limite
Processeur	Puissance de calcul	Processus PHP, application, tâches cron, trafic
Mémoire physique	Mémoire vive des processus de compte	processus parallèles/gourmands en mémoire
E/S	Débit de données lors des opérations sur les fichiers	Sauvegardes, Archive, Importer, Opérations sur les fichiers
IOPS	Nombre d'opérations d'E/S	de nombreuses petites opérations sur les fichiers
Processus d'entrée	processus simultanés / traités simultanément	requêtes dynamiques simultanées
Nombre de processus	Nombre total de processus en cours	Processus d'arrière-plan, tâches parallèles

Analyser systématiquement les valeurs de CloudLinux #

1. Notez la date et l'heure du problème du site web.
2. Ouvrir Valeurs mesurées → Utilisation des ressources.
3. Sélectionnez une période appropriée.
4. Vérifiez si CloudLinux signale une limite de ressources atteinte.
5. Identifiez la ressource concernée.
6. Vérifiez les défauts ou les événements de limite.
7. Compare leur moment avec le problème du site Web.
8. Vérifier les tâches cron, les importations, les sauvegardes et les autres activités à ce moment-là.
9. En cas d'erreurs sur le site Web, vérifiez également le journal des erreurs.
10. Modifiez ensuite spécifiquement une seule cause possible.
11. Comparez à nouveau l'utilisation des ressources après la modification.

Ce que tu ne dois pas faire en cas de ressources élevées #

Évitez en particulier les mesures hâtives suivantes :

• Augmenter globalement la limite de mémoire PHP de manière excessive
• Changer la version PHP sans vérification de compatibilité
• désactiver plusieurs plugins en même temps
• Supprimer des fichiers par précaution
• installer plusieurs plugins de cache
• Supprimer des tâches cron au hasard
• interpréter un seul pic comme une surcharge permanente

Conseil pratique : L'analyse des ressources est un diagnostic temporel. La question n'est pas seulement „ Quelle valeur est élevée ? “, mais surtout „ Quelle limite a été atteinte, quand, et qu'est-ce qui s'est produit exactement à ce moment-là ? “

Si le site Web est lent, mais qu'aucune limite n'est atteinte #

Si CloudLinux ne montre aucun événement de limite pertinent, vous ne devriez pas essayer davantage de forcer un problème de ressources.

Un site web lent peut avoir de nombreuses autres causes.

Cela comprend par exemple :

• requêtes de base de données lentes
• APIs externes
• grandes images ou mal optimisées
• JavaScript dans le navigateur
• Plugins ou thèmes
• mise en cache manquante ou inappropriée
• Dépendances DNS ou réseau

CloudLinux n'est alors qu'une cause possible, que tu as déjà pu mieux circonscrire grâce aux mesures.

Si le site Web n'est pas accessible du tout #

Dans le cas d'un site Web totalement inaccessible, vous ne devez pas vous fier exclusivement à l'affichage de CloudLinux.

Le DNS, la configuration des domaines, le SSL, le serveur web, PHP, l'application et d'autres niveaux peuvent également être pertinents.

Nous traitons le diagnostic complet sous Site web inaccessible : diagnostiquer systématiquement les erreurs d'hébergement.

Quand devez-vous contacter le support CURIAWEB ? #

Si votre compte d'hébergement atteint régulièrement les limites de ressources et que vous ne parvenez pas à identifier clairement l'application ou la tâche responsable, documentez le problème aussi précisément que possible.

Sont particulièrement utiles :

• domaine ou application concerné
• Date et heure du problème
• ressource concernée
• événements de limite visibles ou défauts
• comportement visible du site Web
• que le problème survienne régulièrement ou une seule fois
• modifications récentes
• les tâches cron, les importations ou autres tâches en cours d'exécution à ce moment-là
• le cas échéant, les entrées de journal des erreurs pertinentes

Plus le moment est connu avec précision, plus il est facile d'associer un événement de ressource à une activité spécifique.

Résumé #

Sous Valeurs mesurées → Utilisation des ressources vous pouvez vérifier dans le cPanel de CURIAWEB comment votre compte d'hébergement utilise les ressources gérées par CloudLinux.

Parmi les principaux paramètres de mesure figurent le processeur (CPU), la mémoire physique, les E/S (I/O), le cas échéant les IOPS, les processus d'entrée (Entry Processes) et le nombre total de processus.

Ces valeurs ne doivent pas être confondues avec l'espace de stockage ou la bande passante. De même, la mémoire physique CloudLinux n'est pas la même que le PHP-limite_mémoire.

Pour le diagnostic, il n'y a pas que les valeurs mesurées élevées qui comptent. Il est particulièrement crucial de savoir si une limite de ressources a effectivement été atteinte, quand cela s'est produit et si ce moment coïncide avec un problème visible du site web.

Les « Entry Processes » ne correspondent pas au nombre de vos visiteurs. De même, une valeur CPU de 100 % dans l'affichage des ressources ne signifie pas automatiquement que l'ensemble du serveur d'hébergement est pleinement sollicité.

Des pics de charge brefs peuvent être normaux lors d'importations, de sauvegardes, de tâches cron ou d'autres opérations. En revanche, des événements de dépassement de limites récurrents associés à un site web lent ou défectueux doivent être examinés de plus près.

Comparez les événements de ressources avec les tâches cron, les mises à jour, le trafic, les journaux d'erreurs et d'autres activités au même moment. Modifiez ensuite toujours une seule cause possible à la fois et vérifiez si le comportement s'améliore.

La règle la plus importante est : Ne pas chercher la valeur la plus élevée, mais associer l'événement de limite réel avec l'horodatage et l'activité responsable.