Comprendre et vérifier les limites LVE de CloudLinux dans l'hébergement mutualisé

Ce qui limite un LVE en hébergement mutualisé

Dans le cadre de l'hébergement mutualisé, plusieurs clients se partagent les ressources d'un serveur. CloudLinux permet de surveiller l'utilisation d'un compte client à l'aide d'un Environnement virtualisé léger, ou LVE en abrégé. C'est le fournisseur qui définit ces limites. Elles visent à empêcher qu'un compte n'utilise des ressources de manière illimitée ; à l'inverse, votre propre site web peut également atteindre ces limites.

Une limite correspond à un plafond et ne correspond pas automatiquement à une ressource réservée. Une limite de CPU, par exemple, ne signifie pas qu’un cœur de processeur t’est exclusivement réservé ni qu’un temps de réponse spécifique t’est garanti. La vitesse de fonctionnement d’une application dépend également de sa tâche, du matériel et d’autres composants.

Un LVE ne transforme pas non plus votre forfait d'hébergement en serveur dédié. Le fournisseur continue de gérer l'environnement partagé et en détermine la configuration. En tant que client, vous ne pouvez vérifier par vous-même les paramètres en vigueur et leurs conséquences que dans la mesure où votre forfait et le panneau d'hébergement fournissent les informations correspondantes.

Il convient de distinguer cela de CageFS: Cela concerne l'isolation de la vue du système de fichiers, tandis que les limites LVE restreignent l'utilisation des ressources. Ces deux fonctions peuvent se compléter, mais ne sont pas identiques. Le fournisseur pourra te confirmer quels composants sont effectivement actifs dans ton offre.

Tu trouveras une présentation plus détaillée des composants dans l'article consacré à la Isolement des processus avec CloudLinux SecureLVE. Pour un dépannage concret, la configuration de ton propre pack reste toutefois déterminante : l'interface et le niveau de détail de l'affichage des ressources peuvent varier en fonction du panneau et des options activées.

À qui s'appliquent ces limites ?

Ce qui est déterminant, ce n'est pas seulement le montant d'une limite, mais aussi son Champ d'application. Si, par exemple, vous gérez un blog et une boutique en ligne sur le même compte d'hébergement, les deux peuvent utiliser le même budget de ressources dans le cadre d'une configuration liée au compte. Une importation dans la boutique peut alors mobiliser des ressources dont le blog a également besoin au même moment.

Cela ne signifie pas que chaque page lente soit due à un autre projet du compte. Mais cela explique pourquoi, en cas d'incident, il ne faut pas se limiter à examiner uniquement le domaine concerné. Les tâches planifiées et les autres sites web du même compte peuvent également jouer un rôle pendant la période en question.

CloudLinux fournit une documentation sur Isolats elle offre également la possibilité de définir des limites au niveau du site web. La désignation « CloudLinux » ne permet pas à elle seule de déterminer si cette fonctionnalité est utilisée ni comment elle s'applique dans l'offre concernée. Une analyse isolée ne remplace donc pas la consultation des conditions tarifaires concrètes.

Avant de comparer les offres, posez des questions aussi précises que possible au prestataire : les indicateurs SPEED, PMEM, IO, IOPS, EP et NPROC s'appliquent-ils par compte d'hébergement ou par site web ? Si plusieurs projets partagent un même budget, il est également important de savoir quels domaines et quelles tâches sont affectés à ce budget. Tu éviteras ainsi de prévoir par inadvertance une valeur indiquée pour chaque site web individuellement.

Si le panneau n'affiche qu'une seule statistique globale, celle-ci permet dans un premier temps de délimiter la période concernée, mais pas nécessairement d'attribuer la charge à une application spécifique. Veuillez alors contacter le service d'assistance pour savoir quelles ventilations sont disponibles et si la charge peut être attribuée à un projet ou à une tâche.

Distinguer le processeur, la mémoire et les limites d'accès

Les différentes limites de l'hébergement mutualisé restreignent divers types d'activités. SPEED correspond au budget CPU : s'il est épuisé, les processus gourmands en ressources sont ralentis et le traitement des requêtes peut prendre plus de temps. Une limite CPU dans l'hébergement n'est donc qu'une explication possible au ralentissement des pages ; elle n'est pas synonyme de toutes les limites de l'environnement virtuel (LVE).

