tout d'abord je ne suis pas programmeur python mais admin système/réseaux.
Je voudrais mettre en place un serveur Zope et faire tourner Plone dessus.
J'ai fait un test sur une Redaht AS 3.0 ça se passe bien avec un zope
2.6.4 et un python 2.2.3. C'est celui par defaut de Redhat 3.0 et qu'il
est difficile d'upgrader parce que les outils d'admin de redhat sont
écrites en python.
La machine de tests est un quadri-Xeon avec 2Go de ram. Là ou le bas
blaisse c'est que je ne dépasse pas les 5-6 connexions à la seconde. Ce
qui est ridiculement faible pour les besoins de l'appli.
En fait je me suis apperçu que je n'avais qu'un process python me
prenant 100% d'un de mes CPU, zéro sur les 3 autres.
Il n'est pas possible avec Zope|Python de gérer plusiers processeurs.
1) Zope est il capable de pre-forker pour utiliser tous les CPU (comme
un apache) ? Ou de gérer des thread posix ?
2) En ce qui concerne la gestion des thread sous python, comment ça se
passe ? Je pense qu'il doit être possible d'utiliser soit des
green-thread soit des pthread (threads posix) comme avec Perl. Sous Perl
c'est une option de compilation et il est possible de voir avec un "Perl
-v" si perl a été compilée avec des pthread ou pas. Comment fait on en
python ?
Si les thread sont générés en utilisant l'appèle système clone() de
linux, les thread devraient pouvoir être répartis sur plusieurs procs.
On pourrait m'arguer qu'il suffit d'acheter une ferme de serveurs avec
un système de load balacing devant (genre CSS de Cisco) mais c'est très
lourd et bcp plus cher.
Quelles sont les solutions simples pour utiliser toutes les ressources
CPU. Le problème vient il du fait que g un vieux python et un vieux zope
sur ma machine ?
Si. La différence des Apache2 c'est qu'il utilise AUSSI des threads. Alors que apache 1 ne faisait que du preforking et ensuite n'utilisait des select pour gérer plusieur clients à partir d'un seul process.
C'est pour ça que je dis plus tout a fait ...
Je viens d'écrire un petit script Perl qui lance des threads (dsl, j'ai pas le temps de chercher comment faire ça en python malgrès la sympathie que je porte à ce dernier) Le voici: --------- #!/usr/bin/perl use threads; $thr1 = threads->new(&sub1); $thr2 = threads->new(&sub1); $thr3 = threads->new(&sub1); $thr4 = threads->new(&sub1); $thr1->join; $thr2->join; $thr3->join; $thr4->join; sub sub1 { while(1) { } } ---------
Je lance ça sur mon quadri-pro Redhat AS3. # uname -a Linux blake 2.4.21-9.0.1.ELsmp #1 SMP Mon Feb 9 22:26:51 EST 2004 i686 i686 i386 GNU/Linux
Je ne vois qu'un seul process Perl (contrairement à ce que vous me dire, mais je sais que les noyaux Redhat AS sont bcp patchés par redhat pour améliorer les SMP...)
Oui, RHAS3 utilise meme les NPTL qui normalement n'existent que sur du 2.6, RH à cette manie de backporter comme un sauvage ...
Quand je parle d'un 2.4, je veux dire un vrai 2.4 hein ? :)
Mais avec un CPU de 400% (399.4 pour chippoter): ----- 24967 root 23 0 3912 3912 1592 S 399,4 0,1 1:47 3 perl ----- en faisant un top: ----- CPU states: cpu user nice system irq softirq iowait idle total 399,6% 0,0% 0,0% 0,0% 0,0% 0,0% 0,0% cpu00 100,0% 0,0% 0,0% 0,0% 0,0% 0,0% 0,0% cpu01 99,8% 0,0% 0,1% 0,0% 0,0% 0,0% 0,0% cpu02 100,0% 0,0% 0,0% 0,0% 0,0% 0,0% 0,0% cpu03 100,0% 0,0% 0,0% 0,0% 0,0% 0,0% 0,0% ----- Donc mon prog perl avec mes trois threads utilise de manière optimale toutes mes ressources CPU.
Normale
Quand j'avais lancé mon Zope j'avais un de mes quatres processeurs à 100% et quasiment rien sur les autres.
Je ne conteste pas, et je trouve ça etrange...
Voilà ou j'en suis...
J'ai un RHAS3 qui traine avec 4 CPU, je vais faire quelque test, parce que je me demande si c'est pas le kernel de RH qui est en cause en fait...
J'ai fais quelque recherches et si tout le monde parle des perfs lamentable de Zope en SMP, personne n'evoque un probleme similaire au tien...
Cedric Foll wrote:
Plus tout à fait vrai pour Apache 2.0
Si.
La différence des Apache2 c'est qu'il utilise AUSSI des threads.
Alors que apache 1 ne faisait que du preforking et ensuite n'utilisait
des select pour gérer plusieur clients à partir d'un seul process.
C'est pour ça que je dis plus tout a fait ...
Je viens d'écrire un petit script Perl qui lance des threads (dsl, j'ai
pas le temps de chercher comment faire ça en python malgrès la sympathie
que je porte à ce dernier)
Le voici:
---------
#!/usr/bin/perl
use threads;
$thr1 = threads->new(&sub1);
$thr2 = threads->new(&sub1);
$thr3 = threads->new(&sub1);
$thr4 = threads->new(&sub1);
$thr1->join;
$thr2->join;
$thr3->join;
$thr4->join;
sub sub1 {
while(1) {
}
}
---------
Je lance ça sur mon quadri-pro Redhat AS3.
# uname -a
Linux blake 2.4.21-9.0.1.ELsmp #1 SMP Mon Feb 9 22:26:51 EST 2004 i686
i686 i386 GNU/Linux
Je ne vois qu'un seul process Perl (contrairement à ce que vous me dire,
mais je sais que les noyaux Redhat AS sont bcp patchés par redhat pour
améliorer les SMP...)
Oui, RHAS3 utilise meme les NPTL qui normalement n'existent que sur du
2.6, RH à cette manie de backporter comme un sauvage ...
Quand je parle d'un 2.4, je veux dire un vrai 2.4 hein ? :)
Mais avec un CPU de 400% (399.4 pour chippoter):
-----
24967 root 23 0 3912 3912 1592 S 399,4 0,1 1:47 3 perl
-----
en faisant un top:
-----
CPU states: cpu user nice system irq softirq iowait idle
total 399,6% 0,0% 0,0% 0,0% 0,0% 0,0% 0,0%
cpu00 100,0% 0,0% 0,0% 0,0% 0,0% 0,0% 0,0%
cpu01 99,8% 0,0% 0,1% 0,0% 0,0% 0,0% 0,0%
cpu02 100,0% 0,0% 0,0% 0,0% 0,0% 0,0% 0,0%
cpu03 100,0% 0,0% 0,0% 0,0% 0,0% 0,0% 0,0%
-----
Donc mon prog perl avec mes trois threads utilise de manière optimale
toutes mes ressources CPU.
Normale
Quand j'avais lancé mon Zope j'avais un de mes quatres processeurs à
100% et quasiment rien sur les autres.
Je ne conteste pas, et je trouve ça etrange...
Voilà ou j'en suis...
J'ai un RHAS3 qui traine avec 4 CPU, je vais faire quelque test, parce
que je me demande si c'est pas le kernel de RH qui est en cause en fait...
J'ai fais quelque recherches et si tout le monde parle des perfs
lamentable de Zope en SMP, personne n'evoque un probleme similaire au
tien...
Si. La différence des Apache2 c'est qu'il utilise AUSSI des threads. Alors que apache 1 ne faisait que du preforking et ensuite n'utilisait des select pour gérer plusieur clients à partir d'un seul process.
C'est pour ça que je dis plus tout a fait ...
Je viens d'écrire un petit script Perl qui lance des threads (dsl, j'ai pas le temps de chercher comment faire ça en python malgrès la sympathie que je porte à ce dernier) Le voici: --------- #!/usr/bin/perl use threads; $thr1 = threads->new(&sub1); $thr2 = threads->new(&sub1); $thr3 = threads->new(&sub1); $thr4 = threads->new(&sub1); $thr1->join; $thr2->join; $thr3->join; $thr4->join; sub sub1 { while(1) { } } ---------
Je lance ça sur mon quadri-pro Redhat AS3. # uname -a Linux blake 2.4.21-9.0.1.ELsmp #1 SMP Mon Feb 9 22:26:51 EST 2004 i686 i686 i386 GNU/Linux
Je ne vois qu'un seul process Perl (contrairement à ce que vous me dire, mais je sais que les noyaux Redhat AS sont bcp patchés par redhat pour améliorer les SMP...)
Oui, RHAS3 utilise meme les NPTL qui normalement n'existent que sur du 2.6, RH à cette manie de backporter comme un sauvage ...
Quand je parle d'un 2.4, je veux dire un vrai 2.4 hein ? :)
Mais avec un CPU de 400% (399.4 pour chippoter): ----- 24967 root 23 0 3912 3912 1592 S 399,4 0,1 1:47 3 perl ----- en faisant un top: ----- CPU states: cpu user nice system irq softirq iowait idle total 399,6% 0,0% 0,0% 0,0% 0,0% 0,0% 0,0% cpu00 100,0% 0,0% 0,0% 0,0% 0,0% 0,0% 0,0% cpu01 99,8% 0,0% 0,1% 0,0% 0,0% 0,0% 0,0% cpu02 100,0% 0,0% 0,0% 0,0% 0,0% 0,0% 0,0% cpu03 100,0% 0,0% 0,0% 0,0% 0,0% 0,0% 0,0% ----- Donc mon prog perl avec mes trois threads utilise de manière optimale toutes mes ressources CPU.
Normale
Quand j'avais lancé mon Zope j'avais un de mes quatres processeurs à 100% et quasiment rien sur les autres.
Je ne conteste pas, et je trouve ça etrange...
Voilà ou j'en suis...
J'ai un RHAS3 qui traine avec 4 CPU, je vais faire quelque test, parce que je me demande si c'est pas le kernel de RH qui est en cause en fait...
J'ai fais quelque recherches et si tout le monde parle des perfs lamentable de Zope en SMP, personne n'evoque un probleme similaire au tien...
mordicus
Cedric Foll wrote:
Je lance ça sur mon quadri-pro Redhat AS3. # uname -a Linux blake 2.4.21-9.0.1.ELsmp #1 SMP Mon Feb 9 22:26:51 EST 2004 i686 i686 i386 GNU/Linux
Je ne vois qu'un seul process Perl (contrairement à ce que vous me dire, mais je sais que les noyaux Redhat AS sont bcp patchés par redhat pour améliorer les SMP...)
En fait j'ai finalement fait la même chose (je crois) en Python: ------------------ #!/usr/bin/python import threading class TestThread(threading.Thread): def run(self): while 1: a = 1 t1 = TestThread() t1.start() t2 = TestThread() t2.start() t3 = TestThread() t3.start() t4 = TestThread() t4.start() t1.join() -----------------
Voici ce que ça me donne comme conso: ----------------- CPU states: cpu user nice system irq softirq iowait idle total 37,6% 0,0% 296,0% 0,0% 0,0% 0,0% 66,0% cpu00 9,1% 0,0% 73,4% 0,0% 0,0% 0,0% 17,3% cpu01 9,7% 0,0% 74,8% 0,0% 0,0% 0,0% 15,3% cpu02 8,3% 0,0% 76,0% 0,0% 0,0% 0,0% 15,5% cpu03 10,5% 0,0% 71,6% 0,0% 0,0% 0,0% 17,7% (...) root 21 0 1932 1932 1172 S 328,6 0,0 0:27 2 thread.py -----------------
D'une part il consomme bien tous les CPU (328,6%) mais là ou c'est très étrange c'est que la plupart du CPU est pris par "system" plutôt que par "user". Ca serait le scheduler du kernel qui prendrait tout ce CPU ?
J'ai fait une petite comparaison entre Perl et Python pour les thread. Je lance dans les deux cas 4 threads qui compte jusqu'à 100 000. Voici le résultats du test: ----------- # time ./thread.pl
real 0m0.112s user 0m0.170s sys 0m0.020s
# time ./thread.py
real 0m5.071s user 0m1.770s sys 0m15.040s ------------ C'est clair il y a un problème... Enfin c'est peut être que je m'y prend mal pour lancer mes threads. Je n'ai aucun recul sur python ...
Python en SMP est deplorable a cause de ses lock, c'est pas un secret ...
Plone j'ai pas utiliser donc je ne sais pas
Bon, en tout cas, ca viens pas du Kernel apparement
Cedric Foll wrote:
Je lance ça sur mon quadri-pro Redhat AS3.
# uname -a
Linux blake 2.4.21-9.0.1.ELsmp #1 SMP Mon Feb 9 22:26:51 EST 2004 i686
i686 i386 GNU/Linux
Je ne vois qu'un seul process Perl (contrairement à ce que vous me
dire, mais je sais que les noyaux Redhat AS sont bcp patchés par
redhat pour améliorer les SMP...)
En fait j'ai finalement fait la même chose (je crois) en Python:
------------------
#!/usr/bin/python
import threading
class TestThread(threading.Thread):
def run(self):
while 1:
a = 1
t1 = TestThread()
t1.start()
t2 = TestThread()
t2.start()
t3 = TestThread()
t3.start()
t4 = TestThread()
t4.start()
t1.join()
-----------------
Voici ce que ça me donne comme conso:
-----------------
CPU states: cpu user nice system irq softirq iowait idle
total 37,6% 0,0% 296,0% 0,0% 0,0% 0,0% 66,0%
cpu00 9,1% 0,0% 73,4% 0,0% 0,0% 0,0% 17,3%
cpu01 9,7% 0,0% 74,8% 0,0% 0,0% 0,0% 15,3%
cpu02 8,3% 0,0% 76,0% 0,0% 0,0% 0,0% 15,5%
cpu03 10,5% 0,0% 71,6% 0,0% 0,0% 0,0% 17,7%
(...)
root 21 0 1932 1932 1172 S 328,6 0,0 0:27 2 thread.py
-----------------
D'une part il consomme bien tous les CPU (328,6%) mais là ou c'est très
étrange c'est que la plupart du CPU est pris par "system" plutôt que par
"user". Ca serait le scheduler du kernel qui prendrait tout ce CPU ?
J'ai fait une petite comparaison entre Perl et Python pour les thread.
Je lance dans les deux cas 4 threads qui compte jusqu'à 100 000. Voici
le résultats du test:
-----------
# time ./thread.pl
real 0m0.112s
user 0m0.170s
sys 0m0.020s
# time ./thread.py
real 0m5.071s
user 0m1.770s
sys 0m15.040s
------------
C'est clair il y a un problème... Enfin c'est peut être que je m'y prend
mal pour lancer mes threads. Je n'ai aucun recul sur python ...
Python en SMP est deplorable a cause de ses lock, c'est pas un secret ...
Plone j'ai pas utiliser donc je ne sais pas
Bon, en tout cas, ca viens pas du Kernel apparement
Je lance ça sur mon quadri-pro Redhat AS3. # uname -a Linux blake 2.4.21-9.0.1.ELsmp #1 SMP Mon Feb 9 22:26:51 EST 2004 i686 i686 i386 GNU/Linux
Je ne vois qu'un seul process Perl (contrairement à ce que vous me dire, mais je sais que les noyaux Redhat AS sont bcp patchés par redhat pour améliorer les SMP...)
En fait j'ai finalement fait la même chose (je crois) en Python: ------------------ #!/usr/bin/python import threading class TestThread(threading.Thread): def run(self): while 1: a = 1 t1 = TestThread() t1.start() t2 = TestThread() t2.start() t3 = TestThread() t3.start() t4 = TestThread() t4.start() t1.join() -----------------
Voici ce que ça me donne comme conso: ----------------- CPU states: cpu user nice system irq softirq iowait idle total 37,6% 0,0% 296,0% 0,0% 0,0% 0,0% 66,0% cpu00 9,1% 0,0% 73,4% 0,0% 0,0% 0,0% 17,3% cpu01 9,7% 0,0% 74,8% 0,0% 0,0% 0,0% 15,3% cpu02 8,3% 0,0% 76,0% 0,0% 0,0% 0,0% 15,5% cpu03 10,5% 0,0% 71,6% 0,0% 0,0% 0,0% 17,7% (...) root 21 0 1932 1932 1172 S 328,6 0,0 0:27 2 thread.py -----------------
D'une part il consomme bien tous les CPU (328,6%) mais là ou c'est très étrange c'est que la plupart du CPU est pris par "system" plutôt que par "user". Ca serait le scheduler du kernel qui prendrait tout ce CPU ?
J'ai fait une petite comparaison entre Perl et Python pour les thread. Je lance dans les deux cas 4 threads qui compte jusqu'à 100 000. Voici le résultats du test: ----------- # time ./thread.pl
real 0m0.112s user 0m0.170s sys 0m0.020s
# time ./thread.py
real 0m5.071s user 0m1.770s sys 0m15.040s ------------ C'est clair il y a un problème... Enfin c'est peut être que je m'y prend mal pour lancer mes threads. Je n'ai aucun recul sur python ...
Python en SMP est deplorable a cause de ses lock, c'est pas un secret ...
Plone j'ai pas utiliser donc je ne sais pas
Bon, en tout cas, ca viens pas du Kernel apparement
Encolpe DEGOUTE
Dans fr.comp.lang.python, Cedric Foll écrivit:
Bonjour,
tout d'abord je ne suis pas programmeur python mais admin système/réseaux. Je voudrais mettre en place un serveur Zope et faire tourner Plone dessus. J'ai fait un test sur une Redaht AS 3.0 ça se passe bien avec un zope 2.6.4 et un python 2.2.3. C'est celui par defaut de Redhat 3.0 et qu'il est difficile d'upgrader parce que les outils d'admin de redhat sont écrites en python.
Je ne vais pas plus loin. Il est très déconseillé d'utilisé python 2.2 avec Zope 2.6.4. Soit c'est Zope 2.7 et python 2.3, soit c'est Zope 2.6 avec python 2.1. Je conseille une fedora plutôt que les serveurs professionels RedHat, car les versions de python sont trop anciennes, et les patchs apportés au noyau mettent souvent le python-ldap en rade. De plus, le paquet python 2.3 existe pour fedora core2.
Sinon, nous utilisons ici des debian sarge avec les paquets debian pour zope (2.6.4) et zope2.7 (2.7.2) et cela fonctionne très bien en multiprocesseur. Le seul problème de monté en charge connu est un bug dans la gestion des threads lié à python qui est en train d'être résolu.
-- Encolpe DEGOUTE http://fleurbleue.colpi.info/~encolpe/ Logiciels libres, hockey sur glace et autres activités cérébrales
Dans fr.comp.lang.python, Cedric Foll écrivit:
Bonjour,
tout d'abord je ne suis pas programmeur python mais admin système/réseaux.
Je voudrais mettre en place un serveur Zope et faire tourner Plone dessus.
J'ai fait un test sur une Redaht AS 3.0 ça se passe bien avec un zope
2.6.4 et un python 2.2.3. C'est celui par defaut de Redhat 3.0 et qu'il
est difficile d'upgrader parce que les outils d'admin de redhat sont
écrites en python.
Je ne vais pas plus loin. Il est très déconseillé d'utilisé python 2.2
avec Zope 2.6.4. Soit c'est Zope 2.7 et python 2.3, soit c'est Zope 2.6
avec python 2.1.
Je conseille une fedora plutôt que les serveurs professionels RedHat,
car les versions de python sont trop anciennes, et les patchs apportés
au noyau mettent souvent le python-ldap en rade.
De plus, le paquet python 2.3 existe pour fedora core2.
Sinon, nous utilisons ici des debian sarge avec les paquets debian pour
zope (2.6.4) et zope2.7 (2.7.2) et cela fonctionne très bien en
multiprocesseur. Le seul problème de monté en charge connu est un bug
dans la gestion des threads lié à python qui est en train d'être résolu.
--
Encolpe DEGOUTE
http://fleurbleue.colpi.info/~encolpe/
Logiciels libres, hockey sur glace et autres activités cérébrales
tout d'abord je ne suis pas programmeur python mais admin système/réseaux. Je voudrais mettre en place un serveur Zope et faire tourner Plone dessus. J'ai fait un test sur une Redaht AS 3.0 ça se passe bien avec un zope 2.6.4 et un python 2.2.3. C'est celui par defaut de Redhat 3.0 et qu'il est difficile d'upgrader parce que les outils d'admin de redhat sont écrites en python.
Je ne vais pas plus loin. Il est très déconseillé d'utilisé python 2.2 avec Zope 2.6.4. Soit c'est Zope 2.7 et python 2.3, soit c'est Zope 2.6 avec python 2.1. Je conseille une fedora plutôt que les serveurs professionels RedHat, car les versions de python sont trop anciennes, et les patchs apportés au noyau mettent souvent le python-ldap en rade. De plus, le paquet python 2.3 existe pour fedora core2.
Sinon, nous utilisons ici des debian sarge avec les paquets debian pour zope (2.6.4) et zope2.7 (2.7.2) et cela fonctionne très bien en multiprocesseur. Le seul problème de monté en charge connu est un bug dans la gestion des threads lié à python qui est en train d'être résolu.
-- Encolpe DEGOUTE http://fleurbleue.colpi.info/~encolpe/ Logiciels libres, hockey sur glace et autres activités cérébrales
Gilles Lenfant
"Cedric Foll" a écrit dans le message de news:cj8p9q$abe$
Gilles Lenfant wrote:
"Cedric Foll" a écrit dans le message de news:
Bonjour,
[...]
Quelles sont les solutions simples pour utiliser toutes les ressources CPU. Le problème vient il du fait que g un vieux python et un vieux zope sur ma machine ?
Le problème vient du fait que Python ne sait pas (encore) tirer parti d'une
architecture multiproc.
Python ne connait pas la commande fork ??? ;-)
Si, mais ce n'est pas le mode de fonctionnement de Zope qui utilise les threads Python qui sont des threads Posix. On ne peut pas remplacer des threads par des forks et espérer que ça fonctionne comme après un coup de baguette magique :o)
-- Gilles
"Cedric Foll" <cedric.foll@ac-rouen.fr> a écrit dans le message de
news:cj8p9q$abe$1@news.crihan.fr...
Gilles Lenfant wrote:
"Cedric Foll" <cedric.foll@ac-rouen.fr> a écrit dans le message de
news:415416DD.5000009@ac-rouen.fr...
Bonjour,
[...]
Quelles sont les solutions simples pour utiliser toutes les ressources
CPU. Le problème vient il du fait que g un vieux python et un vieux zope
sur ma machine ?
Le problème vient du fait que Python ne sait pas (encore) tirer parti
d'une
architecture multiproc.
Python ne connait pas la commande fork ??? ;-)
Si, mais ce n'est pas le mode de fonctionnement de Zope qui utilise les
threads Python qui sont des threads Posix.
On ne peut pas remplacer des threads par des forks et espérer que ça
fonctionne comme après un coup de baguette magique :o)
"Cedric Foll" a écrit dans le message de news:cj8p9q$abe$
Gilles Lenfant wrote:
"Cedric Foll" a écrit dans le message de news:
Bonjour,
[...]
Quelles sont les solutions simples pour utiliser toutes les ressources CPU. Le problème vient il du fait que g un vieux python et un vieux zope sur ma machine ?
Le problème vient du fait que Python ne sait pas (encore) tirer parti d'une
architecture multiproc.
Python ne connait pas la commande fork ??? ;-)
Si, mais ce n'est pas le mode de fonctionnement de Zope qui utilise les threads Python qui sont des threads Posix. On ne peut pas remplacer des threads par des forks et espérer que ça fonctionne comme après un coup de baguette magique :o)