Rép : Problèmes de performances Plone/Zeocluster

[UNS]

Some javascript/style in this post has been disabled (why?)

Tout d'abord merci à vous pour vos réponses qui furent des plus rapide.

ConflictError: database conflict error (oid 0x1247, class

BTrees._OOBTree.OOBTree, serial this txn started with 0x037a1ffe66682b66

2008-11-25 13:50:24.001620, serial currently committed 0x037a1ffeae62ca44

2008-11-25 13:50:40.871695)

D’après ce que je comprend, il y a un conflit de ma base de données lorsque

l’on veut accéder à un objet, vu que ce n’est apparu qu’après le partage du

temporary_forlder je suppose que c’est lié

Peut -être utilisé pound (ou pen) plutôt que mod_proxy_balancer !

1. Concernant le Zope lui-même, si on ne dispose pas de quantités infinies de mémoire, il peut être judicieux de le relancer de temps à autres. On peut utiliser monit, par exemple, pour lui dire de relancer une instance Zope dès qu'elle occupe plus d'une quantité donnée de mémoire. Lorsqu'on utilise un setup ZEO, avec en frontal un loadbalancer comme pound, on peut même se permettre de relancer les instances « ni vu ni connu », et pound s'occupera de tout (il arrêtera d'envoyer des requêtes vers les instances qui ne répondent plus, mais tentera régulièrement de les recontacter pour les ré-inclure dans le roundrobin).

Je vais me documenter pour Pound ou pen afin de voir comment l'installer et faire des tests sur mon serveur de développement. De même monit semble des plus intéressant.

Même si ceci est sommes toute peu gênant, on m'a conseillé d'utiliser un FileStorage pour mais session lorsque l'on passe sous un zeo qu'en pensez vous ? L'erreur n'est pas des plus alarmante puisqu'elle n'apparaît qu'une à deux fois par jour.

Par moment, sans

raison apparente, sans avoir reçu aucun message ou signal, une instance

s’arrête, puis des fois quelques minutes ou quelques heures plus tard une

autre ..

C'est pas normal.
Un telnet sur le zeoclient donne quoi quand ça arrive
Y a t'il pas des sockets en time-wait.
Les 3 thread des zeoclients ne sont t'il pas okp a faire de opération lourde.
Peut être augmenter le nombre de thread d'ailleurs vu la bête de course.

2. Une instance de 1 à 2 Go ça n'est pas choquant, en revanche, des processus httpd, ça, c'est bizarre. S'agit-il de la taille de l'image en mémoire, ou de la RAM réellement utilisée ? Dans le "top" sous Linux, VIRT indique la taille de l'image (et peut-être très élevé sans que ça pose un problème), tandis que RES indique la taille résidente (la RAM réellement utilisée). Pour nos frontaux web (Apache dirigeant vers quelques centaines d'instances Zope), on a typiquement 1 giga de VIRT mais à peine 20 megas de RES, à titre indicatif.

Pour le problème de la chute des instances, il s'agit réellement d'une chute, plus de thread actif, dans la liste des process plus de python, comme si j'avais demandé un stop alors que ce n'est pas le cas. J'avoue que je ne comprend pas du tout ce qui se passe. Un moment j'ai cru que c'était le manque de ram, mes recherches ayant abouti sur des commentaires disant que si le zeo devait swapper alors il pouvait perdre ses instances qui s'arrêtait.

Pour Apache il s'agit de taille en mémoire virtuelle mais pourquoi une dizaine de process alors que j'ai 5 instances ce qui représente 16 thread ? J'ai lu dans une doc que python gérant mal le multi process il valait mieux diminuer le nombre de thread à 3 voir 2 au lieu des 4 par défauts et de gonfler le nombre d'instances que gère le zeo avez vous un avis sur cela ?

J'ai un autre souci lorsque mon nombre de connexion simultané avoisine les 30, le système met du temps à répondre, à la connexion, j'enregistre la date dans un bd postgre, puis je redirige en fonction du profil vers une page différente suivant deux roles, l'un étant à peine dynamique (chargement d'un résumé de l'espace avec nb des objets) l'autre l'étant beaucoup plus, affichage d'une offre de formation et des cours associé en fonction d'une donnée personnelle de l'étudiant.

La question que je me pose c'est "Est ce le mécanisme de connexion qui bloque ou la génération de ma page après connexion ?" Sous Plone 2 la connexion est elle bloquante ? Gagnerai je beaucoup en vitesse si j'intercallais par exemple une page statique de confirmation de connexion ?

Voilà pour cette fois, en espérant obtenir de nouveau votre aide et en vous remerciant par avance.

_______________________________________________
Plone-FR mailing list
[hidden email]
http://lists.plone.org/mailman/listinfo/plone-fr

[tbenita]

Some javascript/style in this post has been disabled (why?)

Service TICE a écrit :

Tout d'abord merci à vous pour vos réponses qui furent des plus rapide.