PMEM limite la mémoire physique de l'entité LVE. En cas de pression sur la mémoire, le cache peut d'abord être libéré ; si cela ne suffit pas, des processus peuvent être arrêtés. Il convient de ne pas confondre cette valeur avec la valeur obsolète VMEM, qui concerne la mémoire virtuelle. Il en va de même pour le paramètre PHP-memory_limit ne doit pas être assimilé à l'ensemble du budget PMEM du LVE.

En matière d'accès aux fichiers, les termes « IO » et « IOPS » désignent des concepts différents : « IO » fait référence au débit de données, tandis que « IOPS » correspond au nombre d'opérations de lecture et d'écriture par seconde. Un grand nombre de petits fichiers peut donc atteindre une limite différente de celle atteinte par un petit nombre de fichiers volumineux. Dans ce contexte, « IO » ne désigne pas la vitesse de votre connexion Internet.

L'EP comptabilise les entrées dans le LVE et ne constitue pas une limite générale pour le nombre de visiteurs simultanés. La manière dont les entrées sont comptabilisées dépend, entre autres, du serveur web et du modèle de processus. NPROC limite en revanche le nombre de processus et de threads. Une fois cette limite atteinte, il n'est temporairement plus possible de créer de nouveaux processus ; EP et NPROC ne sont donc pas interchangeables.

L'espace de stockage et les inodes sont des éléments tarifaires liés, mais distincts. Un quota de fichiers épuisé ou une limite d'inodes atteinte ne constituent pas automatiquement un problème lié au CPU, à la mémoire PMEM ou à l'EP. Les valeurs que vous pouvez consulter dans le panneau de configuration dépendent du fournisseur et de l'interface mise à disposition.

Aperçu des limites LVE et de leurs conséquences

Les limites LVE n'ont pas toutes le même effet : certaines ralentissent les tâches en cours, d'autres empêchent le lancement de nouveaux processus ou peuvent mettre fin à des processus existants. Le tableau t'aide à associer une ressource affichée à son comportement et à une piste d'audit appropriée. Ce sont les valeurs limites concrètes qui sont définies par ton fournisseur.

À l'adresse suivante : Limite PMEM Ce n'est pas seulement la mémoire des processus d'application individuels qui est prise en compte. La mémoire partagée et le cache de fichiers peuvent également être pris en compte ; la prise en compte du cache dépend de la configuration. Lorsque des processus sont arrêtés, des erreurs HTTP peuvent survenir, mais ce n'est pas nécessairement la conséquence visible.

Ces deux limites d'accès aux fichiers correspondent à des grandeurs différentes : IO limite le débit de données, tandis que les IOPS correspondent au nombre d'opérations. De nombreux petits fichiers peuvent donc solliciter principalement les IOPS, tandis que les fichiers volumineux peuvent générer un débit élevé. Ici, « IO » ne désigne pas la bande passante réseau ; selon CloudLinux, les accès provenant du cache de fichiers ne sont pas pris en compte dans la limite IO.

Calculer la limite du processeur à l'aide d'un exemple

Supposons que ton colis ait un Limite de vitesse de 150 %. Étant donné que 100 % correspondent mathématiquement à un cœur de processeur, cela correspond à un budget CPU équivalent à un cœur et demi. Il s'agit d'un exemple de calcul à titre illustratif, et non d'une mesure. La valeur réelle de votre forfait peut être différente ; seules les informations fournies par le fournisseur font foi.

Cet exemple décrit une limite maximale pour le temps CPU utilisable, et non une réservation d'un cœur exclusif. Cela ne signifie pas non plus que chaque processus puisse utiliser un cœur et demi simultanément. La répartition du budget entre les tâches en cours dépend, entre autres, du nombre de processus qui ont effectivement besoin de temps de calcul en parallèle.

Un taux de 150 % ne garantit ni un temps de réponse ni un nombre précis de visiteurs pouvant être servis simultanément. Une requête simple peut nécessiter peu de calculs, tandis qu'une requête dynamique peut en nécessiter nettement plus. À cela s'ajoutent d'éventuels temps d'attente liés à l'accès aux fichiers ou aux opérations sur la base de données, qu'un budget CPU plus élevé ne supprime pas automatiquement.

Même des pourcentages identiques sur différents serveurs ne permettent pas de comparer directement les vitesses : les cœurs de processeur peuvent présenter des performances différentes. Pour évaluer la limite de votre CPU, il est donc plus important de vérifier si, lors d'un problème concret, l'utilisation se situe de manière répétée à la limite et si des événements de seuil correspondants sont visibles. Même dans ce cas, tu devrais vérifier d'autres causes possibles.

