Mon site est lent/utilisation CPU trop élevée/nombre de processus
Vous avez peut-être reçu un message de notre part indiquant que votre site sollicite trop le CPU (les processeurs des serveurs) ou utilise trop de processus. Cela peut simplement venir d'un grand nombre de visiteurs, mais dans 99,9 % des cas, ce n'est pas la cause.
Certains sites volumineux ou lourds (comme les boutiques en ligne) ont besoin, en utilisation normale, de plus de puissance de calcul que d'autres sites. Si vous êtes convaincu que le site fonctionne correctement, ce qui suit ne s'applique pas. Dans ce cas, vous pouvez passer à une formule d'hébergement plus puissante, disposant de plus de puissance de calcul. Découvrez nos formules d'hébergement ici.
Nous expliquons brièvement ci-dessous les causes possibles d'une utilisation CPU élevée. Si une utilisation excessive du CPU n'est pas résolue (à temps), votre compte/site peut être limité (automatiquement). Dès que l'utilisation CPU redevient normale, votre site est automatiquement réactivé. Toutefois, si cela se répète en peu de temps, il finira par ne plus être réactivé automatiquement.
Ces mesures sont nécessaires pour protéger les serveurs contre la surcharge. En vous attaquant à la surcharge, vous réduisez non seulement l'utilisation CPU, mais votre site devient aussi nettement plus rapide et donc bien plus agréable à visiter.
Site lent et plugins
Les sites créés avec WordPress ou Joomla, par exemple, souffrent parfois de lenteur. La cause se trouve presque toujours dans des plugins qui fonctionnent mal ou sont tout simplement mal développés. Si vous constatez des lenteurs, nous vous conseillons de désactiver tous vos plugins et de vérifier si le site devient rapide. Si c'est le cas, réactivez les plugins un par un en vérifiant à chaque fois si le site reste rapide, jusqu'à trouver le coupable.
Site lent à cause de nombreux enregistrements en base de données
Une autre cause de lenteur peut être que la base de données contient tellement d'enregistrements (nous voyons parfois plusieurs millions d'enregistrements) que le site en pâtit. Il s'agit souvent de tables de statistiques ou de journalisation. Normalement, cela ne devrait pas poser de problème, mais si la table est mal conçue et que des recherches portent sur beaucoup de données sans index adapté, cela peut provoquer une grande lenteur.
Cache de votre navigateur
Il arrive régulièrement que ce ne soit pas le serveur mais votre propre navigateur qui soit devenu lent, à cause d'un cache trop plein. Videz ce cache et/ou essayez un autre navigateur pour voir s'il est lent aussi. Voir par exemple http://www.ehow.com/how_8618453_fix-slow-firefox-ie8-browsers.html
Fichiers journaux Apache / Liste des processus
Si vous avez reçu de notre part un message concernant le CPU, une liste de processus et d'adresses IP figure peut-être en bas de cet e-mail. Cette liste peut fournir des indices, mais il se peut aussi qu'il n'y ait pas de liste ou qu'elle contienne peu d'informations. Dans ce cas, les fichiers journaux peuvent vous aider. Vous y trouverez toujours des informations sur tous les visiteurs de votre site et sur les fichiers qu'ils ont demandés, et à quel moment. Parcourir ces fichiers autour de l'heure de l'alerte est une bonne idée et peut donner une bonne idée des problèmes possibles. Vous trouverez ces informations dans les fichiers journaux Apache. Vous pouvez les consulter via le panneau de contrôle, Site Summary / Statistics / Logs, puis Full Error Log/Usage Log pour le journal du jour. Les journaux des jours précédents se trouvent sous Backed up Apache logs. Vous pouvez aussi consulter ces journaux par FTP ou via le gestionnaire de fichiers, dans le dossier /domains/votredomaine.xx/logs. Notez que les sous-domaines ont des journaux distincts dans le menu des sous-domaines.
Dois-je m'inquiéter ?
Pas immédiatement. Ce n'est que si vous recevez ces avertissements très régulièrement qu'il y a probablement un problème structurel. Les fausses alertes sont rares, mais les conditions varient d'un moment à l'autre. Un script ou une requête mal conçu(e) peut ainsi fonctionner sans problème en temps normal, mais provoquer un avertissement lorsque le serveur concerné est plus chargé.
Causes possibles d'une utilisation CPU excessive
- Vous avez un album photo sur votre site et, au lieu de la version réduite des photos, vous avez mis la version complète en ligne. Lorsque vous affichez la photo, le CPU doit réduire la photo originale, qui pèse parfois plusieurs Mo, avant de pouvoir l'afficher. Si quelques visiteurs le font en même temps, cela peut entraîner une forte utilisation du CPU.
- Solutions possibles : ne mettez que des photos réduites sur votre site et, surtout, veillez à ce que la taille d'affichage des photos corresponde à leur taille réelle, afin que le serveur n'ait rien à réduire et n'ait qu'à les afficher. Mettez au besoin plusieurs versions sur le site : utiliser plus d'espace disque est moins grave qu'utiliser plus de CPU.
- Dans le prolongement de la première cause : afficher des photos via un programme PHP (streaming) est bien plus lent que d'intégrer directement l'URL de la photo.
- Solutions possibles : intégrez l'URL directe des photos, images, etc., sans passer par un programme PHP. C'est plus lent et cela sollicite inutilement le CPU.
- Vous permettez aux visiteurs de commenter un article, une photo ou autre chose. Si vous ne protégez pas cela avec un Captcha ou ne le limitez pas aux utilisateurs inscrits, des spammeurs peuvent en abuser, ce qui peut faire grimper (fortement) le CPU.
- Vous faites recharger automatiquement (refresh) une page toutes les X secondes, ce qui sollicite inutilement le CPU.
- Solutions possibles : supprimez le refresh de la page. Il se trouve généralement dans l'en-tête ou éventuellement dans du JavaScript.
- Vous utilisez une base de données pour votre site. Il est alors important que cette base de données soit entièrement optimisée, c'est-à-dire surtout qu'elle dispose d'index suffisants et corrects. Une base de données de quelques (dizaines de) milliers d'enregistrements/lignes, avec quelques visiteurs et une indexation mauvaise ou absente, peut très vite poser des problèmes de performance.
- Solutions possibles : optimisez votre base de données, MÊME s'il s'agit d'une base standard. Si vous utilisez par exemple OScommerce avec peu d'enregistrements, il n'y a aucun souci. Avec beaucoup d'enregistrements, il faudra vraiment optimiser. Non seulement l'utilisation CPU baisse fortement, mais votre site devient aussi nettement plus rapide et donc plus agréable à visiter.
- Votre site a fonctionné longtemps sans problème et devient soudain lent, et vous recevez des alertes CPU.
- Solutions possibles : il y a de fortes chances que le problème se trouve dans la base de données. Avec le temps, elle contient de plus en plus d'enregistrements/lignes, et l'on revient vite au point précédent : la base de données n'est pas correctement indexée. Il est important de bien optimiser la base de données.
- Vous avez un site avec un très grand nombre de fichiers séparés. Si vous lancez l'explorateur de fichiers dans DirectAdmin, vous obtenez probablement même un timeout, car il veut d'abord lire toute l'arborescence et cela prend trop de temps. Dans ce cas, vous ne pouvez pas utiliser le gestionnaire de fichiers dans DA et devez passer par FTP. Stocker plus de 1.000 fichiers dans un seul répertoire n'est de toute façon jamais recommandé. Un système d'exploitation a vite du mal avec cela, les sauvegardes deviennent lentes, l'ouverture des fichiers aussi, etc.
- Solutions possibles : utilisez si possible des fichiers zip ou rar ; créez des sous-répertoires/sous-dossiers avec au maximum 500 à 1.000 fichiers par répertoire/dossier. Mais pour un site web, il vaut vraiment mieux éviter les arborescences extrêmement volumineuses.
- Certaines tables de votre base de données ont peut-être grossi sans que vous le remarquiez. Il est bon de consulter de temps en temps votre base de données via phpMyAdmin et de vérifier si le nombre d'enregistrements par table correspond à vos attentes.
- Si certaines tables contiennent beaucoup d'enregistrements, vérifiez si c'est vraiment nécessaire et nettoyez les tables quand c'est possible. Sinon, vérifiez si votre base de données peut être optimisée.
Processus
Un serveur web peut gérer un certain nombre de processus simultanés (le nombre de processus n'a rien à voir avec le nombre de visiteurs). La particularité d'un processus de serveur web est qu'il n'est actif que très brièvement. Il livre la page à l'utilisateur, puis il a terminé. Cela se fait généralement en une fraction de seconde, parfois un peu plus pour les grandes pages. Ainsi, un processus peut livrer les pages pour de très nombreux sites/visiteurs. Lorsque des processus restent ouverts, ils ne sont plus recyclés : à terme, la mémoire du serveur se remplit et il devient inaccessible, surtout si le nombre de visiteurs augmente en même temps. Une situation indésirable et inhabituelle, donc. Avant d'en arriver là, nous intervenons automatiquement et le site concerné est désactivé.
Causes possibles d'un trop grand nombre de processus
- Vous avez un script/programme qui contacte un autre serveur, par exemple via curl, ce contact échoue et votre programme reste en attente. Si cela arrive pour plusieurs utilisateurs, un problème peut vite survenir.
- Veillez à ce que chaque appel soit toujours assorti d'un timeout. Jamais plus de 1 ou 2 secondes, car si l'utilisateur doit attendre plus longtemps, il quittera de toute façon la page.
- Votre site est « aspiré » (leeching). Cela signifie que quelque chose ou quelqu'un essaie de copier automatiquement votre site : tous les éléments, les photos, etc.
- Essayez d'extraire du journal Apache les adresses IP susceptibles d'en être à l'origine et bloquez-les. Consultez notre FAQ pour un article sur le blocage d'adresses IP.
- Vous lisez un flux RSS d'un autre site à chaque rafraîchissement de page. Ce n'est pas judicieux : cela ralentit tout inutilement et peut aussi provoquer ces problèmes.
- Lisez les flux RSS seulement toutes les X minutes, et uniquement s'il y a des visiteurs. Veillez aussi à ce qu'un timeout s'applique lors de la lecture de ces flux.