ConflictError: database conflict error (oid 0x1247, class

BTrees._OOBTree.OOBTree, serial this txn started with 0x037a1ffe66682b66

2008-11-25 13:50:24.001620, serial currently committed 0x037a1ffeae62ca44

2008-11-25 13:50:40.871695)

D’après ce que je comprend, il y a un conflit de ma base de données lorsque

l’on veut accéder à un objet, vu que ce n’est apparu qu’après le partage du

temporary_forlder je suppose que c’est lié

Peut -être utilisé pound (ou pen) plutôt que mod_proxy_balancer !

1. Concernant le Zope lui-même, si on ne dispose pas de quantités infinies de mémoire, il peut être judicieux de le relancer de temps à autres. On peut utiliser monit, par exemple, pour lui dire de relancer une instance Zope dès qu'elle occupe plus d'une quantité donnée de mémoire. Lorsqu'on utilise un setup ZEO, avec en frontal un loadbalancer comme pound, on peut même se permettre de relancer les instances « ni vu ni connu », et pound s'occupera de tout (il arrêtera d'envoyer des requêtes vers les instances qui ne répondent plus, mais tentera régulièrement de les recontacter pour les ré-inclure dans le roundrobin).

Je vais me documenter pour Pound ou pen afin de voir comment l'installer et faire des tests sur mon serveur de développement. De même monit semble des plus intéressant.

Même si ceci est sommes toute peu gênant, on m'a conseillé d'utiliser un FileStorage pour mais session lorsque l'on passe sous un zeo qu'en pensez vous ? L'erreur n'est pas des plus alarmante puisqu'elle n'apparaît qu'une à deux fois par jour.

Lorsque tu stockes des fichier dans les objets Fichier de plone, ils sont stockés physiquement dans la base de données ZODB, dans un attribut de l'objet Fichier.
Chaque client ZEOClient gère son propre cache de base ZODB, selon les paramètres définis dans son fichier de configuration zope.conf. Le cache est paramétré en nombre d'objets. De ce fait, le cache peut consommer une énorme quantité de RAM si tu n'utilises pas de stockage filesystem pour les fichiers. Le nombre de clients de cluster multiplie d'autant la taille de la ram consommée pour les caches de chaque client.

Par contre, seul BlobFile et Blob supportent le versionning CMFEditions à ma connaissance. (nos derniers tests datent de trois mois).

Par moment, sans

raison apparente, sans avoir reçu aucun message ou signal, une instance

s’arrête, puis des fois quelques minutes ou quelques heures plus tard une

autre ..

C'est pas normal.
Un telnet sur le zeoclient donne quoi quand ça arrive
Y a t'il pas des sockets en time-wait.
Les 3 thread des zeoclients ne sont t'il pas okp a faire de opération lourde.
Peut être augmenter le nombre de thread d'ailleurs vu la bête de course.

2. Une instance de 1 à 2 Go ça n'est pas choquant, en revanche, des processus httpd, ça, c'est bizarre. S'agit-il de la taille de l'image en mémoire, ou de la RAM réellement utilisée ? Dans le "top" sous Linux, VIRT indique la taille de l'image (et peut-être très élevé sans que ça pose un problème), tandis que RES indique la taille résidente (la RAM réellement utilisée). Pour nos frontaux web (Apache dirigeant vers quelques centaines d'instances Zope), on a typiquement 1 giga de VIRT mais à peine 20 megas de RES, à titre indicatif.

Pour le problème de la chute des instances, il s'agit réellement d'une chute, plus de thread actif, dans la liste des process plus de python, comme si j'avais demandé un stop alors que ce n'est pas le cas. J'avoue que je ne comprend pas du tout ce qui se passe. Un moment j'ai cru que c'était le manque de ram, mes recherches ayant abouti sur des commentaires disant que si le zeo devait swapper alors il pouvait perdre ses instances qui s'arrêtait.

Pour Apache il s'agit de taille en mémoire virtuelle mais pourquoi une dizaine de process alors que j'ai 5 instances ce qui représente 16 thread ? J'ai lu dans une doc que python gérant mal le multi process il valait mieux diminuer le nombre de thread à 3 voir 2 au lieu des 4 par défauts et de gonfler le nombre d'instances que gère le zeo avez vous un avis sur cela ?

J'ai un autre souci lorsque mon nombre de connexion simultané avoisine les 30, le système met du temps à répondre, à la connexion, j'enregistre la date dans un bd postgre, puis je redirige en fonction du profil vers une page différente suivant deux roles, l'un étant à peine dynamique (chargement d'un résumé de l'espace avec nb des objets) l'autre l'étant beaucoup plus, affichage d'une offre de formation et des cours associé en fonction d'une donnée personnelle de l'étudiant.

La question que je me pose c'est "Est ce le mécanisme de connexion qui bloque ou la génération de ma page après connexion ?" Sous Plone 2 la connexion est elle bloquante ? Gagnerai je beaucoup en vitesse si j'intercallais par exemple une page statique de confirmation de connexion ?

