Problème de lenteur affichage pages admin (Résolu)

[melodie]

Bonjour,

Encore moi.

Les pages s'affichent moins vite que cet escargot : http://melodie.citrotux.org/2009/06/27/ip-sur-escargot , pour quelle que manipulation que ce soit sur Citrotux, même charger une simple page d'une autre section de l'administration.

Le site est à jour, j'ai fait la maj la nuit dernière. Ça s'est bien passé, le serveur Legtux affichait un fonctionnement normal, sur la page d'accueil du site Legtux, mais que chaque étape a été lente !

Y aurai-t-il une solution côté serveur pour que ça soit plus fluide ?

Merci,
Mélodie

[Simon Le Guével]

Bonsoir,

Les gens consomment de plus en plus de ressources, on ne peut rien y faire à part fermer temporairement les inscriptions

[hamza]

Je confirmes le problème reporté par melodie. Sous Wordpress, vous pouvez avoir quelques latences due au fait qu'il y a pas de cache dans l'Administration WP. Quand on arrives à avoir ~38Go de data transférer depuis le MySQL seulement en une journée, c'est qu'il y a une surconsommation de la part de quelque utilisateurs.

Quelque chiffres, Il y a environ 1 à 2 semaines, nous (l'ensemble des utilisateurs LegTux) étions à 90 requêtes SQL par seconde en moyenne. Maintenant, nous sommes à environ 110 requêtes SQL par moyenne par seconde. Une consommation grandissante. Le serveur MySQL (LegTux) a envoyé pas loin de 235 Go de données en moins d'une semaine. Nous sommes arrivé à un point ou le serveur MySQL ne tient plus la charge et donc "refuses" 10 connexions en moyenne toutes les heures.

Donc, éviter les "SELECT *"

P.S : Le temps d'écrire ce message, 200Mo de données ont été envoyé depuis le serveur MySQL.

[Simon Le Guével]

Les valeurs données par Hamza sont réelles.
Le problème vient de tous les CMS utilisés sans cache. On a pourtant recommandé plusieurs fois d'installer le plugin WP-Supercache pour Wordpress, ça évite des requêtes SQL inutiles.

Un autre problème est aussi qu'il y a une sur-utilisation des CMS, notamment pour des sites statiques, les gens préfèrent installer un WP ou un Joomla plutôt que de faire une simple HTML pourtant bien moins éprouvante pour le serveur (et donc plus rapide à charger). "Incompétence" ou solution de facilité ? Je ne sais pas.

En attendant, je vais diminuer le nombre de comptes sur le serveur, ça sera déjà ça.

[hamza]

Pourquoi pas envoyer une newsletter pour avertir les utilisateurs et leur faire comprendre que les pages statiques généré à la volé (et donc dynamique) sont gênante pour les ressources serveur.

Un autre problème est aussi qu'il y a une sur-utilisation des CMS, notamment pour des sites statiques, les gens préfèrent installer un WP ou un Joomla plutôt que de faire une simple HTML pourtant bien moins éprouvante pour le serveur (et donc plus rapide à charger). "Incompétence" ou solution de facilité ?
Je penses plutôt que la plus part des utilisateurs qui agisse de cette façon, le font pour la facilité d'utilisation et en grande partie pour les templates mis à disposition par les communautés "CMS"

Le problème vient de tous les CMS utilisés sans cache. On a pourtant recommandé plusieurs fois d'installer le plugin WP-Supercache pour Wordpress, ça évite des requêtes SQL inutiles.
Pourquoi, ne pas l’intégrer dans le package WordPress fourni par Legtux ? Bien sur, il devra être notifié qu'un plugin (thrid party) a été inclut.

Quelque choses à savoir afin que vous (utilisateurs de Legtux) pourrez éviter de faire,

Le site est à jour, j'ai fait la maj la nuit dernière. Ça s'est bien passé,

Le fait de lancer une mise à jour/modification importante sur votre compte par le biais d'outil tel que WP Update Manager comme melodie sembles avoir fait peux provoquer plus de problèmes que vous le pensez.

Quelque explications,
Lors que vous lancer une mise à jour par exemple sous WordPress. Votre WordPress utilises une fonction php nommée fsockopen qui lui permet de télécharger la mise à jour puisque vous lui avez demander de faire la mise à jour automatiquement. Donc ici, consommation de bande passante pas enorme mais consommation quand même, après vous lui demander de mettre à jour votre WordPress et donc les fichiers qui le compose ce qui provoque une avalanche d’opérations de fichiers sur les disques dur du serveur Legtux (2 fois un disque de 1To en RAID 1). Souhaitant avoir une sécurité maximal pour ses utilisateurs, Legtux utilises une technologie nommé RAID et plus précisément dans le cas de Legtux, RAID 1 (Disque miroir). En clair, chaque opérations de fichiers effectué sur votre compte ou bien même le simple ajout d'un enregistrement dans votre base de donnée est fait 2 fois pour une sécurité renforcer. Bref, ce n'est pas ça le problème, c'est que certains d'entre vous utilisant WordPress ou autre CMS (Gestion de contenu) utilises une belle fonction nommé plus communément "Mise à jour automatique" qui surcharges le processeur du serveur pour des choses basique tel que une mise à jour automatique de WordPress.

Maintenant, il y a "Mise à jour automatique" et "Mise à jour automatique", et oui, certains CMS comme phpBB "fusionnes" les fichiers présents sur le serveur avec ceux de la mise à jour, ce qui augmentes d'avantage la charge processeur que votre compte utilises. C'est pour cela que je recommandes l'utilisation d'un client FTP pour effectuer la mise à jour des vos fichiers puis de lancer l'assistant de mise à jour pour "mettre à jour" votre base de donnée ou le schéma qui la composes.

Utiliser un client FTP, c'est bien mais avec modération, surtout quand on augmentes le nombre de transferts simultanés de 2 à 10 pour "accélérer" le transfert de vos fichiers. Faites attention, à chaque fois que vous uploader/envoyés un fichier via FTP, vous faites 1 requête SQL pour vous identifier auprès de la base de données Legtux. Désolé, mais pour permettre un accès à tous le monde, les connexions persistante sont désactivés car le quota par défaut des serveurs FTP est de 500 "connectés". Donc vous transférer 10 fichiers simultanément, vous faites 500-10=490 connexions restantes. Je ne penses pas que Legtux augmentera le quota puisque cela augmentera la charge CPU et surtout le nombre de requêtes SQL envoyé au serveur MySQL. Et donc dégradera la qualité de service qu'il fournit.

Encore un exemple qui me touches tous les jours, moi comme d'autres utilisateurs voulons effectuer une action automatiser/tache planifié tous les jours, juste parce que la charge est trop élevé, mon cron personnel ne sais jamais exécuté et la raison est simple, le "robot" qui exécutes les taches planifiés laches/tomber bien avant d'arriver à mon compte.

Je sais que vous voulez aidez Legtux, et je vous y encourage vivement, même si vous n'avez pas les moyens financier pour faire des dons réguliers/ponctuels, vous pouvez aidez Legtux en diminuant votre empreinte en terme de ressource sur le serveur. Legtux est géré par seulement 2 personnes actuellement, elles sont tous les deux bénévoles et "gères" dans le temps libre sans aucune contre partie.

Donc, essayez d'utiliser au minimum le PHP et surtout le MySQL quand cela n'est pas nécessaire. Je dirais même que c'est mieux d’utiliser la crontab/tache planifié pour effectuer une action à une certaine heure que d'utiliser PHP et de vérifier avec des fonctions comme date qui sont elles-même consommatrice de ressource

[melodie]

Salut,

Le plugin wp-supercache posait des problèmes. Je ne sais plus quoi, j'avais testé en mode debug et il générait des erreurs. Je vais regarder ce qui se fait maintenant.

PS: le planet.legtux plante avec une "Internal Server Error" luguubre !!

Internal Server Error

The server encountered an internal error or misconfiguration and was unable to complete your request.

Please contact the server administrator, [no address given] and inform them of the time the error occurred, and anything you might have done that may have caused the error.

More information about this error may be available in the server error log.

PS-2 : la fonction de mise à jour automatique de Wordpress est précisément un des éléments clé qui fait son avantage. Mon site est un multisites : un seul moteur pour plusieurs sites ! Une seule mise à jour de chacun des composants qui est partagé entre le site et les sous-sites ! J'ai un certain nombre d'extensions fonctionnelles et quelques autres pour la sécurité. Je n'active que celles dont j'ai besoin, et celles qui ne sont là que pour servir de temps en temps sont installées mais ne sont pas activées tout le temps. Vu le nombre de ces plugins et vu le temps que prend une mise à jour générale de ceux-ci, ainsi que des thèmes, si je ne pouvais pas utiliser la mise à jour en automatique, il vaudrait mieux que j'aille mettre en ligne ailleurs. Pour ce qui est du moteur par contre, je préfère toujours le ftp parce que j'en profite pour faire une vraie mise à jour, en ne conservant du site que ce qui est utile et pas plus. Bien entendu tous les plugins sont désactivés au moment de commencer cette mise à jour du moteur. Enfin, je ne fais pas des mises à jour à chaque fois qu'il s'en présente, je fais les mises à jour des extensions juste avant de mettre à jour Wordpress lui-même. C'est bien de donner des conseils et des suggestions sur quoi faire mieux et comment, je peux tout de même dire que au début, ça marche bien et au bout d'une paire d'années ça devient lent. Je me demande s'il n'y aurait pas autre chose, dû à l'âge de l'installation ?

[melodie]

Bonjour,

J'ai fait la mise à jour complète de Citrotux, de la manière décrite ci-dessus. J'ai ajouté Quick Cache, un plugin de cache Wordpress bien noté, l'affichage de Citrotux est toujours lent. L'affichage du site Legtux est très lent aussi aujourd'hui. Le serveur est en surcharge selon la page d'accueil de Legtux. Même l'affichage du forum et le changement de page dans le forum est lent aujourd'hui.

Voilà, je voulais le signaler.

Notez que sous Linux, les fichiers se fragmentent aussi : à la longue. Je dis ça, je dis rien…

[Simon Le Guével]

Bonsoir Mélodie,

Je sens comme une pointe de méchanceté dans tes messages, je me trompe ?
Le serveur MySQL est responsable de la charge, principalement au niveau du disque qui est le goulot d'étranglement (le SSD, c'est cher). Et oui, au bout « d'une paire d'années », ça marche moins bien, ce qui fonctionnait bien avec 1400 utilisateurs et le trafic de 2010 fonctionne moins bien en 2012.

