Support #6454
fermé
Statistiques des fichiers joints fait ramer le portail
100%
Description
Bonjour,
Depuis quelques mise à jour (5.14, au moins), il nous est impossible de lancer des statistiques de fichiers joints (évolutions, et autres) pendant la journée, car ceci rend le portail quasi inutilisable pour tous les utilisateurs (200 utilisateurs connectés en permanence).
La génération des rapports, lorsqu'elle s'affiche, peut être très longue (>30 min), et pendant ce temps, le portail est très ralentit.
Le processeur n'est pourtant pas très chargé, mais les accès disques augmentent beaucoup pendant l'analyse.
Il n'y a aucun moyen d'arrêter le processus, et pendant ce temps, il faut presque 2 minutes pour charger la page de garde d'un espace.
Après plusieurs essais, il semble que la première analyse est particulièrement longue, mais les fois suivantes (dans la même journée, il me semble), cela est plus rapide, mais reste très long.
Sur un test fait en production (par erreur) :- la première analyse a durée presque 1h30, et le résultat ne s'est jamais affiché. La fenêtre d'attente ne cessait de tourner. Après 1h30, les ressources sont revenues à la normale, mais le résultat ne s'est pas affiché.
- Pendant ce temps, les utilisateurs avaient beaucoup de mal à s'authentifier (plusieurs minutes), voire obtenait un "Problème technique", et une fois dedans, la naviguation était très lente (2 minutes par pages).
- Si l'on fait une nouvelle analyse, celle-ci est plus rapide (30 minutes en prod, quand même), mais pendant ce temps, les conséquences sont identiques.
- 1ère analyse = ~30 minutes;
- 2ème analyse = ~1 minutes.
- Bien que plus réactif, nous contatons quand même un ralentissement lors de la naviguation.
Résultat, nous ne lançons plus d'analyse, de peur de paralyser tout le monde, et nous n'avons plus aucune idées de nos statistiques actuelles.
Merci pour une prise en compte de ce problème
Fichiers
| Statistiques_disk_20150409_1112_1139.jpg (113 ko) Statistiques_disk_20150409_1112_1139.jpg | |||
| Statistiques_cpu_20150409_1112_1139.jpg (98,7 ko) Statistiques_cpu_20150409_1112_1139.jpg |
Mis à jour par David Lesimple il y a environ 9 ans
- Tracker changé de Bug à Support
- Statut changé de New à Feedback
- Assigné à mis à David Lesimple
Mis à jour par David Lesimple il y a environ 9 ans
- Statut changé de Assigned à Feedback
Sur le serveur de test, j'observe :
- Nb de fichiers joints: 21s (environ 300000 fichiers)
- Taille des fichiers joints: 31s (155 go)
- Evolution: 1s
Dans tous les cas, cela prend beaucoup de CPU (et c'est normal).
Comme je vous l'avais recommandé, je vous engage à mettre à jour Postgresql, la version 8.4date de Décembre 2009.
De nombreuses améliorations de performances ont été apportées depuis, jusqu'à la version actuelle 9.4.
Mis à jour par Emmanuel GRANGE il y a environ 9 ans
- Assigné à
David Lesimplesupprimé
Effectivement, une fois que l'analyse a été effectué, les fois suivantes sont beaucoup plus rapide.
Dans mon compte rendu, j'ai dit "dans la même journée", mais je n'ai en fait pas réussit à définir exactement à partir de quand l'analyse se remet à être longue.
J'ai même essayé de redémarrer le portail, mais ça n'est pas ça non plus.
Je suis en train de vérifier en redémarrant le serveur complètement.
Justement, nous comptions mettre à jour le serveur en 5.14.3, et s'il faut on mettra à jour Postgres.
Il s'agit quand même d'une mise à jour majeur 8.4 > 9.4.
Y-a-t'il des pré-requis à vérifier ?
Mis à jour par Emmanuel GRANGE il y a environ 9 ans
- Fichier Statistiques_disk_20150409_1112_1139.jpg Statistiques_disk_20150409_1112_1139.jpg ajouté
- Fichier Statistiques_cpu_20150409_1112_1139.jpg Statistiques_cpu_20150409_1112_1139.jpg ajouté
- Assigné à mis à David Lesimple
Je te confirme, qu'après un redémarrage du serveur complet, les statistiques moulinent pendant 1/2 heure.
Ci-joint des captures des activités disk et CPU de la VM pendant l'analyse des statistiques du portail de test de 11:12 à 11:39.
Mis à jour par David Lesimple il y a environ 9 ans
Emmanuel GRANGE a écrit :
Justement, nous comptions mettre à jour le serveur en 5.14.3, et s'il faut on mettra à jour Postgres.
Il s'agit quand même d'une mise à jour majeur 8.4 > 9.4.
Y-a-t'il des pré-requis à vérifier ?
Aucun. La migration des bases se fait par dump/restore.
Une fois la 9.4 installée, il faut réajuster si nécessaire postgresql.conf (max_connexions) et pg_hba.conf (pour les authorisations d'accès)
un aperçu des changements:
http://www.postgresql.org/about/featurematrix/#performance
Mis à jour par Emmanuel GRANGE il y a environ 9 ans
Nous avons fait la mise à jour de la version de Postgres sur le portail de Test.
Il est désormais en 9.4.
Les analyses des volumes du portail restent très longues (~30 minutes) après un redémarrage.
Mis à jour par David Lesimple il y a plus de 8 ans
- % réalisé changé de 0 à 50
Emmanuel GRANGE a écrit :
Nous avons fait la mise à jour de la version de Postgres sur le portail de Test.
Il est désormais en 9.4.Les analyses des volumes du portail restent très longues (~30 minutes) après un redémarrage.
En prod, vous etes toujours en 8.x ?
Sur ce problème de stats de volume, combien de temps dure la commande
du -hs workspacesen étant dans le répertoire data.
Mis à jour par Emmanuel GRANGE il y a plus de 8 ans
- Votre version de Silverpeas changé de 5.14.3 à 5.15
Désormais, en Prod, nous sommes en PostgreSQL 9.3, et le "du -hs" dure à peu près 9 minutes 30
Mis à jour par David Lesimple il y a plus de 8 ans
- Votre version de Silverpeas changé de 5.15 à 5.14.4
Bonjour Emmanuel,
Par contre, vous n'êtes pas encore en 5.15 mais en 5.14.4 il me semble.
Mis à jour par Emmanuel GRANGE il y a plus de 8 ans
- Votre version de Silverpeas changé de 5.14.4 à 5.15
Le portail de test est en 5.15 et il a le même problème.
Mis à jour par David Lesimple il y a plus de 8 ans
ok mais dans ce cas, merci de préciser qu'il s'agit de votre serveur de test.
Mis à jour par Emmanuel GRANGE il y a plus de 8 ans
OK, mais nous avons le même problème sur le portail de Prod.
Le problème est pire sur le portail de Prod, car cela impacte tous les utilisateurs.
Mis à jour par David Lesimple il y a plus de 8 ans
il est possible que votre disque de stockage ne soit pas très performant.
J'attendais le résultat de la commande du pour pouvoir comparer sur d'autres serveurs.
Je reviens vers toi dès que j'ai quelques éléments de comparaison.
Mis à jour par David Lesimple il y a plus de 8 ans
Emmanuel, sur votre serveur de test, j'ai fait un du -hs de workspaces qui a duré 4-5 secondes
et dans administration, la tailles des fichiers joints a duré environ 1 mn et le nb de fichiers joints: 40s
Mis à jour par David Lesimple il y a plus de 8 ans
pour moi, les stats sont très longues, car le serveur est très fortement sollicité (RAM, CPU et disque).
Globalement, il faudra de toute manière améliorer les performances de votre plate-forme de prod.
Nous avons quelques solutions que Sébastien et moi vous exposerons prochainement.
Mis à jour par David Lesimple il y a plus de 8 ans
J'ai fait quelques mesures sur votre serveur de test dans workspaces, il apparait que c'est le comptage du nombre de fichiers qui prend du temps (1 heure) :
Debut calcul nombre de fichiers
vendredi 11 décembre 2015, 10:44:21 (UTC+0100)
Nb de fichiers: 431912
vendredi 11 décembre 2015, 11:42:05 (UTC+0100)
Fin calcul nombre de fichiers
Coté dossiers, c'est rapide (- de 30") :
Debut calcul nombre de dossiers
vendredi 11 décembre 2015, 11:42:05 (UTC+0100)
Nb de dossiers: 1298085
vendredi 11 décembre 2015, 11:42:31 (UTC+0100)
Fin calcul nombre de dossiers
Mis à jour par David Lesimple il y a plus de 8 ans
- Assigné à changé de David Lesimple à Miguel Moquillon
De mon point de vue et après analyse du code, ce dernier est déja pas mal optimisé, on fait face à un limitation en performances de la lecteur d'arborescence avec le jdk 6.
Depuis jdk 7, des méthodes plus performantes ont été mises au point.. Ce sera donc pour la version 6 de Silverpeas.
Nicolas ou Miguel, merci d'infirmer ou de confirmer mes dires si nécessaire.
Mis à jour par Miguel Moquillon il y a plus de 5 ans
- Statut changé de Feedback à Resolved
Je confirme
Mis à jour par David Lesimple il y a environ 5 ans
- Dupliqué par Bug #10539: STATISTIQUES - Temps de réponse inaccessible et plantage ajouté
Mis à jour par David Lesimple il y a plus de 2 ans
- Statut changé de Resolved à Closed
- % réalisé changé de 50 à 100