🌍
Français
ddtddt a écrit:
oliverfr a écrit:
Bonjour,
Les uploads depuis une connexion fibre 100/10 (j'uploade, en réel, à 1 Mo/s) et ADSL (à peu près deux fois plus lente)...Bonjour,
une piste de recherche
Qu'a tu installé comme librairie graphique ?
As tu essayer de la réinstallé ?
As tu essayer de passer par une autre libraire graphique ?
Bonjour !
Oui, j'ai brièvement fait utiliser gd au lieu de imagemagick, mais cela n'a causé aucun changement.
J'avais mis
$conf['graphics_library'] = 'gd';
$conf['show_exif'] = false;
$conf['use_exif'] = false;
Et l'accueil de piwigo disait qu'il utilisait bel et bien GD après cela. Hélas, à l'upload, pareil...
oliverfr a écrit:
Bonjour,
Les uploads depuis une connexion fibre 100/10 (j'uploade, en réel, à 1 Mo/s) et ADSL (à peu près deux fois plus lente)...
Bonjour,
une piste de recherche
Qu'a tu installé comme librairie graphique ?
As tu essayer de la réinstallé ?
As tu essayer de passer par une autre libraire graphique ?
Bonjour,
Les uploads depuis une connexion fibre 100/10 (j'uploade, en réel, à 1 Mo/s) et ADSL (à peu près deux fois plus lente)...
Bonjour,
je suis étonné aussi du phénomène. J'ai comme serveur un i7. J'arrive à charger à presque 100% les différents cœurs lorsque je génère en batch les différentes tailles d'images, mais jamais en uploadant des images.
Vos uploads travaillent sur des connexions fibres optiques à 100 Mb/s ? Ca je ne peux pas tester )=:
Heuuu... Aucune idée ^^
Cependant, j'ai regardé, sur mon propre serveur, mon cher kimsufi, j'ai aussi ces tables de toute petite taille, les utilisateurs sont aussi tous des non-enregistrés, et je peux allègrement lancer cinq uploads simultanés, et ce alors même qu'il y a des visiteurs en train de visiter la gallerie...
si je ne me trompe le cache est recalculé -à tort- à chaque page vue!
je notifie plg PS:en fait il est abonné à la discussion ^^
Hmm, il n'y a que trois ou quatre utilisateurs avec un compte, le reste ce sont des guests.
Phpmyadmin me -//:---\spam
piwigo_user_cache à 2.2 Ko
piwigo_user_cache_categories à 90 Ko
En comparaison, la BDD est petite, la plus grosse table est piwigo_images, autour de 10 Mo, juste précédée de piwigo_history à 15 Mo (qu'il faudrait purger de ses détails, tiens).
oula
c'est clair qu'à 130 000 lignes examinées tt les 2sec, ça mouline sec!
ce sont des guest qui visitent ou des utilisateurs?
la table de USER_CACHE_CATEGORIES_TABLE (sans les maj) ets remplie ?
Les plugins actifs sont :
Advanced Menu Manager, Comments On Albums, Grum Plugin classes.3, LocalFiles Editor, Statistics, Subscribe to Comments
Dans Local Files Editor > Local Config, il y a
$conf['derivative_default_size'] = 'large';
Il y a eu (puis ça a été enlevé, c'était pour tester)
$conf['graphics_library'] = 'gd';
$conf['show_exif'] = false;
$conf['use_exif'] = false;
Dans Local Files Editor > CSS, il y a
.browsePath{
width:75%;
(Aucune idée de pourquoi c'est là :D )
Et c'est tout...
vous avez une config locale ou un plugin perso ?
Rebonjour ! Cela fait un bout de temps, je reviens sur ce problème...
J'ai fait davantage de tests, et uploader une gallerie, ou supprimer les images d'une gallerie, cela met le serveur toujours à genoux, la totalité du CPU y passe, en passant d'une charge moyenne de 10-20% à 100% (et, si on regarde coeur par coeur, 600%, tous les coeurs y passent, et 0% idle).
Mes tests ont tout de même circonscrit un peu l'origine du problème :
- dire à piwigo d'utiliser GD à la place de ImageMagick : aucun changement
- dupliquer la totalité de la gallerie piwigo fautive, fichiers et BDD : le clone marche au poil
... MAIS, et c'est un MAIS de taille : si les visiteurs sont redirigés sur le clone de la gallerie piwigo, au bout de quelques minutes, cette fois-ci c'est le clone qui va mettre le serveur à genoux si j'uploade/downloade des images. Tandis que le piwigo original, lui, délesté de ses visiteurs, remarche au poil quoi que nous testions.
- Confirmation de la découverte, si nous lockons la gallerie piwigo, pour être seuls dessus, les admins, là l'upload se passe parfaitement bien, le download aussi
Tenez, voici un pastebin de /var/log/mysql/mysql-slow.log , il y a eu plusieurs milliers de lignes supplémentaires pour quelques images, j'en ai fait un extrait :
http://pastebin.com/APKer7a5
...
En somme, c'est quand la gallerie a beaucoup de visiteurs que le bug se déclenche.
Comme si l'accès à la fois en lecture et en écriture posait problème.
C'est quand-même curieux, non ?
Le serveur est un Host-32 de OVH, avec les bases de données et le cache et le système installés sur 2 disques durs SSD en Raid-1, tandis que les sites web sont dans /home, sur 2 disques durs SATA en Raid-1.
A votre avis, est-ce que c'est possible que le bug soit lié, d'une manière ou d'une autre, au fonctionnement des disques SSD ? O_o
Le monitoring du serveur ne trouve rien de problématique avec les disques, tout est normal, pourtant...
Bonjour,
Pas de bol, le problème est de retour, uploader des images avec piwigo tue le serveur :(
Augmenter le MaxProcessCount a réduit les occurences du problème, non en réglant le vrai problème, mais en libérant la capacité du serveur à ne pas s'écrouler sous la charge générée par piwigo.
Pendant les uploads, commande "top", la charge serveur passe de 3-10% (charge habituelle) à presque 100%, avec mysql consommant la quasi-totalité de la montée de charge. La commande "mpstat -P ALL 1" confirme que tous les coeurs sont également mis à charge, avec presque pas d'IOwait, pour mysql.
Et tandis que rame le serveur, les visiteurs demandant à voir des pages dynamiques se font massivement servir une erreur 503 forbidden, tandis que le Apache error_log accumule des tonnes d'erreurs mod_fcgid can't apply process slot for php5.fcgi.
Regardez-moi cet abominable /var/log/mysql/mysql-slow.log , j'en ai extrait ce qu'il s'y est rajouté en quelques minutes : 1712 lignes de log mysql causées par l'envoi d'un paquet de 5 ou 10 images.
Lien : http://pastebin.com/hmcUZ74u
C'est très étrange.
J'ai obtenu un accès complet pour tester, alors j'ai
- installé un piwigo tout neuf sur le même site web, dans un répertoire juste à côté : aucun problème à l'upload, tout marche bien
- sur ce piwigo tout neuf, j'ai copié la base existante de photos (/upload et /_data), le dossier /plugins, j'ai importé la base de données du piwigo originel en mettant juste à jour galleries_url dans la table piwigo_sites. Bref, j'ai dupliqué la gallerie cassée. J'ai lancé un upload... et aucun souci, l'upload se passe au poil.
- j'ai pris un piwigo tout neuf téléchargé depuis piwigo.org, j'ai lancé l'upload des fichiers pour écraser les fichiers présents dans le dossier du piwigo cassé. Testons l'upload : ah, de nouveau le CPU peake, Mysql accumule les slow_queries, et les visiteurs voient un serveur à genoux.
Si vous voulez les paramètres du serveur, au fait, un extrait :
/etc/apache2/mods-available
<IfModule mod_fcgid.c>
AddHandler fcgid-script .fcgi
FcgidConnectTimeout 60
MaxProcessCount 400
MaxRequestLen 33554432
</IfModule>
/etc/apache2/apache2.conf
Timeout 300
KeepAlive On
MaxKeepAliveRequests 200
KeepAliveTimeout 3
<IfModule mpm_prefork_module>
StartServers 5
MinSpareServers 5
MaxSpareServers 10
ServerLimit 600
MaxClients 600
MaxRequestsPerChild 1000
</IfModule>...
Et là, franchement, je cale. Vraiment, je ne comprends pas.
Certes, je pourrais dire "on repart à zéro et on croise les doigts, hé !", mais ça n'est pas sain. S'il y a quelque-chose de tellement cassé entre le serveur et piwigo et que l'on peut mettre à genoux en Host-32 de OVH en uploadant une douzaines d'images, il faut trouver pourquoi, et empêcher que ça se reproduise :(
Franchement je doute que ce soit de la faute de Piwigo, mais alors, quoi, what, où est le problème sur le serveur ?!?
Auriez-vous une idée sur la façon de débugger cela ?
Ou sur ce qui pourrait causer le problème ?
Merci énormément si vous avez votre idée là-dessus ! :)
- MAJ rapide : tiens, je viens de voir, il y a le même problème quand je supprime des images d'une gallerie. WTF sérieusement, haha ^^
Re-MAJ : je renomme une gallerie, j'ai un petit pic CPU. Sculder, Mully, êtes-vous là ? :D
flop25 a écrit:
Piwigo.com des centaines installations sur un seul serveur.
Plutôt des "milliers" par serveur :-)
Piwigo.com est aussi sur OVH mais avec des serveurs moins puissants. Piwigo est très peu gourmand en ressources (CPU, mémoire...). Notre machine type utilise un CPU i5-2400. En revanche on lance PHP avec mod_php dans Apache. Comme on n'a aucun soucis de perfs, on n'a pas trop chercher à optimiser avec nginx ou php-fpm.
bonjour,
tout s'arrange !
Cordialement
k5
Bonjour !
Yahaaa, le problème est résolu !
Alors, si vous êtes curieux, un infogérant est passé par là, le problème rédisant dans la valeur MaxProcessCount dans /etc/apache2/mods-available/fcgid.conf, qui était à un niveau trop bas de toutes façons, mais qui causait juste d'occasionnels ralentissements sans piwigo. Apparemment, une fois ajouté piwigo, c'était la goutte d'eau qui fait déborder le vase... enfin... plutôt façon l'Obélix qui fait déborder la piscine.
En ce qui me concerne, je ne m'y connais pas assez pour comprendre ce qu'il se passe quand piwigo uploade des images, mais pour ce que j'en comprends, il tentait de tirer à lui bien plus que le serveur n'avait à offrir, et tout le système se bloquait.
Bon, voilà, case closed :)
Pardon d'avoir détourné votre temps, tous, et merci des tentatives d'aide :)