Il va encore falloir diminuer le nombre de comptes admissibles sur le serveur puisque chaque compte consomme plus.
J'ai monté ton timeout à 600 secondes, si ça peut aider à finir tes mises à jour...

[melodie]

Bonsoir Mélodie,

Je sens comme une pointe de méchanceté dans tes messages, je me trompe ?

Bonsoir Simon,
Oui tu te trompes. J'ai juste été pas très contente de ce que disait hamza quand j'ai eu fini de lire son post plus attentivement, et ce à propos de l'idée de télécharger les plugins un par un pour les mettre à jour en ftp. Je gère aussi pclinuxos-fr.org, linuxvillage.org, et un autre multisites plus personnel, et les mises à jour en automatique c'est vraiment très pratique (déconseillé pour la mise à jour du site lui-même, mais surtout pour le fait qu'il vaut mieux supprimer des vieux fichiers qui peuvent ne plus exister dans une nouvelle mouture).

Pour le reste, je ne fais que rapporter des observations. (planet qui ne s'affichait pas, forum qui était lent aussi... ), ça a l'air d'aller mieux, ce soir.

Le serveur MySQL est responsable de la charge, principalement au niveau du disque qui est le goulot d'étranglement (le SSD, c'est cher). Et oui, au bout « d'une paire d'années », ça marche moins bien, ce qui fonctionnait bien avec 1400 utilisateurs et le trafic de 2010 fonctionne moins bien en 2012.

Écoute Simon, j'ai eu mon blog sur deux autres hébergeurs, tous deux libristes, un libre et l'autre professionnel et jusqu'ici partout le constat est le même : après deux ans environ ça marche moins bien. Je veux bien que ce soit dû au nombre des utilisateurs qui croît, même sur deux hébergeurs libristes utilisant des hébergements en mutu, mais chez un professionnel aussi ? Je soupçonne que les systèmes de fichiers linux se soient fragmentés au bout de ce laps de temps. (Et oui, les partitions linux se fragmentent aussi, même si c'est supra lent comparé à ce qui peut se passer dans une Ntfs). Si ce que je dis peut être juste, une solution serait de faire des transferts de fichiers sur une partition fraiche. Quand à mysql, eh bien en effet ça pourrait aussi être bien de faire une installation fraiche, car pour ce qui est de Wordpress je me suis rendue compte un jour où j'éditais un dump que c'est bourré de données tout à fait inutiles, comme des infos en provenance de backtracks ou je ne sais pas quoi comme news de chez eux.