Voilà pour cette fois, en espérant obtenir de nouveau votre aide et en vous remerciant par avance.

Il faut monitorer la charge CPU lors de nombreuses connexions. Si la charge CPU plafonne, même si c'est sur un seul CPU, il faut optimiser la politique de caches de la page d'accueil. Si la charge CPU est faible, il y a vraissemblablement un problème de swap ou de configuration.

Concernant la consommation de RAM par Apache, ça peut aussi arriver si tu utilises le RAMCache d'apache.

Cordialement,

Thierry Bénita.



[tbenita.vcf]

---

begin:vcard
fn:Thierry BENITA - atReal
n:BENITA;Thierry
adr:;;113 Bd de Pont-de-Vivaux;Marseille;;13010;France
email;internet:[hidden email]
title:atReal
tel;work:[phone]
tel;fax:[phone]
note;quoted-printable:-- =
        =0D=0A=
        atReal=0D=0A=
        Solutions libres pour Entreprises et Collectivit=C3=A9s=0D=0A=
        http://www.atreal.net - http://www.atreal.fr=0D=0A=
        04 91 29 42 81
x-mozilla-html:FALSE
url:http://www.atreal.net
version:2.1
end:vcard

---

_______________________________________________
Plone-FR mailing list
[hidden email]
http://lists.plone.org/mailman/listinfo/plone-fr

[Alexandre Garel]

Bonjour,

Je réponds sur un point précis ou deux :

Service TICE a écrit :
>
> Je vais me documenter pour Pound ou pen afin de voir comment
> l'installer et faire des tests sur mon serveur de développement. De
> même monit semble des plus intéressant.
>
> Même si ceci est sommes toute peu gênant, on m'a conseillé d'utiliser
> un FileStorage pour mais session lorsque l'on passe sous un zeo qu'en
> pensez vous ? L'erreur n'est pas des plus alarmante
> puisqu'elle n'apparaît qu'une à deux fois par jour.

Je ne suis pas sur que ça rêgle le problème mais pourquoi pas essayer.
 
Avez vous une application particulière qui tourne sur Plone ? Dans ce
cas je dirais qu'il y a peut être quelque chose à faire au niveau
applicatif.

Une application qui utilise beaucoup les sessions c'est mal (tm), ça
joue contre la possibilité de clusteriser.

Au pire si l'application utilise beaucoup les sessions, essayez d'avoir
un répartiteur qui réparti préférentiellement les requêtes d'un même
utilisateurs vers la même  instance zope.
>
> Pour Apache il s'agit de taille en mémoire virtuelle mais pourquoi une
> dizaine de process alors que j'ai 5 instances ce qui représente 16
> thread ?
Apache gère les requêtes en amont et crée les process en fonction de la
charge puis dialogue avec Zope via http. Aucune corrélation donc entre
votre nombre d'instance/thread et le nombre de processus que Apache va
créer. Apache décide de sa politique tout seul.

> J'ai lu dans une doc que python gérant mal le multi process il valait
> mieux diminuer le nombre de thread à 3 voir 2 au lieu des 4 par
> défauts et de gonfler le nombre d'instances que gère le zeo avez vous
> un avis sur cela ?
Python ne gère pas le multiprocess au niveau de l'execution du code
Python (recherche sur GIL pour Global Interpreter Lock) mais il le gère
sur les attente d'entrées / sorties. Donc pas besoin de gonfler le
nombre de process si vous avez beaucoup de calcul, par contre s'il fait
beaucoup d'E/S (lecture et écriture ZEO, lecture et écriture BDD ou
LDAP), ça peut valoir le coup de passer à plus de thread (6 ou 7 par
exemple). Le mieux est de pouvoir faire un benchmark.

>
> J'ai un autre souci lorsque mon nombre de connexion simultané avoisine
> les 30, le système met du temps à répondre, à la connexion,
> j'enregistre la date dans un bd postgre, puis je redirige en fonction
> du profil vers une page différente suivant deux roles, l'un étant à
> peine dynamique (chargement d'un résumé de l'espace avec nb des
> objets) l'autre l'étant beaucoup plus, affichage d'une offre de
> formation et des cours associé en fonction d'une donnée personnelle de
> l'étudiant.
>
> La question que je me pose c'est "Est ce le mécanisme de connexion qui
> bloque ou la génération de ma page après connexion ?" Sous Plone 2 la
> connexion est elle bloquante ? Gagnerai je beaucoup en vitesse si
> j'intercallais par exemple une page statique de confirmation de
> connexion ?

Impossible à dire avec si peu d'information. Utilisez vous bien le
catalogue ?

En espérant avoir été utile,

Alex

--
Alexandre Garel - [hidden email]
Pilot Systems - 9, rue Desargues - 75011 Paris
Tel : [phone] - http://www.pilotsystems.net
Hébergement Zope et Plone gratuit - http://www.objectis.org



_______________________________________________
Plone-FR mailing list
[hidden email]
http://lists.plone.org/mailman/listinfo/plone-fr