Bonjour à tous,
Kdedino suit l'affaire. Le temps de prendre un ptit dej en reflechissant.

Cordialement
kdedino

Bonjour, merci de vos retours !

Ben, moi j'ai un kimsufi à titre personnel (avec PHP 5.3.3-7, MySQL 5.1.72-2-log, debian squeeze, virtualmin), et je peux faire tourner une gallerie piwigo sans problème, en uploadant cinq ou même huit galleries simultanément sans souci.

Le serveur sur lequel ça plante est plus récent bien que similaire (5.4.4-14+deb7u7, MySQL 5.5.33, debian wheezy, virtualmin - c'est le même installeur).

Il n'y a qu'une seule installation piwigo sur le serveur qui a le problème.

Il n'y a qu'un seul moteur PHP d'installé, mais, oui, l'.htaccess mentionne bien PHP5.
A part ça, il y a juste quelques bannissements, les trucs de base de wordpress, et une fonction pour éviter les URLs trop longues (si j'ai bien compris, c'est pour les cas où une entrée n'est pas escapée correctement, pour réduire les risques) :
RewriteEngine on
RewriteCond %{REQUEST_URI} .{450}
RewriteRule (.*) - [F]
RewriteCond %{QUERY_STRING}  .{450}
RewriteRule (.*) - [F]

Qu'y aurait-il d'autre comme différence... Un filesystem et les bases de données sur SSD, tandis que les sites (/home/) sont en SATA (sur mon serveur à moi, tout est en SATA, mais je vois mal les SSD causer un problème, leur monitoring ne -//:---\spam pas de défaillances, il n'y a pas de mauvais secteurs).

On ne sait pas trop où chercher, si vous voyez d'autres informations pertinentes, n'hésitez pas :)

Dernière modification par oliverfr (2014-01-26 13:48:25)

Mon kimsufi c'est un intel i5-2300 3.1 Ghz 4 coeurs. Le host-32 de OVH, heuuu... Après vérification sur le site de OVH puis sur google, c'est un AMD Opteron 4334, du 3.5 Ghz 6 coeurs.

Mais c'est sur le kimsufi, censément moins puissant, que piwigo marche parfaitement, hein.

A la rigueur, peut-être une réinstallation... Si l'on conserve le dossier /upload/ et la base de données, on peut supprimer tout le reste, pour le remplacer par une copie neuve ? Ou il faut garder d'autres dossiers, pour conserver les paramètres de l'installation existante ?
Je préférerais vraiment trouver pourquoi piwigo casse le moteur PHP (sinon, bah, ma suggestion de faire appel à Piwigo tombe aux oubliettes, tant pis), bien sûr, cependant tenter une réinstallation sera une solution de dernier recours...

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 :)

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.

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...

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...