Recherche une solution d'execution sur des multi-processeurs
9 réponses
Denis Valdenaire
Bonjour,
Je recherche quelque chose d'un peu particulier. Je dispose (par
exemple) de machines =E0 4 ou 8 processeurs. J'ai besoin de gzipper 50
fichiers. Gzip n'=E9tant pas (=E0 ma connaissance) multithread (mais
m=EAme s'il l'=E9tait, ce n'est qu'un exemple, je dis gzipper comme
j'aurais dit parser avec awk) je me retrouve =E0 faire une boucle shell
du genre :
for FILE in `ls *.log`; do gzip -v $FILE; done
et du coup un seul des 4 ou 8 processeurs fonctionne...
Donc, ma question : connaissez vous un utilitaire ou une m=E9thode
simple pour dire "faire tel lot de t=E2ches en parral=E8lle, avec X
t=E2ches simultan=E9es" ? Je pourrais faire une boucle plus =E9labor=E9e,
mais je pense qu'il doit exister des solutions pour ce genre de
choses... Je pense =E0 quelque chose qui ne soit pas au niveau du noyau,
bien sur.
L'id=E9al, c'est que =E7a fonctionne sur plusieurs unix, bien sur :)
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
Dam
En Perl avec Parallel::Simple peut-être?
Bonjour,
Je recherche quelque chose d'un peu particulier. Je dispose (par exemple) de machines à 4 ou 8 processeurs. J'ai besoin de gzipper 50 fichiers. Gzip n'étant pas (à ma connaissance) multithread (mais même s'il l'était, ce n'est qu'un exemple, je dis gzipper comme j'aurais dit parser avec awk) je me retrouve à faire une boucle shell du genre :
for FILE in `ls *.log`; do gzip -v $FILE; done
et du coup un seul des 4 ou 8 processeurs fonctionne...
Donc, ma question : connaissez vous un utilitaire ou une méthode simple pour dire "faire tel lot de tâches en parralèlle, avec X tâches simultanées" ? Je pourrais faire une boucle plus élaborée, mais je pense qu'il doit exister des solutions pour ce genre de choses... Je pense à quelque chose qui ne soit pas au niveau du noyau, bien sur.
L'idéal, c'est que ça fonctionne sur plusieurs unix, bien sur :)
Merci d'avance !
Denis Valdenaire
En Perl avec Parallel::Simple peut-être?
Bonjour,
Je recherche quelque chose d'un peu particulier. Je dispose (par
exemple) de machines à 4 ou 8 processeurs. J'ai besoin de gzipper 50
fichiers. Gzip n'étant pas (à ma connaissance) multithread (mais
même s'il l'était, ce n'est qu'un exemple, je dis gzipper comme
j'aurais dit parser avec awk) je me retrouve à faire une boucle shell
du genre :
for FILE in `ls *.log`; do gzip -v $FILE; done
et du coup un seul des 4 ou 8 processeurs fonctionne...
Donc, ma question : connaissez vous un utilitaire ou une méthode
simple pour dire "faire tel lot de tâches en parralèlle, avec X
tâches simultanées" ? Je pourrais faire une boucle plus élaborée,
mais je pense qu'il doit exister des solutions pour ce genre de
choses... Je pense à quelque chose qui ne soit pas au niveau du noyau,
bien sur.
L'idéal, c'est que ça fonctionne sur plusieurs unix, bien sur :)
Je recherche quelque chose d'un peu particulier. Je dispose (par exemple) de machines à 4 ou 8 processeurs. J'ai besoin de gzipper 50 fichiers. Gzip n'étant pas (à ma connaissance) multithread (mais même s'il l'était, ce n'est qu'un exemple, je dis gzipper comme j'aurais dit parser avec awk) je me retrouve à faire une boucle shell du genre :
for FILE in `ls *.log`; do gzip -v $FILE; done
et du coup un seul des 4 ou 8 processeurs fonctionne...
Donc, ma question : connaissez vous un utilitaire ou une méthode simple pour dire "faire tel lot de tâches en parralèlle, avec X tâches simultanées" ? Je pourrais faire une boucle plus élaborée, mais je pense qu'il doit exister des solutions pour ce genre de choses... Je pense à quelque chose qui ne soit pas au niveau du noyau, bien sur.
L'idéal, c'est que ça fonctionne sur plusieurs unix, bien sur :)
Merci d'avance !
Denis Valdenaire
Nicolas George
"Denis Valdenaire" wrote in message :
Donc, ma question : connaissez vous un utilitaire ou une méthode simple pour dire "faire tel lot de tâches en parralèlle, avec X tâches simultanées" ?
Peut-être make -j 2 dans un cas aussi simple.
"Denis Valdenaire" wrote in message
<1153379458.676213.80870@m73g2000cwd.googlegroups.com>:
Donc, ma question : connaissez vous un utilitaire ou une méthode
simple pour dire "faire tel lot de tâches en parralèlle, avec X
tâches simultanées" ?
Donc, ma question : connaissez vous un utilitaire ou une méthode simple pour dire "faire tel lot de tâches en parralèlle, avec X tâches simultanées" ?
Peut-être make -j 2 dans un cas aussi simple.
Pascal Bourguignon
"Denis Valdenaire" writes:
Bonjour,
Je recherche quelque chose d'un peu particulier. Je dispose (par exemple) de machines à 4 ou 8 processeurs. J'ai besoin de gzipper 50 fichiers. Gzip n'étant pas (à ma connaissance) multithread (mais même s'il l'était, ce n'est qu'un exemple, je dis gzipper comme j'aurais dit parser avec awk) je me retrouve à faire une boucle shell du genre :
for FILE in `ls *.log`; do gzip -v $FILE; done
et du coup un seul des 4 ou 8 processeurs fonctionne...
Donc, ma question : connaissez vous un utilitaire ou une méthode simple pour dire "faire tel lot de tâches en parralèlle, avec X tâches simultanées" ? Je pourrais faire une boucle plus élaborée, mais je pense qu'il doit exister des solutions pour ce genre de choses... Je pense à quelque chose qui ne soit pas au niveau du noyau, bien sur.
L'idéal, c'est que ça fonctionne sur plusieurs unix, bien sur :)
np=4 i=$np for file in *.log ; do gzip -v "$file" & i=$(( $i - 1 )) if [ $i -eq 0 ] ; then wait ; i=$(( $i + 1 )) ; fi done
Ou:
np=4 files=( "*.log" ) i=0 while [ $i -lt ${#files} -a $i -lt $np ] ; do gzip -v "${files[$i]}" & i=$(( $i + 1 )) ; done while [ $i -lt ${#files} ] ; do wait gzip -v "${files[$i]}" & i=$(( $i + 1 )) ; done
Une solution simple est d'utiliser batch:
for file in *.log ; do echo "gzip -v "$file"" | batch ; done
Comme batch lance les processus tant que la charge du système est en dessous de 0.8, ça devrait fonctionner. (S'il y a déjà 2 processus par processeur, ce n'est pas la peine de faire travailler les gzip en parallèle...) Mais on n'est pas informé de la completion de tous les jobs, seulement de chacun des jobs, si on met l'option -m.
-- __Pascal Bourguignon__ http://www.informatimago.com/ Litter box not here. You must have moved it again. I'll poop in the sink.
Je recherche quelque chose d'un peu particulier. Je dispose (par
exemple) de machines à 4 ou 8 processeurs. J'ai besoin de gzipper 50
fichiers. Gzip n'étant pas (à ma connaissance) multithread (mais
même s'il l'était, ce n'est qu'un exemple, je dis gzipper comme
j'aurais dit parser avec awk) je me retrouve à faire une boucle shell
du genre :
for FILE in `ls *.log`; do gzip -v $FILE; done
et du coup un seul des 4 ou 8 processeurs fonctionne...
Donc, ma question : connaissez vous un utilitaire ou une méthode
simple pour dire "faire tel lot de tâches en parralèlle, avec X
tâches simultanées" ? Je pourrais faire une boucle plus élaborée,
mais je pense qu'il doit exister des solutions pour ce genre de
choses... Je pense à quelque chose qui ne soit pas au niveau du noyau,
bien sur.
L'idéal, c'est que ça fonctionne sur plusieurs unix, bien sur :)
np=4
i=$np
for file in *.log ; do
gzip -v "$file" &
i=$(( $i - 1 ))
if [ $i -eq 0 ] ; then wait ; i=$(( $i + 1 )) ; fi
done
Ou:
np=4
files=( "*.log" )
i=0
while [ $i -lt ${#files} -a $i -lt $np ] ; do
gzip -v "${files[$i]}" & i=$(( $i + 1 )) ; done
while [ $i -lt ${#files} ] ; do
wait
gzip -v "${files[$i]}" & i=$(( $i + 1 )) ; done
Une solution simple est d'utiliser batch:
for file in *.log ; do echo "gzip -v "$file"" | batch ; done
Comme batch lance les processus tant que la charge du système est en
dessous de 0.8, ça devrait fonctionner. (S'il y a déjà 2 processus
par processeur, ce n'est pas la peine de faire travailler les gzip en
parallèle...) Mais on n'est pas informé de la completion de tous les
jobs, seulement de chacun des jobs, si on met l'option -m.
--
__Pascal Bourguignon__ http://www.informatimago.com/
Litter box not here.
You must have moved it again.
I'll poop in the sink.
Je recherche quelque chose d'un peu particulier. Je dispose (par exemple) de machines à 4 ou 8 processeurs. J'ai besoin de gzipper 50 fichiers. Gzip n'étant pas (à ma connaissance) multithread (mais même s'il l'était, ce n'est qu'un exemple, je dis gzipper comme j'aurais dit parser avec awk) je me retrouve à faire une boucle shell du genre :
for FILE in `ls *.log`; do gzip -v $FILE; done
et du coup un seul des 4 ou 8 processeurs fonctionne...
Donc, ma question : connaissez vous un utilitaire ou une méthode simple pour dire "faire tel lot de tâches en parralèlle, avec X tâches simultanées" ? Je pourrais faire une boucle plus élaborée, mais je pense qu'il doit exister des solutions pour ce genre de choses... Je pense à quelque chose qui ne soit pas au niveau du noyau, bien sur.
L'idéal, c'est que ça fonctionne sur plusieurs unix, bien sur :)
np=4 i=$np for file in *.log ; do gzip -v "$file" & i=$(( $i - 1 )) if [ $i -eq 0 ] ; then wait ; i=$(( $i + 1 )) ; fi done
Ou:
np=4 files=( "*.log" ) i=0 while [ $i -lt ${#files} -a $i -lt $np ] ; do gzip -v "${files[$i]}" & i=$(( $i + 1 )) ; done while [ $i -lt ${#files} ] ; do wait gzip -v "${files[$i]}" & i=$(( $i + 1 )) ; done
Une solution simple est d'utiliser batch:
for file in *.log ; do echo "gzip -v "$file"" | batch ; done
Comme batch lance les processus tant que la charge du système est en dessous de 0.8, ça devrait fonctionner. (S'il y a déjà 2 processus par processeur, ce n'est pas la peine de faire travailler les gzip en parallèle...) Mais on n'est pas informé de la completion de tous les jobs, seulement de chacun des jobs, si on met l'option -m.
-- __Pascal Bourguignon__ http://www.informatimago.com/ Litter box not here. You must have moved it again. I'll poop in the sink.
Denis Valdenaire
Juste pour info, la solution Perl, j'ai jeté un coup d'oeil, il y a effectivement des trucs interessants de ce côté, par exemple Parallel::Jobs; cela dit ça implique de programmer : j'ai rien contre mais c'est pas mon objectif en ce moment...
Par contre la solution batch me convient tout à fait !
Merci de votre aide
Denis Valdenaire
Juste pour info, la solution Perl, j'ai jeté un coup d'oeil, il y a
effectivement des trucs interessants de ce côté, par exemple
Parallel::Jobs; cela dit ça implique de programmer : j'ai rien contre
mais c'est pas mon objectif en ce moment...
Par contre la solution batch me convient tout à fait !
Juste pour info, la solution Perl, j'ai jeté un coup d'oeil, il y a effectivement des trucs interessants de ce côté, par exemple Parallel::Jobs; cela dit ça implique de programmer : j'ai rien contre mais c'est pas mon objectif en ce moment...
Par contre la solution batch me convient tout à fait !
Merci de votre aide
Denis Valdenaire
Dam
Re rien... ravi que batch te satisfasse...
Juste pour info, la solution Perl, j'ai jeté un coup d'oeil, il y a effectivement des trucs interessants de ce côté, par exemple Parallel::Jobs; cela dit ça implique de programmer : j'ai rien contre mais c'est pas mon objectif en ce moment...
Par contre la solution batch me convient tout à fait !
Merci de votre aide
Denis Valdenaire
Re rien... ravi que batch te satisfasse...
Juste pour info, la solution Perl, j'ai jeté un coup d'oeil, il y a
effectivement des trucs interessants de ce côté, par exemple
Parallel::Jobs; cela dit ça implique de programmer : j'ai rien contre
mais c'est pas mon objectif en ce moment...
Par contre la solution batch me convient tout à fait !
Juste pour info, la solution Perl, j'ai jeté un coup d'oeil, il y a effectivement des trucs interessants de ce côté, par exemple Parallel::Jobs; cela dit ça implique de programmer : j'ai rien contre mais c'est pas mon objectif en ce moment...
Par contre la solution batch me convient tout à fait !
Merci de votre aide
Denis Valdenaire
fabrice-pas-despame.bacchella
On Thu, 20 Jul 2006 14:22:24 +0200, Pascal Bourguignon wrote:
Comme batch lance les processus tant que la charge du système est en dessous de 0.8, ça devrait fonctionner. (S'il y a déjà 2 processus par processeur, ce n'est pas la peine de faire travailler les gzip en parallèle...) Mais on n'est pas informé de la completion de tous les jobs, seulement de chacun des jobs, si on met l'option -m.
Batch travaille sur la file d'attende CPU (load). Pour des processus consommateurs d'IO, il risque de tous les lancer, sans se rendre compe que le disque dur est complétement saturé.
Comme batch lance les processus tant que la charge du système est en
dessous de 0.8, ça devrait fonctionner. (S'il y a déjà 2 processus
par processeur, ce n'est pas la peine de faire travailler les gzip en
parallèle...) Mais on n'est pas informé de la completion de tous les
jobs, seulement de chacun des jobs, si on met l'option -m.
Batch travaille sur la file d'attende CPU (load). Pour des processus
consommateurs d'IO, il risque de tous les lancer, sans se rendre compe
que le disque dur est complétement saturé.
On Thu, 20 Jul 2006 14:22:24 +0200, Pascal Bourguignon wrote:
Comme batch lance les processus tant que la charge du système est en dessous de 0.8, ça devrait fonctionner. (S'il y a déjà 2 processus par processeur, ce n'est pas la peine de faire travailler les gzip en parallèle...) Mais on n'est pas informé de la completion de tous les jobs, seulement de chacun des jobs, si on met l'option -m.
Batch travaille sur la file d'attende CPU (load). Pour des processus consommateurs d'IO, il risque de tous les lancer, sans se rendre compe que le disque dur est complétement saturé.
Pascal Bourguignon
writes:
On Thu, 20 Jul 2006 14:22:24 +0200, Pascal Bourguignon wrote:
Comme batch lance les processus tant que la charge du système est en dessous de 0.8, ça devrait fonctionner. (S'il y a déjà 2 processus par processeur, ce n'est pas la peine de faire travailler les gzip en parallèle...) Mais on n'est pas informé de la completion de tous les jobs, seulement de chacun des jobs, si on met l'option -m.
Batch travaille sur la file d'attende CPU (load). Pour des processus consommateurs d'IO, il risque de tous les lancer, sans se rendre compe que le disque dur est complétement saturé.
Quand le disque dur est occupé, les autres processus en attente d'I/O sont dans l'état D qui est un sous état de R, et la charge du processeur monte.
Comme batch lance les processus tant que la charge du système est en
dessous de 0.8, ça devrait fonctionner. (S'il y a déjà 2 processus
par processeur, ce n'est pas la peine de faire travailler les gzip en
parallèle...) Mais on n'est pas informé de la completion de tous les
jobs, seulement de chacun des jobs, si on met l'option -m.
Batch travaille sur la file d'attende CPU (load). Pour des processus
consommateurs d'IO, il risque de tous les lancer, sans se rendre compe
que le disque dur est complétement saturé.
Quand le disque dur est occupé, les autres processus en attente d'I/O
sont dans l'état D qui est un sous état de R, et la charge du
processeur monte.
On Thu, 20 Jul 2006 14:22:24 +0200, Pascal Bourguignon wrote:
Comme batch lance les processus tant que la charge du système est en dessous de 0.8, ça devrait fonctionner. (S'il y a déjà 2 processus par processeur, ce n'est pas la peine de faire travailler les gzip en parallèle...) Mais on n'est pas informé de la completion de tous les jobs, seulement de chacun des jobs, si on met l'option -m.
Batch travaille sur la file d'attende CPU (load). Pour des processus consommateurs d'IO, il risque de tous les lancer, sans se rendre compe que le disque dur est complétement saturé.
Quand le disque dur est occupé, les autres processus en attente d'I/O sont dans l'état D qui est un sous état de R, et la charge du processeur monte.
On Sun, 30 Jul 2006 20:45:05 +0200, Pascal Bourguignon wrote:
Quand le disque dur est occupé, les autres processus en attente d'I/O sont dans l'état D qui est un sous état de R, et la charge du processeur monte.
Vous êtes sur ? Sur linux : D = uninterruptible sleep R = running or runnable S = Interruptible sleep (waiting for an event to complete)
Solaris ne connait pas l'état D, il y a : O Sleeping: process is waiting for an event to complete R Runnable: process is on run queue.
Tout ça c'est pas des sous états, mais des états distinct. Et man getloadavg parle bien de la run queue, ce que j'interprète comme étant l'état R. Un read, tout comme select sont en mesure de rendre EINTR, donc de toute façon on parle de O ou de S, pas de D.
Quand le disque dur est occupé, les autres processus en attente d'I/O
sont dans l'état D qui est un sous état de R, et la charge du
processeur monte.
Vous êtes sur ?
Sur linux :
D = uninterruptible sleep
R = running or runnable
S = Interruptible sleep (waiting for an event to complete)
Solaris ne connait pas l'état D, il y a :
O Sleeping: process is waiting for an event to complete
R Runnable: process is on run queue.
Tout ça c'est pas des sous états, mais des états distinct. Et man
getloadavg parle bien de la run queue, ce que j'interprète comme étant
l'état R. Un read, tout comme select sont en mesure de rendre EINTR,
donc de toute façon on parle de O ou de S, pas de D.
On Sun, 30 Jul 2006 20:45:05 +0200, Pascal Bourguignon wrote:
Quand le disque dur est occupé, les autres processus en attente d'I/O sont dans l'état D qui est un sous état de R, et la charge du processeur monte.
Vous êtes sur ? Sur linux : D = uninterruptible sleep R = running or runnable S = Interruptible sleep (waiting for an event to complete)
Solaris ne connait pas l'état D, il y a : O Sleeping: process is waiting for an event to complete R Runnable: process is on run queue.
Tout ça c'est pas des sous états, mais des états distinct. Et man getloadavg parle bien de la run queue, ce que j'interprète comme étant l'état R. Un read, tout comme select sont en mesure de rendre EINTR, donc de toute façon on parle de O ou de S, pas de D.
Pascal Bourguignon
writes:
On Sun, 30 Jul 2006 20:45:05 +0200, Pascal Bourguignon wrote:
Quand le disque dur est occupé, les autres processus en attente d'I/O sont dans l'état D qui est un sous état de R, et la charge du processeur monte.
Vous êtes sur ? Sur linux : D = uninterruptible sleep R = running or runnable S = Interruptible sleep (waiting for an event to complete)
C'est le comportement que j'observe sur Linux, quand il y a beaucoup de process attendant sur le disque dur, ils se retrouvent en D, et comptent dans le load average.
Solaris ne connait pas l'état D, il y a : O Sleeping: process is waiting for an event to complete R Runnable: process is on run queue.
Tout ça c'est pas des sous états, mais des états distinct. Et man getloadavg parle bien de la run queue, ce que j'interprète comme étant l'état R. Un read, tout comme select sont en mesure de rendre EINTR, donc de toute façon on parle de O ou de S, pas de D.
ADVISORY: There is an extremely small but nonzero chance that, through a process known as "tunneling," this product may spontaneously disappear from its present location and reappear at any random place in the universe, including your neighbor's domicile. The manufacturer will not be responsible for any damages or inconveniences that may result.
Quand le disque dur est occupé, les autres processus en attente d'I/O
sont dans l'état D qui est un sous état de R, et la charge du
processeur monte.
Vous êtes sur ?
Sur linux :
D = uninterruptible sleep
R = running or runnable
S = Interruptible sleep (waiting for an event to complete)
C'est le comportement que j'observe sur Linux, quand il y a beaucoup
de process attendant sur le disque dur, ils se retrouvent en D, et
comptent dans le load average.
Solaris ne connait pas l'état D, il y a :
O Sleeping: process is waiting for an event to complete
R Runnable: process is on run queue.
Tout ça c'est pas des sous états, mais des états distinct. Et man
getloadavg parle bien de la run queue, ce que j'interprète comme étant
l'état R. Un read, tout comme select sont en mesure de rendre EINTR,
donc de toute façon on parle de O ou de S, pas de D.
ADVISORY: There is an extremely small but nonzero chance that,
through a process known as "tunneling," this product may
spontaneously disappear from its present location and reappear at
any random place in the universe, including your neighbor's
domicile. The manufacturer will not be responsible for any damages
or inconveniences that may result.
On Sun, 30 Jul 2006 20:45:05 +0200, Pascal Bourguignon wrote:
Quand le disque dur est occupé, les autres processus en attente d'I/O sont dans l'état D qui est un sous état de R, et la charge du processeur monte.
Vous êtes sur ? Sur linux : D = uninterruptible sleep R = running or runnable S = Interruptible sleep (waiting for an event to complete)
C'est le comportement que j'observe sur Linux, quand il y a beaucoup de process attendant sur le disque dur, ils se retrouvent en D, et comptent dans le load average.
Solaris ne connait pas l'état D, il y a : O Sleeping: process is waiting for an event to complete R Runnable: process is on run queue.
Tout ça c'est pas des sous états, mais des états distinct. Et man getloadavg parle bien de la run queue, ce que j'interprète comme étant l'état R. Un read, tout comme select sont en mesure de rendre EINTR, donc de toute façon on parle de O ou de S, pas de D.
ADVISORY: There is an extremely small but nonzero chance that, through a process known as "tunneling," this product may spontaneously disappear from its present location and reappear at any random place in the universe, including your neighbor's domicile. The manufacturer will not be responsible for any damages or inconveniences that may result.