Bien interpréter les indicateurs de ressources

Si votre fournisseur a activé l'affichage des ressources, commencez par un incident aussi précisément cerné que possible. Notez le nom de domaine, la date, l'heure et le fuseau horaire, ainsi que, le cas échéant, le statut HTTP affiché. Décrivez également ce qui était lent ou n'a pas fonctionné. Sans ces informations, il est difficile d'associer un pic dans les statistiques à un problème concret.

Sélectionnez ensuite la même période dans l'affichage et comparez, pour chaque élément (CPU, PMEM, IO, IOPS, EP et NPROC), l'utilisation, la limite définie et, le cas échéant, les valeurs affichées Erreurs. Toutes les interfaces n'affichent pas les mêmes données. S'il te manque des statistiques ou si tu ne sais pas à quel compte elles se rapportent, renseigne-toi auprès du prestataire.

Fais attention à la résolution temporelle: Une moyenne horaire faible peut masquer un bref pic correspondant à l'atteinte d'une limite. Si possible, choisissez une période plus courte ou un affichage plus détaillé. Comparez ce pic à l'heure de l'erreur consignée, plutôt que de conclure, sur la seule base d'une moyenne journalière ou horaire, qu'il n'y a pas eu de goulot d'étranglement.

Les erreurs signalent des événements limites, mais ne constituent pas un décompte direct du nombre de visiteurs concernés ou de pages non chargées. Une erreur survenant à un moment donné constitue un indice, mais ne constitue pas encore une preuve complète de la cause. Vérifie donc également si, au même moment, une importation, une sauvegarde, une tâche planifiée ou une modification de l'application a eu lieu.

L'interface et ses fonctionnalités dépendent du panneau et de l'activation ; il n'existe donc pas de chemin de menu universel. Pour en savoir plus sur les aspects techniques de l'administration, consultez l'article consacré à CloudLinux LVE Manager et gestion des ressources Plus d'informations. Les étapes de configuration administrative décrites ici nécessitent toutefois des droits d'accès spécifiques et ne sont pas automatiquement disponibles pour votre compte client.

Classification des pages lentes et des erreurs

Si votre CMS est lent lors de la modification de pages ou lors de l'affichage dynamique de pages, comparez d'abord la période concernée avec l'affichage de l'utilisation du processeur. Si l'utilisation atteint de manière répétée la limite SPEED et que des erreurs correspondantes sont visibles, il s'agit d'un Limitation de la fréquence du processeur plausible. La coïncidence temporelle en fait un indice, mais ne prouve pas pour autant quelle tâche a été à l'origine de cette charge.

Vérifiez par exemple si des tâches planifiées sont en cours d'exécution au même moment ou si une modification apportée à des extensions coïncide avec le problème. Des opérations sur la base de données, des problèmes réseau ou une interface externe peu réactive peuvent également ralentir le chargement des pages. Une charge CPU élevée ne signifie donc pas en soi que le forfait choisi n’est pas adapté, ni qu’une extension particulière en est nécessairement responsable.

Si des erreurs surviennent lors de l'arrivée simultanée de plusieurs requêtes dynamiques, un Erreur EP aider. Les requêtes de longue durée occupent plus longtemps les connexions ; par ailleurs, un visiteur peut générer plusieurs requêtes. L'EP n'est donc pas un compteur de visiteurs. Sous Apache, le code HTTP 508 peut résulter d'un dépassement de la limite d'EP, mais ce code d'état ne suffit pas à lui seul à en expliquer la cause.

Si un message d'erreur PMEM s'affiche pendant une importation, la limite de mémoire LVE peut en être la cause. Outre l'importation, des processus PHP s'exécutant simultanément peuvent également monopoliser de la mémoire ; sans données de processus appropriées, il est impossible de déterminer quelle tâche a été à l'origine du problème. De même, une erreur HTTP 500 ou 503 peut avoir d'autres causes et ne constitue pas en soi une preuve de manque de mémoire.

La valeur PHP memory_limit Cela ne répond pas à cette question à lui seul : cela ne décrit pas l'utilisation totale de la mémoire par toutes les tâches du LVE. Comparez donc l'heure de l'importation avec l'utilisation de la mémoire PMEM et les erreurs, et notez quelles autres tâches s'exécutaient en parallèle avant de modifier un paramètre ou le tarif.

Vérifier la charge de fond et faire appel au support technique

