Bonjour fabricefacorat :-)

Alors en effet, tu as sans doute bien analysé le fonctionnement de site_update.php : ce n'est pas du tout résistant à plusieurs synchronisations simultanées (parce que c'est PHP qui génère les ids).

Pour être tout à fait transparent, je n'ai pas touché sérieusement à la synchro depuis au moins 7 ans. Le dernier à avoir fait des choses "lourdes" c'est rvelices mais il y a très longtemps aussi (2006, [Subversion] r1029). En tout cas le principe de noter le max(id) et de laisser PHP gérer l'incrément, c'est là depuis très longtemps. Clairement aujourd'hui je chercherais à faire autrement pour laisser la base de données gérer la concurrence avec son propre auto increment.

Depuis 7 ans, j'ai beaucoup plus travaillé sur les autres modes d'ajout de photos...

Je notifie rvelices pour voir si le problème lui parle. Si la réponse est non, je me remettrai dans le code...

Ce soir j'essaie de reproduire mon problème sur un serveur dédié Dedibox avec les mêmes paramètres MySQL.

Si j'y arrive, je vais voir comment je peux modifier le code pour que le problème ne se pose plus ( crash BD ). Par contre pour le côté race condition si une autre update se fait, je vais y réfléchir aussi.

Si j'ai un truc qui marche, je n'hésiterai pas à soumettre un patch :D

Ok,

j'ai procédé à des tests sur mon serveur dédié en synchronisant les dossiers, puis en synchronisant les photos mois par mois ( ~ 9 000 photos chaque mois ). Je n'ai eut aucun problème pour charger les photos, et je suis allé jusqu'à 2 ans, soit 232 836 photos.

Au bout de 200 000 photos, en consultant mes slowqueries, j'ai remarqué que je commençais à avoir seulement quelques requêtes > 1 secondes :


root@sd-48702:/var/www/websalsazur/galleries/2012/2013# grep Query
/var/log/mysql/slowqueries.log | cut -f3 -d" " | sort | tail -n 10
0.549440
0.579074
0.648145
0.654104
0.681259
0.736319
0.741843
0.766754
2.310792
2.796499

# Query_time: 2.310792  Lock_time: 0.000089 Rows_sent: 0  Rows_examined: 386406
SET timestamp=1413411009;
SELECT DISTINCT(id)
  FROM piwigo_images INNER JOIN piwigo_image_category ON id=image_id
  WHERE category_id NOT IN (0)
    AND level>8;


# Query_time: 2.796499  Lock_time: 0.000072 Rows_sent: 232836
Rows_examined: 931344
SET timestamp=1413411269;
SELECT DISTINCT(id)
  FROM piwigo_images
    INNER JOIN piwigo_image_category AS ic ON id = ic.image_id
  WHERE date_available>=LEAST(SUBDATE(CURRENT_DATE,INTERVAL 7
DAY),SUBDATE('2014-10-16 00:13:38',INTERVAL 1 DAY))
  ORDER BY date_available DESC,date_available DESC, file ASC, id ASC;


Par conséquent le problème vient vraiment de la BD côté OVH.

Cependant, mes investigations m'ont montré quelques axes d'améliorations possibles côtés Piwigo :
- race condition dans mass upload si ajout de photos en parallèle car on gère manuellement les id des images,
- quelques requêtes SELECT avec des DISTINCT et/ou des JOINS qui pourraient être optimisées ou mis en cache,

Par exemple cette requête sans la jointure sur piwigo_image_category voit son temps d'exécution divisé par 2 :
SELECT DISTINCT(id)
  FROM piwigo_images
    INNER JOIN piwigo_image_category AS ic ON id = ic.image_id
  WHERE date_available>=LEAST(SUBDATE(CURRENT_DATE,INTERVAL 7
DAY),SUBDATE('2014-10-16 00:13:38',INTERVAL 1 DAY))
  ORDER BY date_available DESC,date_available DESC, file ASC, id ASC;


- Piwigo affiche TOUTES les nouvelles photos uploadées sans limites hors celle des 7 derniers jours mais si on upload 100 000 photos dans la journées, Piwigo affiche les 100 000 photos dans la gallerie "Nouvelles photos"

Si j'ai le temps, j'essaierai de proposer des patchs.

En tout cas merci pour votre attention. De notre côté on va voir pour changer d'hébergement, mais aussi évaluer piwigo ou plusieurs instances de piwigo ou une autre solution pour héberger et afficher au moins 5 années de photos ( ~ 5 * 100 000 photos )

l'URL du site a change, voici la nouvelle URL : http://photos.websalsazur.com/

Pour le serveur, c'est une dedibox classique 2014 v2 ( Intel® Xeon® E3 1220 v2, 16Go RAM, RAID 1 SATA, Ubuntu 14.04 LTS, MySQL 5.5 tuné avec mysqltuner et autre ) :
http://www.online.net/fr/serveur-dedie/ … ssic2k14v2

Il y avait un gros problème du serveur MySQL précédent que les équipes d'OVH n'ont détecté que très tardivement => donc préférer un serveur dédié plutôt qu'une plateforme mutualisée qui lorsqu'il y a des problèmes est plus difficile à débugger.

Parmi mes observations pour un gros volume de photos concernant Piwigo :
- Pas de problèmes côté code de Piwigo, par contre le problème vient plus côté BD
- Piwigo fait pas mal de SELECT DISTINCT/GROUP BY avec des jointure notamment entre piwigo_images et piwigo_image_categories sans clause LIMIT qui provoquent la création de table temporaires => définir une taille suffisante pour max_heap_table_size et tmp_table_size pour éviter qu'ils ne crée ses tables temporaires sur disques
- RAM RAM RAM, et encore RAM : il faut suffisamment de RAM et une taille confortable de key_buffer_size
- Si trop de requêtes passent en "on disk temporary table", mettre /tmp en tmpfs en RAM :D

Donc une fois le tuning DB fait, tout devrait rouler. Et surveiller de temps en temps au fur et à mesure que le nombre de photos augmente.

on est d'accord que là on ne parle que de synchro comme méthode qui fait laguer ?

Dernière modification par flop25 (2014-11-03 15:28:47)

Voici un Piwigo de volumétrie similaire (86k photos) http://songsview.piwigo.com

Vous trouvez lent ? Et bien sachez que ça tourne sur un serveur de ce type http://www.ovh.com/fr/serveurs_dedies/s … FS-12T.xml donc un processeur Intel Atom C2750 (très très loin des performances d'un Xeon E3 1220v2). Et bien sûr il y a d'autres Piwigo sur le même serveur !