Il va encore falloir diminuer le nombre de comptes admissibles sur le serveur puisque chaque compte consomme plus.
J'ai monté ton timeout à 600 secondes, si ça peut aider à finir tes mises à jour...

Merci bien. Je te dirai comment ça se passe à la prochaine occasion de mise à jour, et je vais surveiller un peu pour voir si après avoir installé Quick Cache l'affichage des pages est plus réactif.

Bonne nuit.

PS: pour infor, je viens d'essayer d'aller visiter le planet, que je ne connais pas encore, et ça affiche encore une page 500 etc... comme hier.

Internal Server Error

The server encountered an internal error or misconfiguration and was unable to complete your request.

Please contact the server administrator, [no address given] and inform them of the time the error occurred, and anything you might have done that may have caused the error.

More information about this error may be available in the server error log.

:-/

[Simon Le Guével]

Le serveur MySQL est responsable de la charge, principalement au niveau du disque qui est le goulot d'étranglement (le SSD, c'est cher). Et oui, au bout « d'une paire d'années », ça marche moins bien, ce qui fonctionnait bien avec 1400 utilisateurs et le trafic de 2010 fonctionne moins bien en 2012.

Écoute Simon, j'ai eu mon blog sur deux autres hébergeurs, tous deux libristes, un libre et l'autre professionnel et jusqu'ici partout le constat est le même : après deux ans environ ça marche moins bien. Je veux bien que ce soit dû au nombre des utilisateurs qui croît, même sur deux hébergeurs libristes utilisant des hébergements en mutu, mais chez un professionnel aussi ? Je soupçonne que les systèmes de fichiers linux se soient fragmentés au bout de ce laps de temps. (Et oui, les partitions linux se fragmentent aussi, même si c'est supra lent comparé à ce qui peut se passer dans une Ntfs). Si ce que je dis peut être juste, une solution serait de faire des transferts de fichiers sur une partition fraiche. Quand à mysql, eh bien en effet ça pourrait aussi être bien de faire une installation fraiche, car pour ce qui est de Wordpress je me suis rendue compte un jour où j'éditais un dump que c'est bourré de données tout à fait inutiles, comme des infos en provenance de backtracks ou je ne sais pas quoi comme news de chez eux.

Il y a certainement un peu de fragmentation, mais ce n'est pas le principal problème.
Aujourd'hui, on est à 158 requêtes SQL par seconde en moyenne (stats les 8 derniers jours), alors que c'était deux fois moins important il y a un an.
Ça ne vaut vraiment pas le coup de passer une nuit entière à copier des données pour un problème de fragmentation. Mieux vaut attendre le prochain upgrade de serveur !

PS: pour infor, je viens d'essayer d'aller visiter le planet, que je ne connais pas encore, et ça affiche encore une page 500 etc... comme hier.

Ça c'est autre chose, la récupération des flux RSS ne se passe pas comme elle le devrait, il va falloir voir ça !