Si une sauvegarde ou une importation de fichiers est lente, vérifiez IO et IOPS distincts. L'IO limite le débit de données lors des accès au disque dur, tandis que l'IOPS désigne le nombre d'opérations de lecture et d'écriture par seconde. Le transfert d'un grand nombre de petits fichiers peut donc atteindre une limite différente de celle du transfert d'un petit nombre de fichiers volumineux ; l'IO ne correspond pas à la bande passante Internet.

Une sauvegarde peut solliciter à la fois le processeur et la mémoire. Vérifiez donc non seulement les valeurs d'E/S et d'IOPS, mais aussi celles de SPEED et de PMEM pour la même période, au lieu de déduire la cause uniquement à partir de la durée. Selon CloudLinux, les accès effectués à partir du cache de fichiers ne sont pas pris en compte dans la limite d'E/S ; l'utilisation d'E/S affichée ne reflète donc pas de manière uniforme chaque accès au fichier.

Si une tâche planifiée peut être reportée, comparez son exécution habituelle pendant une période moins chargée à une période antérieure similaire. Tenez compte de l'ampleur de la tâche et des tâches exécutées en parallèle : une petite importation n'est pas directement comparable à une sauvegarde complète. Il n'est pas nécessaire de réaliser des tests de charge supplémentaires en production ni de supprimer des fichiers pour effectuer cette comparaison.

De même, les Charge de la base de données peut jouer un rôle, même si l'utilisation affichée du processeur Web est faible. Son attribution au compte et les éventuelles limites MySQL distinctes dépendent de la configuration. Demandez au fournisseur quelles valeurs de base de données vous pouvez consulter dans le panneau de contrôle et si l'activité de la base de données est comptabilisée dans le LVE ou si elle fait l'objet d'une limitation distincte.

Pour toute demande d'assistance, il est utile d'indiquer le nom de domaine, l'heure avec le fuseau horaire, le statut HTTP observé et l'opération concernée. Ajoutez les limites, les valeurs d'utilisation et les défaillances visibles au cours de la même période, ainsi que les importations ou sauvegardes connues. Veuillez nous fournir le classement des événements limites et, si possible, une analyse des instantanés de processus ; cela permettra de vérifier l'hypothèse de manière plus ciblée.

Optimiser, mettre à niveau ou changer de serveur ?

Commence par la Optimisation d'une tâche identifiée, si ses besoins en ressources peuvent être réduits de manière justifiable. Vérifie par exemple les paramètres de cache, les extensions et les tâches en arrière-plan planifiées en parallèle. Compare ensuite des périodes similaires et prête attention aussi bien aux problèmes rencontrés par les utilisateurs qu’aux valeurs des ressources concernées. Une modification unique permet ainsi de repérer plus facilement ce qui a réellement changé.

Une mise à niveau constitue une alternative lorsque des pics récurrents et avérés atteignent les limites attribuées malgré une optimisation adéquate. Renseignez-vous au préalable sur les valeurs concrètes de SPEED, PMEM, IO, IOPS, EP et NPROC. Ne vous contentez pas de comparer les noms des paquets : une limite CPU plus élevée ne résout ni une limite EP existant indépendamment, ni un manque de mémoire LVE.

Vers Comparaison des tarifs Le champ d'application en fait également partie. Indiquez au fournisseur le nombre de sites web que contient votre compte et demandez-lui s'ils partagent un budget de ressources commun ou si des limites s'appliquent par site web. CloudLinux propose une solution pour cette dernière option avec « Isolates » ; toutefois, le nom du produit ne permet pas à lui seul de déterminer si votre offre utilise cette fonctionnalité.

Un VPS ou un serveur géré peut offrir davantage de flexibilité, mais ne constitue pas pour autant une solution automatique pour tous les sites web lents. Les ressources disponibles, la charge réelle et le modèle d'exploitation sont déterminants : dans le cas d'un VPS, tu dois notamment préciser quelles tâches d'administration tu prendras en charge toi-même ; dans le cas d'un serveur géré, quelles tâches seront prises en charge par le fournisseur.

Si la cause reste inconnue, il est plus judicieux de se renseigner en fournissant les horaires et les erreurs relevés plutôt que de procéder à un changement à l'aveuglette. Même en dessous d'une limite LVE, l'application, le réseau ou la base de données peuvent ralentir le système. Avant de prendre une décision, assure-toi de connaître les statistiques et l'assistance disponibles dans l'offre concernée.